Ne pas utiliser les mots corrects augmente le risque d'être mal compris
Entrer dans le domaine de l’Agilité implique d’acquérir un nouveau vocabulaire. C’est vrai en particulier avec Scrum et ses métaphores sportives (sprint, mêlée). Comme la plupart des termes viennent de l’anglais, le vocabulaire subit les aléas liés à la traduction. Ou à la non traduction si on garde le mot anglais.
Pour ne pas ajouter à ces difficultés de communication, il convient d’utiliser le bon vocabulaire. Lors de présentations ou de discussions, j’ai relevé des mots ou des expressions, qu’à mon avis, il vaudrait mieux éviter.
La première est le sprint0 (ou itération zéro).
Ceci est une annonce commerciale ostensible : je vais animer une formation publique “Les Ateliers de l’Agilité” les 2 et 3 décembre 12 et 13 mars 2009 à Toulouse.
Dans son deuxième commentaire de mon billet sur la variation de périmètre, Zorro revient sur les courbes et s’y perd entre les notions de valeur, d’effort et de coût.
J’essaie d’éclaircir.
Le burndown chart montre l’effort qui reste à faire. Il est obtenu en collectant le nombre de points des éléments qui restent à faire dans le backlog de produit.
James Shore qui l’a déclenchée avec son billet The Decline and Fall of Agile.
L’article est intéressant, les commentaires aussi. En (très court) résumé : il y a des risques de se planter avec Scrum si on est mal formé et il faut des pratiques d’ingénierie pour éviter la dette technique.
J’ai assisté ce matin à une présentation des projets des étudiants du Master1 de l’IUP ISI. Il s’agit des étudiants que je forme, avec d’autres, aux méthodes agiles (50 heures de cours et TD). Ils ont également des projets qui commencent en octobre et durent jusqu’en mars. Une équipe (motivée) qui travaille sur un projet peut y passer jusqu’à 2000 heures, ce qui permet de belles réalisations.
À la fin d’un sprint, il y a la revue et la rétrospective. Les plans sont actualisés et les rapports sont mis à jour. Mais toutes les partie-prenantes ne participent pas aux réunions et n’ont pas toujours un accès facile à ces rapports. Il peut être utile de diffuser un petit compte-rendu, sous forme de présentation, qui les contient.
Pour cela, j’ai un plan-type de présentation OpenOffice qui permet de produire un compte-rendu en quelques minutes, en y faisant figurer les informations importantes :
La pratique agile du jour : garder un peu de mou dans les plans
Même si on a fait une analyse des risques et mis en place une stratégie de réduction, des impondérables surviennent toujours sur un projet. Un impondérable (impediment) a pour effet de bloquer ou ralentir une ou plusieurs tâches en cours.
Pour empêcher ces impondérables de remettre en cause les engagements, il faut se garder du mou lorsqu’on planifie (c’est d’ailleurs aussi une stratégie de réduction des risques).
Une des réalisations dont je me souviens de ma vie de développeur, c’est l’écriture d’un générateur de code à partir de tables décrivant un automate. Plutôt un moteur d’automate, capable de lancer les actions élémentaires d’une transition suite à la réception d’un événement dans un état. A l’époque je travaillais à Telic-Alcatel dans le monde des autocommutateurs (PABX). Le comportement du poste téléphonique était décrit avec des automates à états finis. On disait simplement automate.
Attention, c’était de gros automates.
L’an dernier, j’avais fait un billet sur les features, stories, epics.
Aujourd’hui je revisite ces notions à l’occasion d’évolutions dans IceScrum, qui les embarque actuellement de façon pas très limpide. Pour simplifier l’usage, nous allons fusionner les notions de thèmes et de features, et nous appuyer sur des idées de Dean Leffingwell et Philippe Kruchten.
C'est le sujet de ma présentation de vendredi au SigmaT8
Ceux qui ne connaissent pas trop l’agilité pensent parfois, à tort, qu’on ne peut pas planifier sur les projets agiles, parce que ça change tout le temps. Ils ont bien compris que le client pouvait faire des changements. Ils doivent en déduire :
À quoi ça sert de faire des plans s’ils sont remis en question ?
J’ai été invité à participer à la réunion mensuelle d’un groupe de praticiens parisiens. Comme j’étais justement à Paris ce soir, entre une formation Scrum pour un client et une rétrospective de sprint 2 pour un autre, j’y ai assisté.
Tous les ans, c’est pareil, il faut que je trouve un sujet pour l’examen du module Ingénierie du Logiciel Agile. Même 2 fois par an avec la repêche de septembre.
Je corrige les copies. Une question de mon sujet d’examen portait sur les pratiques agiles. J’ai donné aux étudiants une liste d’une trentaine de pratiques, en leur demandant d’en choisir 6 pour les présenter et les expliquer. Je leur laissais le choix, donc je suppose qu’ils ont choisi celles qu’ils ont le mieux comprises.
Avec les couleurs, ça fait plus gai, vous ne trouvez-pas ?
Un burndown chart de sprint montre au jour le jour le reste à faire sur les tâches du sprint. Une de mes équipes a produit lors de son dernier sprint une variante de burndown qui montre en plus le reste à faire sur chaque story réalisée pendant le sprint.
