Ce 27 mars 2012 a eu lieu le Scrum Day 2012, l’évènement annuel organisé par le French Scrum User Group. L’événement se déroulait à la salle CAP15, et la salle était comble : 500 personnes ! Un record d’affluence, plus une seule place de disponible.

Etant Scrum Master au sein de ma société (GFI Informatique), j’ai eu la chance de pouvoir participer à la grande messe Scrum annuelle qu’est le ScrumDay ! Mon billet en poche, je m’en allais découvrir avec un autre collègue Scrum Master (http://twitter.com/guillaumew) cet événement.

Nous avions déjà participé à la ScrumNight fin décembre 2011 et avions beaucoup apprécié l’ambiance qui règne au sein du FSUG. Nous sommes d’ailleurs maintenant membre du FSUG depuis cette fameuse nuit Scrum.

Mais venons en aux faits :

Petite introduction du ScrumDay 2012

(Reprise sur le site officiel du scrumday, car j’ai pas trouvé mieux à dire ! )

Comme je le disais, ce 27 mars a eu lieu le Scrum Day 2012, l’évènement annuel organisé par le French Scrum User Group.

L’association se donne pour ambition de faire du Scrum Day un rendez-vous incontournable pour tous les acteurs de l’Agilité. Il s’agit d’un rassemblement majeur pour la communauté SCRUM : il permet de réunir sur une journée un grand nombre de membres, ainsi que les personnes impliquées dans l’Agilité en général.

L’objectif de cet évènement est triple :

• Rassembler en un même lieu pendant un jour, des personnes qui découvrent l’Agilité, mais aussi celles qui souhaitent progresser, ainsi que des spécialistes;
• Diffuser les bonnes pratiques et les dernières techniques reconnues par les experts;
• Favoriser les rencontres professionnelles et les échanges inter-entreprises.
• Résolument interactif, l’événement revêt différents formats, comme des keynotes, des conférences, des ateliers, des open spaces et des retours d’expériences, au cours desquels les participants apprendront et échangeront dans une ambiance conviviale.

Mon retour et mes impressions sur les présentations

Je vais vous parler ici des présentations auxquelles j’ai pu assister durant cette journée.

Gamestorming

NB: L’ensemble des dessins de la présentation ont étés réalisés par lui-même ! Belle performance

Dans la peau du manager Agile

Très bonne présentation de Jean Claude Grosjean, Coach agile pluridisciplinaire dans un temps très court : 30 minutes de présentation/questions.

Il a fait le tour des valeurs que l’on demande aujourd’hui à un middle manager qui doit composer avec ses équipes agile et son top management.

Mention spéciale à son ROTI (Return on time invested) qui est une méthode qui permet d’obtenir du feedback rapide sur le meeting qui vient de se dérouler via un vote à 5 doigts.

Vivement la mise en ligne de sa présentation que je puisse me remémorer les 4 valeurs indispensables au « management 3.0″ ou comme le dis Jean-Claude au Management Lean et Agile !

Je reste néanmoins déçu car je souhaitais le rencontrer, chose que je n’ai pu faire cette fois-ci mais comme échangé sur Twitter, ce n’est que partie remise.

De V vers l’Agile

Scrum Master Academy

Ma rétrospective sur le ScrumDay 2012

2. Ce qui a moins bien marché

• Trop de monde pour le jeu Agile « Joli Tableau », empêchant certains de pratiquer avec Alexandre Boutin son serious game.
• Pas d’alternative à la dernière présentation (je l’avais déjà vue à la ScrumNight), cela dit en passant, le leadership des talents était une de mes présentations préférée…
• Aucune présentation n’a abordé la contractualisation au forfait, c’est dommage car c’est un point beaucoup abordé par les visiteurs de ce ScrumDay lors des sessions de networkings.
• Je n’ai pas eu le temps de discuter avec la moitié des gens que je voulais voir, et notamment Jean-Claude .

3. Les axes d’améliorations

• Augmenter encore la capacité de chaque salle ? Je n’ai pu participer à Joli tableau, faute de place car je suis resté discuter avec Guillaume Saint-Etienne sur le TDD et BDD !
• Un « libraire » était présent, cependant apporter encore plus de choix autour de l’agilité serait un bon point, même si c’était déjà bien fourni.
• Plus de l’ordre personnel, et pour mes collègues au sein de GFI, devenir orateur à un ou plusieurs évènements Agiles sur une pratique (pourquoi ne pas pousser l’intégration continue si chère à nos « Scrum Masters »), une méthode (Scrum, XP, Kanban,…), la phase de tests (le TDD, ATDD et BDD : notre stratégie de tests)

—

Voilà, c’est tout pour ma rétrospective sur le Scrum Day 2012. N’hésitez pas à laisser vos impressions ci-dessous ou à me poser vos questions sur l’évènement. Je reviendrais assez vite sur le blog pour vous faire un petit récapitulatif de l’ensemble des présentations ainsi que des ressources disponibles sur Internet pour que vous puissiez les voir ou les revoir à travers les slides et les vidéos prises durant cette journée.

A bientôt sur le blog ou sur twitter (@_adesousa) !

Pour cela, rien de plus simple puisque Symfony2 prévoit une interaction avec un outil de test très utilisé par les développeurs PHP: PHPUnit. Et concernant les tests d’acceptation, je vous en ai déjà parlé dans un précédent article, je compte utiliser Behat qui s’intègre très facilement à Symfony2.

Je réalise l’ensemble de mes projets de développement sous Linux Mint 12 (Lisa). Je décide donc d’installer PHPUnit via apt en lancant la commande que tout le monde connait sous système Debian:

Commandes d’installation via apt

apt-get install phpunit

Seulement voilà, les repos Mint propose via apt l’installation d’une version antérieure à la version demandée par Symfony2. Je commence donc à chercher un peu partout sur le net des solutions et là autant vous dire que ce fut une authentique traversée du désert… En-effet, en cherchant je trouve énormément de ressources sur le sujet mais aucune ne parvient à résoudre mon problème.

Et pourtant, comment n’ais-je pu y penser avant ?!! PHPUnit est porté par Sebastian Bergmann. Comme tout projet open source qui se respecte, un site dédié existe : http://www.phpunit.de/manual/current/en/index.html.
Et là miracle, une explication claire, limpide, expliquant une méthode universelle permettant d’installer la dernière version en date de PHPUnit via PEAR !!

Alors, pour tous mes amis francophones, qui chercheraient pendant des mois, des jours, des heures, bon ok soyons réalistes pendant quelques minutes sur Internet comment faire cette fameuse installation voici le Saint Graal :

Commandes d’installation via PEAR

sudo pear upgrade PEAR
pear config-set auto_discover 1
pear install pear.phpunit.de/PHPUnit

Je vous entends déjà de l’autre côté de votre écran vous dire : « Comment ?! C’est tout ? Il n’y a que ces trois commandes à passer pour installer phpunit en dernière version? » Ce à quoi je vous répondrais : OUI

Néanmoins si ce n’est pas suffisant, je vous invite à aller lire la doc de PHPUnit ici ; http://www.phpunit.de/manual/3.6/en/installation.html pour obtenir plus d’informations sur son installation.

Me voilà donc paré à piloter le développement de mon application par les tests ainsi que les tests d’acceptation via BeHat!

Bon courage à tous ceux qui  débutent le TDD, sachez qu’une fois ce cap passé, vous commencerez à produire un code de meilleure qualité, et vous vous intégrerez très facilement dans une équipe agile Scrum-XP entre autres bénéfices.

Ayant maintenant changé de bord depuis quelques temps (seulement au niveau du développement hein!), le ScrumMaster que je suis maintenant, applique systématiquement à chaque nouveau projet une méthodologie Scrum couplé à des pratiques XP ce qui inclut donc du TDD pour plus de qualité et de maintenabilité du code…

Aujourd’hui, je cherchais un peu de doc sur les tests d’acceptation que doivent écrire nos chers Product Owners pour chaque User Story et notamment le formalisme que doit prendre chaque test écrit par les Product Owners avant de les coder réellement.

C’est ce qu’on appelle une approche ATDD (acceptance tests driven development).

Je savais, de plus, que Claude Aubry préconisait un template d’écriture pour les Product Owners qui a fait ses preuves dans divers projets et qui est, si j’ai bien compris, dérivé d’un logiciel appelé Cucumber :

Etant donné la tâche Analyser dans le projet P, tâche qui est déjà prise, et le rôle Analyste joué par le participant Paulo sur P,
Quand Paulo prend la tâche Analyser…,
Alors la tâche Analyser ne lui est pas associée et un message lui explique qu’il ne peut pas prendre une tâche déjà prise.

(http://www.aubryconseil.com/post/2007/05/23/231-formaliser-les-criteres-d-acceptation)

En cherchant un peu je découvre que cette notation s’appelle le Gherkin et que cette approche se nomme le BDD (behavior driven development)

Maintenant, voici le plus intéressant, je savais que des outils étaient capables de transformer les tests écrit en Gherkin en langage python, ruby et autres langages tels que du PHP aussi, notamment à travers des outils appelé RobotFramework de façon générique, et Cucumber pour le Ruby par exemple (si vous arrivez à me suivre, vous vous dites normal, puisqu’on a dis plus haut que cette notation venait de ce logiciel ).

Ce que je ne savais alors pas c’est qu’il existe un nouvel outil dédié au BDD en PHP et qui s’appelle BeHat (http://behat.org/). Alors me direz-vous quel intérêt s’il en existe déjà d’autres tels que RobotFramework ? Eh bien c’est simple :

Behat est inspiré du projet Cucumber et notamment concernant le Gherkin. Il fonctionne comme Cucumber avec des fichiers d’entrée et des données de sorties sur la console, sauf que son core est développé en pure php sous framework Symfony2 ! Autant dire que pour tous les projets sous Symfony2 l’intégration est parfaite à travers un bundle existant et même sur Symfony 1.4, ils ont crée un plugin pour pouvoir l’utiliser.

Je vais effectuer quelques tests avec cet outil, et s’il est simple d’utilisation et ne comporte pas de difficultés d’écriture comme sous RobotFramework, je vais sans doute commencer à l’utiliser dans mes futurs projets et à le recommander dans les propales que j’écris !

Je vous tiens au courant, mais si vous avez déjà touché à cet outil, n’hésitez pas à m’en informer en commentaire. Tout les retours d’expérience sont bons à prendre.

A bientôt sur coffee-meeting !

Je n’est pas l’habitude de traiter de sujets technique, quoique j’en fasse beaucoup néamoins, mais comme je suis en ce moment Scrum Master sur un projet PHP avec Drupal, je souhaitais vous parlez de la mise en place des tests automatisés dans Drupal.

En-effet, Drupal 7 facilite grandement la mise en place de tests automatisés et d’une plateforme d’intégration continue.

Comment se déroulent les tests dans Drupal ?

Drupal depuis sa version 7 contient en natif un framework de tests pour le PHP. Ce framework est un outil qui facilite l’intégration continue via l’implémentation du concept d’automatisation de tests.

L’automatisation des tests, pour quoi faire ?

Si on automatise les tests grâce à une plateforme d’intégration continue et un framework de tests par exemple, on va pouvoir obtenir :

-          Un développement simplifié

-          Une simplification de la refactorisation du code

-          Une réduction importante du débogage.

-          Moins d’erreurs dans le code

-          Une réduction des bugs de régression

Le framework de tests intégré à Drupal : SimpleTest

SimpleTest est leframework choisi par Drupal pour réaliser des tests. Il est open source et la base c’est un projet à part entière utilisable dans n’importe quel autre projet PHP à l’instar de PHPUnit par exemple.

Il permet donc de réaliser des tests unitaires mais également des tests fonctionnels de l’application et notamment de l’interface.

Sa puissance et son avantage réside dans le fait qu’il est mis à disposition avec une batterie de tests du cœur de Drupal que vous pouvez relancer tous les jours, si vous l’intégrez notamment à un environnement  d’intégration continue.

Cela permet de tester l’ensemble de l’application et de vérifier que les développements ajoutés à la plateforme ne créent pas des régressions au sein du cœur de Drupal.

Et sans plateforme d’intégration continue ?

Si vous ne possédez pas de plateforme d’intégration continue, Drupal dispose d’une interface d’administration de tests qui vous permettra de choisir les tests que vous souhaitez déclencher.

Il sera facile d’avoir accès aux tests qui sont passés et ceux qui ne sont pas passés grâce à cette interface simplifiée.

Ainsi pour pouvoir assurer le suivi de mon projet, j’ai demandé à travailler avec IceScrum. Cependant, il a fallu un certain temps avant que je puisse l’utiliser et pour ne pas perdre de temps dans mon suivi, j’ai du revenir aux bonnes vieilles méthodes !

Même si on n’applique pas à la lettre toutes les pratiques d’une méthode en particulier, on aimerait parfois pouvoir gérer son projet de façon agile ou avec des briques de Kanban. Mais pour une raison ou une autre, il arrive que nous n’ayons pas d’outils spécialisés sous le coude :

• Problème de budget (IceScrum est néanmoins gratuit).
• Problème de licences.
• Problème de droits sur son propre poste (mon cas au sein de cette mission).

C’est alors que vient à l’esprit l’utilisation d’outils de remplacement que presque tout le monde dispose dans son entreprise : un tableur type Excel et un tableau blanc !!

Le fichier Excel vous permet de tenir à jour votre product backlog, ainsi que de visualiser vos sprints et même de faire du reporting avec le burndown chart dans votre fichier.

Vous trouverez en pièce jointe de cet article le fichier Excel que j’utilise en remplacement d’un vrai outil dédié tel qu’IceScrum ou VersionOne.

Template Backlogs Version 1 – www.coffee-meeting.com

Maintenant il ne vous reste plus qu’à coupler cela avec une pointe de management visuel en réalisant un TaskBoard. Sur ce tableau vous pourrez y mettre les tâches du sprint, ainsi que le burndown chart du sprint. Voici un exemple avec le tableau des tâches que j’utilise en complément de mon fichier excel ou d’IceScrum :

Mon Taskboard

Ce tableau est composé à gauche des tâches de chaque user story ainsi que leurs état. A droite, on retrouve le burndown chart visible de tous durant tout le sprint, et en dessous quelques indications sur la vélocité et les tâches non planifiées. Ce taskboard est loin d’être complet et le must serait d’en faire un vrai radiateur d’informations en y ajoutant quelques données supplémentaires. Je vous invite d’ailleurs à aller lire un article de Jean-Claude GROSJEAN autour du principe de radiateur d’information en complément de cet article : http://www.qualitystreet.fr/2007/11/26/information-radiator-indispensable/.

Voilà, j’espère que cette solution de substitution vous servira autant qu’elle m’a servi quand je n’avais pas de logiciel dédié.

Pour débuter cette série d’articles sur mon retour d’expérience au sein de la société Vivalur en tant que ScrumMaster, j’ai décidé de vous parler des prémices de la mise en place de Scrum afin de respecter la chronologie du projet. 14 Septembre 2010 : date officielle de démarrage de notre « bb » : Vivalur ! Ça fait maintenant 3 ans qu’on y travaille, presque d’arrache-pied, pendant nos soirées, week-end, voir même en cours (ce n’était pas forcément l’idéal ni très académique mais je ne suis pas là pour faire dans la langue de bois ! Et puis rassurez-vous comme je le dis dans mon retour au blog … j’ai eu mon diplôme !) Nous voilà donc lancés dans ce projet entrepreunariale avec une dose de motivation surdimensionnée mais aussi beaucoup de compétences, avec chacun son domaine de prédilection :

- Guillaume Warckol : l’initiateur du projet et à ce jour la personne la plus génératrice d’idées qu’il m’ait été donné de rencontrer. Autant dire qu’il est l’homme de la situation pour trouver de nouveaux projets et faire émerger des besoins dans le monde du Web. Il était le product owner de vivalur.

- Olivier Dolbeau : Lead developer, ce fut le pilier de l’équipe en terme de développement. Autant dire que sans lui la capacité de l’équipe aurait pratiquement été divisée par deux à chaque sprint. C’est également le développeur le plus performant que j’ai pu côtoyé jusqu’à aujourd’hui à tel point qu’il ne serait pas chez Sensio (l’éditeur du Framework Symfony) s’il n’était pas performant en développement php symfony…

- André De Sousa : moi même! Pour ma part, je fus le scrum master de cette belle équipe. Je devais mettre en pratique la méthode et la faire respecter pour que l’on soit les plus efficaces.

Après ce rapide récapitulatif de l’équipe, je vais vous expliquer les premiers jours difficiles ou il a fallu mettre à plat, l’ensemble du projet qui existait déjà depuis près de 3 ans pour pouvoir mettre en route la mécanique agile. Tout a commencé par un atelier de regroupement des fonctionnalités et des discussions sur la vision de chacun du projet. Au bout de ces deux jours de mise en commun nous avons pu recenser les éléments du projet. Il nous fallait maintenant décomposer les éléments en user stories puis les prioriser.

Le jour suivant fut l’occasion de mettre en pratiques ces belles paroles en priorisant les users stories. En tant que bon scrum master j’avais prévu le coup en achetant 3 decks de cartes agiles de chez agile42 (lien vers le site qui vend les cartes) avant de démarrer le projet. Celles-ci sont livrées avec un jeu de carte de planning poker (pour l’estimation des users stories) ainsi que d’un jeu de cartes nommé « Business game value » pour la priorisation de celles ci.

C’est donc ce dernier qui nous a permis de prioriser nos users stories pour enfin avoir un product backlog. Je ne vais volontairement pas m’étendre sur le principe de cette méthode de priorisation car je compte dédier un article entier à ce sujet. Une fois le product backlog en place, il ne restait plus qu’à planifier nos releases ainsi que nos premiers sprints. La méthode employée ici fut le planning poker via le deck d’agile42 toujours.

Voilà donc très brièvement la démarche agile adoptée par l’équipe. Certaines étapes n’ont pas été décortiqués ici et j’espère pouvoir vous en faire part plus tard. Le but était, à travers cet article, de vous présenter rapidement les différentes phases de démarrage du projet du point de vue des méthodes agiles.

Des difficultés d’adoption ?

Il est clair qu’étant une équipe novice en matière de mise en application de Scrum, certaines pratiques ont mis du temps à se réaliser. Cependant, l’ensemble fut bien reçu et nous nous accordions tous sur l’efficacité et la motivation procurée par cette approche agile, notamment concernant la priorisation et l’estimation des fonctionnalités du projet vivalur. Bientôt la suite de ce REX (retour d’expérience pour ceux qui n’auraient pas compris) consacré aux 6 mois passés avec l’équipe Vivalur !

Après l’article sur le retour au blog me revoilà. Cette fois-ci je vous propose un sujet de fond qui je l’espère sera suffisamment complet à vos yeux !

A l’occasion de mes débuts comme consultant chez altran, j’ai été amené à présenter Scrum en 5 minutes à plusieurs reprises.

Je vais donc essayer de vous livrer ici quelques éléments de ma présentation, qui je l’espère, aideront ceux qui sont en pleine découverte de cette méthode agile à y voir plus clair rapidement.

Cette présentation a volontairement été vulgarisée afin de s’adapter à mon auditoire. Si toutefois elle vous semble trop complexe, n’hésitez pas à me le faire savoir en commentaire, j’essaierai d’y apporter une réponse.

SCRUM en action: une rapide introduction à son utilisation

• Scrum est une méthode de gestion de projet de plus en plus utilisée dans l’industrie du logiciel.
• La méthode est particulièrement adaptée à des équipes de 10 personnes max.
• Pour les projets que l’on peut découper en mini projets dont les périodes de temps sont inférieures à un mois.
• Les méthodes traditionnelles de gestion de projets sont centrées sur la réalisation dans les temps.
• Les méthodes agiles telles que Scrum se focalisent plutôt sur la livraison d’un produit à forte valeur ajoutée pour le client.

Un schéma simplifié du processus Scrum

source de l’image: agileforall.com

Voici quelques points détaillant ce schéma:

• Scrum est basé sur des itérations (périodes courtes de développement dont les objectifs sont définis à l’avance) appelées sprints.
• Les objectifs font partis d’un référentiel d’exigences appelé le product backlog qui est fourni et tenu à jour par le product owner (“Correspondant métier”).
• Ce référentiel est composé de fonctionnalités constamment priorisées. Avant chaque sprint, les fonctionnalités les plus prioritaires passent dans le sprint backlog et deviennent donc les objectifs à réaliser durant le sprint (itération).
• Un sprint démarre toujours par sa planification en partant de discussions entre le product owner et l’équipe concernant le product backlog. A l’issue de cette rencontre, des tâches sont définies et le sprint peut débuter.
• L’équipe de développement est piloté par le Scrum Master qui a pour but de résoudre les obstacles, participer au développement en cas de besoin et tout mettre en œuvre pour que les objectifs soient réalisés durant le sprint.
• Chaque sprint améliore la valeur ajoutée du produit en ajoutant de nouvelles fonctionnalités qui peuvent être livrées au client.

Les rôles: L’équipe de développement

• L’équipe SCRUM: Equipe comportant au maximum 10 personnes. L’équipe est auto-organisée et chacun doit être capable de reprendre les tâches d’un autre membre.
• Le Product Owner: correspondant métier, il représente le métier et doit gérer la priorisation, et l’évolution du product backlog. Il doit se rendre disponible pour répondre aux questions de l’équipe Scrum.
• Le Scrum Master : Il combine plusieurs rôles: Coach, chargé de projet, développeur, animateur… Il doit faire respecter le cérémonial Scrum à son équipe et veiller à ce qu’ils ne soient troublés par des faits extérieurs, tout en assurant le reporting.

Quelques pratiques agiles

• L’utilisation d’un Product Baklog: référentiel des exigences et des fonctionnalités. Il doit être priorisé par le Product Owner.
• Le Sprint (itération): Fondement même de l’agilité, il consiste à développer un incrément du logiciel en une période courte inférieure à 30 jours.
• Le Daily Scrum ou coffee-meeting: Pratique visant à éviter les dérives, motiver l’équipe et tenir à jour les métriques projet. Il est quotidien et présidé par le Scrum Master.
• Démo et revue de Sprint: A chaque fin de sprint, l’équipe présente l’incrément logiciel développé au client, et celui-ci valide les différents points du backlog ou indique des changements à opérer.
• Le burndown Chart: Diagramme indiquant les tâches restantes avant la fin du Sprint sur un axe du temps :
  

  Burndown chart provenant du blog: scrum.jeffsutherland.com

Pourquoi utiliser Scrum ?

Enfin, pour terminer cette overview, voici quelques points visant à vous convaincre d’utiliser Scrum comme méthodologie de gestion de projet:

• Les projets sont trop long pour être estimés correctement.
• Scrum permet d’être transparent envers les métiers.
• La flexibilité des développements est permise grâce aux itérations et aux changements de priorités du product backlog.
• L’agilité favorise la motivation et l’auto-organisation des équipes de développement.
• Les utilisateurs communiquent directement avec l’équipe et réduisent les risques d’incompréhensions.
• Un sentiment de reconnaissance des équipes se fait immédiatement sentir.

Voilà c’est tout pour cette présentation « rapide » de Scrum.

Encore une fois ces quelques points sont issus d’une présentation et n’ont vocation qu’à vous présenter simplement la méthode et ses pratiques sans rentrer dans le détail.

Si des points ne sont pas clairs ou que vous n’êtes pas d’accord avec ma vision agile, faites le moi savoir en commentaire !

Qu’il est bon de reprendre ses projets d’antan ! Il me tardait de reprendre le chemin de l’écriture sur ce blog lorsque je trouverais à nouveau du temps.

C’est donc avec grand plaisir que j’ai décidé de revenir après une longue interruption, où je n’ai pourtant pas chômé, pour vous parler d’agilité, entre autre.

Alors que s’est-il passé en 2010 ?

Me voilà donc de retour après un an d’absence sur le blog. Depuis Février 2010, beaucoup de choses ce sont passées en commençant par l’une des plus importantes : j’ai obtenu mon master en informatique.

En plus d’avoir obtenu mon diplôme je suis passé par plusieurs expériences qui ont confortées mon opinion sur l’agilité. A tel point que je ne conçois plus ma carrière professionnelle sans agilité ni sans standup ou coffee meeting .

J’ai également pu vivre l’aventure d’entrepreneur en compagnie deux de mes fidèles compagnons de route « informatique » ! Mais sur ce point j’y reviendrais plus tard…

En-effet, cette année passée, a surtout été l’occasion pour moi de concrétiser un projet d’ entreprenariat Web avec la mise en ligne du site Vivalur avec deux collègues qui étaient en cours avec moi depuis le début de mon BTS : Guillaume Warckol (@guillaumew : profil twitter) et Olivier Dolbeau (@odolbeau : profil twitter).

Quelle belle expérience ! J’ai tellement appris durant ce projet et il y aurait tant à dire que l’on pourrait en écrire un bouquin à nous trois ! Cependant je me cantonerais simplement à quelques articles pour vous faire un retour d’expérience sur des sujets qui me tiennent à coeur comme l’agilité au sein du projet Vivalur.

Et en 2011 alors ?

J’ai depuis peu intégré une société de conseil en informatique (Altran), où je pense pouvoir faire bénéficier de mon expérience les entités qui le souhaiteront et profiter bien sur des expériences d’altran dans le domaine agile mais pour le moment, je ne suis que consultant chargé de projet SharePoint, il faut parfois être patient !

Je mise aussi beaucoup sur Altran pour pouvoir monter en compétences sur la méthode scrum et devenir Scrum Master assez rapidement.

Je vous dis à très bientôt sur coffee-meeting, pour cette série d’articles !

Qu’est ce que le Coffee-Meeting ?

On peut considérer le Coffee-Meeting comme le daily scrum ou encore standup meeting. A un point près. Ces deux réunions journalières se basent sur 3 questions. Or les expériences ont montrées que bien souvent les membres de l’équipe projet sont distraits et certains même ni voit pas d’intérêt persuadés que c’est une perte de temps. J’ai pour ma part, eu l’occasion d’expérimenter le Coffee-Meeting en lieu et place d’un stand up meeting et je peux vous assurer que les résultats sont impressionnants.

L’instant plaisir

Afin d’améliorer la productivité et la motivation de chacun, il est important de rendre obligatoire le café, thé, chocolat, jus d’orange ou autre boisson propice le matin et un apport en viennoiseries, ou autre gâteau. Pourquoi rendre obligatoire ce genre de gourmandise ? Tout simplement car le fait d’ajouter une composante plaisir à ce genre d’exercice renforce d’une part l’intérêt des membres à y participer, motives plus facilement l’équipe et permet d’autre part, de faire une sorte de « lien » entre ce qui est dit durant la réunion et un moment de détente, et de plaisir comme celui d’une pause café.

Il est prouvé que le cerveau assimile plus facilement de l’information s’il est détendu et ouvert à la discussion. Cette méthode va donc détendre les participants et leurs permettre de répondre plus facilement aux questions posées.

Le moment

Par expérience, il a semblé plus intéressant et plus productif d’organiser ce genre de réunion fédératrice tôt le matin, juste après être arrivé sur son lieu de travail. La plupart du temps entre 9H et 9H30. Cela permet de commencer la journée sans perdre de temps par un point qui est inévitable pour une équipe agile tout en profitant du début de journée par son petit café !

La durée

Un coffee-meeting ne doit pas excéder 30 minutes pour être optimal. Si l’on dépasse cette durée, il est possible que l’on perde une partie de l’équipe et que la productivité laisse place au sentiment de perte de temps. Il faut aussi compter dans cette période le fait que chacun au début se serves en café, gâteaux et discutes pendant 5 minutes hors contexte projet (Ice breaking).

Les questions à se poser

Comme un Daily Scrum, il faut se poser les bonnes questions. Alors même si on savoure un bon café bien chaud, il faut bien rentrer dans le vif du sujet, alors quelles sont ces questions ?

• Qu’as-tu fait hier ?

Chacun explique sa journée antérieure, et les tâches sur lesquelles il a travaillé.

• Que fais-tu aujourd’hui ?

Chacun donne son programme personnel de la journée. Sur quoi il compte avancer.

• Rencontres-tu des obstacles ?

Chacun tente d’expliquer les potentiels obstacles qu’il rencontre.

Conclusion

Que les choses soient claires. Ces réunions périodiques ne sont pas un moment ou l’on doit trouver des solutions. Le but est que chacun puisse donner son ressenti sur le projet et avouer les obstacles qui lui font perdre du temps. Un collègue pourrait avoir une solution pour celui qui rencontre un obstacle. Si des problèmes existent, ils devront toutefois être résolus plus tard après la réunion. Ces rencontres permettent d’anticiper certains risques tôt et ainsi éviter d’éventuelles dérives irrattrapables.

En y intégrant un aspect de détente à ces réunions périodiques, le chargé de projet pourra obtenir plus vite et plus facilement les informations de ses collègues projet. Ceci permet donc de faire du management par la motivation et par la même occasion, d’améliorer la productivité de son équipe.

Comme vous le savez tous maintenant, je suis issu d’un cursus technique (si ce n’est le cas, il n’est pas trop tard pour jeter un œil à Qui suis-je ?). Etant développeur avant d’être chargé de projet, j’ai réalisé quelques sites internet en PHP. Bien souvent ce sont les mêmes problématiques inhérentes à PHP qui reviennent : « Le langage est trop laxiste et n’impose pas un cadre suffisant à la production de qualité. », « Certaines tâches récurrentes sont inévitables » ou encore « Des problèmes de performances se font sentir ! Serait-ce nos développeurs le problème ? »
Afin de pallier aux lacunes de PHP, l’équipe dont je faisais partie à décider d’opter pour un Framework capable de couvrir l’ensemble de nos besoins. C’est ainsi que j’ai eu l’occasion d’expérimenter Symfony, un Framework PHP qui propose une multitude d’outils d’aide au développement. Mais ne nous étendons pas là dessus, si vous voulez plus d’informations concernant le Framework en lui-même, je vous invite à consulter le site web du projet Symfony

Voyons maintenant les raisons qui me poussent à affirmer que Symfony est un Framework agile, et qu’il a été conçu afin de faciliter la mise en application de certaines méthodes telles que XP (Extreme Programming). Fabien Potencier, si vous lisez cet article, n’hésitez pas à commenter cette supposition !

L’architecture MVC

Ce modèle consiste à séparer le code en trois couches distinctes à vocations différentes: Le modèle, la vue et le contrôleur. Chaque partie est entièrement séparée et permet donc une réutilisabilité de code de haute qualité. La collaboration au sein du groupe de développeurs en est facilitée par le fait que chaque couche peut être abordée par différents développeurs sans créer de conflits sur un même fichier. Ainsi les tâches sont partagées et chacun sait situer chaque élément du projet.

Revue et qualité de code

Vous allez me dire que la qualité du code généré dépend entièrement de l’équipe dont on dispose. C’est vrai ! Mais il est évident que le cadre que l’on impose à une équipe de développeurs aide grandement à la qualité. C’est pourquoi cette architecture MVC permet d’améliorer grandement sa conception et sa maintenabilité sans pour autant parler de normes de code. Si vous couplez l’architecture avec quelques règles de normage de code, vous obtiendrez alors une application tout à fait pérenne et dont la revue sera aisée par un quelconque membre de l’équipe. D’ailleurs si vous jeter un œil aux classes composant le Framework vous y verrez la rigueur avec laquelle le code a été travaillé, toutes les variables sont nommées de la même façon, les noms de fichiers suivent une règle bien précise, etc.

Le travail collaboratif est possible et fortement conseillé

L’arborescence mise en place lors de la création d’un projet avec Symfony, nous fait dire qu’elle a été pensée pour le travail collaboratif. En-effet, la répartition des modules est gérée toujours dans un souci de qualité et réutilisabilité de code dans d’autres projets par exemple. Tout y est structuré de façon à ce qu’une équipe puisse travailler sans en impacter une autre qui développerait un autre module.
Afin d’amplifier encore l’impact du Framework sur vos projets je vous conseil donc de l’utiliser avec un gestionnaire de configurations tel que SVN (si vous ne savez pas ce qu’est SVN, je vous invite à lire l’excellente introduction à SVN d’Olivier Dolbeau. Cet outil facilite la collaboration par des équipes travaillant sur plusieurs sujets à la fois, sur les mêmes fichiers ou encore pour des équipes offshore. Enfin, il permet de garder un historique de toute version d’un fichier.

Tests unitaires et tests fonctionnels

Certaines méthodes préconisent l’utilisation du TDD (Tests Driven Development).
Le cycle préconisé par TDD comporte cinq étapes :

1. Ecrire un premier test ;
2. Vérifier qu’il échoue (car le code qu’il teste n’existe pas), afin de vérifier que le test est valide;
3. Ecrire juste le code suffisant pour passer le test,
4. Vérifier que le test passe,
5. Puis refactoriser le code, c’est-à-dire l’améliorer tout en gardant les mêmes fonctionnalités

Symfony met en œuvre des fonctionnalités d’automatisation de tests unitaires et de tests fonctionnels.

Les versions applicatives

La mise en place de versions logicielles dites de pré-production pour assurer les démonstrations de fin d’itérations est simplifiée. Ainsi l’intégration continue peut s’opérer dans les meilleures conditions, et nombreux sont les projets dont cette étape se passe dans la douleur…

Gain de temps considérable

Le développement est plus rapide grâce aux classes Symfony: Avant il fallait une multitude de lignes pour pouvoir se connecter à une base et récupérer des données. Maintenant une simple déclaration de variable suivi de l’appel d’une méthode suffit!

Exemple: $vente = VentePeer::retrieveByPK(10); // Récupération de la vente stocké en base de données ayant pour id 10.

Génération du code pour certains modules tels que l’administration, toute la couche d’abstraction aux données de la base de données peux également être générée par Symfony.

Voilà quelques raisons pour lesquels selon moi, Symfony peut donc tout à fait être considéré comme un framework agile. Il s’accorde parfaitement avec des méthodes telles que XP (Extrem programming) et couplé à des pratiques agiles et des outils collaboratifs tels que SVN, il est alors d’une efficacité redoutable pour tous ceux qui doivent respecter des délais serrés et produire une qualité de code exemplaire.
Croyez-moi, pour l’avoir testé sans méthodologie agile puis avec des pratiques agiles je dois dire que dans le second cas, le Framework m’a bluffé d’efficacité. Nos délais de livraison ont été raccourcis et notre code à gagner en clarté et qualité. J’ai pu noter d’ailleurs un regain de motivation au sein de l’équipe qui reprenait enfin goût au développement d’un projet qui paraissait pourtant s’embourber et démotiver les troupes au fil des mois.

Un grand merci à l’équipe de développement de Symfony, car la communauté de développeurs PHP avait depuis longtemps besoin d’un tel framework !

—

N’hésitez pas à me laisser en commentaire vos avis concernant ce Framework.
Avez-vous eu l’occasion d’utiliser le couple « Symfony + méthodes agiles » telles que XP, SCRUM lors de vos projets ? Etait-ce une réussite ?