L'agilité ne se vend pas en pack de 12, il faut l'adapter à chaque projet.
Mes conseils
Des recommandations tirées d'expériences dans les projets
Apprendre, ça fait partie du métier de développeur
20 dimanche juin 2010 15:09
Il y avait moins de monde que d'habitude au SigmaT14 ce vendredi.
Le cas des cas d'utilisation
10 lundi mai 2010 08:50
Un lecteur de mon livre m'interpelle à propos des use-cases.
Documentation contractuelle et Scrum
29 vendredi janvier 2010 07:39
La transition à Scrum dans un contexte de gouvernance et de modèle économique imposant habituellement une production abondante de documents.
Scrum CMMI, niveau 2, niveau 5
28 mercredi octobre 2009 13:38
A la fin de ma présentation à l'Agile Tour, j'ai eu une question sur le CMMI et sa compatibilité avec les méthodes agiles. J'y ai répondu d'une façon convenue, comme celle qu'on entend dans les retours d'expérience sur l'utilisation de Scrum dans un contexte CMMI niveau 2 : oui, en cherchant bien dans les 2 domaines on trouve des zones de convergence et oui on peut faire du Scrum dans un contexte CMMI.
Mais dans le fond je pense que les organisations qui mènent les 2 initiatives en même temps sont un peu schizophrènes (Je n'en ai rencontré qu'une ; les autres avec lesquelles je travaille ne connaissent même pas CMMI pour la plupart). Je partage ce qu'en dit un consultant CMMI : l'agilité et CMMI sont deux faces opposées d'une même médaille.
J'ai tendance à penser qu'il faudrait que le CMMI (ou plutôt la façon de le mettre en application) évolue beaucoup pour être compatible avec l'agilité, l'évolution allant dans le sens de ce que dit cmmi-déploiement dans le dernier paragraphe de son billet.
En attendant je conseille à ceux qui sont intéressés par les 2 initiatives de commencer par appliquer Scrum, l'orientation est déjà vers la valeur ajoutée (et ça ira plus vite).
Évidemment si l'organisation est déjà au niveau 5, le mariage de Scrum et CMMI est bien plus facile. C'est ce que montre l'article "Mature Scrum at Systematic" dans l'excellent Methods and Tools de cet automne.
Cohabitation d'outils
18 mardi août 2009 22:58
Suite à mon billet sur les Fonctions d'un outil Scrum, Xavier se demande si je ne suis pas contradictoire :
Si une équipe utilise le tableau mural, comment peut elle afficher le burndown chart dans son outil Scrum sans double saisie?
Ma position est effectivement de privilégier le tableau des tâches du sprint avec des Post-it collés au mur, quand c'est possible. Quand le tableau des tâches est bien fait, avec les colonnes (ou les lignes) pour montrer les états des tâches, je considère que le burndown chart de sprint n'a pas grand intérêt. J'avais eu une discussion un peu animée avec Laurent sur le sujet l'année dernière. Un an après, je suis encore plus partisan du suivi par les états.
Si on utilise un outil informatique pour le reste (backlog de produit, plan de release, burndown de release...) et un tableau des tâches mural, il n'y a pas de double saisie pour les tâches, qui ne sont que sur les Post-it. Il y en a une pour les stories du sprint, qu'il est bien de visualiser sur le tableau des tâches. Pas besoin de burndown chart de sprint donc, mais si on y tient vraiment, on peut le faire à la main sur le tableau. Pas difficile de faire la somme du reste à faire affiché sur les Post-it des tâches.
Les fonctions d'un outil Scrum
08 samedi août 2009 13:05
Le groupe de discussion Scrum de Montréal s'interroge sur les outils pour Scrum. Je reprends leur compte-rendu en donnant mon point de vue d'utilisateur, de consultant et aussi de Product Owner d'IceScrum.
Dette technique, nique nique
18 lundi mai 2009 21:17
Le terme dette technique revient pas mal en ce moment. On en parle dans les blogs et je l'entends même dans mon équipe.
Il n'est pas récent : il vient d'un article de Ward Cunningham de 1992 pour une conférence OOPSLA.
A l'époque, pas d'agile ! Mais du développement incrémental et orienté objet.
Scrum structure les équipes
27 lundi avril 2009 00:05
Product Owner et Backlog sont les mamelles d'une équipe.
Transition à l'agilité et contexte des projets
11 mercredi mars 2009 10:59
L'intelligence situationnelle favorise le succès. Comme au rugby.
Théorie Y
24 mardi février 2009 09:15
La transition d'une organisation à l'agilité est plus ou moins facile. Cela dépend du mode de gouvernance. La façon dont les managers gèrent leur organisation influe sur les comportements des personnes. La culture ainsi développée en fonction de la gouvernance a un impact très important sur la conduite du changement pour passer à l'agilité.
En s'appuyant sur les théories X et Y, on voit l'analogie des principes de l'Agilité avec la théorie Y. Et on comprend que les organisations où la gouvernance a développé les présupposés de la théorie X auront un peu plus de mal à devenir agiles. Cela ne veut pas dire que ce n'est pas possible, ce sera plus long et plus difficile puisqu'il faudra faire évoluer les cultures. Parce que vouloir être agile en gardant une gouvernance proche de la théorie X, c'est incompatible.
Vocabulaire imprécis
09 dimanche novembre 2008 17:48
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.
Variation de périmètre
12 dimanche octobre 2008 11:13
Un burndown chart de release donne une bonne indication du travail qui reste à faire. En y ajoutant la consommation du budget, on obtient des indicateurs permettant de répondre à des questions fondamentales de la gestion d'un projet : où en sommes-nous dans l'avancement du projet, combien de budget avons-nous consommé ?
Seulement, et c'est normal avec une méthode agile, le périmètre initial, représenté par le point de départ d'un burndown chart, évolue toujours. Je définis ici le périmètre comme le total des points des éléments qui constituent le backlog pour une release.
Il évolue toujours, sur tous les projets auquel j'ai participé. La raison la plus évidente est l'ajout d'une nouvelle story qui n'avait pas été prévue au début du projet. Il y en a de nombreuses autres :
- la décomposition, suivie d'une estimation. Il est fréquent que le total des points des éléments décomposés ne soit pas identique au total estimé pour l'élément avant décomposition
- la suppression d'un élément. Il arrive qu'on décide de le reporter pour une prochaine release
- une ré-estimation d'un ou plusieurs éléments du backlog qui avaient été mal compris
- un élément qu'on n'avait pas encore estimé, parce qu'on n'avait pas eu le temps et/ou parce qu'il n'était pas prioritaire. Le simple fait de lui donner une estimation ajoute des points au total et modifie le périmètre.
Le burndown chart classique ne permet pas de voir l'évolution de périmètre. Pour l'avoir, il convient simplement de tenir compte de la vélocité. A la fin de chaque sprint, cela revient à faire 2 mesures : le reste à faire et la vélocité du sprint qui se finit. Les deux comptées en points.
Par exemple :
- fin du sprint 0 : 100 points à faire dans le backlog de produit
- fin du sprint 1: 82, vélocité 16
- fin du sprint 2 : 64, vélocité 19
- fin du sprint 3 : 56, vélocité 18
- fin du sprint 4: 30, vélocité 20
Cela permet de savoir que pendant le sprint 3, l'évolution de périmètre a été de 18 - (64-56) , soit une augmentation de périmètre de 10 points. Au contraire pendant le sprint 4, le périmètre a diminué de (56-30) - 20, soit 6 points.
Cela peut se voir un graphique, en voici un exemple :
En rouge la courbe de reste à faire, le burndown classique. En bleu, le reste à faire si le périmètre était resté constant, obtenu simplement en utilisant la vélocité à partir du reste à faire au départ.
Quelle valeur pour la valeur ?
21 jeudi août 2008 07:33
Pas facile de donner une valeur à la valeur ajoutée par une user story...
A la recherche du cycle en V
20 mercredi août 2008 08:28
J'ai écrit il y a presque 2 ans que le cycle en V n'existait pas. Pourtant il y a en a qui le cherchent encore.
Je le sais, parce que les statistiques de mon blog montrent que des visiteurs arrivent sur mon blog en tapant cycle en V sur Google. Plus de 400 depuis le début de l'année !
Mais qui sont ces chercheurs du mythique cycle en V ?
J'avais tendance à penser que c'étaient des étudiants révisant leurs cours de génie logiciel. Mais je vois qu'il y en a encore 11 rien qu'hier dans mes stats, alors que les étudiants sont en vacances ou en stage.
Visiteur qui arrive ici en googlant cycle en V, dis-moi qui tu es !
Même dans les présentations du cycle en V comme celle-ci, il est dit clairement qu'il n'est pas applicable. Alors on évoque un intérêt pédagogique. Elle a bon dos la pédagogie, quand on voit les dégâts provoqués : une confusion entre les activités d'ingénierie (analyse, conception, codage, tests) et le déroulement dans le temps du projet. Le V ne sert qu'à montrer des dépendances entre les activités, alors que le nom cycle fait croire, à tort, qu'il s'agit d'un cycle de vie. Présenter le "cycle en V" comme un cycle de vie est une aberration pédagogique.
Adaptation et anticipation
05 mardi août 2008 23:17
L'agilité favorise l'adaptation mais n'interdit pas un peu d'anticipation
Suivi des tâches par les états
12 samedi juillet 2008 14:50
La pratique usuelle de suivi des tâches dans un sprint consiste à mettre à jour quotidiennement le reste à faire et à produire un burndown chart de sprint. Une autre pratique répandue est de suivre l'avancement avec un tableau des tâches avec 3 colonnes (ou 3 lignes).
La première pratique se préoccupe de la valeur estimée en heures du temps restant pour finir la tâche. La seconde est basée sur les états de la tâches. Une tâche du sprint est dans un de ces 3 états :
- à faire
- en cours
- finie
Ces 2 pratiques ne sont pas exclusives : on peut utiliser un tableau des tâches tout en estimant le reste à faire et en produisant un burndown chart[1]. Mais je pense qu'avec un bon suivi sur le tableau des tâches on peut se passer de l'estimation du reste à faire.
Pour un développeur est-il plus facile d'estimer qu'il reste 6h sur une tâche que de dire qu'elle est en cours et qu'elle sera finie demain ?
Mon expérience avec de nombreuses équipes me pousse à privilégier le suivi par les états plutôt que par les valeurs en heures. J'ai constaté que pour les membres de l'équipe c'est beaucoup plus facile à vivre. Certains sont tourmentés quand on leur demande avec insistance le reste à faire. Ce n'est pas le cas quand il s'agit simplement de donner l'état de la tâche.
En se passant du reste à faire, on évite de perdre du temps à y réfléchir. Mais peut-on assurer un bon suivi ? Cela dépend des équipes et de l'expérience du ScrumMaster. Un bon ScrumMaster va savoir déceler un problème quand une tâche reste en cours plusieurs jours sans se terminer, par exemple.
C'est un choix à faire par l'équipe, par exemple lors d'une rétrospective, pour aller encore plus loin, que dans relever les heures, c'est mal, à la chasse au gaspillage .
« billets précédents - page 1 de 4
