Académique Documents
Professionnel Documents
Culture Documents
ScrumAndXpFromTheTrenches French
ScrumAndXpFromTheTrenches French
2007 C4Media Inc Tous droits rservs. C4Media, Editeur de InfoQ.com. Ce livre fait partie de la collection de livres InfoQ Enterprise Software Development. Pour plus dinformations ou pour commander ce livre ou dautres livres InfoQ, prire de contacter books@c4media.com. Aucune partie de cette publication ne peut tre reproduite, stocke dans un systme de recherche, ou transmise sous aucune forme ni aucun moyen, lectronique, mcanique, photocopiage, recodage, scanner ou autre sans que cela ne soit autoris par les Sections 107 ou 108 du Copyright Act 1976 des Etats-Unis, ni sans lautorisation crite pralable de lditeur. Les termes utiliss par les entreprises pour distinguer leurs produits sont souvent dclars comme des marques commerciales. Dans tous les cas o C4Media Inc. est informe dune telle dclaration, les noms de produits apparaissent avec une Majuscule initiale ou EN TOUTES LETTRES MAJUSCULES. Toutefois, les lecteurs devraient contacter les entreprises appropries pour des informations plus compltes au sujet des marques commerciales et de leur enregistrement. Rdacteur en chef: Diana Plesa Traducteurs:
Guillaume Mathias Bruno Orsier Emmanuel Etasse Christophe Bunn
http://bruno-orsier.developpez.com http://homoagilis.blogspot.com
Rfrence de la bibliothque du Congrs Cataloguing-inPublication : ISBN: 978-1-4303-2264-1 Imprim dans les Etats-Unis dAmrique
Remerciements
Le premier brouillon de ce papier a t tap en un week-end seulement, mais ce fut un sacr week-end ! Focalisation 150% :o) Merci ma femme Sophia et mes enfants Dave et Jenny pour avoir support mon asocialit ce week-end, et aux parents de Sophia, Eva et Jrgen, pour tre venus aider prendre en charge la famille. Merci galement mes collgues de Crisp Stockholm et aux gens sur le groupe yahoo scrumdevelopment pour avoir corrig le papier et pour mavoir aid lamliorer. Et, finalement, merci tous mes lecteurs qui ont fourni un flux constant de feedback utile. Je suis particulirement content dentendre que ce papier a incit autant dentre vous essayer le dveloppement de logiciels agile !
INTRO ............................................................................................................7 AVERTISSEMENT ..........................................................................................8 POURQUOI JAI ECRIT CECI ...........................................................................8 MAIS SCRUM, QU'EST-CE QUE C'EST ? ..........................................................9 COMMENT NOUS FAISONS LES BACKLOGS DE PRODUIT..........11 CHAMPS D'HISTOIRE SUPPLEMENTAIRES ....................................................13 COMMENT NOUS GARDONS LE BACKLOG DE PRODUIT A UN NIVEAU METIER ...................................................................................................................14 COMMENT NOUS PREPARONS LA REUNION DE PLANNING DU SPRINT.........................................................................................................16 COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT.............19 POURQUOI LE DIRECTEUR DE PRODUIT DOIT Y ASSISTER ............................19 POURQUOI LA QUALITE N'EST PAS NEGOCIABLE .........................................21 LES REUNIONS DE PLANNING DE SPRINT QUI S'ETERNISENT... .....................22 LORDRE DU JOUR DE LA REUNION DE PLANNING DE SPRINT ......................23 LE CHOIX DE LA DUREE DU SPRINT .............................................................24 LA DEFINITION DU BUT DU SPRINT .............................................................25 LE CHOIX DES HISTOIRES A INCLURE DANS LE SPRINT ................................26 COMMENT LE DIRECTEUR DE PRODUIT PEUT-IL EXERCER UNE INFLUENCE SUR LES HISTOIRES QUI IRONT DANS LE SPRINT ?........................................27 COMMENT LES EQUIPES CHOISISSENT-ELLES LES HISTOIRES A INCLURE DANS LE SPRINT? .................................................................................................29 POURQUOI NOUS UTILISONS DES FICHES.....................................................35 DEFINITION DE TERMINE ........................................................................38 LESTIMATION DE TEMPS AVEC LE POKER DE PLANNING ............................38 LA CLARIFICATION DES HISTOIRES .............................................................40 LA DECOMPOSITION DES HISTOIRES EN PLUS PETITES HISTOIRES................42 LA DECOMPOSITION DES HISTOIRES EN TACHES .........................................42 LE CHOIX DU LIEU ET LHEURE POUR LA MELEE QUOTIDIENNE...................44 OU TRACER LA LIMITE ? .............................................................................44 LES HISTOIRES TECHNIQUES .......................................................................45 SYSTEME DE SUIVI DE BUG VS. BACKLOG DE PRODUIT ...............................48 LA REUNION DE PLANNING DE SPRINT EST FINALEMENT TERMINEE !..........49 COMMENT NOUS COMMUNIQUONS SUR LES SPRINTS...............51
COMMENT NOUS FAISONS LES BACKLOGS DE SPRINT..............55 FORMAT DU BACKLOG DE SPRINT ...............................................................55 COMMENT LE TABLEAU DES TACHES FONCTIONNE .....................................57 EXEMPLE 1 - APRES LA PREMIERE MELEE QUOTIDIENNE ............................58 EXEMPLE 2 APRES QUELQUES JOURS .......................................................59 COMMENT LE BURNDOWN CHART FONCTIONNE .........................................61 LES SIGNAUX DAVERTISSEMENT DU TABLEAU DES TACHES ......................62 HE, ET LA TRAABILITE ?!..........................................................................64 ESTIMATIONS EN JOURS VS. HEURES...........................................................64 COMMENT NOUS ORGANISONS LE BUREAU DE LEQUIPE .......67 LE COIN CONCEPTION .................................................................................67 INSTALLEZ LEQUIPE ENSEMBLE ! ..............................................................69 GARDER LE DIRECTEUR DE PRODUIT A DISTANCE .......................................70 GARDER LES DIRECTEURS ET LES COACHS A DISTANCE ..............................70 COMMENT NOUS FAISONS LES MELEES QUOTIDIENNES..........73 COMMENT NOUS METTONS A JOUR LE TABLEAU DES TACHES .....................73 TRAITER AVEC LES RETARDATAIRES ..........................................................74 TRAITER AVEC JE NE SAIS PAS QUOI FAIRE AUJOURDHUI .....................75 COMMENT NOUS FAISONS LES DEMOS DE SPRINT......................77 POURQUOI NOUS INSISTONS POUR QUE TOUS LES SPRINTS FINISSENT PAR UNE DEMO ..................................................................................................77 CHECKLIST POUR LES DEMOS DE SPRINT ....................................................78 SOCCUPER DES CHOSES INDEMONTRABLES .........................................78 COMMENT NOUS FAISONS LES RETROSPECTIVES DE SPRINT 81 POURQUOI NOUS INSISTONS POUR QUE TOUTES LES EQUIPES FASSENT DES RETROSPECTIVES ........................................................................................81 COMMENT NOUS ORGANISONS LES RETROSPECTIVES .................................82 LA DIFFUSION DES ENSEIGNEMENTS TIRES ENTRE EQUIPES ........................83 CHANGER OU NE PAS CHANGER ..................................................................84 EXEMPLES DE CHOSES QUI PEUVENT REMONTER PENDANT LES RETROSPECTIVES ........................................................................................85 RELACHER LE RYTHME ENTRE LES SPRINTS ...............................87 COMMENT NOUS FAISONS LA PLANIFICATION DE RELEASE ET LES CONTRATS AU FORFAIT ...............................................................91 DEFINIR VOS SEUILS DACCEPTATION.........................................................91 ESTIMATION EN TEMPS DES ELEMENTS LES PLUS IMPORTANTS...................92 ESTIMER LA VELOCITE ...............................................................................94 TOUT METTRE ENSEMBLE DANS UN PLAN DE RELEASE ...............................95 ADAPTER LE PLAN DE RELEASE ..................................................................96 COMMENT NOUS COMBINONS SCRUM AVEC XP ..........................97
LA PROGRAMMATION EN BINOME ..............................................................97 LE DEVELOPPEMENT DIRIGE PAR LES TESTS (DDT) ..................................98 LA CONCEPTION INCREMENTALE..............................................................101 LINTEGRATION CONTINUE ......................................................................101 LA PROPRIETE COLLECTIVE DU CODE .......................................................102 UN ESPACE DE TRAVAIL INFORMATIF .......................................................102 LES NORMES DE CODAGE .........................................................................102 LE RYTHME SOUTENABLE / LE TRAVAIL ENERGISE ...................................103 COMMENT NOUS FAISONS LES TESTS............................................105 VOUS NE POUVEZ PROBABLEMENT PAS ELIMINER LA PHASE DE TESTS DACCEPTATION .......................................................................................105 MINIMISEZ LA PHASE DE TESTS DACCEPTATION......................................106 AUGMENTER LA QUALITE EN METTANT DES TESTEURS DANS LEQUIPE SCRUM .....................................................................................................107 AUGMENTER LA QUALITE EN EN FAISANT MOINS PAR SPRINT...................110 EST-CE QUE LES TESTS DACCEPTATION DEVRAIENT FAIRE PARTIE DU SPRINT ? ...................................................................................................110 DES CYCLES DE SPRINTS VS. DES CYCLES DE TEST DACCEPTATION .........111 NE DISTANCEZ PAS LE MAILLON LE PLUS LENT DE VOTRE CHAINE ...........115 RETOUR A LA REALITE .............................................................................116 COMMENT NOUS GERONS LES EQUIPES MULTI-SCRUM.........117 COMBIEN DEQUIPES FAUT-IL CREER........................................................117 SPRINTS SYNCHRONISES OU NON ? ........................................................120 POURQUOI NOUS AVONS INTRODUIT LE ROLE DU MENEUR DEQUIPE ..121 COMMENT NOUS AFFECTONS LES PERSONNES AUX EQUIPES.....................123 EQUIPES SPECIALISEES OU NON ?...........................................................124 REARRANGER LES EQUIPES ENTRE LES SPRINTS OU PAS ? ......................127 LES MEMBRES DEQUIPE A TEMPS PARTIEL...............................................128 COMMENT NOUS FAISONS LES SCRUMS-DE-SCRUMS................................129 INTERCALER LES MELEES QUOTIDIENNES .................................................131 LES EQUIPES DE POMPIERS .......................................................................132 PARTAGER LE BACKLOG DE PRODUIT OU PAS ?......................................133 BRANCHES DE CODE .................................................................................138 RETROSPECTIVES MULTI-EQUIPES ............................................................139 COMMENT NOUS GERONS LES EQUIPES GEOGRAPHIQUEMENT DISPERSEES ...............................................141 DELOCALISER OFFSHORE .........................................................................142 QUIPIERS TRAVAILLANT DE LA MAISON .................................................144 PENSE-BETE DU SCRUM MASTER ....................................................145 DEBUT DU SPRINT ....................................................................................145 TOUS LES JOURS .......................................................................................145 FIN DU SPRINT..........................................................................................146
ii | SCRUM ET XP DEPUIS LES TRANCHEES itratif est fondamental dans le Manifeste Agile - dlivrer tt et frquemment du logiciel qui marche. Aprs des annes de rtrospectives avec des centaines d'quipes Scrum, Nokia a dvelopp des exigences de base pour le dveloppement itratif : Les itrations doivent tre de dure fixe et infrieure six semaines. Le code la fin de l'itration doit tre test par le AQ et doit fonctionner correctement.
Sur les 30 personnes qui prtendaient appliquer Scrum, seulement la moiti affirmait se conformer au premier principe du Manifeste Agile sur les standards Nokia. J'ai ensuite demand s'ils suivaient les standards Nokia pour Scrum : Une quipe Scrum doit avoir un Directeur de produit et doit savoir qui c'est. Le Directeur de produit doit grer un Backlog de produit avec des estimations fournies par l'quipe. L'quipe doit avoir une Courbe du reste faire et doit connatre sa vlocit. Aucune personne extrieure ne doit interfrer avec l'quipe durant le Sprint.
L'apport du livre d'Henrik est que, si vous suivez les pratiques dcrites, vous aurez un Directeur de produit, des estimations pour votre Backlog de produit, une Courbe du reste faire, et vous connatrez la vlocit de votre quipe ainsi que de nombreuses autres pratiques essentielles pour un Scrum dangereusement oprationnel. Vous passerez le test Nokia pour Scrum et serez digne de l'investissement dans votre travail. Si vous tes une startup, vous pouvez mme bnficier du financement d'une socit capital-risque. Vous serez peut-tre le futur du dveloppement logiciel et le crateur d'une nouvelle gnration d'minents logiciels. Jeff Sutherland, Ph.D., Co-Crateur de Scrum
INTRO | iii
Cest par cette focalisation sur le faire plutt que le thoriser que se distingue ce livre. Il est facile de sapercevoir que Henrik Kniberg la bien compris ds le dbut. Il ne fait pas de longs discours sur ce quest Scrum ; pour a, il se rfre des sites faciles comprendre. Au lieu de cela, Henrik entre dans le vif du sujet et commence directement dcrire comment son quipe gre et travaille son carnet de produit. A partir de l, il parcourt tous les autres lments et les pratiques dun projet agile bienportant. Pas de thorie. Pas de rfrence. Pas de note de bas de page. Aucun besoin de cela. Le livre dHenrik nest pas un expos philosophique expliquant pourquoi Scrum marche ou pourquoi vous voudriez utiliser ceci ou cela. Il sagit dune description sur comment une certaine quipe agile efficace travaille.
Cest pour cette raison que le sous-titre du livre, Comment nous appliquons Scrum , est si appropri. Ce nest peut-tre pas la faon dont vous appliquez Scrum, cest comment lquipe dHenrik applique Scrum. Il se peut que vous vous demandiez pourquoi vous devriez vous intresser la faon dont une autre quipe applique Scrum. Vous devriez vous y intresser car nous pouvons tous apprendre amliorer notre pratique de Scrum en tirant partie des expriences des autres, spcialement lorsquils le font bien. Il ny a pas et il ny aura jamais de liste des meilleures pratiques Scrum car le contexte de lquipe et du projet prvaut sur toute autre considration. A la place, ce que nous avons besoin de savoir, ce sont les bonnes pratiques et les contextes dans lesquels elles ont russi. Lisez assez de tmoignages dquipes qui russissent et comment elles se sont dbrouilles et vous serez prpar pour affronter les obstacles survenus sur votre chemin durant votre mise en uvre de Scrum et XP.
Henrik fournit une multitude de bonnes pratiques ainsi que lindispensable contexte pour nous aider mieux comprendre comment appliquer Scrum et XP dans les tranches de nos propres projets. Mike Cohn Auteur de Agile Estimating and Planning et User Stories Applied for Agile Software Development.
1
Intro
Vous tes sur le point d'utiliser Scrum dans votre organisation. Ou peuttre vous avez dj utilis Scrum pendant quelques mois. Vous avez les bases, vous avez lu les livres, peut-tre que vous avez mme obtenu votre certification de Scrum Master. Flicitations ! Mais pourtant vous ressentez de la confusion. Selon les mots de Ken Schwaber, Scrum n'est pas une mthodologie, c'est un cadre. Ce qui signifie que Scrum ne va pas rellement vous dire exactement ce que vous devez faire. Zut. La bonne nouvelle c'est que je vais vous dire comment je pratique Scrum, dans les plus petits dtails. La mauvaise nouvelle est qu'il s'agit uniquement de comment je pratique Scrum. Cela ne signifie pas que vous devriez faire exactement la mme chose. En fait je pourrais mme le faire d'une autre manire si je rencontrais une autre situation. La force et la douleur de Scrum est que vous tes obligs de l'adapter votre situation particulire. Mon approche actuelle de Scrum est le rsultat d'une anne d'exprimentation dans une quipe de dveloppement d'environ 40 personnes. L'entreprise tait dans une situation difficile avec beaucoup d'heures de travail supplmentaires, de graves problmes de qualit, des incendies teindre constamment, des dates de livraison manques, etc. L'entreprise avait dcid d'utiliser Scrum, mais n'avait pas termin son implmentation, ce qui devait tre mon travail. Pour la plupart des membres de l'quipe de dveloppement l'poque, Scrum tait juste un trange mot la mode entendu de temps en temps dans les couloirs, sans relle implication sur leur travail quotidien.
8 | SCRUM ET XP DEPUIS LES TRANCHEES Sur une anne nous avons implment Scrum travers toutes les couches de l'entreprise, essay diffrentes tailles d'quipe (3-12 membres), diffrentes dures d'itration (2-6 semaines), diffrentes manires de dfinir termin , diffrents formats pour les carnets de produit et les carnets de d'itration (Excel, Jira, cartes d'index), diffrentes stratgies de test, diffrentes faons de faire les dmonstrations, diffrentes manires de synchroniser des quipes Scrum multiples, etc. Nous avons galement expriment avec les pratiques XP - diffrentes manires de faire l'intgration continue, la programmation en binme, le dveloppement dirig par les tests, etc., et comment les combiner avec Scrum. C'est un processus d'apprentissage constant, donc l'histoire ne s'arrte pas ici. Je suis convaincu que cette entreprise va continuer d'apprendre (s'ils poursuivent les rtrospectives de fin d'itration) et de dcouvrir de nouvelles ides sur les meilleures manires d'implmenter Scrum dans leur contexte particulier.
Avertissement
Ce document ne prtend pas reprsenter la bonne manire de pratiquer Scrum. Il reprsente seulement une faon de pratiquer Scrum, le rsultat d'une anne de perfectionnement constant. Vous pourriez mme dcider que nous avons tout faux. Tout le contenu de ce document reflte mes opinions personnelles et subjectives, et n'est en aucune faon une dclaration officielle de Crisp ou de mon client actuel. Pour cette raison j'ai intentionnellement vit de mentionner des personnes ou des produits spcifiques.
INTRO | 9
J'espre que ce papier va susciter un feedback utile de la part de ceux qui sont dans la mme situation. Eclairez-moi s'il vous plat !
2
Comment nous faisons les backlogs de produit
Le Backlog de produit est le cur de Scrum. C'est l o tout commence. Le Backlog de produit est en gros une liste priorise d'exigences, d'histoires, de caractristiques ou autre. Des choses que le client veut, dcrites selon la terminologie du client. Nous appelons a des histoires, ou parfois simplement des lments du backlog. Nos histoires incluent les champs suivants : ID - un identifiant unique, juste un nombre auto-incrment. Cela vite de perdre la trace des histoires quand on les renomme. Nom - Un nom, une description courte de l'histoire. Par exemple Voir l'historique de ses transactions . Suffisamment claire pour que les dveloppeurs et le directeur de produit comprennent approximativement de quoi ils parlent, et suffisamment claire pour la distinguer des autres histoires. Normalement 2 10 mots. Importance - l'importance attribue par le directeur de produit cette histoire. Par exemple 10. Ou 150. leve = plus important. o Je fais attention d'viter le terme priorit parce que la priorit 1 est typiquement considre comme la plus haute priorit, ce qui est dommage si plus tard vous dcidez que quelque chose d'autre est encore plus important. Quelle priorit devrait-on lui attribuer ? Priorit 0 ? Priorit -1 ?
Estimation initiale - l'valuation initiale de l'quipe sur la quantit de travail qui est ncessaire pour implmenter cette
12 | SCRUM ET XP DEPUIS LES TRANCHEES histoire par rapport aux autres histoires. L'unit est les points d'histoire et correspond habituellement peu prs des jourshommes idaux . o Demandez l'quipe si vous pouvez prendre le nombre optimal de personnes pour cette histoire (ni trop peu ni trop nombreux, typiquement 2), et que vous vous enfermez dans une salle avec plein de nourriture et que vous travaillez sans jamais tre drang, aprs combien de jours sortiriez-vous avec une implmentation finie, dmontrable, teste, et livrable ? . Si la rponse est avec 3 gars enferms dans une salle a prendrait approximativement 4 jours alors l'estimation initiale est de 12 points d'histoire. Le point important n'est pas d'obtenir des estimations absolues correctes (c'est--dire que 2 points d'histoire devraient prendre 2 jours), le point important est d'avoir des estimations relatives correctes (c'est--dire que 2 points d'histoire devraient ncessiter peu prs la moiti du travail de 4 points d'histoire). Comment le dmontrer - une description succincte de comment cette histoire sera dmontre la dmo de fin d'itration. C'est essentiellement la spcification d'un test simple. Fais ci, ensuite fais a, puis ceci devrait arriver . Si vous pratiquez le DDT (Dveloppement Dirig par les Tests) cette description peut tre utilise comme du pseudo-code pour vos tests d'acceptance. Notes - n'importe quelle autre info, des clarifications, des rfrences aux autres sources d'info, etc. Normalement trs bref. o
BACKLOG DE PRODUIT (exemple) ID Nom Imp Est Dmo. 1 Dpt 30 5 Authentification, ouvrir la page de dpt, dposer 10, aller sur la page du solde et vrifier que a a bien augment de 10. 2 Voir 10 8 Authentification, l'historique cliquez sur de ses transactions .
Notes Ncessite un diagramme de squences UML. Ne pas se soucier du cryptage pour l'instant. Utiliser la pagination pour viter
Nous avons expriment beaucoup d'autres champs, mais la fin, les six champs ci-dessus taient les seuls que nous utilisions sprint aprs sprint. Nous faisons habituellement un document Excel avec le partage activ (c'est--dire que plusieurs utilisateurs peuvent modifier le fichier en mme temps). Officiellement le directeur de produit possde ce document, mais nous ne voulons pas verrouiller l'accs aux autres utilisateurs. Rgulirement un dveloppeur veut ouvrir le document pour clarifier quelque chose ou changer une estimation. Pour la mme raison, nous ne plaons pas le document dans le dpt de contrle de version ; nous le plaons dans un rpertoire partag plutt. Ceci semble la manire la plus simple d'autoriser les modifications simultanes sans causer des verrous ou des conflits de rconciliation. Cependant, presque tous les autres artefacts sont placs dans le systme de contrle de version.
14 | SCRUM ET XP DEPUIS LES TRANCHEES souhaitez rendre plus facile pour chaque quipe de dcider quelles histoires prendre. Demandeur - le directeur de produit peut vouloir garder une trace de quel client ou quelle partie prenante avait demand cet lment l'origine, dans le but de les informer sur l'avancement. ID de suivi de bug - si vous avez un systme de suivi des bogues spar, comme nous faisons avec Jira, il est utile de garder une trace de toute correspondance directe entre une histoire et un ou plusieurs bogues.
3
Comment nous prparons la runion de planning du sprint
OK, le jour de planification du sprint arrive rapidement. Une leon que nous rapprenons sans cesse est : Leon : Faites en sorte que le backlog de produit soit en ordre avant cette runion de planification du sprint. Et qu'est-ce que cela signifie ? Que toutes les histoires doivent tre parfaitement dfinies ? Que toutes les estimations doivent tre correctes ? Que toutes les priorits doivent tre fixes ? Non, non et non ! Tout ce que cela veut dire est :
le backlog de produit devrait exister ! (imaginez que non ?) il devrait y avoir un backlog de produit et un directeur de produit (par produit bien sr) un niveau d'importance devrait avoir t attribu tous les lments importants, et ces niveaux devraient tre diffrents. o En fait, c'est OK si les lments de plus faible importance ont le mme niveau, puisqu'ils ne seront probablement pas mentionns durant la planification de sprint de toute manire. o Si le directeur de produit croit qu'une histoire a une probabilit (mme trs faible) d'tre adopte dans la prochaine itration, alors cette histoire devrait avoir un niveau d'importance unique. o Le niveau d'importance est utilis uniquement pour trier les lments par importance. Donc si l'lment A a une importance de 20 et l'lment B une importance de 100, cela signifie simplement que B est plus important que A. Cela ne signifie pas que B est cinq fois plus important que A. Si B avait pour niveau d'importance 21, cela signifierait exactement la mme chose !
COMMENT NOUS PREPARONS LA REUNION DE PLANNING DE SPRINT | 17 Il est utile de laisser des trous dans la squence des niveaux pour le cas o un lment C arrive et est plus important que A mais moins important que B. Bien sr vous pourriez utiliser un niveau d'importance de 20,5 mais cela devient dplaisant, donc nous laissons des trous la place ! le directeur de produit devrait comprendre chaque histoire (normalement il en est l'auteur, mais il arrive que d'autres personnes ajoutent des demandes, dont le directeur de produit peut choisir la priorit). Il n'a pas besoin de savoir exactement ce qui doit tre implment, mais il devrait comprendre pourquoi l'histoire est l.
o
Note : d'autres personnes que le directeur de produit peuvent ajouter des histoires au backlog de produit. Mais elles n'ont pas attribuer un niveau d'importance, seul le directeur de produit en a le droit. Elles n'ont pas ajouter d'estimations non plus, seule l'quipe en a le droit. Voici d'autres approches que nous avons essayes :
Utiliser Jira (notre systme de suivi de bugs) pour hberger le backlog de produit. Toutefois la plupart de nos directeurs de produit ont trouv qu'il fallait trop de clics pour l'utiliser. Excel est agrable et facile manipuler directement. Vous pouvez facilement utiliser des codes de couleur, rarranger les lments, ajouter de nouvelles colonnes ad-hoc, ajouter des notes, importer et exporter des informations, etc. Utiliser un outil de support de processus agile comme VersionOne, ScrumWorks, XPlanner, etc. Nous n'avons pas encore trouv le temps d'en tester un, mais nous le ferons probablement.
4
Comment nous faisons les plannings de sprint
Le planning de sprint est une runion critique, probablement l'vnement le plus important dans Scrum (d'aprs mon opinion subjective bien sr). Une runion de planning de sprint mal excute peut perturber un sprint complet. Le but de la runion de planning de sprint est de donner l'quipe suffisamment d'informations pour qu'elle soit capable de travailler paisiblement, sans drangements pendant quelques semaines, et de donner au directeur de produit suffisamment de confiance pour les laisser faire. OK, c'est un peu flou. Concrtement, la fin de cette runion on doit avoir : Un but pour le sprint. Une liste des membres d'quipe (et de leur niveau d'engagement, si ce n'est pas 100%). Un backlog de sprint (= une liste des histoires incluses dans le sprint). Une date bien dfinie pour la dmonstration. Une heure et un lieu bien dfinis pour la mle quotidienne.
20 | SCRUM ET XP DEPUIS LES TRANCHEES histoire contient trois variables qui dpendent fortement les unes des autres.
La porte et l'importance sont dtermines par le directeur de produit. L'estimation est dtermine par l'quipe. Durant une runion de planning de sprint, ces trois variables sont affines continuellement grce au dialogue face--face entre l'quipe et le directeur de produit. Normalement le directeur de produit commence la runion en rsumant son but pour le sprint et les histoires les plus importantes. Ensuite l'quipe parcourt chaque histoire et estime le temps qu'il faudra pour la raliser, en commenant par la plus importante. Pendant qu'ils font a, ils auront des questions importantes sur la porte est-ce que cette histoire de suppression d'utilisateur comprend le fait de parcourir chaque transaction en attente pour cet utilisateur, et de l'annuler? Dans certains cas les rponses surprendront l'quipe et la conduiront changer son estimation. Dans d'autres cas l'estimation du temps pour une histoire ne sera pas ce que le directeur de produit attendait. Cela peut le conduire changer l'importance de l'histoire. Ou changer la porte de l'histoire, ce qui conduira l'quipe r-estimer, etc, etc. Ce type de collaboration directe est fondamental dans Scrum et en fait dans tout dveloppement logiciel agile. Que faire si le directeur de produit persiste dire qu'il n'a pas le temps de participer aux runions de planning de sprint ? Habituellement j'essaie les stratgies suivantes, dans l'ordre propos :
Essayer d'aider le directeur de produit comprendre pourquoi sa participation directe est cruciale, et esprer qu'il change d'avis. Essayer de convaincre quelqu'un de l'quipe de se porter volontaire pour servir de reprsentant du directeur de produit pendant la runion. Dire au directeur de produit : Puisque que vous ne pouvez pas venir, nous laisserons Jeff ici prsent vous
COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 21 reprsenter. Il aura les pleins pouvoirs pour changer la priorit et la porte des histoires pendant la runion. Je vous suggre de vous synchroniser avec lui le mieux possible avant la runion. Si Jeff ne vous convient pas comme reprsentant, merci de suggrer quelqu'un d'autre, condition que cette personne puisse rester avec nous pour toute la dure de la runion. Essayer de convaincre l'quipe de direction de dsigner un nouveau directeur de produit. Repousser le dmarrage du sprint jusqu' ce que le directeur de produit trouve le temps de participer la runion. En attendant, refuser de s'engager sur une quelconque livraison. Laisser l'quipe consacrer chaque jour ce qui lui parat le plus important ce jour-l.
La qualit externe est ce qui est peru par les utilisateurs du systme. Une interface utilisateur lente et pas intuitive est un exemple de mauvaise qualit externe. La qualit interne fait rfrence des points qui habituellement ne sont pas visibles par l'utilisateur, mais qui ont un profond effet sur la maintenabilit du systme. Des choses comme la cohrence de la conception, la couverture de test, la lisibilit du code, les remaniements (refactoring).
En gnral, un systme avec une qualit interne leve peut tout de mme avoir une qualit externe faible. Mais un systme avec une faible qualit interne aura rarement une qualit externe leve. Il est difficile de btir quelque chose de bien sur des fondations pourries. Je traite la qualit externe comme faisant partie de la porte. Dans certains cas il peut y avoir d'excellentes raisons pour livrer une version du systme qui aurait une interface utilisateur lente et peu lgante, et livrer ensuite une version nettoye plus tard. Je laisse ce compromis au directeur de produit, puisqu'il est responsable de dfinir la porte. Toutefois la qualit interne n'est pas sujette discussion. C'est la responsabilit de l'quipe de maintenir la qualit du systme dans toutes les circonstances et ceci est simplement non ngociable. Jamais. (Eh bien, OK, presque jamais)
22 | SCRUM ET XP DEPUIS LES TRANCHEES Alors comment faisons-nous la diffrence entre les problmes de qualit interne et ceux de qualit externe ? Considrons que le directeur de produit dise : OK les gars, je respecte votre estimation de temps de 6 points d'histoire, mais je suis certain que vous pouvez faire quelque chose de rapide pour a en moiti moins de temps pour peu que vous y rflchissiez. Aha ! Il est en train d'essayer d'utiliser la qualit interne comme variable. Comment je le sais ? Parce qu'il veut que nous rduisions l'estimation de l'histoire sans payer le prix de rduire la porte. Les mots quelque chose de rapide devraient dclencher une alarme dans votre tte... Et pourquoi est-ce que nous n'autorisons pas a ? Mon exprience est que sacrifier la qualit interne est presque toujours une trs trs mauvaise ide. Le temps conomis est largement dpass par le cot court et long terme. Une fois qu'une base de code est autorise commencer se dtriorer, il est trs difficile d'y remettre de la qualit plus tard. A la place, j'essaie de faire avancer la discussion vers la porte. Puisqu'il est important pour vous d'avoir cette fonctionnalit rapidement, pouvonsnous rduire sa porte pour qu'elle soit plus rapide implmenter ? Peuttre que nous pourrions simplifier la gestion d'erreur et avoir 'Gestion d'erreur avance' comme histoire utilisateur spare conserver pour plus tard ? Ou bien pouvons-nous rduire la priorit des autres histoires pour pouvoir nous focaliser sur celle-ci ? Une fois que le directeur de produit a appris que la qualit interne n'tait pas ngociable, il devient normalement assez bon manipuler les autres variables la place.
COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 23 Nous essayons de nous y tenir. Donc que faisons-nous quand la runion de planning de sprint en temps limit est proche de sa fin et qu'il n'y a pas signe d'un but de sprint ou d'un backlog de sprint ? Est-ce que nous courtons la runion ? Ou nous continuons pour encore une heure ? Ou nous arrtons la runion et continuons le jour suivant ? Cela arrive encore et toujours, en particulier pour les nouvelles quipes. Donc que faites-vous ? Je ne sais pas. Mais que faisons-nous? Oh, euh, eh bien, habituellement jcourte brutalement la runion. Point final. Laissons le sprint souffrir. Plus prcisment, je dis lquipe et le directeur de produit alors cette runion se finit dans 10 minutes. Nous navons pas grand-chose comme plan de sprint en fait. Est-ce que nous faisons avec ce que nous avons, ou bien est-ce nous organisons une autre runion de planning de sprint de 4 heures demain matin 8h ? Vous pouvez devinez ce quils rpondent :o) Jai essay de laisser la runion sterniser. Habituellement ca ne sert rien car les gens sont fatigus. Sils nont pas produit un plan de sprint dcent en 2-8 heures (ou autre limite de temps votre convenance), ils ny arriveront probablement pas en une heure de plus. Lautre option (organiser une nouvelle runion le jour suivant) nest pas mal non plus. Sauf que les gens sont gnralement impatients de dmarrer le sprint, et pas de passer encore quelques heures planifier. Donc jcourte. Et en effet le sprint souffre. Le ct positif, toutefois, est que lquipe a appris une leon de forte valeur, et la runion de planning de sprint suivante sera bien plus efficace. De plus les gens rsisteront moins quand vous proposerez une dure de runion quils auraient auparavant considre comme trop longue. Apprenez respecter vos limites de temps, apprenez dfinir des limites ralistes. Ceci sapplique la fois la dure des runions et des sprints.
24 | SCRUM ET XP DEPUIS LES TRANCHEES Runion de planning de sprint : 13:00 17:00 (10 minutes de pause toutes les heures) 13:00 13:30. Le directeur de produit dcrit le but du sprint et rsume le backlog de produit. Le lieu, la date et lheure de la dmonstration sont fixs. 13:30 15:00. Lquipe fait les estimations en temps, et dcompose les lments selon les besoins. Le directeur de produit met jour les niveaux dimportance selon les besoins. Les lments sont clarifis. Comment dmontrer est explicit pour chacun des lments les plus importants. 15:00 16:00. Lquipe slectionne les histoires inclure dans le sprint. Elle fait les calculs de vlocit pour se confronter la ralit. 16:00 17:00. On choisit le lieu et lheure pour la mle quotidienne (sils sont diffrents du dernier sprint). On poursuit la dcomposition des histoires en tches. Ce plan nest en aucune faon respect trop strictement. Le Scrum master peut allonger ou raccourcir ces limites de temps comme ncessaire au fur et mesure que la runion progresse.
COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 25 En gnral les directeurs de produit aiment les sprints courts et les dveloppeurs aiment les sprints longs. Donc la dure du sprint est un compromis. Nous avons beaucoup expriment ce sujet et avons dcouvert notre longueur favorite : 3 semaines. La plupart de nos quipes (mais pas toutes) font des sprints de 3 semaines. Cest assez court pour nous donner suffisamment dagilit dentreprise, et suffisamment long pour permettre lquipe davoir du dbit et de rcuprer des problmes qui surgissent au cours du sprint. Lune de nos conclusions est : faites des expriences avec la dure des sprints au dbut. Ne perdez pas trop de temps analyser, choisissez simplement une dure de sprint dcente, essayez l pour un sprint ou deux, puis changez cette dure. Toutefois, une fois que vous avez dcid quelle dure vous prfrez, tenez-y vous pour un bon moment. Aprs quelques mois dexprimentation, nous avons trouv que 3 semaines ctait bien. Donc nous faisons des sprints de 3 semaines, point final. De temps en temps cela va paratre lgrement trop long, de temps en temps lgrement trop court. Mais en gardant toujours cette dure, cela devient comme un battement de cur dentreprise, dans lequel tout le monde sinstalle confortablement. Il ny a pas de dbat au sujet de dates de livraison et autres parce que tout le monde sait que toutes les 3 semaines il y a une livraison, point final.
26 | SCRUM ET XP DEPUIS LES TRANCHEES Le but du sprint devrait rpondre la question fondamentale Pourquoi faisons-nous ce sprint ? Pourquoi est-ce que nous ne partons pas tous en vacances la place ? En fait un moyen dextraire un but de sprint du directeur de produit est de poser littralement cette question. Le but devrait tre quelque chose qui na pas dj t ralis. Impressionner le PDG peut tre un bon but, mais pas sil a dj t impressionn par le systme tel quil est maintenant. Dans ce cas tout le monde pourrait rentrer la maison et le but du sprint serait quand mme ralis. Le but du sprint peut sembler bte ou forc durant le planning de sprint, mais il sert souvent mi-sprint, quand les gens commencent devenir perplexes sur ce quils devraient faire. Si vous avez plusieurs quipes Scrum (comme nous) qui travaillent sur diffrents produits, il est trs utile de lister les buts de sprint de toutes les quipes sur une seule page de wiki (ou quivalent) et de les mettre un endroit bien visible, de telle sorte que tout le monde dans lentreprise (pas seulement le management de haut niveau) sache ce que lentreprise est en train de faire et pourquoi !
COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 27 Regardez limage ci-dessus. Chaque rectangle reprsente une histoire, trie par importance. Lhistoire la plus importante est au sommet de la liste. La taille de chaque rectangle reprsente la taille de cette histoire (cest--dire lestimation de temps en points dhistoire). La hauteur de la parenthse bleue reprsente la vlocit estime de lquipe, cest--dire combien de points dhistoire lquipe croit quelle pourra terminer durant le prochain sprint. Le backlog de sprint droite est un ensemble dhistoires du backlog de produit. Il reprsente la liste des histoires sur lesquelles lquipe va sengager durant ce sprint. Lquipe dcide combien dhistoires vont tre prises dans le sprint. Pas le directeur de produit ou qui que ce soit dautre. Cela soulve deux questions : 1. Comment lquipe dcide-t-elle quelles histoires inclure dans le sprint ? 2. Comment le directeur de produit peut-il influencer leur dcision ? Je vais commencer par la deuxime question.
Comment le directeur de produit peut-il exercer une influence sur les histoires qui iront dans le sprint ?
Supposons que nous avons la situation suivante durant une runion de planning de sprint.
Le directeur de produit est du que lhistoire D ne soit pas incluse dans le sprint. Quelles sont ses options durant la runion ?
28 | SCRUM ET XP DEPUIS LES TRANCHEES Une option est de redfinir les priorits. Sil donne llment D le plus haut niveau dimportance, lquipe sera oblige de lajouter en premier dans le sprint (et dans ce cas djecter lhistoire C).
La deuxime option est de changer la porte rduire la porte de lhistoire A jusqu ce que lquipe croie que lhistoire D va tenir dans le sprint.
La troisime option est de partager une histoire. Le directeur de produit pourrait dcider quil y a certains aspects de lhistoire A qui ne sont finalement pas si importants, et donc il partage A en deux histoires A1 et A2 avec des niveaux dimportance diffrents.
Comme vous le voyez, bien que le directeur de produit ne puisse normalement pas contrler la vlocit estime, il y a plusieurs moyens par lesquels il peut exercer une influence sur les histoires qui seront prises dans le sprint.
30 | SCRUM ET XP DEPUIS LES TRANCHEES Scrum master: Confiant 90% ? 50% ? Lisa & Tom: A peu prs 90%. Scrum master: OK, prenons D. Et si nous ajoutons lhistoire E ? Sam: Peut-tre. Scrum master: 90%? 50%? Sam: Je dirais plus proche de 50%. Lisa: Je ne suis pas sre. Scrum master: OK, alors ne la prenons pas. Nous nous engagerons pour A, B, C, et D. Nous finirons E bien sr si nous le pouvons, mais personne ne devrait compter dessus, du coup nous la laisserons en dehors du plan du sprint. Quen dtesvous? Tout le monde: OK! Lintuition marche plutt bien pour des petites quipes et des sprints courts.
COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 31 Notez que la vlocit effective est base sur les estimations initiales de chaque histoire. Les mises jour des estimations du temps de lhistoire faites durant le sprint sont ignores. Dj, jentends votre objection : En quoi est-ce utile ? Une vlocit basse ou leve peut dpendre de tout un tas de facteurs ! Des programmeurs stupides, des estimations initiales incorrectes, glissement de primtre, perturbations inattendues durant le sprint, etc. ! Je suis daccord, il sagit dun nombre approximatif. Mais cela reste un nombre utile, spcialement quand il est compar rien du tout. Il vous donne de solides faits. Quelles que soient les raisons, voici la diffrence entre combien nous avions pens pouvoir faire et combien nous avons rellement pu finir. Que dire dune histoire qui est presque finie durant un sprint ? Pourquoi ne pas compter les points partiellement accomplis pour celle-ci dans notre vlocit effective ? Eh bien cest pour souligner le fait que Scrum (en fait le dveloppement logiciel agile et le lean manufacturing en gnral) est entirement focalis sur lobtention de quelque chose de compltement termin, pouvant tre livr ! La valeur dune chose moiti fini est zro (peut-tre en fait mme ngative). Lisez Managing the Design Factory de Donald Reinertsen ou un des livres des Poppendieck pour en savoir plus sur le sujet. Alors travers quel arcane magique estimons-nous la vlocit ? Une faon trs simple destimer la vlocit est dtudier le pass de lquipe. Quelle a t leur vlocit durant les sprints passs ? Alors on fait lhypothse que la vlocit sera grosso modo la mme au prochain sprint. Cette technique est connue sous le nom de la mto de la veille. Cela est faisable seulement avec des quipes qui ont dj fait quelques sprints (des statistiques sont alors disponibles) et qui feront le prochain sprint de la mme faon, avec la mme taille dquipe et dans les mmes conditions de travail, etc. Bien sr ceci nest pas toujours le cas. Une variante plus sophistique consiste faire un simple calcul de ressource. Disons que nous planifions un sprint de 3 semaines (15 jours de travail) avec une quipe de 4 personnes. Lisa est en congs durant 2 jours. Dave est disponible seulement 50% et il sera en congs durant 1 jour. Mettant tout cela ensemble
cela nous donnes 50 jours-homme pour ce sprint. Est-ce cela notre vlocit estime ? Non ! Car notre unit destimation est le point dhistoire qui, dans notre cas, correspond peu prs autant de jours-homme idaux. Un jour-homme idal est un jour de travail, parfaitement efficace, sans perturbation, ce qui est rare. De plus, nous devons tenir compte de choses comme le travail inattendu qui va sajouter au sprint, des personnes malades, etc. Du coup, notre vlocit estime sera certainement infrieure 50. Mais de combien infrieure ? Nous utilisons cette fin le terme facteur de focalisation.
Le facteur de focalisation est une estimation indiquant quel point lquipe est concentre. Un faible facteur de focalisation devrait signifier que lquipe sattend avoir de nombreuses perturbations ou sattend ce que ses estimations soient trop optimistes. La meilleure faon de dterminer un facteur de focalisation raisonnable est de regarder le dernier sprint (ou mme mieux, la moyenne des quelques derniers sprints).
La vlocit effective est la somme des estimations initiales de toutes les histories qui ont t termines durant le dernier sprint. Disons que le dernier sprint a fait 18 points dhistoire avec une quipe de 3 personnes constitue de Tom, Lisa et Sam travaillant durant 3 semaines pour un total de 45 jours-homme. Et maintenant nous essayons davoir
COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 33 une ide de notre vlocit estime pour le sprint qui arrive. Pour compliquer les choses, un nouveau gars Dave rejoint lquipe pour ce sprint. Prenant en compte les congs et le reste nous obtenons 50 jourshomme pour le prochain sprint.
Notre vlocit estime pour le prochain sprint est donc de 20 points dhistoire. Cela veut dire que lquipe devrait rajouter des histoires au sprint jusqu cela atteigne environ 20.
Dans ce cas lquipe peut choisir les 4 histoires en tte pour un total de 19 points dhistoire, ou les 5 histoires en tte pour un total de 24 points. Disons quils choisissent 4 histoires, car cela est le plus proche de 20 points. En cas de doute, choisissez moins dhistoires. Comme ces 4 histoires font au total 19 points dhistoires, leur vlocit estime finale pour ce sprint est 19. La mto de la veille est une technique pratique mais utilisez la avec une dose de bon sens. Si le dernier sprint tait anormalement mauvais car la plupart des membres de lquipe tait malade pendant une semaine, alors il serait prudent de considrer que vous ne serez pas malchanceux une seconde fois et vous pourrez estimer un facteur de focalisation plus lev pour le prochain sprint. Si lquipe a mis en place rcemment un nouveau systme dintgration continu aussi rapide que la foudre, alors vous pouvez probablement augmenter le facteur de focalisation en raison de cela. Si une nouvelle personne va rejoindre lquipe, vous devez baisser le
34 | SCRUM ET XP DEPUIS LES TRANCHEES facteur de focalisation pour prendre en compte la formation de ce dernier, etc. Chaque fois que cela est possible, regardez en arrire de plusieurs sprints et faites la moyenne des chiffres afin dobtenir des estimations plus sres. Que faire si lquipe est compltement nouvelle et que vous navez aucune statistique? Observez le facteur de focalisation dautres quipes sous des conditions similaires. Que faire si vous navez pas sautre quipe observer? Devinez le facteur de focalisation. La bonne nouvelle est que votre intuition ne jouera que pour le premier sprint. Aprs cela vous aurez des statistiques, vous pourrez mesurer de faon continue et amliorer votre facteur de focalisation et la vlocit estime. Le facteur de focalisation que jutilise par dfaut pour les nouvelles quipes est gnralement 70%, car cest l que la plupart de nos quipes ont abouti au fil du temps.
COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 35 A la fin de la journe, lobjectif est simplement de dcider des histoires inclure dans le sprint. Le facteur de focalisation, la disponibilit des ressources, et la vlocit estime sont juste des moyens pour atteindre ce but.
Il sagit dune interface utilisateur suprieure compare au projecteur, car: Tout le monde se sent plus impliqu personnellement (plutt que juste le gars avec le clavier) Les gens sont debout et marchent autour => ils restent veills, plus en alerte
36 | SCRUM ET XP DEPUIS LES TRANCHEES Plusieurs histoires peuvent tre modifies en mme temps Changer la priorit est triviale il faut juste dplacer les fiches Aprs la runion, les fiches peuvent tre transfres directement vers la salle de lquipe et tre utilises comme panneau mural des tches (voir page 45 Comment nous faisons les backlogs de sprint) Vous pouvez soit les crire la main ou (comme nous le faisons habituellement) utiliser un simple script qui gnre des fiches imprimer directement partir du backlog de produit.
PS le script est disponible sur mon blog ici http://blog.crisp.se/henrikkniberg. Important: Aprs la runion de planification de sprint, notre Scrum master met jour le backlog de produit sous Excel, en respectant le moindre changement apport physiquement sur les fiches. Oui, il sagit dune lgre paperasserie administrative mais nous trouvons quelle est parfaitement acceptable en considrant quel point la runion de planification de sprint est efficace avec les fiches. Une remarque propos du champ Importance. Il sagit de limportance spcifie dans le backlog du produit sous Excel au moment de limpression. Lavoir sur la fiche rend facile le tri des fiches par ordre dimportance (en gnral nous mettons les lments les plus importants gauche, et les moins importants droite). Cependant, une fois que les fiches sont au mur vous pouvez ignorer le niveau dimportance et utiliser la place lordre dans lequel les fiches sont physiquement places. Si le Directeur de produit permute deux lments ne perdez pas de temps mettre jour le niveau dimportance sur le papier. Veillez seulement ce
COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 37 que le niveau dimportance soit mis jour dans le backlog du produit dans Excel lissue de la runion. Les estimations en temps sont gnralement plus facile faire (et plus prcis) si une histoire est dcoupe en tches. En fait nous utilisons le terme activit car le mot tches veut dire quelque chose de compltement diffrent en sudois :o) Cela est aussi agrable et facile faire avec nos fiches. Vous pouvez avoir lquipe qui se divise en binmes et qui dcoupe une histoire chacun, en parallle. Physiquement, nous faisons cela en ajoutant de petits post-its sous chaque histoire, chaque post-it correspondant une tche de cette historie.
Nous ne mettons pas jour le backlog du produit dans Excel avec notre dcoupage en tche, pour deux raisons : Le dcoupage en tches est gnralement tout fait phmre, i.e. les tches sont frquemment modifies et raffines durant le sprint, de telle sorte quil serait trop harassant de garder le backlog du produit synchronis dans Excel. Le Directeur de produit na pas besoin dtre impliqu ce niveau de dtail de toute faon.
38 | SCRUM ET XP DEPUIS LES TRANCHEES De la mme faon que les fiches, les post-its des tches peuvent tre directement rutilises dans le backlog de sprint (voir page 45 Comment nous faisons les backlogs de sprint)
Dfinition de termin
Il est important que le Directeur de produit et lquipe saccorde sur une dfinition claire de termin. Une histoire est-elle termine lorsque tout le code a t archiv ? Ou est-elle termine seulement quand elle a t dploye sur un environnement de test et vrifie par une quipe de test dintgration ? Chaque fois que cela est possible, nous utilisons la dfinition de termin prt dployer en production mais ds fois nous devons nous rabattre sur la dfinition de termin dploy sur serveur de test et prt pour le test dacceptation. Au commencement nous utilisions des checklists dtailles pour cela. Maintenant souvent nous disons juste une histoire est termine quand le testeur de lquipe Scrum le dit. Cest alors au testeur de sassurer que lintention du Directeur de produit est bien compris par lquipe, et que llment est assez termin pour satisfaire la dfinition requise de termin. Nous sommes venus raliser que toutes les histoires ne peuvent pas tre traites de la mme faon. Une histoire appele Formulaire de requte utilisateurs sera traite trs diffremment dune histoire nomme Guide des oprations. Dans le dernier cas, la dfinition de termin pourrait simplement tre accept par lquipe des oprations.Cest pourquoi le bon sens est souvent meilleur que les checklists formelles. Si la dfinition de termin vous semble souvent confuse (ce qui tait notre cas au dbut) vous devriez probablement avoir un champ dfinition de termin pour chaque histoire individuelle.
COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 39 Les histoires impliquent normalement plusieurs personnes et plusieurs sortes dexpertise (conception dinterface utilisateur, codage, test, etc.). Pour pouvoir fournir une estimation, un membre dquipe a besoin dune certaine comprhension de lhistoire. En demandant tout le monde destimer chaque lment, nous assurons que chaque membre dquipe comprend chacun des lments. Cela augmente la probabilit que les membres de lquipe vont saider mutuellement durant le sprint. Cela augmente galement la probabilit que des questions importantes sur lhistoire sont poses tt. En demandant tout le monde destimer une histoire nous dcouvrons souvent des situations o deux membres de lquipe ont des estimations extrmement diffrentes pour la mme histoire. Cest bien mieux de dcouvrir et discuter ce genre de choses le plus tt possible. Si vous demandez lquipe de fournir une estimation, normalement la personne qui comprend le mieux lhistoire va se lancer en premier. Malheureusement cela influence fortement les estimations de tous les autres. Il y a une excellente technique pour viter cela elle est appele poker de planning (terme invent par Mike Cohn je pense).
Chaque membre de lquipe reoit un jeu de 13 cartes comme montr cidessus. Chaque fois quune histoire doit tre estime, chaque membre de lquipe slectionne une carte qui reprsente son estimation de temps (en points dhistoire) et la place sur la table face cache. Quand tous les membres de lquipe ont termin, toutes les cartes sur la table sont
40 | SCRUM ET XP DEPUIS LES TRANCHEES rvles simultanment. De cette manire chaque membre de lquipe est forc rflchir par lui-mme au lieu de sappuyer sur lestimation de quelquun dautre. Sil y a un gros cart entre deux estimations, lquipe discute les diffrences et tente dlaborer une vision commune du travail impliqu par lhistoire. Ils peuvent mme faire une sorte de dcomposition en tches. Aprs, lquipe estime de nouveau. Cette boucle est rpte jusqu ce que les estimations convergent, cest--dire que toutes les estimations soient approximativement les mmes pour cette histoire. Il est important de rappeler aux membres de lquipe quils sont l pour estimer la quantit de travail total pour cette histoire. Pas seulement leur part du travail. Le testeur ne devrait pas estimer uniquement la quantit de travail de test. Notez que la suite des nombres nest pas linaire. Par exemple il ny a rien entre 40 et 100. Pourquoi ? Cest pour viter un faux sentiment de prcision pour les grandes estimations de temps. Si une histoire est estime a environ 20 points dhistoire, il nest pas pertinent de discuter si ce devrait tre 20 ou 18 ou 21. Tout ce que nous savons, cest que cest une grosse histoire et quelle est difficile estimer. Donc 20 est notre estimation la louche. Vous voulez des estimations plus dtailles ? Dcoupez lhistoire en histoires plus petites et estimez plutt les petites histoires ! Et non, vous ne pouvez pas tricher en combinant 5 et 2 pour faire un 7. Vous devez choisir soit 5 soit 8, il ny a pas de 7. Quelques cartes particulires : 0 = cette histoire est dj faite or cette histoire cest pratiquement rien, juste quelques minutes de travail . ? = Je nai aucune ide. Vraiment aucune. Tasse de caf = Je suis trop fatigu pour penser. Faisons une courte pause.
COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 41 produit fronce les sourcils et dit eh bien cest sympa, mais ce nest pas ce que jai demand ! Comment vous assurez vous que la comprhension dune histoire par le directeur de produit corresponde la comprhension de lquipe ? Ou que chaque membre de lquipe a la mme comprhension de chaque histoire ? Eh bien vous ne pouvez pas. Mais il y a quelques techniques simples pour identifier les incomprhensions les plus flagrantes. La plus simple des techniques est de sassurer que tous les champs sont bien remplis pour chaque histoire (ou plus prcisment, pour chaque histoire qui a suffisamment dimportance pour tre considre pour ce sprint). Exemple 1: Lquipe et le directeur de produit sont satisfaits du plan du sprint et sont prts terminer la runion. Le Scrum master dit attendez une seconde, cette histoire appele Ajouter un utilisateur, elle na pas destimation. Estimons-l ! Aprs quelques tours de poker de planning, lquipe saccorde sur 20 points tandis que le directeur de produit clate de colre Quest-ce que ca veut dire ? . Aprs quelques minutes de discussion anime, il savre que lquipe navait pas compris la porte de Ajouter un utilisateur, ils pensaient que cela signifiait une belle interface web pour ajouter, supprimer, et chercher des utilisateurs , tandis que le directeur de produit voulait juste dire ajouter des utilisateurs en faisant manuellement du SQL sur la BD . Ils estiment nouveau et tombent sur 5 points. Exemple 2: Lquipe et le directeur de produit sont satisfaits du plan du sprint et sont prts terminer la runion. Le Scrum master dit attendez une seconde, cette histoire appele Ajouter un utilisateur, comment faudrait-il la dmontrer ? . Quelques grommellements sensuivent, et aprs une minute quelquun se lve et dit eh bien, dabord on se connecte au site web, et puis mais le directeur de produit linterrompt en disant se connecter au site web ?! Non, non et non, cette fonctionnalit ne devrait pas du tout concerner le site web, ce devrait tre un bte petit morceau de script SQL pour les administrateurs . Le Comment dmontrer dune histoire peut (et devrait) tre trs court. Sinon vous ne finirez pas le planning du sprint temps. Essentiellement cest une description de haut niveau en franais de comment excuter manuellement le scnario de test le plus typique. Faire ceci, puis cela, et alors vrifier ceci .
42 | SCRUM ET XP DEPUIS LES TRANCHEES Jai remarqu que cette description simple fait souvent apparatre des incomprhensions importantes sur la porte dune histoire. Cest bien de les dcouvrir trs tt, nest-ce pas ?
Voici quelques observations intressantes : Les nouvelles quipes Scrum rechignent passer du temps dcouper lavance un lot dhistoires en tches comme cela. Certains ressentent cela comme une approche de type cycle en V. Pour les histoires bien comprises, cest tout aussi simple de faire ce dcoupage lavance que de le faire plus tard. Ce type de dcoupage rvle souvent du travail supplmentaire qui entrane une hausse de lestimation, ce qui par consquent donne un plan de sprint plus raliste. Ce type de dcoupage lavance rend les mles quotidiennes visiblement plus efficaces (voir page 74 Comment nous faisons les mles quotidiennes ). Mme si le dcoupage est imprcis et changera une fois le travail dmarr, les avantages ci-dessus restent valables. Donc nous essayons davoir une limite de temps pour la runion de planning de sprint suffisamment importante pour faire tenir tout cela, mais si nous manquons de temps nous laissons tomber (voir O tracer la limite ci-dessous). Note nous pratiquons le DDT (dveloppement dirig par les tests) ce qui en pratique signifie que la premire tche pour presque toutes les histoires
44 | SCRUM ET XP DEPUIS LES TRANCHEES est crire un test qui choue et la dernire tche est remaniement (refactor) (= amliorer la lisibilit du code et supprimer les duplications).
O tracer la limite ?
OK, le temps commence manquer. Parmi toutes les choses que nous voulons faire durant le planning de sprint, quest-ce nous laissons de ct si le temps manque ? Eh bien, jutilise la liste de priorits suivante :
COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 45 Priorit 1 : Un but de sprint et une date de dmonstration. Cest vraiment le minimum dont vous avez besoin pour dmarrer un sprint. Lquipe a un but, une date de fin et ils peuvent travailler directement partir du backlog du produit. Ca craint, bien sr, et vous devriez considrer srieusement de prvoir une nouvelle runion de planning demain, mais si vous devez vraiment dmarrer le sprint alors cela ira probablement. Pour tre honnte, toutefois, je nai jamais rellement dmarr un sprint avec aussi peu dinformations. Priorit 2 : Liste des histoires que lquipe a acceptes pour ce sprint. Priorit 3 : Estimations remplies pour chaque histoire du sprint. Priorit 4 : Comment dmontrer rempli pour chaque histoire du sprint. Priorit 5 : Les calculs de vlocit et de ressources, pour vrifier la vraisemblance de votre plan de sprint. Cela inclue la liste des membres de lquipe et leurs engagements (sinon vous ne pouvez pas calculer la vlocit). Priorit 6 : une heure et un lieu bien dfinis pour la mle quotidienne. Cela prend juste un moment pour dcider, mais si vous manquez de temps le Scrum master peut simplement le dcider aprs la runion et envoyer un mail tout le monde. Priorit 7 : Les histoires dcoupes en tches. Ce dcoupage peut sinon tre fait quotidiennement en conjonction avec les mles quotidiennes, mais cela va lgrement perturber le droulement du sprint.
46 | SCRUM ET XP DEPUIS LES TRANCHEES Installer un serveur de construction (build) en continu o Pourquoi il faut le faire : parce que cela conomise dnormes quantits de temps pour les dveloppeurs et rduit le risque de problmes dintgration de type bigbang la fin dune itration. Rdiger une vue densemble de la conception du systme o Pourquoi il faut le faire : parce que les dveloppeurs oublient sans arrt la conception globale, et par consquent crivent du code incohrent. Il faut un document qui montre une vue densemble pour garder tout le monde synchronis sur la conception. Remanier (refactor) la couche daccs aux donnes (DAO) o Pourquoi il faut le faire : parce que la couche daccs est devenue vraiment embrouille et cote du temps tout le monde cause de la confusion et des bugs pas ncessaires. Nettoyer le code va faire conomiser du temps tout le monde et va amliorer la robustesse du systme. Mettre jour Jira (systme de suivi de bugs) o Pourquoi il faut le faire : la version actuelle est trop bugge et lente, mettre jour fera conomiser du temps tout le monde. Sagit-il dhistoires au sens habituel ? Ou bien sagit-il de tches qui ne sont pas connectes une histoire particulire ? Qui les priorise ? Est-ce que le directeur de produit devrait tre impliqu dans ces choses ? Nous avons beaucoup expriment avec diffrentes manires de grer les histoires techniques. Nous avons essay de les traiter comme des histoires de premire classe, tout comme nimporte quelle autre. Cela nallait pas, en effet quand le directeur de produit priorisait le backlog de produit ctait comme comparer des pommes avec des oranges. En fait, pour des raisons videntes, les histoires techniques recevaient souvent une faible priorit avec des motivations du type oui les gars, je suis sr quun serveur de construction en continu est important et tout, mais commenons dabord par construire des fonctionnalits qui rapportent des sous, nest-ce pas ? Ensuite vous pourrez ajouter votre petit plaisir technique, OK ? . Dans certains cas le directeur de produit a raison, mais souvent il a tort. Nous avons conclus que le directeur de produit nest pas toujours qualifi pour tablir le bon compromis. Donc voici ce que nous faisons :
COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 47 1) Essayer dviter les histoires techniques. Rechercher vraiment un moyen de transformer une histoire technique en histoire normale avec une valeur mtier mesurable. De cette manire le directeur de produit a de meilleures chances de faire des compromis corrects. 2) Sil nest pas possible de transformer une histoire technique en histoire normale, voir si le travail peut tre fait en tant que tche dans une autre histoire. Par exemple remanier la couche daccs aux donnes pourrait tre une tche dans lhistoire diter lutilisateur , puisquelle implique la couche daccs. 3) Si les deux mthodes ci-dessus chouent, dfinir une histoire technique, et maintenir une liste spare de telles histoires. Permettre au directeur de produit de la voir mais pas de lditer. Utiliser les paramtres facteur de focalisation et vlocit estime pour ngocier avec le directeur de produit et obtenir un peu de temps dans le sprint pour implmenter les histoires techniques. Exemple (un dialogue trs similaire celui-ci sest pass durant lun de nos plannings de sprint). Equipe : Nous avons des trucs techniques faire. Nous voudrions passer 10% de notre temps a, cest--dire rduire le facteur de focalisation de 75% 65%. Est-ce OK ? Directeur de produit : Surement pas ! Nous navons pas le temps ! Equipe : Eh bien, regardez le sprint dernier (toutes les ttes se tournent vers les gribouillages de vlocit sur le tableau blanc). Notre vlocit estime tait de 80, et notre vlocit relle tait de 30, nest-ce pas ? Directeur de produit : Exactement ! Donc nous navons pas de temps pour faire des trucs techniques internes ! On a besoin de nouvelles fonctionnalits ! Equipe : Eh bien, la raison pour laquelle notre vlocit sest avre si mauvaise tait que nous avons pass normment de temps essayer dassembler des versions cohrentes pour le test . Directeur de produit : Oui, et alors ? Equipe : Eh bien, notre vlocit va probablement continuer tre aussi mauvaise si nous ne faisons pas quelque chose. Directeur de produit : Oui, et alors ? Equipe : Donc nous proposons de prendre environ 10% de ce sprint pour mettre en place un serveur de construction en continu et dautres choses qui vont enlever cette pine de lintgration.
48 | SCRUM ET XP DEPUIS LES TRANCHEES Cela va probablement augmenter notre vlocit dau moins 20% pour chaque sprint suivant, indfiniment ! Directeur de produit : Vraiment ? Alors pourquoi ne lavonsnous pas fait le sprint dernier ? Equipe : Euh parce que vous navez pas voulu Directeur de produit : Oh, hum, trs bien, alors on dirait que cest une bonne ide de le faire maintenant ! Bien sr lautre option est de laisser le directeur de produit en dehors du circuit ou de lui donner un facteur de focalisation non ngociable. Mais il ny a aucune excuse pour ne pas essayer de dabord atteindre un consensus. Si le directeur de produit est un gars comptent et raisonnable (et nous avons eu de la chance ici) je suggre de le garder aussi inform que possible, et de le laisser dcider les priorits globales. La transparence est lune des valeurs centrales de Scrum, nest-ce-pas ?
COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 49 3) La correction de bugs est considre comme tant en dehors du sprint, cest--dire que lquipe garde un facteur de focalisation suffisamment faible (par exemple 50%) pour garantir quils ont du temps pour corriger les bugs. On suppose alors que lquipe va passer un certain temps chaque sprint corriger des bugs enregistrs dans Jira. 4) Mettre le backlog de produit dans Jira (cest--dire enterrer Excel). Traiter les bugs comme nimporte quelle autre histoire. Nous navons pas rellement conclu quelle stratgie est la meilleure pour nous ; en fait cela varie dquipe en quipe et de sprint en sprint. Jai toutefois tendance prfrer la premire stratgie. Elle est simple et lgante.
5
Comment nous communiquons sur les sprints
Il est important de tenir au courant toute l'entreprise sur ce qui se passe. Autrement les gens se plaindront ou, pire, feront de fausses hypothses sur ce qui se passe. Pour cela nous utilisons une page d'information de sprint .
Parfois nous ajoutons aussi des informations qui expliquent comment chaque user story sera dmontre.
52 | SCRUM ET XP DEPUIS LES TRANCHEES Juste aprs la runion de planification d'itration, le ScrumMaster cre cette page, la dpose sur le wiki, et envoie un spam toute l'entreprise.
Nous avons aussi un tableau de bord sur notre wiki qui donne des liens vers toutes les itrations en cours.
En plus, le ScrumMaster imprime la page d'information de sprint et l'affiche sur le mur extrieur du bureau de l'quipe. De cette faon n'importe qui passant par l peut y jeter un il pour savoir ce que cette quipe est en train de faire. Comme cela indique aussi o et quand ont lieu la mle quotidienne et la dmonstration de sprint, cette personne sait o aller pour obtenir plus d'information. Quand l'itration approche de la fin, le ScrumMaster rappelle tout le monde la prochaine dmo.
COMMENT NOUS COMMUNIQUONS SUR LES SPRINTS | 53 Avec tout cela, personne n'a vraiment d'excuse pour ne pas savoir ce qui se passe.
6
Comment nous faisons les backlogs de sprint
Vous tes arriv jusque l ? Ouf, bon travail. Maintenant que nous avons termin la runion de planification du sprint et parl au monde entier de notre superbe nouveau sprint, il est temps pour le Scrum master de crer un backlog de sprint. Cela doit tre fait aprs la runion de planification du sprint, mais avant la premire mle quotidienne.
Vous pourriez utiliser un tableau blanc bien sr. Mais ce serait un peu du gchis. Si possible, gardez les whiteboards pour les brouillons de conception et utilisez les murs sans whiteboards pour les tableaux des tches. NOTE - si vous utilisez des post-its pour les tches, n'oubliez pas de les attacher avec du vrai scotch, ou vous retrouverez un jour tous vos post-its en tas sur le sol.
Vous pourriez bien sr ajouter toute sorte de colonnes. En attente pour les tests d'intgration par exemple. Ou Annul . Cependant avant que vous ne compliquiez les choses, rflchissez longuement. Est-ce que cet ajout est vraiment, vraiment ncessaire ? J'ai trouv que la simplicit est extrmement importante pour ce genre de choses, aussi je rajoute de la complexit que lorsque ne pas le faire devient trop coteux.
Comme vous pouvez le voir, trois tches ont t rserves , cest--dire que lquipe va travailler dessus aujourdhui. Parfois, pour de grandes quipes, une tche reste coince rserv car personne ne se souvient qui a travaill dessus. Si cela arrive frquemment dans une quipe elle adopte gnralement une politique dtiquetage des tches rserves en indiquant le nom de la personne qui la rserve.
Comme vous pouvez le voir, nous avons termin lhistoire dposer (cest--dire quelle a t enregistre dans le rfrentiel des sources, teste, refactore, etc). Loutil de migration est en partie fini, lhistoire back office login est commence, et le back office user admin nest pas entam. Nous avons 3 lments non planifis, comme vous pouvez le voir en bas droite. Cest utile pour se rappeler ce que lon a fait pour la rtrospective de sprint.
Ici cest lexemple dun vrai backlog de sprint approchant la fin du sprint. Il devient moins ordonn au fur et mesure que le sprint progresse, mais cest bon tant que a ne dure pas longtemps. A chaque nouveau sprint nous crons un nouveau backlog de sprint, tout propre.
Cette courbe montre que : Le premier jour du sprint, le 1er aot, lquipe a estim quil y avait approximativement 70 points dhistoire de reste faire. Cest en fait la vlocit estime du sprint entier. Le 16 aot lquipe estime quil y a approximativement 15 points dhistoire de reste faire. La ligne de tendance en pointills montre quils sont sur la bonne voie, cest--dire qu ce rythme ils auront tout fini dici la fin du sprint. Nous excluons les weekends sur laxe des abscisses puisque le travail est rarement fait le week-end. Nous avions lhabitude dinclure les weekends mais cela rend la courbe un peu confuse, car elle stagne les weekends ce qui ressemble un signal davertissement.
H, et la traabilit ?!
La meilleure traabilit que je peux offrir dans ce modle est de prendre une photo numrique du tableau des tches chaque jour. Si vous le devez. Je lai fait parfois mais je nai jamais eu besoin dutiliser ces photos. Si la traabilit est trs importante pour vous, alors peut-tre que le tableau des tches nest pas la solution qui vous convient. Mais je suggre dessayer destimer la valeur apporte par une traabilit dtaille du sprint. Une fois que le sprint est fini et que le code qui marche a t livr et que la documentation a t enregistre, est-ce que a intresse vraiment quelquun de savoir combien dhistoires taient termines au 5e jour du sprint ? Est-ce que a intresse vraiment quelquun de savoir quelle tait lestimation de temps pour crire un test qui choue pour Dposer ?
COMMENT NOUS FAISONS LES BACKLOGS DE SPRINT | 65 simplement laisse avec lestimation 0.5 (il nya pas grand mal surestimer un peu). Elgant et simple.
7
Comment nous organisons le bureau de lquipe
Le coin conception
Jai not que beaucoup de discussions de conception les plus intressantes et ayant le plus de valeur prennent place spontanment en face du tableau des tches. Pour cette raison, nous essayons darranger cet espace en coin conception.
Cest vraiment utile. Il ny a pas de meilleur moyen pour avoir une vue densemble du systme quen se tenant dans le coin conception, on peut
68 | SCRUM ET XP DEPUIS LES TRANCHEES jeter un il sur les deux murs, puis jeter un il sur lordinateur et essayer le dernier build du systme (si vous avez assez de chance pour avoir une intgration continue, allez voir p.100 Comment nous combinons Scrum et XP ). Le mur de conception est juste un grand tableau blanc contenant les schmas et les impressions des documents de conception les plus importants (diagrammes de squences, prototypes IHM, modles mtier, etc).
Ci-dessus : une mle quotidienne se passant dans le coin mentionn plus haut.
Hmmmm..... ce burndown semble trop parfait et trop droit, vous ne trouvez pas ? Mais lquipe insiste quil est authentique :o)
70 | SCRUM ET XP DEPUIS LES TRANCHEES Visibilit : Tout le monde peut voir tout le monde. Tout le monde peut voir le tableau des tches. Pas forcment assez prs pour pouvoir le lire, mais au moins le voir. Isolation : Si toute votre quipe se lve soudainement et engage une discussion spontane et anime sur la conception, il ny a personne dextrieur lquipe proximit qui pourrait tre perturb. Et vice versa.
LIsolation ne signifie pas que lquipe doit tre compltement isole. Dans un environnement de cabines ce serait suffisant si votre quipe avait sa propre cabine et des murs de cabine suffisamment pais pour filtrer la plupart du bruit extrieur. Et si vous avez une quipe distribue ? Vous navez pas de chance. Utilisez autant de moyens techniques que vous pouvez pour minimiser les dgts vido confrence, webcams, outils de partage de bureau, etc.
COMMENT NOUS ORGANISONS LE BUREAU DE LEQUIPE | 71 la plupart des gens pensent que ctait une bonne chose, car javais de lexprience avec le dveloppement logiciel agile. Mais, ensuite, jtais (dmarrez la musique de Dark Vador) le responsable des dveloppements, un rle de responsable fonctionnel. Ce qui signifie pour une quipe quelle devient automatiquement moins auto-organise. Heck, le chef est l, il a probablement des tas davis sur ce quon devrait faire et qui devrait le faire. Je vais le laisser parler. Mon avis est ; si vous tes Scrum coach (et peut-tre aussi un directeur), impliquez vous autant que possible. Mais seulement pour une priode limite, puis effacez-vous et laissez lquipe prendre forme et sautogrer. Surveillez lquipe de temps en temps (pas trop souvent) en assistant aux dmos de sprint et en regardant le tableau des tches et en coutant aux mles quotidiennes. Si vous voyez des points amliorer, prenez le Scrum master part et conseillez-le. Pas devant lquipe. Une autre bonne ide est dassister aux rtrospectives de sprint (voir p.82 Comment nous faisons les rtrospectives de sprint), Si votre quipe vous fait confiance, ne laissez pas votre prsence les intimider. Pour que les quipes Scrum fonctionnent bien, assurez-vous quils ont tout ce quil faut, puis restez lcart ( part pendant les dmos de sprint). .
8
Comment nous faisons les mles quotidiennes
Nos mles quotidiennes suivent peu prs le livre. Elles commencent exactement lheure, chaque jour la mme place. Au dbut nous allions dans une pice spare pour faire le sprint planning ( lpoque o nous utilisions des backlogs de sprint lectroniques), mais maintenant nous faisons les mles quotidiennes dans le bureau de lquipe pile en face du tableau des tches. Il ny a rien de mieux. Nous faisons les mles en nous tenant debout, ce qui diminue le risque de dpasser les 15 minutes.
Certaines quipes adoptent comme politique de mettre jour le tableau des tches avant chaque mle. Cela fonctionne aussi. Choisissez juste une politique est tenez-vous y.
74 | SCRUM ET XP DEPUIS LES TRANCHEES Indpendamment du format de votre backlog de sprint, essayez dimpliquer toute lquipe en gardant le backlog de sprint jour. Nous avons essay des sprints o le Scrum Master est le seul maintenir le backlog de sprint et o il doit faire le tour chaque jour et demander aux gens leurs estimations de reste faire. Les inconvnients de cette mthode: Le Scrum master passe trop de temps soccuper des tches administratives, au lieu de supporter lquipe et denlever des obstacles. Les membres de lquipe ne sont pas au courant du statut du sprint, puisquils nont pas besoin de prter attention au backlog de sprint. Ce manque de feedback rduit lagilit globale et la concentration de lquipe. Si le backlog de sprint est bien conu il devrait tre aussi facile pour chaque membre de le mettre jour lui-mme. Immdiatement aprs la mle quotidienne, quelquun additionne toutes les estimations de temps (en ignorant celles de la colonne termin bien sr) et marque un nouveau point sur la courbe du reste faire du sprint.
76 | SCRUM ET XP DEPUIS LES TRANCHEES de la section venir en bas droite du tableau des tches, et dplacezles vers la colonne non rserv . Puis refaites la mle quotidienne. Avertissez le directeur de produit que vous avez ajout des lments au sprint. Mais que faire si vous navez atteint lobjectif du sprint et que Joe et Lista continuent de refuser de se rendre utile. Je considre habituellement lune des stratgies suivantes (aucune delle nest lgante, mais il sagit dun dernier recours) : La honte : Bien si tu nas aucune ide de comment aider lquipe, je suggre que tu rentres chez toi, ou que tu lises un bouquin ou quelque chose dautre. Ou assied-toi jusqu ce quelquun tappelle pour laider. Vieille cole : Assignez leur simplement une tche. Pression collective : Dtes prenez tout votre temps Joe et Lisa, nous resterons l jusque vous trouviez quelque chose faire qui peut nous aider atteindre lobjectif Servitude : Dtes Bien, vous pouvez aider lquipe indirectement en tant les majordomes aujourdhui. Faites le caf, donnez des massages, nettoyez les poubelles, prparez le djeuner, et tout ce que nous pourrions demander durant la journe. Vous pourriez tre surpris par la vitesse laquelle Joe et Lisa russissent trouver des tches techniques utiles :o)
Si une personne vous force frquemment aller si loin, vous devriez probablement prendre cette personne part et faire du coaching pouss. Si le problme persiste, vous devez valuer si cette personne est importante pour votre quipe ou pas. Si elle nest pas importante, essayez de la dgager de votre quipe. Si elle est importante, alors essayez de la mettre en binme avec quelquun qui sera son berger . Joe est peut-tre un bon dveloppeur ou architecte, cest juste quil prfre vraiment que quelquun dautre lui dise quoi faire. Bien. Donnez Niklas la responsabilit dtre le berger permanent de Joe. Ou prenez cette responsabilit vous-mme. Si Joe est assez important pour votre quipe leffort sera moindre. Nous avons eu des cas comme a et a marchait plus ou moins bien.
9
Comment nous faisons les dmos de sprint
La dmo de sprint (ou revue de sprint comme certains lappellent) est une partie importante de Scrum que les gens ont tendance sous-estimer. Oh devons-nous vraiment faire cette dmo ? Il ny vraiment pas grandchose damusant montrer ! Nous navons pas le temps de prparer une &%$# de dmo! Je nai pas le temps dassister aux dmos des autres quipes !
Pourquoi nous insistons pour que tous les sprints finissent par une dmo
Une dmo de sprint bien faite, bien que a puisse sembler peu marquant, a un effet profond. Lquipe se voit attribuer le mrite pour le travail accompli. Ils se sentent bien. Les autres personnes dcouvrent ce que lquipe fait. La dmo donne un retour vital de la part des intervenants. Les dmos sont (ou devraient) tre un vnement social o les diffrentes quipes peuvent interagir entre elles et discuter de leur travail. Cela a de la valeur. Faire une dmo force lquipe terminer leur travail et le livrer (mme si cest seulement pour environnement de test). Sans dmo, nous garderions une norme pile de choses termine 99%. Avec les dmos nous avons peut-tre moins dlments termins, mais ils sont rellement termins, ce qui est (dans notre cas) une bien meilleure chose que davoir une pile entire de tches qui sont peu prs termins et qui pollueront le prochain sprint. Si lquipe est plus ou moins oblige de faire une dmo, si elle na pas quelque chose qui fonctionne vraiment, la dmo sera embarrassante.
78 | SCRUM ET XP DEPUIS LES TRANCHEES Lquipe bgaiera et hsitera pendant la dmo et les applaudissements ne seront qu moiti sincres. Les gens se sentiront dsols pour lquipe, et seront peut-tre irrit davoir gch du temps pour assister une dmo aussi nulle. Ca blesse. Mais leffet est comme une mdecine amre. Le prochain sprint, lquipe essaiera davoir des choses vraiment termines ! Ils se diront que bien, peut-tre nous ne pouvons montrer que 2 choses au prochain sprint au lieu de 5, mais merde cette fois a MARCHERA ! . Lquipe sait quelle aura faire une dmo, peu importe quoi, ce qui augmente les chances quil y ait quelque chose dutile montrer. Jai vu arriver cela plusieurs fois.
COMMENT NOUS FAISONS LES DEMOS DE SPRINTS | 79 Membre de lquipe : Jai install le systme sur un environnement de tests de performance, jai dmarr 8 serveurs de charge et jai stress le systme avec des requtes simultanes . Scrum master: Mais as-tu une indication comme quoi le systme peut supporter 10000 utilisateurs ? . Membre de lquipe : Oui. Les machines de test sont pourries, cependant elles ont support 50000 requtes simultanes pendant mon test . Scrum master: Comment le sais-tu ? Membre de lquipe (frustr): Ben jai ce rapport ! Vous pouvez voir par vous-mme, il montre comment le test tait configur et combien de requtes ont t lances ! Scrum master: Excellent ! Alors voil ta dmo . Montre juste le rapport et fais le passer dans laudience. Mieux que rien, non ? . Membre de lquipe : Ah, cest suffisant ? Mais cest moche, il faudrait le rendre plus prsentable.. Scrum master: OK, mais ny passe pas trop de temps. Ca na pas besoin dtre joli, juste informatif.
10
Comment nous faisons les rtrospectives de sprint
Pourquoi nous insistons pour que toutes les quipes fassent des rtrospectives
La chose la plus importante propos des rtrospectives est de sassurer quelles ont lieu. Pour certaines raisons, les quipes ne semblent pas toujours enclines faire des rtrospectives. Si on ne les aiguille pas dlicatement, la plupart des quipes laissent tomber la rtrospective et passent directement au sprint suivant. Il sagit peut-tre dun truc culturel en Sude, pas sr. Cependant, tout le monde semble daccord, les rtrospectives sont extrmement utiles. En fait, je dirais que la rtrospective est la seconde partie la plus importante de Scrum (la premire tant la runion de planification de sprint) parce que cest la meilleure chance de vous amliorer ! Bien sr, vous navez pas besoin dune runion de rtrospective pour avoir de bonnes ides, vous pouvez le faire dans votre baignoire la maison ! Mais lquipe va-t-elle accepter votre ide ? Peut-tre, mais la probabilit davoir ladhsion de lquipe est beaucoup plus importante si lide vient de lquipe , cest--dire si elle vient pendant la rtrospective quand tout le monde est autoris contribuer et discuter des ides. Sans les rtrospectives vous trouverez des quipes qui reproduiront les mmes erreurs, encore et encore.
Nos rtrospectives ne sont gnralement pas trs structures. Le thme implicite est toujours le mme : que pouvons-nous amliorer au prochain sprint . Ceci est un exemple de tableau blanc lors dune rcente rtrospective :
Trois colonnes : Bien : Si nous pouvions refaire le mme sprint, nous ferions ces choses exactement pareil. Peut mieux faire : Si nous pouvions refaire le mme sprint, nous ferions ces choses diffremment. Amliorations : Ides concrtes pour samliorer dans le futur. Les colonnes 1 et 2 concernent le pass, tandis que la colonne 3 concerne le futur. Aprs que les membres de lquipe aient dball tous ces post-its, ils utilisent le vote par points pour dterminer quelles amliorations prendre en compte au prochain sprint. Chaque membre de lquipe dispose de 3 aimants et sont invits voter pour les amliorations quils aimeraient voir pris en compte en priorit pendant le prochain sprint. Chaque membre peut distribuer ces aimants comme il veut, il peut mme placer les 3 sur le mme post-it. En se basant l-dessus ils slectionnent les 5 amliorations faire en priorit, et les suivront la prochaine rtrospective. Cest important de ne pas tre trop ambitieux ici. Concentrez-vous sur un petit nombre damliorations par sprint.
84 | SCRUM ET XP DEPUIS LES TRANCHEES parce que le directeur des ventes kidnappe les programmeurs en tant quexperts techniques dans les runions de vente. ? Cest une information importante. Peut-tre que les autres quipes ont le mme problme ? Devrions-nous mieux duquer la direction propos de nos produits, afin quils puissent faire eux-mmes le support des ventes ? Une rtrospective ne se limite pas comment cette quipe peut faire mieux le prochain sprint, a a des implications plus larges. Notre stratgie pour apprhender a est trs simple. Une personne (dans ce cas, moi) assiste toutes les rtrospectives de sprint et agit comme un pont de connaissance. Assez simple. Une alternative serait que chaque quipe Scrum publie un rapport de rtrospective de sprint. Nous avons essay a mais nous trouvons que peu de gens lisent les rapports, et encore moins sy conforment. Cest pourquoi nous faisons a de manire simple la place. Les rgles importantes pour la personne qui fait le pont de connaissances : Il doit savoir couter. Si la rtrospective est trop silencieuse, il doit tre prt poser des questions simples mais cibles afin de stimuler les discussions au sein du groupe. Par exemple si vous pouviez remonter le temps et refaire le mme sprint depuis le 1er jour, quest-ce que vous changeriez ? . Il devrait prendre le temps daller aux rtrospectives de toutes les quipes. Il devrait avoir une certaine autorit, de faon mettre en uvre les suggestions damlioration qui ne sont pas sous le contrle de lquipe. Cela marche assez bien mais il peut y avoir dautres approches qui fonctionnent encore mieux. Dans ce cas, clairez-moi.
COMMENT NOUS FAISONS LES RETROSPECTIVES DE SPRINTS | 85 communication ? Ajouter plus de pages dans le wiki ? Cest bien, peuttre. Mais encore une fois, peut-tre pas. Nous avons observ que, dans beaucoup de cas, identifier clairement un problme est suffisant pour quil se rsolve tout seul au prochain sprint. Surtout si vous accrochez la rtrospective de sprint sur le mur du bureau de lquipe (ce que nous oublions toujours de faire, honte nous !). Chaque chose que vous introduisez a un cot, aussi avant dintroduire des changements, envisagez de ne rien faire du tout et esprez que le problme disparatra (ou rduira) automatiquement. Lexemple ci-dessus ( nous ne communiquons pas assez dans lquipe ) est un exemple typique o la meilleure solution est de ne rien faire. Si vous introduisez un nouveau changement chaque fois quelquun se plaindra, les gens seront rticents remonter les problmes mineurs, ce qui serait terrible.
Nous devrions passer plus de temps dcomposer les histoires en sous-lments et tches
Cest assez courant. Chaque jour lors de la mle quotidienne, des membres de lquipe se retrouvent dire Je ne sais pas trop quoi faire aujourdhui . Alors aprs chaque mle quotidienne vous passez du temps trouver des tches concrtes. Cest gnralement plus efficace de faire a en amont. Actions typiques : aucune. Lquipe rglera a probablement dellemme la prochaine runion de planification de sprint. Si cela se rpte, prvoyez plus de temps pour le sprint planning.
Nous nous sommes trop engags et nous navons termin que la moiti du travail
Actions typiques : aucune. Lquipe ne sengagera probablement pas trop au prochain sprint. Ou du moins pas autant que cette fois.
11
Relcher le rythme entre les sprints
Dans la vraie vie, vous ne pouvez pas sprinter tout le temps. Vous avez besoin de vous reposer entre deux sprints. Si vous sprintez tout le temps, vous tes en effet juste en train de faire un jogging. Cest la mme chose avec Scrum et le dveloppement logiciel en gnral. Les sprints sont plutt intenses. En tant que dveloppeur vous ne vous relchez jamais, chaque jour vous devez assister cette fichue runion et dire tout le monde ce que vous avez fait la veille. Peu auraient tendance dire Jai pass la majeure partie de la journe mon bureau surfer sur des blogs et siroter du capuccino. En plus de la vraie pause elle-mme, il y a une autre bonne raison davoir un relchement entre les sprints. Aprs la dmo du sprint et la rtrospective, la fois lquipe et le directeur de produit seront saturs dinformations et dides digrer. Sils se remettent immdiatement courir et commencer planifier le sprint suivant, il est peu probable que quiconque ait loccasion de digrer une information ou des leons apprises, que le directeur de produit naura pas le temps dajuster ses priorits aprs la dmo de sprint, etc. Mauvais :
Nous essayons dinsrer du relchement avant de commencer un nouveau sprint (plus spcifiquement, la dure aprs la rtrospective de sprint et avant la prochaine runion de planification de sprint).
88 | SCRUM ET XP DEPUIS LES TRANCHEES Tout au moins, nous essayons de faire en sorte que la rtrospective de sprint et la runion de planification du sprint venir narrivent pas le mme jour. Tout le monde devrait avoir au moins une bonne nuit de sommeil sans sprint avant de dmarrer un nouveau sprint. Mieux :
Encore mieux :
Une faon de faire cela sont les jours labo (ou quoique vous choisissiez de les appeler). Ce sont des journes o les dveloppeurs sont autoriss faire essentiellement ce quils veulent (OK, je le reconnais, inspir par Google). Par exemple, tudier fond les derniers outils et APIs, suivre une formation, discuter de trucs dinformatique avec les collgues, coder un projet perso, etc. Notre but est davoir un jour labo entre chaque sprint. De cette faon vous avez naturellement une pause entre les sprints, et vous avez une quipe de dveloppement qui a de relles chances de garder jour leurs connaissances. De plus, cest un avantage plutt attractif pour lemployeur. Meilleur?
Actuellement nous avons des jours labo une fois par mois. Le premier vendredi de chaque mois pour tre prcis. Pourquoi pas entre les sprints la place ? Eh bien, parce que jai pens que ctait important que toute lentreprise soit en journe labo en mme temps. Autrement les gens ont tendance ne pas le faire srieusement. Et comme nous (jusque l)
RELACHER LE RYTHME ENTRE LES SPRINTS |89 navons pas align les sprints travers tous les produits, jai du choisir la place une journe labo indpendamment des sprints. On pourrait un jour tenter de synchroniser les sprints travers tous les produits (i.e. mme dmarrage et fin de sprint pour tous les produits et les quipes). Dans ce cas nous mettrons dfinitivement un jour labo entre chaque sprint.
12
Comment nous faisons la planification de release et les contrats au forfait
Ds fois, on a besoin de planifier lavance plus dun sprint la fois. Typiquement dans un contexte de contrat au forfait o on doit planifier en avance, ou sinon on risque de signer pour quelque chose quon ne peut dlivrer temps. Typiquement, la planification de release est pour nous une tentative de rpondre la question quand, au plus tard, serons-nous en mesure de dlivrer la version 1.0 de ce nouveau systme ? . Si vous voulez vraiment apprendre la planification de release je vous suggre de sauter ce chapitre et la place dacheter le livre de Mike Cohn Agile estimating and planning . Jaurais voulu avoir lu ce livre plus tt (Je lai lu aprs que nous soyons arrivs comprendre par nous mmes). Ma version de la planification de release est assez simpliste mais elle devrait tre un bon point de dpart.
92 | SCRUM ET XP DEPUIS LES TRANCHEES Les lments avec une importance de 25-49 sont requis mais peuvent tre faits dans une version future 1.1. Les lments avec une importance <25 sont spculations et pourraient ne jamais tre requis. Et voici un exemple de backlog de produit, avec un code couleur bas sur les rgles ci-dessus. Importance 130 120 115 110 100 95 80 70 60 40 35 10 10 Nom banane pomme orange goyave poire raisin cacahute beignet oignon pamplemousse papaye myrtille pche
Rouge = doit tre inclus dans la version 1.0 (banane poire) Jaune = devrait tre inclus dans la version 1.0 (raisin oignon) Vert = peut tre fait plus tard (pamplemousse pche) Donc si nous livrons tous les lments de banane oignon temps nous sommes sains et saufs. Si le temps se met manquer nous devrions nous en sortir en cartant raisin, cacahute, beignet ou oignon. Tout ce qui est en dessous doignon est du bonus.
PLANIFICATION DE RELEASE ET CONTRATS AU FORFAIT |93 Une estimation en temps a de la valeur si elle se rvle tre proche de la ralit, moins de valeur si elle se rvle tre cot, disons, de 30%, et compltement sans valeur si elle na aucune relation avec la ralit. Voici mon interprtation de la valeur dune estimation en temps en relation avec ceux qui la calculent et combien de temps ils y passent dessus.
Tout cela est juste une faon verbeuse de dire : Laissez lquipe faire les estimations. Ne leur faites pas passer trop de temps dessus. Assurez-vous quils comprennent que les estimations en temps sont des estimations approximatives, non des engagements. Habituellement le directeur de produit rassemble toute lquipe dans une pice, fournit quelques boissons, et lui explique que le but de cette runion est destimer en temps les 20 premires (ou autre) histoires du backlog de produit. Il aborde chaque histoire une fois, puis il laisse lquipe retourner travailler. Le directeur de produit reste dans la pice pour rpondre aux questions et clarifier le primtre de chaque histoire si ncessaire. Juste comme pendant la planification du sprint, le champ comment dmontrer est un moyen trs utile pour rduire le risque de malentendus. Cette runion doit tre strictement borne en temps, sans quoi les quipes auraient tendance passer trop de temps estimer trop peu dhistoires. Si le directeur de produit veut passer plus temps sur cela, il programme simplement une autre runion plus tard. Lquipe doit sassurer que limpact de ces runions sur leurs sprints en cours est clairement visible pour le directeur produit, de telle sorte quil comprenne que leurs estimations en temps ne sont pas gratis.
94 | SCRUM ET XP DEPUIS LES TRANCHEES Voici un exemple qui montre quoi les estimations en temps pourraient ressembler (en points dhistoire) :
Nom Estimation banane 12 pomme 9 orange 20 goyave 8 poire 20 raisin 12 cacahute 10 beignet 8 oignon 10 pamplemousse 14 papaye 4 myrtille pche
Estimer la vlocit
OK, alors maintenant nous avons des sortes destimations brutes pour les histoires les plus importantes. La prochaine tape est destimer notre vlocit moyenne par sprint. Cela veut dire que nous avons besoin de dfinir notre facteur de focalisation. Voir page XXX Comment lquipe choisit les histoires inclure dans le sprint ? . Le facteur de focalisation revient fondamentalement se demander quelle est la part du temps pass par lquipe consacre aux histoires adoptes en cours ? . Ce nest jamais 100% car les quipes perdent du temps en faisant des choses non prvues, en changeant de contexte, en aidant les autres quipes, en lisant leurs emails, en rparant les problmes dordinateur, en discutant politique dans la cuisine, etc. Disons que nous dterminons un facteur de focalisation de 50% pour lquipe (trs bas, normalement on tourne autour de 70%). Et disons que notre sprint dure 3 semaines (15 jours) et que la taille de lquipe et 6.
PLANIFICATION DE RELEASE ET CONTRATS AU FORFAIT |95 Chaque sprint fait alors 90 jours*homme, mais produira seulement 45 jours*homme dhistoires ( cause du facteur de focalisation de 50%). Notre vlocit estime est donc de 45 points dhistoire. Si chaque histoire avait une estimation en temps de 5 jours (ce qui nest pas le cas) alors cette quipe avalerait approximativement 9 histoires par sprint.
Chaque sprint contient autant dhistoires que possible dans la limite de la vlocit estime de 45. Maintenant on peut voir que nous aurons probablement besoin de 3 sprints pour finir tous les doit tre inclus et les devrait tre inclus .
96 | SCRUM ET XP DEPUIS LES TRANCHEES 3 sprints = 9 semaines calendaires = 2 mois calendaires. Maintenant est-ce vraiment la date de livraison promise au client ? Cela dpend entirement de la nature du contrat ; quel point le primtre est-il fix, etc. Gnralement nous ajoutons une rserve significative pour nous protger contre les mauvaises estimations en temps, les problmes imprvus, les fonctionnalits inattendues, etc. Donc dans ce cas nous pouvons nous mettre daccord sur une livraison dans 3 mois, ce qui nous donne 1 mois de rserve . Ce qui est bien cest que nous pouvons dmontrer quelque chose dutilisable au client toutes les 3 semaines et linviter modifier ses exigences au fur mesure que nous avanons (cela dpend bien sr du type de contrat).
13
Comment nous combinons Scrum avec XP
Dire que Scrum et XP (eXtreme Programming) peuvent tre combins avec profit nest pas une dclaration rellement sujette controverse. La plupart des choses que je vois sur le net sont en faveur de cette hypothse, donc je ne vais pas passer de temps argumenter pourquoi. Tout de mme, je vais mentionner une chose. Scrum se concentre sur le management et les pratiques dorganisation tandis que XP se concentre surtout sur les pratiques de programmation concrtes. Cest pour a quils fonctionnent bien ensemble ils concernent diffrentes zones et sont complmentaires. Je dclare donc formellement que jajoute ma voix aux preuves empiriques dj existantes que Scrum et XP peuvent tre combins de manire productive ! Je vais souligner certaines des pratiques XP les plus intressantes, et comment elles sappliquent notre travail de tous les jours. Toutes nos quipes nont pas russi adopter toutes les pratiques, mais au total nous avons expriment la plupart des aspects de la combinaison XP/Scrum. Certaines pratiques XP sont directement prises en compte par Scrum et peuvent tre vues comme du recouvrement, par exemple Toute lquipe , Sasseoir ensemble , Histoires et Jeu du planning . Dans ces cas nous nous en sommes simplement tenus Scrum.
La programmation en binme
Nous avons commenc cela rcemment dans une de nos quipes. Ca a plutt bien fonctionn en fait. La plupart de nos autres quipes ne travaillent toujours pas beaucoup en duo, mais aprs lavoir rellement essay avec une quipe pendant maintenant plusieurs sprints, je suis motiv pour essayer dentraner plus dquipes faire lessai.
98 | SCRUM ET XP DEPUIS LES TRANCHEES Quelques conclusions pour linstant sur la programmation en binme : La programmation en binme amliore la qualit du code. La programmation en binme amliore la focalisation de lquipe (par exemple quand le gars derrire vous dit h est-ce que ce truc est vraiment ncessaire pour ce sprint ? ). Curieusement beaucoup de dveloppeurs qui sont fortement opposs la programmation en binme ne lont pas rellement essaye, et apprennent rapidement lapprcier une fois quils lessayent. La programmation en binme est puisante et ne devrait pas tre pratique toute la journe. Faire tourner frquemment les duos est bnfique. La programmation en binme amliore la diffusion des connaissances dans le groupe. De faon tonnamment rapide. Quelques personnes ne sont simplement pas laise avec la programmation en binme. Ne jetez pas un excellent programmeur juste parce quil nest pas laise avec la programmation en binme. Les revues de code sont une alternative acceptable la programmation en binme. Le copilote (le type qui nutilise pas le clavier) devrait galement avoir un ordinateur lui. Pas pour le dveloppement, mais pour de petites activits quand cest ncessaire, pour parcourir la documentation quand le pilote (le type au clavier) est bloqu, etc. Nimposez pas la programmation en binme aux gens. Encouragez-les et fournissez les bons outils mais laissez-les exprimenter leur propre rythme.
COMMENT NOUS COMBINONS SCRUM AVEC XP | 99 principalement pour amliorer la lisibilit et supprimer les duplications. Rincez et recommencez. Quelques rflexions sur le dveloppement dirig par les tests. Le DDT est difficile. Cela prend du temps un programmeur pour voir la lumire. En fait, dans beaucoup de cas, le temps que vous passez former et dmontrer na pas rellement beaucoup dimportance dans beaucoup de cas la seule manire pour un programmeur de voir la lumire est de le faire programmer en duo avec quelquun de vraiment bon en DDT. Une fois quun programmeur voit la lumire, cependant, il sera en principe gravement infect et ne voudra jamais plus travailler dune autre manire. Le DDT a un effet profondment positif sur la conception du systme. Cela prend du temps pour avoir du DDT parfaitement au point dans un nouveau produit, surtout des tests dintgration en boite noire, mais le retour sur investissement est rapide. Assurez-vous dinvestir le temps ncessaire pour que ce soit facile dcrire des tests. Cela signifie obtenir les bons outils, duquer les gens, fournir des classes utilitaires ou des classes de base appropries, etc. Nous utilisons les outils suivants pour le dveloppement dirig par les tests : jUnit / httpUnit / jWebUnit. Nous envisageons TestNG et Selenium. HSQLDB en tant que BD embarque en mmoire pour les tests. Jetty en tant que container web embarqu en mmoire pour les tests. Cobertura pour les mtriques de couverture de test. Spring pour cbler diffrents types de montages de test (avec mocks, sans mocks, avec base de donnes externe, avec base de donnes en mmoire, etc). Dans nos produits les plus sophistiqus (du point de vue du DDT) nous avons des tests dacceptation automatiss de type bote noire. Ces tests dmarrent le systme complet en mmoire, y compris les bases de donnes et les serveurs web, et accdent au systme en utilisant uniquement ses interfaces publiques (par exemple HTTP). Cela permet des cycles dveloppement-construction-test extrmement rapides. Cela agit galement comme un filet de scurit, donnant suffisamment de confiance aux dveloppeurs pour remanier (refactor)
100 | SCRUM ET XP DEPUIS LES TRANCHEES souvent, ce qui signifie que la conception reste propre et simple mme quand le systme grandit.
COMMENT NOUS COMBINONS SCRUM AVEC XP | 101 dautomatiser le test que nous avons oubli de le faire tape par tape, la premire tape tant de construire des choses qui rendent le test manuel plus efficace. Leon tire : si vous tes coincs avec du test de rgression manuel, et voulez vous en dbarrasser en lautomatisant, ne lautomatisez pas ( moins que ce soit vraiment facile). A la place, construisez des choses qui rendent le test de rgression manuel plus facile. Ensuite, considrez lautomatisation du vritable test.
La conception incrmentale
Cela signifie garder la conception simple au dpart et lamliorer continuellement, plutt quessayer de tout faire parfaitement ds le dpart et ensuite tout geler. Nous sommes plutt bons a, cest--dire que nous passons un temps raisonnable remanier et amliorer la conception existante, et que nous passons rarement du temps faire de grandes conceptions lavance. Quelques fois nous chouons bien sr, par exemple en permettant une conception branlante de simplanter trop fortement, si bien que le remaniement devient un gros projet. Mais tout bien considr nous sommes raisonnablement satisfaits. Lamlioration continue de la conception est principalement un effet de bord automatique du DDT.
Lintgration continue
La plupart de nos produits ont un systme dintgration continue plutt sophistiqu, bas sur Maven et QuickBuild. Cela est trs efficace et fait conomiser du temps. Cest la solution ultime au bon vieux problme h mais a marche sur ma machine . Notre serveur de build en continu sert de juge ou point de rfrence partir duquel on peut dterminer la sant de toutes nos bases de code. Chaque fois que quelquun enregistre quelque chose dans le systme de gestion de version, le serveur de build en continu reconstruit tout partir de zro sur un serveur partag, et excute tous les tests. Si quelque chose ne va pas il envoie un email notifiant toute lquipe que le build a chou, en indiquant quel changement dans le code a cass le build, des liens sur les rapports de test, etc.
102 | SCRUM ET XP DEPUIS LES TRANCHEES Chaque nuit le serveur de build en continu va reconstruire le produit partir de zro et va publier les binaires (fichiers de type .EAR, .WAR, etc.), la documentation, les rapports de test, les rapports de couverture de test, les rapports de dpendance, etc, sur notre portail interne de documentation. Certains produits vont aussi tre dploys automatiquement sur un environnement de test. Mettre en place tout cela a reprsent beaucoup de travail, mais chaque minute passe en valait la peine.
COMMENT NOUS COMBINONS SCRUM AVEC XP | 103 La plupart des programmeurs ont leur propre style de codage bien distinct. De petits dtails comme comment ils grent les exceptions, comment ils commentent le code, quand ils retournent null, etc. Dans certains cas la diffrence na pas dimportance, dans dautres cas elle peut conduire une conception systme gravement incohrente et du code trs difficile lire. Des normes de codage sont trs utiles dans ce cas, du moins tant que vous vous concentrez sur les choses qui importent. Voici quelques exemples de nos normes : Vous pouvez violer nimporte laquelle de ces rgles, mais assurez-vous quil y a une bonne raison et documentez-l. Utilisez les conventions de codage de Sun par dfaut : http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html Ne jamais, jamais, jamais, attraper des exceptions sans les relancer ou enregistrer la pile dappel dans un journal. log.debug() cest bien, mais simplement ne perdez pas cette pile dappel. Utilisez linjection de dpendances base sur les accesseurs pour dcoupler les classes les unes des autres (sauf bien sr quand un couplage fort est dsir). Evitez les abrviations. Les abrviations bien connues comme ADO sont acceptables. Les mthodes qui retournent des collections ou des tableaux ne devraient pas retourner null. Retournez des collections et des tableaux vides la place de null.
104 | SCRUM ET XP DEPUIS LES TRANCHEES Aprs quelques mois nous avons russi ramener le nombre dheures des niveaux dcents. Les gens travaillent le nombre normal dheures (sauf quelquefois dans des situations critiques). Et, surprise, la productivit et la qualit se sont amliores de manire notable. Bien sr, la rduction des heures de travail na t en aucune manire le seul aspect ayant conduit cette amlioration, mais nous sommes tous convaincus quelle a jou un grand rle.
14
Comment nous faisons les tests
Cest la partie la plus difficile. Je ne sais pas si cest la partie la plus difficile de Scrum, ou juste la partie la plus difficile du dveloppement logiciel en gnral. Le test est la partie qui va probablement varier le plus entre diffrentes organisations. Cela dpendra du nombre de testeurs que vous avez, de lampleur de lautomatisation de vos tests, de quel type de systme vous avez (juste server+application web ? ou bien vous tes un diteur de logiciel vendu dans des botes ?), de la dure des cycles de release, de la criticit du logiciel (un serveur de blog vs. un systme de contrle de vol), etc. Nous avons pas mal expriment sur la manire de faire des tests dans Scrum. Je vais essayer de dcrire ce que nous avons fait et appris jusque l.
Faux. Daprs notre exprience, cela ne fonctionne gnralement pas. Il y aura de mchants bugs. Si la qualit a une valeur quelconque pour vous, il faut une sorte de phase de test dacceptation manuelle. Cest le moment o des testeurs ddis, qui ne font pas partie de lquipe, martlent le systme avec ces types de tests que lquipe Scrum navait pas imagins, ou navait pas eu le temps de faire, ou pour lesquels elle navait pas le matriel ncessaire. Les testeurs accdent au systme exactement comme les utilisateurs finaux, ce qui signifie quils doivent le faire manuellement (en supposant que votre systme est destin des utilisateurs humains).
Lquipe de test va trouver des bugs, lquipe Scrum va devoir faire des releases de corrections de bugs, et tt ou tard (jespre tt) vous pourrez livrer aux utilisateurs finaux une version corrige 1.0.1, au lieu de la version instable 1.0.0. Quand je dis phase de tests dacceptation , je fais rfrence la priode complte de tests, dbogage, et nouvelles releases jusqu ce quil y ait une version suffisamment bonne pour la production.
COMMENT NOUS FAISONS LES TESTS | 107 nous y parvenons) essayer de la minimiser. Plus prcisment, de minimiser la quantit de temps ncessaire pour la phase de tests dacceptation. Ce rsultat est obtenu en : Maximisant la qualit du code produit par lquipe Scrum Maximisant lefficacit du travail de test manuel (cest--dire trouver les meilleurs testeurs, leur donner les meilleurs outils, sassurer quils rapportent les tches consommatrices de temps qui pourraient tre automatises) Alors comment maximisons-nous la qualit du code produit par lquipe Scrum ? Eh bien, il y a plein de manires. En voici deux qui marchent trs bien daprs nous : Mettre des testeurs dans lquipe Scrum En faire moins par sprint
Oui, jentends bien les deux objections : Mais cest vident ! Les quipes Scrum sont supposes tre multifonctions. Les quipes Scrum sont supposes tre sans rle. On ne peut pas avoir quelquun qui serait uniquement un testeur ! Laissez-moi clarifier. Ce que je veux dire par testeur dans ce cas est une personne dont le talent principal est le test , plutt que une personne dont le rle est seulement de tester . Les dveloppeurs sont souvent dassez mauvais testeurs. Surtout les dveloppeurs testant leur propre code.
Le testeur est le gars qui signe officiellement En plus dtre juste un membre de lquipe, le testeur a un boulot important. Cest le gars qui dcide quand cest termin. Rien nest
108 | SCRUM ET XP DEPUIS LES TRANCHEES considr comme termin dans un sprint tant que lui na pas dit que ctait termin. Jai dcouvert que les dveloppeurs disent souvent que quelque chose est termin alors que ce ne lest pas rellement. Mme si vous avez une dfinition de termin trs claire (et vous devriez vraiment en avoir une, voir page 40 la dfinition de termin ), les dveloppeurs vont loublier frquemment. Nous programmeurs sommes des gens impatients et nous dsirons passer la tche suivante ds que possible. Mais alors comment M. T (notre testeur) sait-il que quelque chose est termin ? Eh bien, avant tout, il devrait (surprise) le tester ! Dans beaucoup de cas, il savre que quelque chose considr comme termin par un dveloppeur nest mme pas testable. Parce que son travail na pas t enregistr dans le systme de gestion de sources, parce quil na pas t dploy sur le serveur de tests, ou parce quil nest pas possible de lexcuter, etc. Une fois que M. T a test la fonctionnalit, il devrait parcourir la check-list dfinissant termin (si vous en avez une) avec le dveloppeur. Par exemple si la dfinition de termin exige quil devrait y avoir une note de release, alors M. T vrifie quil y a bien une note de release. Sil existe une sorte de spcification plus formelle pour la fonctionnalit (cest rare dans notre cas) alors M. T vrifie cela galement. Etc. Un effet de bord positif de tout cela est que lquipe a maintenant un gars qui est parfaitement au point pour organiser la dmonstration du sprint.
COMMENT NOUS FAISONS LES TESTS | 109 des types de test diffrents de ceux dun bon dveloppeur, si bien quils sont complmentaires lun de lautre. Si lquipe ne pratique pas le DDT, ou sil ny a pas assez dcriture de cas de tests pour occuper tout le temps du testeur, il devrait simplement faire ce quil peut pour aider lquipe atteindre le but du sprint. Tout comme nimporte quel autre membre de lquipe. Si le testeur peut programmer cest super. Sinon, votre quipe devra identifier toutes les tches hors programmation qui doivent tre faites dans le sprint. Durant la dcomposition des histoires en tches pendant la runion de planning de sprint, lquipe a tendance se focaliser sur les tches de programmation. Toutefois, habituellement il y a beaucoup de tches hors programmation qui doivent tre faites dans le sprint. Si vous passez du temps essayer didentifier les tches hors programmation durant la phase de planning du sprint, il y a des chances pour que M. T soit capable de contribuer pas mal, mme sil ne sait pas programmer et sil ny a pas de tests faire tout de suite. Exemples de tches hors programmation qui doivent souvent tre faites dans un sprint : Mettre en place un environnement de test. Eclaircir les spcifications. Discuter les dtails de dploiement avec le service Oprations. Ecrire les documents de dploiement (notes de release, demandes de commentaires, ou quoi que ce soit que votre organisation fasse). Grer les contacts avec des ressources externes (concepteurs dIHM par exemple). Amliorer les scripts de build. Raffiner la dcomposition des histoires en tches. Identifier les questions cls poses par les dveloppeurs et obtenir des rponses. Dun autre ct, que faisons-nous si M. T devient un goulet dtranglement ? Disons que nous sommes au dernier jour du sprint et que soudainement beaucoup de choses sont faites et que M. T na aucune chance de tout tester. Que faisons-nous ? Eh bien nous pourrions transformer tout le monde dans lquipe en assistants de M. T. Il dcide ce quil doit faire lui-mme, et il dlgue le travail de base au reste de lquipe. Voil en quoi consiste une quipe multifonctionnelle !
110 | SCRUM ET XP DEPUIS LES TRANCHEES Donc oui, M. T joue un rle spcial dans lquipe, mais il est tout de mme autoris faire dautres travaux, et les autres membres de lquipe sont tout de mme autoriss faire son travail.
Cela nest en aucune faon une solution parfaite mais elle est suffisamment bonne pour nous dans la plupart des cas.
Aprs le sprint 1, une version 1.0.0 bugge est livre. Durant le sprint 2, des rapports de bugs commencent arriver et lquipe passe la majeure partie de son temps dbugger et est force de faire mi-sprint une release 1.0.1 de correction de bugs. Ensuite la fin du sprint 2 ils livrent une nouvelle version 1.1.0 avec de nouvelles fonctionnalits, qui est bien sr encore plus bugge puisquils ont eu encore moins de temps pour la faire correctement cette fois-ci tant donn toutes les perturbations venant de la release prcdente. Etc etc. Les hachures rouges dans le sprint 2 symbolisent le chaos. Pas trs joli nest-ce pas ? Eh bien, ce qui est triste cest que le problme perdure mme si vous avez une quipe de test dacceptation. La seule diffrence est que la plupart des rapports de bugs vont venir de lquipe de test au lieu de clients finaux mcontents. Cest une norme diffrence sur le plan commercial, mais pour les dveloppeurs cela revient peu prs la mme chose. Sauf que les testeurs sont habituellement moins agressifs que les utilisateurs finaux. Habituellement.
Nous navons trouv aucune solution simple ce problme. Cependant nous avons beaucoup expriment avec diffrents modles. Avant tout, nouveau, il faut maximiser la qualit du code que lquipe Scrum dlivre. Le cot de trouver et corriger les bugs trs tt, durant un sprint, est bien plus faible en comparaison du cot de les trouver et corriger aprs. Mais il reste le fait que, mme si on peut minimiser le nombre de bugs, il y aura toujours des rapports de bugs qui arriveront aprs quun sprint soit termin. Comment grons-nous cela ?
Approche 1 : Ne commencez pas construire de nouvelles choses avant que les anciennes ne soient en production
Ca a lair bien nest-ce pas ? Avez-vous ressenti vous aussi ce sentiment de satisfaction ? Nous avons t proches dadopter cette approche plusieurs fois, et avons conu de beaux modles sur la manire de le faire. Toutefois nous avons toujours chang davis quand nous avons ralis linconvnient. Il nous faudrait ajouter une priode de release sans limite de temps entre les sprints, pendant laquelle nous ferions seulement du test et du dbogage jusqu ce que nous puissions faire une release de production.
114 | SCRUM ET XP DEPUIS LES TRANCHEES Nous navons pas aim lide davoir des priodes sans limite de temps entre les sprints, principalement parce que cela casserait le rythme rgulier des sprints. Il ne serait plus possible de dire toutes les 3 semaines nous dmarrons un nouveau sprint . De plus, cela ne rsout pas compltement le problme. Mme si nous avons une priode de release, il y aura toujours des rapports de bugs urgents qui arriveront de temps en temps, et il nous faut tre prt les grer.
Approche 2 : OK pour commencer construire de nouvelles choses, mais priorisez la mise en production des anciennes
Cest notre approche prfre. En tout cas pour le moment. Fondamentalement, quand nous finissons un sprint nous commenons le suivant. Mais nous nous attendons passer un certain temps dans le sprint suivant corriger des bugs du dernier sprint. Si le sprint suivant est srieusement endommag cause du temps quil a fallu pour corriger des bugs du sprint prcdent, nous valuons pourquoi cela est arriv et comment nous pouvons amliorer la qualit. Nous nous assurons que les sprints sont suffisamment longs pour survivre une bonne priode de correction de bugs du sprint prcdent. Progressivement, sur une priode de pas mal de mois, la quantit de temps passe corriger des bugs des sprints prcdents a diminu. De plus nous avons pu impliquer moins de gens quand des bugs arrivaient, si bien quil ntait pas ncessaire de perturber lensemble de lquipe chaque fois. Maintenant nous sommes un niveau plus acceptable.
Durant les runions de planning de sprint nous fixons le facteur de focalisation une valeur suffisamment basse pour prendre en compte le temps que nous nous attendons passer corriger des bugs du sprint dernier. Avec le temps les quipes sont devenues assez bonnes cette estimation. La mtrique de vlocit aide beaucoup (voir page 31 Comment lquipe dcide quelles histoires inclure dans le sprint ? ).
116 | SCRUM ET XP DEPUIS LES TRANCHEES Dfinir certains sprints comme des sprints de test pendant lesquels lquipe complte travaille comme une quipe de test dacceptation. Embaucher plus de testeurs (mme si cela signifie supprimer des postes de dveloppeurs) Nous avons essay toutes ces solutions (sauf la dernire). La meilleure solution long terme est bien sr les points 2 et 3, cest--dire de meilleurs outils et scripts ainsi que lautomatisation des tests. Les rtrospectives sont un bon forum pour identifier le maillon le plus lent dans la chane.
Retour la ralit
Je vous ai probablement donn limpression que nous avons des testeurs dans toutes les quipes Scrum, que nous avons de grosses quipes de test dacceptation pour chaque produit que nous livrons aprs chaque sprint, etc. Eh bien, nous ne les avons pas. Nous avons quelquefois russi faire tout cela, et nous en avons vu les effets positifs. Mais nous sommes encore loin dun processus dassurance qualit acceptable, et nous avons encore beaucoup apprendre dans ce domaine.
15
Comment nous grons les quipes multi-Scrum
Beaucoup de choses deviennent plus difficiles quand vous avez plusieurs quipes Scrum qui travaillent sur le mme projet. Ce problme est universel et na pas vraiment de lien avec Scrum. Plus de dveloppeurs = plus de complications. Nous avons (comme dhabitude) fait des essais. Au plus nous avions une quipe de 40 personnes environ qui travaillaient sur le mme projet. Les questions cls sont : Combien dquipes faut-il crer ? Comment rpartir les personnes dans les quipes ?
118 | SCRUM ET XP DEPUIS LES TRANCHEES dirais que cest une bonne ide de diviser lquipe. Sinon je considrerais de rester avec une quipe, malgr le dsavantage des grosses quipes. Mon exprience est quil est prfrable davoir peu dquipes mme trop grosses que davoir plein de petites quipes qui interfrent les unes les autres. Crez de petites quipes seulement si elles nont pas besoin dinteragir entre elles !
Equipes virtuelles
Comment savoir si vous prenez la bonne ou mauvaise dcision par rapport au compromis entre grosses quipes vs beaucoup dquipes ? Si vous gardez les yeux et les oreilles ouvertes vous aurez remarqu la formule quipes virtuelles . Exemple 1: Vous choisissez davoir une grande quipe. Mais quand vous regardez qui parle qui pendant litration, vous notez que lquipe est effectivement divise en deux sous-quipes.
Exemple 2: Vous choisissez davoir trois quipes plus petites. Mais quand vous regardez qui parle qui pendant litration, vous notez que les quipes 1 et 2 discutent entre elles tout le temps, tandis que lquipe 3 travaille de manire isole.
COMMENT NOUS GERONS LES EQUIPES MULTI-SCRUM | 119 Quest-ce que a signifie ? Que votre stratgie de division des quipes nest pas bonne ? Oui, si les quipes virtuelles semblent plutt permanentes. Non, si vos quipes virtuelles semblent tre temporaires. Regardez lexemple 1. Si les deux sous-quipes virtuelles ont tendance changer de temps en temps (cest--dire que les personnes bougent entre les sous-quipes virtuelles) alors vous avez probablement pris la bonne dcision en les regroupant dans une quipe Scrum unique. Si les deux sous-quipes restent les mmes pendant toute litration, vous voudrez probablement les sparer en deux vraies quipes Scrum pour la prochaine itration. Maintenant regardez lexemple 2. Si lquipe 1 et 2 discutent entre elles (mais pas lquipe 3) durant toute litration, vous voudrez probablement regrouper lquipe 1 et lquipe 2 en une quipe Scrum unique la prochaine itration. Si lquipe 1 et lquipe 2 discutent beaucoup entre elles pendant la premire moiti de litration, et quensuite lquipe 1 et lquipe 3 discutent entre elles pendant la seconde moiti de litration, alors vous devriez considrer de fusionner les trois quipes en une, ou juste les laisser en trois quipes. Abordez la question durant la rtrospective ditration et laissez les quipes dcider elles-mmes. La division des quipes est lune des parties vraiment difficiles de Scrum. Ne rflchissez pas trop ou noptimisez pas trop. Exprimentez, gardez un il sur les quipes virtuelles, et soyez sr que vous prenez suffisamment de temps pour discuter de ce genre de choses pendant les rtrospectives. Tt ou tard vous trouverez la bonne solution votre situation. Le plus important est que les quipes soient confortables et nhsitez pas entre les deux trop souvent.
120 | SCRUM ET XP DEPUIS LES TRANCHEES Disons que vous avez deux produits diffrents, avec une quipe de 3 personnes par produit, et les deux avancent trop lentement. Ca peut tre une bonne ide de les fusionner en une seule quipe de 6 personnes responsable des deux produits. Dans ce cas laissez partir lun des deux directeurs de produit (ou donnez lui un rle consultatif ou autre chose).
Disons que vous avez une seule quipe Scrum de 12 personnes, car le code est dans un tat tellement lamentable quil ny a pas moyen pour 2 quipes diffrentes de travailler dessus indpendamment. Faites de srieux efforts pour corriger le code (au lieu de construire de nouvelles fonctionnalits) jusqu ce que vous puissiez diviser lquipe. Cet investissement sera probablement amorti rapidement.
COMMENT NOUS GERONS LES EQUIPES MULTI-SCRUM | 121 Ca sonne bien. A nimporte quel moment il y aurait un sprint sur le point de finir et un nouveau sprint sur le point de commencer. La charge de travail du directeur de produit serait galement rpartie dans le temps. Il y aurait des nouvelles versions en continu. Des dmonstrations toutes les semaines. Allluia. Oui, je sais, mais a semblait vraiment convaincant lpoque ! Nous avions juste commenc faire a quand un jour jai eu lopportunit de parler avec Ken Schwaber (en conjonction avec ma certification Scrum). Il fit remarquer que ctait une mauvaise ide, quil serait tellement mieux de synchroniser les sprints. Je ne me rappelle pas ces arguments exacts, mais aprs la discussion jtais convaincu.
Cest la solution que nous avons utilise depuis, et nous ne lavons jamais regrett. Je ne saurai jamais si la stratgie des sprints qui se chevauchent aurait choue, mais je pense que oui. Les avantages des sprints synchroniss sont : Il y a un moment naturel o lon peut rarranger les quipes entre les sprints ! En chevauchant les sprints, il ny a pas moyen de rarranger les quipes sans perturber au moins une quipe au milieu du sprint. Toutes les quipes peuvent travailler vers un objectif commun sur un sprint et faire les runions de planification de sprint ensemble, ce qui mne une meilleure collaboration entre quipes. Il y a moins de travail administratif, cest--dire moins de runions de planification de sprint, de dmonstrations de sprint, et de releases.
Le gars en rouge marqu P est le Directeur de produit. Les gars en noir marqus S sont les Scrum Masters. Les autres sont les troufions... euh... les membres respectables dquipe. Avec cette constellation, qui dcide quelles personnes devraient tre dans quelle quipe ? Le directeur de produit ? Les trois Scrum masters ensemble ? Ou chaque personne choisit son quipe ? Mais alors que faire si tout le monde veut tre dans lquipe 1 (parce que le Scrum master 1 est tellement avenant)? Que faire si plus tard il savre impossible davoir plus de deux quipes en parallle sur ce code, et quil soit ncessaire de les transformer en 2 quipes de 9 personnes au lieu de des quipes de 6 personnes. Cela signifie 2 Scrum masters. Alors lequel des 3 Scrum masters sera relev de sa fonction ? Dans beaucoup dentreprises ce sont des questions assez sensibles. Il est tentant de laisser le directeur de produit faire les affectations et raffectations. Mais ce nest pas vraiment le travail du directeur de produit, nest-ce pas ? Le directeur de produit est lexpert mtier qui dit lquipe dans quelle direction elle doit courir. Il ne devrait pas vraiment tre impliqu dans les dtails. Surtout sil sagit dun poulet (si vous avez entendu la mtaphore du poulet et du cochon, sinon tapez chicken and pig sous google). Nous avons rsolu ce problme en introduisant le rle du meneur dquipes . Cela correspond ce que vous pourriez appeler le Scrum des Scrum masters ou le chef ou le Scrum master principal etc. Il na mener aucune quipe, mais il est responsable des problmes transverses aux quipes comme qui devrait tre le Scrum master pour chaque quipe, combien de personnes devraient tre divises en quipes, etc.
COMMENT NOUS GERONS LES EQUIPES MULTI-SCRUM | 123 Nous avons eu du mal trouver un bon nom pour ce rle. Le meneur dquipes tait le moins mauvais nom que nous avons pu trouver. Cette solution a bien march pour nous et je peux la recommander (indpendamment du nom que vous choisissez pour ce rle).
Comme vous le voyez, cela signifierait une rduction du nombre dquipes, passant de 4 3. Nous avons list les membres pour chaque quipe. Groupez-vous sil-vous-plat et mettez-vous devant une section du mur. (le meneur dquipes attend pendant que les personnes se baladent dans la pice, aprs un moment il y a 3 groupes, chacun se tenant devant une section du mur vide). Maintenant cette division dquipes est prliminaire ! Cest juste un point de dpart, pour gagner du temps. Au fur et mesure que la runion de planification de sprint progresse vous tes libre de vous balader vers une autre quipe, de diviser votre quipe en deux, fusionner avec une autre quipe, ou ce que vous voulez. Faites preuve de bon sens en vous basant sur les priorits du directeur de produit. Cest ce que nous avons trouv qui fonctionne le mieux. Un certain niveau de contrle centralis au dbut, suivi par un certain niveau doptimisations dcentralises aprs.
Et disons que vous avez 15 personnes travaillant sur le produit, aussi vous ne voulez vraiment pas en faire une seule quipe Scrum. Quelles quipes crez-vous ?
Cest comme a que nous avons commenc. Ca ne fonctionnait pas trs bien, du moins pas quand la plupart des histoires impliquaient plusieurs composants. Par exemple disons que nous avons une histoire appele tableau daffichage o les utilisateurs peuvent poster des messages aux autres . Cette fonctionnalit de tableau daffichage impliquerait de mettre jour linterface utilisateur ct client, ajouter la logique ct serveur, et ajouter des tables dans la base de donnes.
Cela signifie que les trois quipes lquipe client, lquipe serveur, et lquipe BD doivent collaborer pour que cette histoire soit termine. Pas terrible. Approche n quipes transversales aux composants 2:
Une seconde approche est de crer des quipes transversales aux composants, cest--dire des quipes qui ne sont lies aucun composant.
COMMENT NOUS GERONS LES EQUIPES MULTI-SCRUM | 127 Si beaucoup de vos histoires impliquent plusieurs composants cette stratgie de division dquipes fonctionnera mieux. Chaque quipe peut implmenter une histoire complte incluant la partie client, la partie serveur et la partie base de donnes. Les quipes peuvent ainsi travailler plus indpendamment des autres, ce qui est une Bonne Chose. Lune des premires choses que nous faisons quand nous avons introduit Scrum tait de dmanteler ces quipes spcialises par composant (approche 1) et de crer des quipes transversales aux composants la place (approche 2). Cela rduit le nombre de cas o nous ne pouvons finir cet lment parce que nous attendons que les gars ct serveur fassent leur partie. Cependant, nous assemblons parfois des quipes temporaires spcialises par composant quand le besoin est fort.
128 | SCRUM ET XP DEPUIS LES TRANCHEES Aussi si vous voulez rarranger les quipes, soyez sr de mesurer les consquences. Est-ce un changement long terme ou court terme ? Si cest un changement court terme considrez de le laisser tomber. Si cest un changement long terme, allez-y. Une exception lorsque vous commencez appliquer Scrum avec une grande quipe pour la premire fois. Dans ce cas il vaut probablement mieux exprimenter un peu avec les divisions dquipes jusqu ce que vous trouviez quelque chose de confortable pour tous. Assurez-vous que tout le monde comprenne que cest OK davoir tout faux les quelques premires fois, du moment que vous continuez de vous amliorer.
COMMENT NOUS GERONS LES EQUIPES MULTI-SCRUM | 129 ne lembarque, il assistera aux mles quotidiennes de cette quipe, aux runions de planification de sprint, aux rtrospectives, etc.
Cela signifie que nous avions 2 niveaux de Scrums-de-Scrum. Nous avions un Scrum-de-Scrums de niveau produit compos des quipes du produit D, et un Scrum-de-Scrums niveau global compos de tous les produits.
130 | SCRUM ET XP DEPUIS LES TRANCHEES 1) Tour de table, chacun dcrit ce que son quipe a accompli durant la dernire semaine, ce quil prvoit de finir cette semaine, et quels sont leurs obstacles. 2) Le moindre souci inter-quipe doit y tre rapport, par exemple des problmes dintgration. Lordre du jour du Scrum-de-Scrums nest pas vraiment important pour moi, la chose importante est que vous teniez rgulirement les runions Scrum-de-Scrums.
COMMENT NOUS GERONS LES EQUIPES MULTI-SCRUM | 131 dehors du groupe taient demandeurs de ce type dinformation. Fondamentalement, les quipes veulent savoir ce que font les autres quipes. Du coup nous nous sommes dit que si nous allions nous runir et passer du temps sinformer les uns les autres sur ce que fait chaque quipe, alors pourquoi ne pas laisser venir tout le monde tout simplement.
Lexemple de calendrier ci-dessus correspond la priode durant laquelle nous avions des mles quotidienne dans des bureaux spars, plutt que dans le bureau des quipes. Les runions durent normalement 15 minutes mais chaque quipe se rserve un espace de 30 minutes au cas o il y aurait besoin de dpasser lgrement. Cest extrmement intressant pour deux raisons : 1. Les gens comme le directeur de produit et moi-mme pouvons visiter toutes les mles quotidiennes dans une seule matine. Il ny a pas de meilleur moyen dobtenir une vision raliste de ltat du sprint, et des menaces cls. 2. Les quipes peuvent visiter les mles quotidiennes des autres quipes. Cela narrive pas trop souvent, mais de temps en temps deux quipes vont travailler sur une zone similaire, et ainsi quelques membres se rendent visite dans les mles pour rester synchroniss.
132 | SCRUM ET XP DEPUIS LES TRANCHEES Linconvnient cest moins de libert pour lquipe ils ne peuvent pas choisir le moment quils prfrent pour la mle. Toutefois cela ne sest pas rvl tre un vritable problme pour nous.
COMMENT NOUS GERONS LES EQUIPES MULTI-SCRUM | 133 Cela a plutt bien fonctionn. Comme lquipe Scrum avait reu du temps pour travailler de manire proactive, ils ont finalement russi stabiliser le systme. Pendant ce temps lquipe de pompiers avait compltement abandonn la notion dtre capable de planifier lavance, ils travaillaient uniquement de manire ractive, et corrigeaient juste la crise en cours. Bien sr lquipe Scrum ntait pas compltement labri des perturbations. Frquemment lquipe de pompiers devait impliquer des personnes cls de lquipe Scrum, ou au pire lquipe en entier. Nanmoins, aprs quelques mois, le systme tait suffisamment stable pour que nous puissions enterrer lquipe de pompiers et crer des quipes Scrum supplmentaires la place. Les pompiers taient plutt heureux de ranger leurs casques abims et de rejoindre des quipes Scrum la place.
Pour tre plus concret, voici comment la runion de planning de sprint fonctionne pour cette quipe : La runion de planning de sprint a lieu dans un centre de confrence externe. Juste avant la runion, le directeur de produit dsigne un mur comme le mur du backlog de produit et y fixe des histoires dutilisateur (fiches cartonnes), ordonnes par priorit relative. Il continue en ajouter jusqu ce que le mur soit rempli, ce qui habituellement constitue plus de travail que possible pour un sprint.
Chaque quipe Scrum slectionne une section de mur vide pour elle, et y poste son nom dquipe. Cest leur mur dquipe . Chaque quipe prend alors des histoires sur le mur de backlog de produit, en commenant
COMMENT NOUS GERONS LES EQUIPES MULTI-SCRUM | 135 par les histoires de plus haute priorit, et place les fiches cartonnes sur son propre mur dquipe. Cest illustr par le diagramme ci-dessous, avec les flches jaunes qui symbolisent le flux des fiches depuis le mur de backlog de produit vers les murs des quipes.
Au fur et mesure de la progression de la runion, le directeur de produit et les quipes marchandent sur les fiches cartonnes, les dplacent entre les quipes, les dplacent vers le haut ou le bas pour changer les priorits, les dcoupent en lments plus petits, etc. Aprs une heure environ, chaque quipe a une premire version candidate de backlog de sprint sur leur mur dquipe. Aprs cela, les quipes travaillent indpendamment, et font la dcomposition en tches et lestimation en temps.
Cest bordlique et chaotique et puisant, mais galement efficace et amusant et social. Quand le temps imparti est coul, toutes les quipes ont gnralement suffisamment dinformations pour commencer leur sprint.
Nous navons jamais fait cela, et nous ne le ferons probablement jamais. Si les deux backlogs de produit impliquent la mme base de code, cela va probablement causer de srieux conflits dintrt entre les deux directeurs de produit. Si les deux backlogs de produit impliquent des bases de code spares, alors cela revient partager le produit total en sous-produits spars, et
138 | SCRUM ET XP DEPUIS LES TRANCHEES les grer indpendamment. Cela signifie que nous sommes revenus la situation une quipe un produit , ce qui est lgant et facile.
Branches de code
Avec plusieurs quipes qui travaillent sur la mme base de code, il est invitable davoir grer des branches de code dans le systme de gestion de configurations. Il y a beaucoup de livres et darticles sur la manire de grer plusieurs personnes travaillant sur la mme base de code, donc je nirais pas dans les dtails ici. Je nai rien de nouveau ou de rvolutionnaire ajouter. Toutefois je vais rsumer quelques unes des plus importantes leons que nos quipes ont apprises jusque l. Soyez strict et gardez la ligne principale (ou tronc) dans un tat cohrent. Cela signifie, au minimum, que tout devrait compiler et que tous les tests unitaires devraient passer. Il devrait tre possible de crer une version livrable fonctionnelle nimporte quel moment. De prfrence, le systme de build en continu devrait construire et dployer automatiquement sur un environnement de test toutes les nuits. Etiquetez chaque version livre. Chaque fois que vous livrez une version pour les tests dacceptation ou pour la production, assurez-vous quil y a une tiquette de version sur votre ligne principale, tiquette qui identifie exactement ce qui a t livr. Cela signifie que vous pouvez, nimporte quel point dans le futur, revenir en arrire et crer une branche de maintenance depuis cette tiquette. Crez de nouvelles branches uniquement quand cest ncessaire. Une bonne rgle empirique est de crer une nouvelle branche de code uniquement quand vous ne pouvez pas utiliser une ligne de code existante sans violer la politique de cette ligne. En cas de doute, ne crez pas de branche. Pourquoi ? Parce que chaque branche active est couteuse en administration et complexit. Utilisez les branches principalement pour sparer diffrents cycles de vie. Vous pouvez dcider ou non davoir chaque quipe Scrum sur a propre ligne de code. Mais si vous mlangez des corrections court terme avec des changements long terme dans la mme ligne de code, vous trouverez trs difficile de livrez les corrections court terme !
COMMENT NOUS GERONS LES EQUIPES MULTI-SCRUM | 139 Synchronisez souvent. Si vous travaillez sur une branche, synchronisez avec la ligne principale chaque fois que vous quelque chose qui compile. Tous les matins quand vous arrivez au travail, synchronisez depuis la ligne principale sur votre branche, de telle sorte que votre branche soit jour par rapport aux modifications des autres quipes. Si fusionner cest lenfer, acceptez simplement le fait que cela aurait t bien pire dattendre.
Rtrospectives multi-quipes
Comment faisons nous les rtrospectives de sprint quand plusieurs quipes travaillent sur le mme produit ? Immdiatement aprs la dmonstration du sprint, aprs les applaudissements et le mlange gnral, chaque quipe part dans une pice rserve pour elle, ou pour un endroit confortable lextrieur. Elles font leurs rtrospectives peu prs comme je lai dcrit page 82 Comment nous faisons les rtrospectives de sprint . Durant la runion de planning de sprint ( laquelle toutes les quipes participent, puisque nous faisons des sprints synchroniss pour chaque produit), la premire chose que nous faisons est de laisser un porte-parole par quipe faire un rsum des points cls de leur rtrospective. Cela prend environ 5 minutes par quipe. Ensuite nous avons une discussion ouverte pendant 10 20 minutes. Puis nous faisons une pause. Ensuite nous commenons le planning de sprint proprement dit. Nous navons pas essay dautres manires, ceci marche suffisamment bien. Le plus gros inconvnient est quil ny a pas de temps libre aprs la rtrospective, et avant le planning. (voir page 88 Relcher le rythme entre les sprints ) Pour les produits une seule quipe, nous ne faisons pas ce rsum de rtrospective durant la runion de planning de sprint. Cela nest pas ncessaire, puisque tout le monde tait prsent lors de la rtrospective du sprint.
16
Comment nous grons les quipes gographiquement disperses
Que se passe-t-il lorsque des membres de lquipe sont dans des lieux gographiques diffrents ? Le plus gros de la magie de Scrum et XP sappuie sur des quipiers colocaliss qui collaborent troitement en programmant par paires et en se runissant chaque jour. Nous avons des quipes spares gographiquement les unes des autres, ainsi que des quipiers qui travaillent de chez eux de temps en temps. Notre stratgie est alors assez simple. Nous employons toutes les ficelles imaginables pour maximiser la bande passante utilise par les quipiers spars physiquement, pour communiquer entre eux. Je ne parle pas seulement de bande passante en termes de Mbits/seconde (bien que celleci soit videmment importante galement). Je parle de bande passante en termes de communication, au sens plus large : La capacit programmer par paires. La capacit se rencontrer en tte--tte lors de la mle quotidienne. La capacit discuter en tte--tte tout moment. La capacit se rencontrer physiquement et en dehors du contexte du travail. La capacit runir toute lquipe, de faon impromptue. La capacit accder la mme vue du Sprint Backlog, du Sprint Burndown, du Backlog des produits et dautres sources dinformation. Certaines des mesures que nous avons implmentes (ou que nous sommes en train dimplmenter, elles ne sont pas encore toutes oprationnelles) sont : Une webcam et un casque avec microphone chaque station de travail.
142 | SCRUM ET XP DEPUIS LES TRANCHEES Des salles de confrence quipes pour la communication distance avec des webcams, des microphones de confrence, des ordinateurs allums en permanence, des logiciels de partage des postes de travail, etc. Des fentres distantes . De grands crans dans chaque lieu, montrant en permanence une vue des autres lieux. Un peu comme une fentre virtuelle entre deux services. Vous pouvez vous faire des signes. Vous pouvez voir qui est son poste et qui parle qui. Le but est de crer le sentiment que h, nous sommes tous dans le mme bateau . Des programmes dchange, lors desquels des personnes provenant des divers lieux se rendent visite rgulirement.
En utilisant ces techniques ainsi que dautres, nous commenons lentement mais srement nous habituer organiser des runions de planification du sprint, des dmonstrations, des rtrospectives, des mles quotidiennes, etc. avec les quipiers disperss gographiquement. Comme dhabitude, cest une histoire dexprimentation. Inspecte => adapte => inspecte => adapte => inspecte => adapte => inspecte => adapte =>
inspecte => adapte
Dlocaliser Offshore
Nous avons plusieurs quipes offshore et exprimentons depuis un certain temps des faons de grer la situation avec Scrum. Il existe ici deux stratgies principales : des quipes spares et des quipiers spars.
La premire stratgie, des quipes spares, est un choix incontestable. Cependant, nous avons commenc par la seconde stratgie, des quipiers spars. Pour cela, il y a plusieurs raisons. 1. Nous voulons que les quipiers se connaissent bien entre eux. 2. Nous voulons une excellente infrastructure de communication entre les deux lieux et voulons fortement inciter les quipes la mettre en place. 3. Au dbut, lquipe offshore est trop petite pour constituer une quipe Scrum efficace elle seule. 4. Nous nenvisagerons la cration dquipes offshore quau terme dune priode dchange intense des connaissances.
144 | SCRUM ET XP DEPUIS LES TRANCHEES A long terme, il se peut que nous nous dirigions vers la stratgie des quipes spares .
17
Pense-bte du Scrum Master
Dans cet ultime chapitre, je vais vous montrer notre pense-bte du Scrum master, qui inventorie les routines administratives les plus courantes pour nos Scrum Masters. Des choses qui soublient facilement. Nous passons sur les vidences telles que supprimer les obstacles rencontrs par lquipe .
Dbut du Sprint
Aprs la runion de planification du Sprint, crer une page dinformation du Sprint. o Ajouter un lien cette page depuis le tableau de bord sur le wiki. o Imprimer la page et lafficher sur le mur prs de lquipe et dun lieu de passage. Envoyer un e-mail chacun pour annoncer quun nouveau Sprint a dmarr. Y inclure le but du Sprint ainsi quun lien vers la page dinformation du Sprint. Mettre jour le document des statistiques du Sprint. Ajouter votre vlocit estime, la taille de lquipe, la dure du Sprint, etc.
146 | SCRUM ET XP DEPUIS LES TRANCHEES Sassurer que lquipe tient le Backlog et le Burndown du Sprint jour. Sassurer que les problmes/obstacles sont rsolus ou communiqus au directeur de produit et/ou au responsable du dveloppement.
Fin du Sprint
Organisez une dmonstration publique lissue du Sprint. Tout le monde devrait tre inform de la tenue de la dmonstration un ou deux jours avant. Organisez une rtrospective du Sprint en prsence de toute lquipe et du directeur de produit. Invitez galement le responsable du dveloppement afin quil puisse propager les leons apprises. Mettez jour le document des statistiques du Sprint. Ajoutez-y la vlocit effective ainsi que les points cls de la rtrospective.
18
Mot de la fin
Eh bien ! Je naurais jamais cru que a deviendrait aussi long. Jespre que ce papier vous a donn des ides utiles, que Scrum soit nouveau pour vous ou que vous soyez un vtran chevronn. Parce que Scrum doit tre faonn diffremment pour chaque environnement, il est difficile de dbattre objectivement des meilleures pratiques en gnral. Nanmoins, je suis intress par vos remarques. Dites-moi en quoi votre approche diffre de la mienne. Donnez-moi des ides damlioration ! Nhsitez pas me contacter henrik.kniberg@crisp.se. Je garde aussi un il sur scrumdevelopment@yahoogroups.com. Si vous avez aim ce livre, vous aurez peut-tre envie de jeter un il mon blog de temps en temps. Jespre y ajouter des articles sur Java et le dveloppement informatique agile. http://blog.crisp.se/henrikkniberg/
Lectures recommandes
Voici quelques livres qui mont donn beaucoup dinspiration et dides. Hautement recommands !
A propos de lauteur
Henrik Kniberg (henrik.kniberg@crisp.se) est un consultant chez Crisp Stockholm (www.crisp.se), spcialis dans Java et le dveloppement informatique Agile. Ds lapparition des premiers livres sur XP et du manifeste agile, Henrik adopta les principes agiles et essaya dapprendre les appliquer de faon efficace dans diffrents types dorganisations. En tant que cofondateur et Directeur Technique de Goyada entre 1998 et 2003, il et amplement lopportunit dexprimenter avec le dveloppement dirig par les tests ainsi que dautres pratiques agiles, alors quil construisait et manageait une plateforme technique et une quipe de dveloppement de 30 personnes. Fin 2005, Henrik effectua une mission en tant que responsable du dveloppement dans une socit sudoise dans le domaine du jeu. La socit tait en situation de crise avec des problmes organisationnels et techniques urgents. Par lutilisation de Scrum et XP comme outils, Henrik aida la socit sortir de sa crise en implmentant des principes agiles tous les niveaux de la socit. Un vendredi de novembre 2006, Henrik tait alit avec de la fivre et dcida de prendre quelques notes sur ce quil avait appris pendant lanne passe. Mais une fois quil et commenc crire, il ne pouvait plus sarrter et aprs avoir tap sur son clavier et dessin pendant trois jours, les notes initiales staient transformes en un article de 80 pages intitul Scrum et XP depuis les Tranches , qui ventuellement devint ce livre. Henrik adopte une approche holistique et apprcie de jouer diffrents rles tels que manager, dveloppeur, Scrum Master, professeur et entraneur. Aider les socits dvelopper des applications et des quipes excellentes le passionne, adoptant tout rle quil juge ncessaire. Henrik a grandi Tokyo et vit maintenant Stockholm avec son pouse Sophia et leurs deux enfants. Durant son temps libre, il compose de la musique et joue de la basse et du clavier avec des groupes locaux. Pour plus dinformation, visitez http://www.crisp.se/henrik.kniberg