Agile

La semaine dernière (du 15 au 18 mai 2007) j'ai participé a l'événement DevTeach à Montréal. Il s'agit d'un congrès de formation, axé sur Microsoft .NET. On pouvait choisir parmi des conférences (1h15) dans cinq thèmes (tracks):

• .NET 3.0,
• ASP.NET,
• SmartClient,
• Agile
• track francophone

J'y suis aller avec des collègues (5). La plupart des participants provenaient de la région de Montréal.

D'emblé, disons que la conférence était intéressante et la qualité des conférenciers était excellente en particulier dans la track Agile. Les conférenciers étaient des gens d'expériences, critique des produits MicroSoft.

Ensemble, avec les collègues,  nous nous sommes divisé la tâche pour couvrir le plus de matériel possible, alternant d'un thème à l'autre selon nos intérêts personnels, en fonction des préoccupations que nous avons pour l'incubateur. Le contenu étant très pointu, je ne rentrerai pas dans le détails ici mais si vous voulez qu'on vous parle de Silverlight, de Linq, de WF, de WPF de WCF, de ClickOnce, de l'interop WinForm/WPF, du DSL, du nouveau Entity Framework, de MonoRail, de TeamSystem et TFS, venez nous voir en personne.

Ce que je retiens globalement, coté technique, c'est que la plate-forme MS est 1) très vaste, 2) en perpétuelle évolution et 3) les dernières nouveautés sont souvent immatures, incomplètes et néanmoins excitantes.

Les outils aussi sont immatures (même Orcas, la prochaine version de VisualStudio). De ce côté, la bonne nouvelle c'est que MS était sur place pour écouter les développeurs sur ce qu'ils devraient faire pour l'améliorier et j'ai senti que MS voulait vraiment offrir un produit pour répondre aux besoins de l'entreprise. Espérons que nos suggestions sauront trouver une place dans les versions futures.

Ces éléments vont nous permettre d'apporter une dimension terrain à l'incubateur, en particulier pour le volet SmartClient et l'utilisation de WPF.

Si la plupart des thèmes étaient très technique, le thème"Agile" était plus axée sur la pratique. Il va sans dire, compte tenu de mon intérêt pour le sujet, que c'est dans celle-çi que j'ai trouvé les éléments les plus marquants de la conférence.

Disons d'abord que beaucoup de personnes ont participer à ce thème et que le tiers des participants utilisait déjà les pratiques agiles. On a parlé de l'application de  nouvelles techniques de développement: l'intégration continue, le "test driven developpement (TDD)", les spécifications exécutables, la programmation par paire. J'ai d'ailleur passé la dernière journée sur le seul sujet du TDD.

Tout cela était marquant pour moi car cela confirme comment ces approches sont incontournables aujourd'hui si l'on désire être productif. Cela confirme aussi combien les approches agiles nous sortent de notre zone de confort et combien elles peuvent semblées bizarres à la plupart des gens.

Je vous laisse avec une belle citation de Scott Bellware: "la productivité passe par la qualité, pas par les outils".

Dans un projet qu'on est en train de démarrer, on ne peut pas disposer d'un espace de travail style "war room", faute de locaux disponibles et fautes de temps pour l'aménager. On veut cependant maximiser les opportunités qu'aura l'équipe de voir comment progresse le projet, aussi avons-nous pensé à installer un "war wall", en fait un mur que tout le monde peut voir et qui agira comme radiateur d'information.

Sur ce mur on affichera un sommaire (une page) du projet, un graphique de la progression en terme de reste à faire et un thermomètre de l'avancement des travaux.

Voici un exemple de tableau de suivi des tâches de l'itération. Sur la gauche du tableau on trouve les tâches non débutées, au centre sur la feuille blanche les tâches en cours et à droite, les tâches terminées.

Voici un exemple de graphique de reste à faire pour une itération.

Au lieu de penser en terme de Demande De Changement (DDC) on pourrait penser en terme de Demande D'Échange (DDE).

Imaginons un projet dont la date et le contenu sont fixés d'avance, l'argent n'étant pas une préoccupation majeure. Une façon classique de gérer le changement/imprévue est de traiter les écarts avec le plan comme des demandes de changement. "Tu en veux plus ou des choses qui n'était pas prévue au mandat, pas de problème, mais ça va changer ta date (et peut-être le coût).". Le problème c'est que le client tient peut-être mordicus à sa date.

Pour quoi ne pas introduire la demande d'échange. "Tu en veux plus ou des choses qui n'était pas prévue au mandat, pas de problème, contre quels fonctionnalités désires-tu les échanger pour qu'on arrive à la date auquelle tu tiens? (By the way, ça peut aussi changer le coùt.)."

Cette approche rend explicite le fait que le client devra contrôler son envergure avec nous.

Ce matin j'ai réaliser quelque chose.Dans nos pratiques de gestion de projet (traditionnelle) on met beaucoup d'emphase sur le suivi de l'avancement. Pour les approches agiles le focus est plus sur le reste à faire. D'où peu venir cette différence?

Dans la mesure où les projets agile à souvent des contraintes de temps (date fixe), le reste à faire, associé à la vélocité est un meilleur indicateur du suivi de l'objectif ("est-ce que je vais arriver à la date"). On a juste à jeter un coup d'oeil au burndown chart pour voir la tendance.

Pour les approches traditionnelles, la cible est essentiellement de livrer ce qu'on a prévue au début du projet et dans ce cas l'avancement reflète effectivement l'avancement des travaux. A mi-parcours je devrais avoir réaliser la moitié du travail.

Imaginons qu'il faille remplir une pinte de lait à l'aide du robinet de la cuisine. L'avancement du remplissage est un bon indicateur de la progression.

Imaginons qu'il faille maintenant remplir une balloune avec un robinet dont le débit n'est pas constant. Dans ce cas il est plus facile de suivre le projet en fonction de l'espace qu'il reste à remplir pour répondre à la question, pense-tu remplir la baloune en 30 secondes.