Mug « How Scrum Are You? »

Dans l’esprit du développement durable, le client chez qui je suis actuellement en mission a vivement encouragé son personnel à ne plus utiliser les gobelets en plastique et à amener sa tasse au bureau. Ni une ni deux, je me suis rendu sur le site ++[Zazzle|http://www.zazzle.co.uk/|en]++ et j’ai dessiné mon mug à partir d’un slogan que j’avais repéré sur le ++[blog de Tommy Norman|http://tommynorman.blogspot.com/2009/01/comfortably-scrum-how-scrum-are-you.html|en]++.%%% %%% Après trois grosses semaines d’attente, j’ai reçu un paquet de Zazzle.com Inc. basé à San Jose en Californie :%%% %%% ((/dotclear/public/logos/mug_how_scrum_are_you.png|How Scrum Are You?||How Scrum Are You?)) %%%  »Pour info, ça m’a coûté 20,70 € tout compris. »

La différence entre les modèles de développement en Cascade, en Cascade itératif, Scrum et Lean (en images !)

((/dotclear/public/logos/agile101_logo.png|Logo Agile101|L|Logo Agile101, aoû 2009))J’ai traduit un billet intéressant de Tara Lee Whitaker sur Agile101 : ++[The Difference Between Waterfall, Iterative Waterfall, Scrum and Lean (In Pictures!)|http://agile101.net/2009/09/08/the-difference-between-waterfall-iterative-waterfall-scrum-and-lean-in-pictures/|en]++|http://agile101.net/2009/09/08/the-difference-between-waterfall-iterative-waterfall-scrum-and-lean-in-pictures/|en]++%%% %%% > Voici un aperçu TRÈS simple des principales différences entre __le Développement en Cascade, le Développement en Cascade Itératif, le Développement Scrum/Agile et Lean__.%%% > %%% > __Le Développement en Cascade__%%% > %%% > « Le Développement en Cascade » est un autre nom pour __l’approche la plus traditionnelle du développement logiciel__.%%% > %%% > On l’a baptisé « cascade » car ce type de développement est souvent planifié en utilisant un diagramme de Gantt : __vous terminez une phase (la planification, par exemple) avant de passer à la phase suivante (par exemple, le développement)__.%%% > %%% > Dans les approches en Cascade, __vous aurez rarement l’objectif de revisiter une « phase » une fois qu’elle est terminée__. En tant que tel, __il vaut mieux que vous produisiez correctement du premier coup !__%%% > %%% > Cette approche est __très risquée__, souvent __plus coûteuse__ et généralement __moins efficace__ que la plupart des approches Agile.%%% > %%% > Les __principaux problèmes liés à cette approche__ sont les suivants :%%% > – Vous ne produisez aucune valeur tant que le projet n’est pas fini (déploiement) (__Lire__ ++[Self-Funding Projects – A Benefit of Agile Software Development|http://agile101.net/2009/07/22/self-funding-projects-a-benefit-of-agile-software-development/|en]++).%%% > – Vous réalisez les tests à la fin, ce qui signifie que vous découvrez les problèmes au dernier moment.%%% > – Vous ne recherchez pas l’approbation des parties prenantes avant la fin du projet sachant que leurs besoins pourraient avoir changé.%%% > – Vous êtes fortement dépendant du planning, que vous suivez souvent au détriment du résultat final.%%% > – Vous êtes fortement dépendant d’un chef de projet traçant la voie : le pouvoir à une seule personne.%%% > %%% > __Le Développement Itératif en Cascade__%%% > %%% > Cette approche comporte __moins de risque que l’approche classique en Cascade__, mais reste encore beaucoup __plus risquée et moins efficace que les approches plus Agile__.%%% > %%% > L’__accent est mis sur la livraison d’un sprint de tâches__, et s’oppose à la livraison d’un sprint de fonctionnalités à valeur ajoutée et potentiellement déployables.%%% > %%% > Le problème __le plus fréquent dans ce type de scénario (selon mon expérience) est le goulet d’étranglement__ (bottlenecking).%%% > %%% > Par exemple, vous livrez des portions de code, avec un peu d’avance (?), et vous laissez tout en l’état jusqu’à la dernière minute pour tout tester. __Un problème prend plus de temps que prévu à résoudre, finalement vous dépassez la date limite et vous ne livrez rien.__%%% > %%% > Un autre __symptôme fréquent de ce type d’approche est le sur-engagement__. C’est vraiment __difficile d’estimer l’effort__ (total) liées à une User Story / Fonctionnalité particulière lorsqu’on adopte ce mode de production/livraison.%%% > %%% > Vous êtes plus ou moins __forcé d’estimer chaque phase séparément__ (par exemple estimez le développement séparément des tests dans ce cas) : cela ne fonctionne pas puisque __les phases ne sont pas séparées, elles sont totalement imbriquées__.%%% > %%% > Si vous trouvez un problème lors des tests, vous devez revenir en phase de développement. Toute __l’équipe doit rester concentrée sur la livraison de la cible finale__, pas de phases séparées.%%% > %%% > Il est également intéressant de noter que __la vélocité et les burndowns sont loin d’être (voire pas du tout) utiles dans ce type d’environnement__.%%% > %%% > __Le Développement Scrum__%%% > %%% > Cette approche __comporte un risque beaucoup moins grand que les approches en Cascade__.%%% > %%% > Nous nous __concentrons sur la livraison de fonctionnalités entièrement testées, indépendantes, à valeur ajoutée et suffisamment petites__. En tant que tel, nous __diversifions notre risque__ : si l’une des fonctionnalités tourne mal, elle ne devrait pas en impacter une autre.%%% > %%% > Cela dit, nous __prévoyons encore du travail sous forme d’itérations__ et nous devrons __encore livrés à la fin de chaque itération__.%%% > %%% > __Le Développement Lean__%%% > %%% > Lean est très similaire à Scrum en ce sens que nous mettons __l’accent sur les fonctionnalités plutôt que sur des groupes de fonctionnalités__ : toutefois Lean va encore un peu plus loin.%%% > %%% > En Développement Lean, __vous choisissez, planifiez, développez, testez et déployez une fonctionnalité (sous sa forme la plus simple) avant de choisir, planifier, développer, tester et déployer la prochaine fonctionnalité__. En faisant cela, vous isolez encore plus les risques au niveau de chaque fonctionnalité.%%% > %%% > Dans ces environnements, __on cherche à éliminer le « gaspillage » autant que possible__ : vous ne produisez donc rien jusqu’à ce que vous sachiez que c’est nécessaire ou pertinent.%%% > %%% > ((/dotclear/public/./.the-difference-between-waterfall-iterative-waterfall-scrum-and-lean_t.jpg|The difference between Waterfall, Iterative waterfall, Scrum and Lean (by Agile101)||The difference between Waterfall, Iterative waterfall, Scrum and Lean)) > %%% > Pour voir le schéma dans sa taille normale, rendez-vous sur le ++[billet de l’auteur Tara Lee Whitaker|http://agile101.net/2009/09/08/the-difference-between-waterfall-iterative-waterfall-scrum-and-lean-in-pictures/|en]++

Pourquoi le temps de cycle peut-il en dire plus que la vélocité ?

[((/dotclear/public/logos/.crisp-logo_sq.jpg|Crisp.se|L|Crisp.se))|/dotclear/public/logos/crisp-logo.jpg]Je suis tombé sur un billet très intéressant sur le blog de ++[Crisp|http://blog.crisp.se/|en]++ : ++[« Why cycle time can tell you more than velocity »|http://blog.crisp.se/mattiasskarin/2009/09/06/1252262279228.html|en]++ de Mattias Skarin. Je l’ai traduit en français.%%% > Jetez un coup d’œil à cette courbe et dites-nous si tout va bien ? > > ((/dotclear/public/tc_team_velocity.png|Team velocity||Team velocity))%%% >  »Vélocité d’une super-équipe. Les nombre sont des semaines, les couleurs représentent différents types de tâches. » > > C’est assez dur … Il y a trop de variables qui peuvent fausser nos données. Avons-nous un problème avec nos estimations ? Ou l’homme / jours disponible est-il fluctuant ? Comment pouvons-nous le savoir ? > > Ce problème s’accentue si nous essayons de planifier des livraisons. Si l’on réussit tout de même à sortir un planning sur la base de cette vélocité, à quel niveau de prédictibilité peut-on s’attendre? > > Essayons de comprendre ce qui est en jeu pour améliorer la prédictibilité des versions. > > C’est en soi-même toute une aventure pour sûr 🙂 > > Regardons de plus près le problème : de quoi dépend la vélocité ? > > Essayons d’isoler certains facteurs :%%% > 1. l’Estimation (la difficulté à percevoir ce qui va être)%%% > 2. la Quantité de travail en cours (combien de choses à réaliser)%%% > 3. le Dimensionnement de l’Équipe (combien de personnes)%%% > 4. le Temps qu’il faut pour réaliser le plus petit fragment.%%% > > Il pourrait être possible en utilisant l’analyse statistique de dire lequel de ces facteurs a le plus d’impact. Mais cela n’entre pas dans l’objet de cet article. > > Je vais argumenter sur le fait qu’une forte variabilité de l’un de ces facteurs peut masquer la vision de nos réelles capacités. Pour ce faire, supposons un instant que nous n’avons que deux facteurs, l’Estimation et le Temps nécessaires pour mettre en œuvre le plus petit fragment (que nous appellerons notre capacité à livrer). > > [((/dotclear/public/./.tc_estimationdeliveryprocess_m.jpg|Estimation delivery process||Estimation delivery process))|/dotclear/public/tc_estimationdeliveryprocess.png] > > Ces courbes visent à démontrer visuellement comment la variance d’une série de stories s’ajoute à la vélocité. Les formules mathématiques montrent comment la variance est calculée pour une somme de deux variables. > > Il est donc possible que la variance de l’Estimation masque la variance de la Vélocité même si la capacité réelle à livrer est stable. > > Comment pouvons-nous alors vérifier notre processus de livraison (notre capacité réelle à livrer) ? Nous pouvons utiliser le temps de cycle. Le temps de cycle est moins influencé que la vélocité par les facteurs mentionnés ci-dessus. Bien sûr, il a une dépendance à la complexité (autrement dit, la taille de la story), mais même cela peut être traité en répartissant les stories dans les bonnes catégories. > > Pour une équipe de développement, la meilleure façon de mesurer le temps de cycle est de mesurer le temps de cycle entre le moment où une story est « En cours » (WIP) et le moment où elle est « Terminé » (Done). > > Et maintenant, nous pouvons faire le distinguo : > > ((/dotclear/public/tc_deliveryprocessintrouble.png|Delivery process in trouble||Delivery process in trouble)) > > Instable …. aucun espoir de s’engager sur des dates de livraison… > > ((/dotclear/public/tc_deliveryprocessisstable.png|Delivery process is stable||Delivery process is stable)) > > Ah, il y a un espoir… > > ((/dotclear/public/tc_velocityhowdoweknow.png|Velocity how do we know||Velocity how do we know)) > > Et…%%% > – Si le processus de livraison est stable%%% > – Si la variance des autres facteurs l’est également%%% > > … nous devrions être capables de faire de bonnes prévisions 🙂 C’est plus difficile qu’il n’y paraît… Pour cela nous avons besoin de comprendre et maîtriser au minimum la variance de l’Estimation. Mais même si nous ne pouvons pas la contrôler, il y a certaines actions que nous pouvons faire pour limiter la variance. J’espère revenir sur ce point dans un prochain billet 🙂 > > Résumons ce que nous avons appris :%%% > – La vélocité est souvent faussée et ne peut fournir d’informations pertinentes%%% > – Nous avons besoin d’autres moyens pour mieux déterminer notre capacité à livrer%%% > – Le Temps de cycle constitue l’un de ces moyens.%%%

Quelles sont vos pâtes préférées ?

((/dotclear/public/ravioli.jpg|Ravioli|L|Ravioli))Je me suis rappelé comment mon prof. de Génie Logiciel à la Fac. nous avait raconté l’évolution des concepts de la programmation :%%% – d’abord, la programmation __spaghetti__ avec le langage Basic et une large utilisation des gotos%%% – ensuite, la programmation __lasagne__ avec les langages C, Pascal, Fortran, … où un programme séquentiel est découpé en couches / modules (saisie des données d’entrée, traitement, affichage des résultats)%%% – enfin, la programmation __ravioli__ avec les langages orientés objet Smalltalk, C++, Eiffel, Java,… où chaque objet a son comportement propre et échange des messages avec les autres (le gruyère râpé ?).%%%