C3

Spécifications et Planning :éxecution dans un monde Agile

Stéphane TAVERA & Jacques COUVREUR

lundi 12 octobre 2009

agiletour.org/fr/at2009_geneve.html

USER STORIESPLANNING GAME

Spécifications et Planning : exécution dans un monde Agile

Agile Tour 2009 / GenèveJacques Couvreur Stéphane Tavera

jeudi, 15 octobre 2009

“To me, the most important single thing about XP and Agile as a management process is the continuous, visible, delivery of features as specified by the customer.”

Ron Jeffries, 10/21/2005jeudi, 15 octobre 2009La lecture des 12 principes derrière le manifeste Agile(http://agilemanifesto.org/principles.html) montre que cʼest le coeur des méthodes Agile : - délivrer régulièrement un logiciel qui a de la valeur pour le client

Itératif

jeudi, 15 octobre 2009Un développement itératif découpe le projet en itérations.La taille dʼune itération est généralement de 2 à 4 semaines.Cette taille doit être gardée fixe.

Incrémental

jeudi, 15 octobre 2009Un développement incrémental implique de découper le logiciel en fonctionalités “métier”.Cʼest le contraire du découpage traditionnel en réalisations de couches techniques. “Build the infrastructure as you need it”.

User Stories

Planning Poker

Standup meeting

Planning Gamejeudi, 15 octobre 2009Un petit peu de vocabulaire.SCRUM et XP implémentent tous 2 un mode de développement itératif et incrémental.

Des spécifications exhaustives...

jeudi, 15 octobre 2009Des documents Word de plusieurs centaines de pages en début de projet, dans un jargon incompréhensible.Cela vous rappelle quelque chose ?

USER STORY |ˈIOUZER STORIˈ|NOM (PL. -RIES)

UNITÉ DE FONCTIONALITÉ VISIBLE PAR LE CLIENT.

Kent Beck “eXtreme Programming explained” 2nd edition

jeudi, 15 octobre 2009Une User Story raconte ce que fera le système, dans le vocabulaire du client.Mettre en place une nouvelle version dʼune base de données nʼest pas une User Story.

User Story

Use Case=

jeudi, 15 octobre 2009Dans certains cas, une User Story peut coller avec un Use Case.Cependant, la User Story : - a un vocabulaire “métier” vs un vocabulaire “système”- cʼest lʼexpression dʼun but, pas la représentation idéale dʼune solution. - représente généralement plusieurs Use Cases

jeudi, 15 octobre 2009

Information Radiator

jeudi, 15 octobre 2009Un exemple dʼInformation Radiator.Lʼinformation nʼest pas enfermée dans un “frigidaire” (un outil qui demandeune recherche explicite).Au contraire, lʼinformation rayonne.

UNE FORMULATION POUR VOUS AIDER

As a customer,I want to withdraw cash from an ATM,so that I don’t have to wait in line at the bank.

jeudi, 15 octobre 2009Cette formalisation très “industrielle” a plusieurs avantage :- lʼemphase est mise sur lʼutilisateur. Différents utilisateurs peuvent avoirdes besoins *trés* différents ! - cette contrainte de formalisation permet de détecter des User Stories faibles : - trop vague, peu de valeur “métier”, imprécision du but recherché.

Il nʼest pas obligatoire de lʼemployer systématiquement.

Voir Behaviour Driven Development (BDD, cf références)Voir la technique “Personae”.

L’essence d’une User Story ?

jeudi, 15 octobre 2009

Pierre Boulangerdirigea Citroën de 1935 à 1950

“... possédant une suspension permettant de traverser un champ labouré avec un panier d'œufs sans en casser un seul,...”

jeudi, 15 octobre 2009Le besoin est exprimé, pas la solution.Le test est implicite.pour les plus curieux : http://fr.wikipedia.org/wiki/Citroën_2CV

C C Cjeudi, 15 octobre 2009

Card

Facile à manipuler,affichable sur un

”information radiator”.

jeudi, 15 octobre 2009Attention à ne pas suivre à la lettre.Card implique que ça doit tenir sur une carte. Un outil collaboratif, en ligne, peut sʼavérer plus pratique.

Ce qui est important cʼest lʼabsence de détails ici.

Conversation

Tous les détails ne sont pas présents dans la User Story.

La connaissance est transférée du “métier” vers l’équipe de développement pendant la

réalisation.

jeudi, 15 octobre 2009- le moyen le plus efficace de diffusion de lʼinfo est par le biais de dialogues, fréquents et réguliers. - des idées dʼamélioration peuvent survenir pendant cette discussion.

Aucune interdiction de faire référence à des documents, qui eux vont contenir des précisions complémentaires.(la solution idéale étant quand même dʼexprimer ces précisions par des tests dʼacceptation).

ConfirmationQuand pourra-t-on dire DONE/DONE ?

jeudi, 15 octobre 2009Lʼexpression Done/Done signifie complétement terminée.Pourrait-on vraiment mettre la User Story en production ?La User Story doit donc contenir des pointeurs vers des tests dʼacceptation.(cf le T. dʼINVEST)

Qualités d’une “bonne” User Story

jeudi, 15 octobre 2009

INVESTjeudi, 15 octobre 2009

INDEPENDENT

Tellement plus facile à “manipuler” !

jeudi, 15 octobre 20092 User Stories peuvent nʼavoir de la valeur que livrées ensemble.Par contre, elles doivent être “manipulées” dans lʼexercice de planification comme étant indépendantes.

NEGOTIABLELaisser la possibilité d’ajuster.

jeudi, 15 octobre 2009Attention aussi, à ce que chacun reste dans sa zone de responsabilité.Une User Story ne devrait pas contenir de détails techniques dʼimplémentation (“je veux ce bouton à 45 pixels du bord droit”).

De plus, préciser complétement les choses avant la réalisation peut aboutir à : - une divergence entre la réalisation et les specs - fermer la porte à des idées dʼamélioration ou dʼadaptation

VALUABLE

Le “métier” décide !

jeudi, 15 octobre 2009Même remarque : attention aussi, à ce que chacun reste dans sa zone de responsabilité.Une User Story ne doit pas être exprimée par lʼéquipe de développement.

Exemple : “Changer de version de librairie pour tel ou tel composant”.

ESTIMATABLE

“- Faites marcher le nouveau système comme l’ancien.

- Mais, hé ! Je n’en ai aucune idée! “ ?jeudi, 15 octobre 2009Lʼéquipe de développement doit avoir les éléments dʼinformation suffisantes pour estimer la complexité de réalisation.

SMALL

jeudi, 15 octobre 2009Une User Story dont la complexité est trop importante doit être scindée en User Stories plus petites.

TESTABLE

Je veux des beaux écrans. ?jeudi, 15 octobre 2009Qualité fondamentale !Peut-on vérifier la User Story par une suite de Tests dʼAcceptation ?Attention à lʼexpression dʼun besoin avec des termes subjectifs.

RSPEC/Cucumber (dans le monde Ruby) est un fantastique exemple.Un framework pour décrire (et exécuter) des tests dʼacceptation.

“Prediction is hard, especially about the future.”

Niels Bohrjeudi, 15 octobre 2009

puisque le futur est si difficile à prédire,

pourquoi ne pas regarder leyesterday’s weather ... ?

jeudi, 15 octobre 2009“Some country decides to build a sophisticated computer system to predict the weather. After spending more money than I can imagine, they come up with wonderful result - and proudly claim that the system is 70% accurate. Somebody then figures out that in this country if you predict today's weather will be the same as yesterday's weather you will be 69.5% accurate.”Se fier à des problèmes de difficultés similaires pour estimer.Ne pas espèrer de changement “radical” dʼune itération sur lʼautre.

ESTIMATIONS

User Story estimées en Story Points (pour déduire la velocité de l’équipe)

Estimation des tasks en Heures (pour détecter les goulots d’étranglements)

jeudi, 15 octobre 20092 niveaux dʼestimation.

Les User Stories sont estimées en Story Points.

Les tasks sont estimées en heures.Si vous pouvez mesurer le temps effectif passé sur chaque task,la comparaison avec son estimation révèlera les goulots dʼétranglements.

Estimer = comparer

jeudi, 15 octobre 2009Lʼutilisation dʼune échelle “à la Fibonacci” repose sur notre capacité à estimer des ordres de grandeur,et notre incapacité à être plus précis.

A quelle distance se trouve le 1er arbre ?A quelle distance se trouve le 1er immeuble ?Questions délicates !

Les arbres au premier plan sont-il “à peu près” à la même distance ? OUI.

STORY POINT

• Unité de taille relative utilisée pour estimer la difficulté/complexité d’une User Story.

• Utilisation d’une pseudo-échelle de Fibonacci. Par exemple : 1, 2, 3, 5 et 8

jeudi, 15 octobre 2009

Vos estimations en Story Point de chaque User Storyseront sans doute fausses, *individuellement*.En moyenne, cependant, ces erreurs se compensent.Après quelques itérations, vous devriez avoir *confiance* dans votre capacité à délivrerX fonctionnalités en une itération.

PLANNING POKER

• Une conversation pour obtenir un consensus sur les estimation des User Stories.Les participants sont les personnes en charge de la réalisation.

jeudi, 15 octobre 2009Ce jeu est un déclencheur de conversations, de confrontations de points de vue sur le travail à faire.

Pour yvoir plusclair

jeudi, 15 octobre 2009

CHAQUE JOUR

daily scrum ou standup meeting (XP)1- Hier, j’ai travaillé sur ...2- Aujourd’hui, je vais faire ...3- Ce qui me retarde en ce moment, c’est...

jeudi, 15 octobre 2009

Burndown chart

PENDANT L’ITERATION

jeudi, 15 octobre 2009Le principe est simple.On note réguliérement le reste à faire (courbe rouge),sur un graphe qui comporte tout le travail à faire pour cette itération etla date de fin.La courbe orange représente un développement linéaire et idéal.

Cette courbe est aussi un révélateur de dysfonctionnements :cf http://alistair.cockburn.us/Earned-value+and+burn+charts

ENTRE CHAQUE ITERATION

RETROSPECTIVE

jeudi, 15 octobre 2009La rétrospective est une activité indispensable dans lʼAgilité.Inspect and Adapt !http://agile-alchemist.com/

La velocité est la seule mesurevisible par votre client

jeudi, 15 octobre 2009

     “The mind is not a vessel to be filled but a fire to be kindled.”Plutarch 46-119

jeudi, 15 octobre 2009

atelier

jeudi, 15 octobre 2009

ATELIER : PLANNING GAME

• Présentation

• 1/2 : création des user stories

• 1/2 : estimation

• conclusion

jeudi, 15 octobre 2009

• La vision : une maison d’été, livrée dans 1 an.

• Le nom : Le Pélican Rose

• Les personnaes :

• Jacques : aime les barbecues dans le jardin, le cinéma, travaille de temps en temps à la maison, du coup pas le temps de bricoler, branché high-tech, domotique et énergies propres.

• Stéphanie : aime la mer, faire la cuisine, prendre de longs bains mais ne passe pas beaucoup de temps dans la chambre. Infirmière de profession, c’est une obsédée de l’hygiène.

• Uminonaka : leur enfant, 1 ans 1/2. Dés qu’il voit de l’eau il fonce dessus !

• Moreno : le pote d’enfance, qui s’installe de temps en temps et fouille partout.

jeudi, 15 octobre 2009« Umi no naka » veut dire dans lʼeau (de mer) en japonais...

ATELIER : CONCLUSION

Conversation ⇒ Emergence

Story point ⇒ Convergence

jeudi, 15 octobre 2009

Tous ces changements !

jeudi, 15 octobre 2009

La valeur du planning dans un esprit XP n’est pas de rechercher une précision absolue au départ du projet.

Les buts recherchés sont - délivrer régulièrement selon les priorités “métier” - avoir une vision réaliste et temps réel de l’avancement- avoir confiance sur ce qui peut être effectivement délivré (après quelques itérations)

jeudi, 15 octobre 2009Abandon de la “fausse” précision dʼun calcul précis au niveau des tasks.Le planning nʼest pas figé, mais peut être réaménagé en fonction - des priorités “métier”- de la montée en connaissance de lʼéquipe de développement

La conversation est omni-présente.Elle permet de :

• faire émerger ce qui a vraiment de la valeur.

•diffuser efficacement la connaissance.

jeudi, 15 octobre 2009

REFERENCES

• http://agilemanifesto.org/principles.html

• http://www.mountaingoatsoftware.com/

• http://xprogramming.com/index.php

• http://xprogramming.com/xpmag/expCardConversationConfirmation

• Agile Estimating and Planning” and “User Stories Applied For Agile Software Development”http://www.mountaingoatsoftware.com/books

jeudi, 15 octobre 2009

REFERENCES

• http://dannorth.net/introducing-bdd

• Photos iStockPhoto, sauf 2cv http://image.blog.livedoor.jp/decobocobo/imgs/f/c/fc6424c1.jpg

• http://fr.wikipedia.org/wiki/Citroën_2CV

jeudi, 15 octobre 2009

merci aux sponsors !