Scrum et XP depuis les Tranches

Comment nous appliquons Scrum

Ecrit par : Henrik Kniberg

 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 !

Table des matires

PREFACE DE JEFF SUTHERLAND PREFACE DE MIKE COHN i iii

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

MOT DE LA FIN .......................................................................................147 LECTURES RECOMMANDEES ............................................................149 A PROPOS DE LAUTEUR .....................................................................151

Prface de Jeff Sutherland

Les quipes doivent connatre les bases de Scrum. Comment est-ce que vous crez et estimez un backlog de produit ? Comment le transformezvous en backlog d'itration ? Comment grez-vous une courbe du reste faire et calculez la vlocit de l'quipe ? Le livre d'Henrik est un kit de dmarrage avec les pratiques de base qui aident les quipes passer d'un essai de Scrum une bonne implmentation de Scrum. Une bonne implmentation de Scrum devient plus importante pour les quipes qui cherchent des investissements financiers. En tant que coach Agile pour un groupe investissant en capital-risque, je les aide investir seulement dans les entreprises agiles qui appliquent bien les pratiques agiles. L'associ principal du groupe a demand toutes les socits au sein de son portefeuille si elles connaissent la vlocit de leurs quipes. Elles ont des difficults rpondre la question tout de suite. Les futures opportunits d'investissement vont obliger les quipes comprendre leur vlocit de dveloppement logiciel. Pourquoi est-ce si important? Si les quipes ne connaissent pas leur vlocit, le Directeur de produit ne peut crer de feuille de route pour le produit avec des chances crdibles. Sans des chances fiables, l'entreprise peut chouer et les investisseurs peuvent perdre leur argent ! Ce problme touche les grandes socits comme les petites, nouvelles ou anciennes, finance ou non. Lors d'une discussion rcente sur l'implmentation de Scrum de Google une confrence londonienne, j'ai demand une audience de 135 personnes combien appliquaient Scrum et 30 ont rpondu positivement. Je leur ai ensuite demand s'ils faisaient du dveloppement itratif selon les standards de Nokia. Le dveloppement

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

Prface de Mike Cohn

Scrum et Extreme Programming (XP) demandent tous deux aux quipes de finir certains lments tangibles et livrables de leur travail la fin de chaque itration. Ces itrations sont conues pour tre courtes et dure finie. Laccent mis sur le fait de livrer du code qui marche au bout dune courte priode de temps signifie que les quipes Scrum et XP nont pas de temps pour faire de la thorie. Elles ne svertuent pas dessiner le modle UML parfait dans leur outil de modlisation, crire des cahiers des charges parfaits, ou crire du code qui pourra sadapter tous les changements futurs imaginables. A la place, les quipes Scrum et XP se concentrent pour que les choses soient termines. Ces quipes acceptent quelles puissent faire des erreurs en chemin, mais elles ralisent aussi que le meilleur moyen pour trouver ces erreurs est darrter de penser au logiciel au niveau thorique de lanalyse et de la conception, mais plutt de se lancer, de se salir les mains, et de commencer construire le produit.

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.

iv | SCRUM ET XP DEPUIS LES TRANCHEES

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.

Prface - H, Scrum ca marche !

Scrum ca marche ! Au moins pour nous (cest--dire mon client actuel Stockholm, dont je nai pas lintention de mentionner le nom ici). Jespre quil marchera pour vous aussi ! Peut-tre que ce papier vous aidera au long du chemin. Cest la premire fois que jai vu une mthodologie de dveloppement (dsol Ken, un cadre) marcher exactement comme dans le bouquin. Plug n play. Nous sommes tous heureux avec lui dveloppeurs, testeurs, managers. Il nous a aids nous sortir dune situation difficile, et nous a permis de maintenir une focalisation et un lan malgr de svres turbulences du march et des rductions de personnel. Je ne devrais pas dire que jai t surpris, mais, eh bien oui, je lai t. Aprs avoir initialement digr quelques livres sur le sujet Scrum semblait bien, mais prs trop bien pour tre vrai (et nous connaissons tous le proverbe quand quelque chose semble trop beau pour tre vrai ). Donc jtais lgitimement un peu sceptique. Mais aprs avoir appliqu Scrum pendant un an je suis suffisamment impressionn (et la plupart des gens dans les quipes aussi) pour que je continue probablement utiliser Scrum par dfaut dans les nouveaux projets chaque fois quil ny a pas une trs bonne raison de faire autrement.

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.

Pourquoi jai crit ceci

En me formant Scrum j'ai lu les livres pertinents sur Scrum et l'agilit, je me suis panch dans les sites et forums sur Scrum, j'ai suivi la certification de Ken Schwaber, je l'ai mitraill de questions, et j'ai pass beaucoup de temps discuter avec mes collgues. Toutefois l'une de mes meilleures sources d'information a t les vraies histoires de guerre. Les histoires de guerre transforment les Principes et Pratiques en ... eh bien ... Comment faire en pratique. Elles m'ont aussi permis d'identifier (et parfois d'viter) les erreurs typiques de dbutant. Alors c'est l'occasion pour moi de donner quelque chose en retour. Voici mon histoire de guerre.

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 !

Mais Scrum, qu'est-ce que c'est ?

Oh, dsol. Vous tes compltement dbutant en Scrum et XP ? Dans ce cas vous pourriez avoir envie de jeter un il aux liens suivants : http://agilemanifesto.org/ http://www.mountaingoatsoftware.com/scrum http://www.xprogramming.com/xpmag/whatisxp.htm Si vous tes trop impatient pour le faire, sentez-vous libres de simplement continuer lire. La plupart du jargon Scrum est expliqu au fur et mesure, aussi vous pourriez quand mme trouver cette lecture intressante.

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

COMMENT NOUS FAISONS LES BACKLOGS DE PRODUIT | 13

transactions Faire un dpt. Revenir aux transactions, vrifier que le nouveau dpt apparat. des requtes volumineuses . Conception semblable la page des utilisateurs.

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.

Champs d'histoire supplmentaires

Parfois nous utilisons des champs supplmentaires dans le product backlog, surtout par commodit pour le directeur de produit pour l'aider trier ses priorits. Catgorie - un classement approximatif de cette histoire, par exemple back office ou optimisation . De cette faon le directeur de produit peut facilement filtrer tous les lments optimisation et leur affecter une priorit basse, etc. Composants - Habituellement reprsents par des cases cocher dans un tableau Excel, par exemple base de donnes, serveur, client . Ici l'quipe ou le directeur de produit peut identifier quels composants techniques vont tre impliqus dans l'implmentation de cette histoire. Ceci est utile quand vous avez plusieurs quipes Scrum, par exemple une quipe back office et une quipe client, et que vous

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.

Comment nous gardons le backlog de produit un niveau mtier

Si le directeur de produit a un pass technique il peut vouloir ajouter des histoires comme ajouter des indexes sur les table d'vnements . Pourquoi veut-il faire a ? Le but rel sous-jacent est probablement quelque chose du genre augmenter la rapidit de la recherche des vnements sur le back office . Il se peut que les indexes n'taient pas le goulot d'tranglement qui rendait le formulaire lent. Il se peut que ce soit quelque chose de compltement diffrent. L'quipe est normalement mieux place pour deviner comment rsoudre quelque chose, aussi le directeur de produit devrait garder le focus sur les objectifs mtiers. Quand je vois des histoires orientes technique comme celle-ci, je pose normalement au directeur de produit une srie de questions mais pourquoi jusqu' ce qu'on trouve le but sous-jacent. Ensuite on reformule l'histoire dans les termes de ce but sous-jacent ( augmenter la rapidit de la recherche des vnements sur le back office ). La description technique d'origine finit en tant que note ( indexer la table des vnements peut peut-tre rsoudre le problme ).

COMMENT NOUS FAISONS LES BACKLOGS DE PRODUIT | 15

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.

Pourquoi le directeur de produit doit y assister

Quelquefois les directeurs de produits rechignent passer des heures avec l'quipe pour faire le planning de sprint. Les gars, j'ai dj list ce que je voulais. Je n'ai pas le temps de participer votre runion de planning . C'est un problme vraiment srieux. La raison pour laquelle l'quipe au complet ainsi que le directeur de produit doivent tre cette runion de planning de sprint est que chaque

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.

Pourquoi la qualit n'est pas ngociable

Dans le triangle ci-dessus j'ai intentionnellement vit une quatrime variable qualit.

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.

Les runions de planning de sprint qui s'ternisent...

La plus grande difficult des runions de planning de sprint est que : 1) les gens ne pensent pas qu'elles vont durer si longtemps 2) ... mais c'est toujours le cas ! Tout dans Scrum est en temps limit. J'adore cette rgle simple et cohrente.

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.

Lordre du jour de la runion de planning de sprint

Avoir une sorte dordre du jour prliminaire pour cette runion rduira le risque de ne pas respecter la limite de temps. Voici un exemple dun plan typique pour nous.

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.

Le choix de la dure du sprint

Lun des produits de cette runion de planning de sprint est une date de dmonstration bien dfinie. Cela signifie que vous devez dcider dune dure de sprint. Donc quelle la bonne dure dun sprint ? Eh bien, les sprints courts sont bnfiques. Ils autorisent lentreprise tre agile , cest--dire changer souvent de direction. Les sprints courts = cycle de feedback court = des livraisons plus frquentes = plus de feedback des clients = moins de temps pass courir dans la mauvaise direction = apprendre et amliorer plus rapidement, etc. Cela dit, les longs sprints sont bien aussi. Lquipe a plus temps pour monter en puissance, ils ont plus de temps pour rcuprer des problmes et parvenir tout de mme atteindre le but du sprint, il y a moins de surcharge en terme de runions de planning de sprint, de dmonstrations, etc.

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.

La dfinition du but du sprint

Cela arrive presque chaque fois. A un certain moment durant la runion je demande alors quel est le but de ce sprint ? et tout le monde me regarde fixement et le directeur de produit fronce les sourcils et se gratte le menton. Il se trouve quil est difficile de dterminer un but de sprint. Mais toutefois jai dcouvert que cest vraiment payant de se forcer en trouver un. Il vaut mieux un but demi-merdique que pas de but du tout. Le but pourrait tre gagner plus dargent ou terminer les trois histoires les plus prioritaires ou impressionner le PDG ou rendre le systme suffisamment bon pour tre dploy chez un groupe de beta-testeurs ou ajouter un support basique pour le back office ou nimporte quoi dautre. Le point important est que le but devrait tre dfini en termes mtier, pas en termes techniques. Cela signifie en termes que les gens en dehors de lquipe peuvent comprendre.

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 !

Le choix des histoires inclure dans le sprint

Lune des activits principales de la runion de planning de sprint est de dcider quelles histoires inclure dans le sprint. Plus prcisment, quelles histoires du backlog de produit il faut copier dans le backlog de sprint.

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.

COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 29

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.

Comment les quipes choisissent-elles les histoires inclure dans le sprint?

Pour cela, nous utilisons deux techniques : 1. Lintuition 2. Les calculs de vlocit

Estimation en utilisant lintuition

Scrum master: Eh les gars, peut-on finir lhistoire A dans ce sprint? (montrant llment le plus important du backlog de produit) Lisa: Ben. Bien sr que nous pouvons. Nous avons 3 semaines, et cest une fonctionnalit plutt facile. Scrum master: OK, et nous rajoutons aussi lhistoire B ? (montrons le deuxime lment le plus important) Tom & Lisa ensemble: Pas de problme. Scrum master: OK, et avec les histories A, B et C maintenant ? Sam ( ladresse du Directeur de produit): Est-ce que lhistoire C comporte une gestion avance des erreurs ? Directeur de produit: non, vous pouvez la laisser de cot pour le moment, implmentez juste une gestion basique des erreurs. Sam: alors C devrait tre bonne aussi. Scrum master: OK, et si nous ajoutons lhistoire D ? Lisa: Hum.... Tom: Je pense que nous pouvons le faire.

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.

Estimation en utilisant les calculs de vlocit

Cette technique implique deux tapes: 1. Dcider la vlocit estime 2. Calculer combien dhistoires vous pouvez ajouter sans dpasser la vlocit estime La vlocit mesure la quantit de travail fini, o chaque lment est pondr selon son estimation initiale. Limage ci-dessous montre un exemple de vlocit estime au dmarrage dun sprint et la vlocit effective la fin du sprint. Chaque rectangle est une histoire, et le numro lintrieur est lestimation initiale de cette histoire.

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

32 | SCRUM ET XP DEPUIS LES TRANCHEES

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.

Quelle technique destimation utilisons-nous?

Jai mentionn plusieurs techniques au dessus lintuition, le calcul de vlocit bas sur la mto de la veille, et le calcul de vlocit bas sur le nombre de jours-homme disponible et lestimation du facteur de focalisation. Alors quelle technique utilisons-nous? Nous combinons gnralement toutes ces techniques un certain degr. Cela ne prend pas longtemps. Nous regardons le facteur de focalisation et la vlocit effective du dernier sprint. Nous regardons le total de nos ressources disponibles pour ce sprint et estimons le facteur de focalisation. Nous discutons de la moindre diffrence entre ces deux facteurs de concentration et procdons des ajustements si ncessaire. Une fois que nous avons une liste prliminaire des histoires inclure dans le sprint, je fais une vrification lintuition. Je demande lquipe dignorer les chiffres pour un moment et de sentir tout simplement si cela semble tre un morceau raisonnable se mettre sous la dent pour un sprint. Si cela semble trop gros, nous enlevons une histoire ou deux. Et vice-versa.

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.

Pourquoi nous utilisons des fiches

La plupart des runions de planification de sprint se droulent en se basant sur les histoires du backlog de produit. On les estime, on redfinit leur priorits, on les clarifie, on les dcoupe, etc.. Comment faisons-nous a en pratique ? Eh bien, par dfaut, les quipes avaient lhabitude dallumer le projecteur vido, de montrer le backlog sous Excel, et un gars (typiquement le Directeur de produit ou le Scrum master) prenait le clavier, marmonnait en parcourant chaque histoire et invitait discuter. Comme lquipe et le Directeur de produit discutaient les priorits et les dtails le gars au clavier mettait jour directement lhistoire dans Excel. Cela parat bien, non ? En fait, a ne lest pas. Gnralement a craint. Et le pire cest quen gnral lquipe ne remarque pas que a craint jusqu ce quarrive la fin de la runion et ralise quils nont toujours pas russi parcourir toute la liste des histoires ! Une solution qui marche beaucoup mieux consiste crer des fiches et de les mettre au mur (ou sur une grande table).

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.

Lestimation de temps avec le poker de planning

Lestimation est une activit dquipe chaque membre de lquipe est habituellement impliqu dans lestimation de chaque histoire. Pourquoi ? Au moment du planning, normalement nous ne savons pas exactement qui va implmenter quelle partie de quelle histoire.

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.

La clarification des histoires

Le pire cest quand un membre de lquipe dmontre firement une nouvelle fonctionnalit la dmonstration du sprint, et que le directeur de

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 ?

La dcomposition des histoires en plus petites histoires

Les histoires ne devraient pas tre trop petites ou trop grosses (en termes destimations). Si vous avez un lot dhistoires 0,5 points vous allez probablement tre une victime du micro-management. Dun autre ct, une histoire de 40 points implique un risque lev de finir partiellement termine, ce qui ne produit aucune valeur pour votre entreprise et augmente simplement le travail administratif. De plus, si votre vlocit estime est de 70 et que vos deux histoires prioritaires sont 40 points chacune, le planning devient quelque peu difficile. Vous devez choisir entre le sous-engagement (cest--dire prendre juste un lment) et le surengagement (cest--dire prendre les deux lments). Je remarque quil est presque toujours possible de couper une grosse histoire en plusieurs histoires plus petites. Faites simplement attention que les petites histoires continuent reprsenter des livrables avec une valeur pour le client. Normalement nous nous efforons davoir des histoires pesant de 2 8 jours-hommes. Notre vlocit est habituellement autour de 40-60 pour une quipe typique, ce qui nous donne quelque chose comme environ 10 histoires par sprint. Quelquefois cela descend 5 et quelquefois cela monte 15. Cela reste un nombre de fiches cartonnes grable.

La dcomposition des histoires en tches

Attendez une seconde, quelle est la diffrence entre tches et histoire ? Cest une trs bonne question. La distinction est assez simple. Les histoires sont des choses livrables qui intressent le directeur de produit. Les tches sont des choses non livrables, ou des choses auxquelles le directeur de produit ne sintresse pas. Exemple de dcomposition dune histoire en histoires plus petites :

COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 43

Exemple de dcomposition dune histoire en tches :

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).

Le choix du lieu et lheure pour la mle quotidienne

Un lment de sortie souvent oubli de la runion de planning du sprint est un lieu et une heure bien dfinis pour la mle quotidienne . Sans cet lment votre sprint va faire un mauvais dpart. La premire mle quotidienne est essentiellement le point o tout le monde dcide o commencer travailler. Je prfre les runions du matin. Mais, je dois ladmettre, nous navons pas rellement essay de faire les mles quotidiennes laprs-midi ou mi-journe. Inconvnient des mles de laprs-midi : quand vous venez travailler le matin, vous devez essayer de vous rappeler ce que vous avez dit hier vos collgues au sujet de ce que vous feriez aujourdhui. Inconvnient des mles du matin : quand vous venez travailler le matin, vous devez essayer de vous rappeler ce que vous avez fait hier pour pouvoir le rapporter. Mon point de vue est que le premier inconvnient est pire, puisque la chose la plus importante est ce que vous allez faire, pas ce que vous avez fait. Notre procdure par dfaut est de choisir le moment le plus tt o personne dans lquipe ne se plaigne. Habituellement 9:00, 9:30, ou 10:00. La chose la plus importante est une heure que tout le monde dans lquipe accepte de bon cur.

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.

Les histoires techniques

Voici un point complexe : les histoires techniques. Ou encore lments non-fonctionnels ou quoi que ce soit que vous vouliez les appeler. Je fais rfrence aux choses qui doivent tre faites mais qui ne sont pas livrables, pas lies directement des histoires spcifiques, et qui nont pas de valeur directe pour le directeur de produit. Nous les appelons histoires techniques . Par exemple :

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 ?

Systme de suivi de bug vs. backlog de produit

Voici un point pineux. Excel est un excellent support pour le backlog de produit. Mais vous avez tout de mme besoin dun systme de suivi de bugs, et Excel ne fera probablement pas laffaire. Nous utilisons Jira. Donc comment amenons-nous des entres Jira dans la runion de planning de sprint ? Je veux dire que ca ne le ferait pas de simplement les ignorer et de se focaliser uniquement sur les histoires. Nous avons essay plusieurs stratgies : 1) Le directeur de produit imprime les entres Jira de plus haute priorit, les apporte la runion de planning de sprint, et les met sur le mur avec les autres histoires (et donc spcifie implicitement la priorit de ces lments par rapport aux autres histoires). 2) Le directeur de produit cre des histoires qui font rfrence aux entres Jira. Par exemple Corriger les bugs les plus critiques sur les rapports back office, Jira-124, Jira-126 et Jira-180 .

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.

La runion de planning de sprint est finalement termine !

Waouh, je naurais jamais pens que ce chapitre sur les runions de planning de sprint serait aussi long ! Je devine que cela reflte mon opinion que la runion de planning de sprint est la chose la plus importante que vous faites dans Scrum. Faites beaucoup defforts pour faire ca correctement, et le reste sera tellement plus facile. La runion de planning de sprint est russie si tout le monde (tous les membres de lquipe et le directeur de produit) sortent de la runion avec le sourire, et se lvent le matin suivant avec le sourire, et font leur premire mle quotidienne avec le sourire. Ensuite, bien sr, toutes sortes de choses peuvent se passer horriblement mal, mais au moins vous ne pourrez pas blmer le plan du sprint :o)

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.

Format du backlog de sprint

Nous avons essay diffrents formats pour le backlog de sprint, y compris Jira, Excel et un tableau physique des tches sur le mur. Au dbut, nous avons utilis Excel le plus souvent, il y a disposition du public de nombreux modles Excel pour les backlogs de Sprint, avec gnration automatique de burndown chart et des choses comme a. Je pourrais discuter longtemps sur la faon dont nous avons amlior notre backlog de Sprint sous Excel. Mais je ne le ferai pas. Je ne vais mme pas mettre un exemple ici. A la place je vais vous dcrire en dtail ce que nous considrons tre le format le plus efficace pour les backlogs de sprint - un tableau des tches sur le mur ! Trouvez un grand mur inutilis ou contenant des choses inutiles comme le logo de la socit, des vieux diagrammes ou d'affreuses peintures. Nettoyez le mur (demandez la permission si vous le devez). Scotchez une grande, grande feuille de papier (au moins 2 x 2 mtres, ou 3 x 2 mtres pour une grande quipe). Puis faites ceci :

56 | SCRUM ET XP DEPUIS LES TRANCHEES

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.

COMMENT NOUS FAISONS LES BACKLOGS DE SPRINT | 57

Comment le tableau des tches fonctionne

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.

58 | SCRUM ET XP DEPUIS LES TRANCHEES

Exemple 1 - Aprs la premire mle quotidienne

Aprs la premire mle quotidienne, le tableau des tches devrait ressembler a :

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.

COMMENT NOUS FAISONS LES BACKLOGS DE SPRINT | 59

Exemple 2 aprs quelques jours

Aprs quelques jours le tableau des tches devrait ressembler a :

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.

60 | SCRUM ET XP DEPUIS LES TRANCHEES

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.

COMMENT NOUS FAISONS LES BACKLOGS DE SPRINT | 61

Comment le burndown chart fonctionne

Regardons de plus prs le burndown chart :

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.

62 | SCRUM ET XP DEPUIS LES TRANCHEES

Les signaux davertissement du tableau des tches

Un rapide coup dil sur le tableau des tches devrait donner tout le monde une indication sur le bon droulement du sprint. Le Scrum master a la responsabilit de sassurer que lquipe ragit aux signaux davertissement comme :

COMMENT NOUS FAISONS LES BACKLOGS DE SPRINT | 63

64 | SCRUM ET XP DEPUIS LES TRANCHEES

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 ?

Estimations en jours vs. heures

Dans la plupart des livres et articles sur Scrum vous trouverez que les tches sont estimes en heures, pas en jours. Nous avions lhabitude de faire ainsi. Notre formule gnrale tait : 1 jour-homme effectif = 6 heures-homme effectives. Maintenant nous avons arrt de faire a, au moins dans la plupart de nos quipes, pour les raisons suivantes : Les estimations en heures-homme sont trop fines, cela engendre trop de petites tches de 1-2 heures et entrane par consquent le micro-management. Ca masque le fait que tout le monde pense en jours-homme de toutes faons, et quon multiplie juste par 6 avant dcrire en heures-homme. Hmmmm, cette tche devrait prendre peu prs un jour. Oh je dois crire en heures, jcrirai 6 heures alors . Deux units diffrentes sment la confusion. Cette estimation tait-elle en heures-homme ou en jours-homme ? . Donc maintenant nous utilisons les jours-homme comme base pour toutes nos estimations de temps (bien que nous appelons a des points dhistoire). Notre plus petite valeur est 0.5, cest--dire que toute tche infrieure ) 0.5 est soit supprime, soit combine avec une autre tche, ou

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.

66 | SCRUM ET XP DEPUIS LES TRANCHEES

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)

COMMENT NOUS ORGANISONS LE BUREAU DE LEQUIPE | 69

Installez lquipe ensemble !

Quand on en vient lorganisation des bureaux il y a une chose qui nest jamais assez souligne.

Installez lquipe ensemble !

Pour clarifier un peu, je disais

Installez lquipe ensemble !

Les gens sont rticents bouger. Au moins dans les endroits o jai travaill. Ils nont pas envie de prendre toutes leurs affaires, dbrancher le pc, dplacer toutes leurs poubelles jusqu un nouveau bureau, et tout rebrancher. Plus courte est la distance, plus grande est la rticence. Allez chef, a sert quoi de bouger juste de 5 mtres ? Quand on construit des quipes Scrum efficaces, cependant, il ny a pas dalternative. Mettez juste lquipe ensemble. Mme si vous devez personnellement menacer chaque personne, transporter vous-mme tout leur barda, et effacer leurs anciennes tches de caf. Sil ny a pas de place pour lquipe, faites-en. Nimporte o. Mme si vous devez placer lquipe au sous-sol. Dplacez les tables, soudoyez le responsable des bureaux, faites ce quil faut. Mettez juste lquipe ensemble. Une fois lquipe ensemble, les gains sont immdiats. Aprs le premier sprint dj lquipe sera daccord quil sagissait dune bonne ide de regrouper lquipe (dexprience personnelle, il ny a rien qui dit que votre quipe ne sera pas trop borne pour ladmettre). Maintenant quest-ce que ensemble signifie ? Comment doit-on disposer les bureaux ? Bien, je nai pas dopinion tranche sur la disposition optimale des bureaux. Et mme si jen avais, je suppose que la plupart des quipes nont pas le luxe dtre capable de dcider exactement comment disposer leurs bureaux. Il y a habituellement des contraintes physiques lquipe voisine, la porte des toilettes, la grosse machine au milieu du bureau, peu importe. Ensemble signifie : Audibilit : Nimporte qui dans lquipe peut discuter avec quelquun dautre sans crier ou sortir du bureau.

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.

Garder le directeur de produit distance

Le directeur de produit doit tre suffisamment prs pour que lquipe puisse aller le voir et lui demander quelque chose, et pour quil puisse se promener autour du tableau des tches. Mais il ne doit pas sasseoir avec lquipe. Pourquoi ? Parce quil y a des chances quil ne soit pas capable de sempcher de rentrer dans les dtails, et lquipe ne prendra pas forme comme il faut (cest--dire atteindre une quipe soude, autogre, hyper productive). Pour tre honnte, cest de la spculation. Je nai pas encore vu jusque l un cas o le directeur de produit sassoit avec lquipe, aussi je nai aucune raison empirique pour dire que cest une mauvaise ide. Juste linstinct et des ou-dire dautres Scrum masters.

Garder les directeurs et les coachs distance

Cest un peu dur pour moi dcrire ce propos, puisque jai t directeur et coach... C'tait mon job de travailler aussi prs que possible avec lquipe. Je montais les quipes, je naviguais entre elles, je faisais du programmation en binme avec certaines personnes, je coachais des Scrum masters, jorganisais les runions de planification de sprint, etc. Rtrospectivement

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.

Comment nous mettons jour le tableau des tches

Nous mettons jour le tableau des tches pendant la mle quotidienne. Pendant que chaque personne dcrit ce quelle a fait hier et ce quelle va faire aujourdhui, elle dplace les post-its sur le tableau des tches. Quand elle dcrit une tche non planifie, elle colle un post-it pour a. Quand la personne met jour son estimation de temps, elle crit la nouvelle estimation sur le post-it et raye lancienne valeur. Parfois le Scrum Master soccupe des post-its pendant que les personnes parlent.

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.

Traiter avec les retardataires

Certaines quipes ont un pot pour les pices et billets. Quand vous tes en retard, mme si cest juste une minute, vous ajoutez un montant fixe au pot. Aucune question nest pose. Mme si vous appelez avant la runion pour prvenir que vous serez en retard, vous devrez quand mme payer. Vous chappez la sentence seulement si vous avez une bonne excuse comme un rendez-vous chez le mdecin ou votre propre mariage ou quelque chose dans le genre. Largent dans le pot est utilis pour les vnements collectifs. Pour acheter des hamburgers quand nous passons des nuits jouer par exemple :o) Ca marche bien. Mais cest ncessaire seulement pour les quipes o les gens sont souvent en retard. Certaines quipes nont pas besoin de ce type de pratique.

COMMENT NOUS FAISONS LES MELEES QUOTIDIENNES | 75

Traiter avec je ne sais pas quoi faire aujourdhui

Ce nest pas rare pour quelquun de dire Hier jai fait bla bla bla, mais aujourdhui je nai pas la moindre ide de ce que je peux raliser (h ce dernier vers rime). Maintenant quoi ? Disons que Joe et Lisa sont ceux qui ne savent pas quoi faire aujourdhui. Si je suis Scrum master je passe et laisse la personne suivante parler, mais je note qui na rien faire. Aprs que tout le monde ait parl, je repasse sur le tableau des tches avec toute lquipe, de haut en bas, je vrifie que tout est synchro, que tout le monde sait ce que chaque lment signifie, etc. Jinvite les gens rajouter des post-its. Puis je reviens vers ceux qui ne savaient pas quoi faire maintenant que nous avons pass en revue le tableau des tches, avez-vous une ide de ce que vous pourriez faire aujourdhui? Avec un peu de chance ils ont une ide. Sinon, je considre sil ny a pas une opportunit de programmation en binme ici. Disons que Niklas est en train dimplmenter lIHM dadmin du back-office aujourdhui. Dans ce cas je suggre poliment que peut-tre Joe ou Lisa pourrait programmer en binme avec Niklas sur ce sujet. Ca fonctionne en gnral. Et si a ne fonctionne pas, voici lastuce suivante. Scrum master : OK, qui veut nous montrer la version beta de lapplication ? (en supposant que cest le but de litration) Lquipe : silence confus Scrum master : Nous ne sommes pas prts ? Lquipe: hmm... non Scrum master : Ah bon. Pourquoi ? Quest-ce quil reste faire ? Lquipe : Ben nous navons mme pas de serveur de test pour la lancer, et le script de build est cass. Scrum master : Aha. (ajoutez deux post-its sur le mur des tches). Joe et Lisa, comment pouvez-vous nous aider aujourdhui ? Joe : Hmm.... au hasard je vais essayer de trouver un serveur de test quelque part . Lisa : ... et je vais essayer de rparer ce script de build . Si vous avez de la chance, quelquun va effectivement faire la dmo de la version beta que vous avez demande. Super ! Vous avez atteint le but de votre sprint. Mais que faire si vous tes au milieu du sprint ? Facile. Flicitez lquipe pour le travail accompli, prenez une ou deux histoires

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.

Checklist pour les dmos de sprint

Assurez-vous de prsenter clairement lobjectif du sprint. Sil y a des personnes la dmo qui ne connaissent pas du tout votre produit, prenez quelques minutes pour le prsenter. Ne dpensez pas trop de temps prparer la dmo, surtout pas pour une dmo tape--lil. Ignorez ce qui ne marche pas et concentrez vous sur la dmonstration du code qui marche. Gardez un rythme lev, autrement dit essayez de prparer une dmo rythme plutt quune jolie dmo. Gardez la dmo un niveau mtier, oubliez les dtails techniques. Concentrez-vous sur ce que nous avons fait plutt que sur comment nous lavons fait . Si possible, laissez laudience essayer elle-mme le produit. Ne montrez pas les tas de corrections de bugs mineurs et de fonctionnalits insignifiantes. Mentionnez-les mais ne les montrez pas, car a prend trop de temps et a carte lattention des histoires plus importantes.

Soccuper des choses indmontrables

Un membre de lquipe : Je ne vais pas prsenter cet lment, parce que ce nest pas dmontrable. Lhistoire est Amliorer la monte en charge pour que le systme puisse supporter 10000 utilisateurs simultanment. Je ne peux tout de mme pas inviter 10000 utilisateurs la dmo ? Scrum master : Cet lment est-il termin ? Membre de lquipe. Oui, bien sr . Scrum master: Comment le sais-tu ?

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.

82 | SCRUM ET XP DEPUIS LES TRANCHEES

Comment nous organisons les rtrospectives

Le format gnral varie un peu, mais gnralement nous faisons quelque chose comme a : Nous allouons 1 3 heures selon le volume de discussions qui est anticip. Participants : le directeur de produit, lquipe complte, et moimme. Nous allons dans une pice ferme, un coin avec un canap confortable, un patio, ou une place du mme style. Du moment que nous pouvons discuter sans tre drangs. Nous ne faisons pas les rtrospectives dans le bureau de lquipe, car lattention des membres a tendance se relcher. Quelquun est dsign comme secrtaire. Le Scrum master montre le sprint backlog et, avec laide de lquipe, rsume le sprint. Les vnements et dcisions importantes, etc. Nous faisons des tours de table. Chaque personne a une chance de dire, sans tre interrompu, ce quelle pense tre bien, ce quelle pense qui peut tre mieux, et ce quelle pense qui devrait tre diffrent pour le prochain sprint. Nous comparons la vlocit estime et la vlocit effective. Sil y a une grosse diffrence nous essayons danalyser pourquoi. Quand le temps est presque coul le Scrum master essaie de rsumer les suggestions concrtes pour amliorer le prochain sprint.

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 :

COMMENT NOUS FAISONS LES RETROSPECTIVES DE SPRINTS | 83

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.

La diffusion des enseignements tirs entre quipes

Les informations tires dune rtrospective de sprint ont gnralement beaucoup de valeur. Est-ce que cette quipe a du mal se concentrer

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.

Changer ou ne pas changer

Disons que lquipe conclut que nous ne communiquons pas assez dans lquipe, nous nous marchons dessus et nous mettons la pagaille dans la conception des autres. Que feriez-vous pour y remdier ? Introduire des runions quotidiennes sur la conception ? Introduire de nouveaux outils pour faciliter la

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.

Exemples de choses qui peuvent remonter pendant les rtrospectives

Voici quelques exemples typiques de ce qui peut arriver pendant un sprint planning, et les actions typiques.

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.

86 | SCRUM ET XP DEPUIS LES TRANCHEES

Trop de drangements extrieurs

Actions typiques : demandez lquipe de rduire leur facteur de focalisation pour le prochain sprint, afin davoir un plan plus raliste demandez lquipe de bien noter les drangements pendant le prochain sprint. Qui les drange, combien de temps. Ca aidera rsoudre le problme plus tard. demandez lquipe dessayer de rediriger tous les drangements vers le Scrum master ou le directeur de produit demandez lquipe de dsigner une personne comme gardien , tous les drangements sont redirigs vers lui, ainsi le reste de lquipe peut se concentrer. Ce peut tre le Scrum master ou quelquun tour de rle.

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.

Notre bureau est trop bruyant et bordlique

Actions typiques : essayez de crer un meilleur environnement, ou dmnagez lquipe. Louez une chambre dhtel. Ce que vous voulez. Voir page 68 Comment nous organisons le bureau de lquipe ). Si ce nest pas possible, dtes lquipe de rduire leur facteur de focalisation, et indiquez clairement que cest cause du bruit et du dsordre. En esprant que le directeur de produit commencera harceler la direction ce sujet. Heureusement je nai jamais eu menacer de dmnager lquipe. Mais je le ferai si je le devais :o)

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.

Dfinir vos seuils dacceptation

En plus du backlog de produit habituel, le directeur de produit dfinit une liste des seuils dacceptation qui est une classification simple de ce que signifient les niveaux dimportance utiliss dans le backlog de produit par rapport aux aspects contractuels. Voici un exemple de rgles de seuils dacceptation : Tous les lments avec une importance >= 100 doivent tre inclus dans la version 1.0, ou sinon nous serions condamns payer des pnalits de retard. Tous les lments avec une importance de 50-99 devraient tre inclus dans la version 1.0, mais nous devrions tre en mesure de nous en sortir en les incluant dans une release disponible court terme.

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.

Estimation en temps des lments les plus importants

Afin de faire la planification de releases, le directeur de produit a besoin destimations, au moins pour toutes les histoires qui sont incluses dans le contrat. Tout comme la planification de sprint, il sagit dun effort mutuel entre le directeur de produit et lquipe lquipe estime, le directeur de produit dcrit les lments et rpond aux questions.

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) :

Imp 130 120 115 110 100 95 80 70 60 40 35 10 10

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.

Tout mettre ensemble dans un plan de release

Maintenant que nous avons des estimations en temps et une vlocit (45) nous pouvons facilement dcouper le backlog de produit en plusieurs sprints : Imp 130 120 115 110 100 95 80 70 60 40 35 10 10 Estimation Sprint 1 banane 12 pomme 9 orange 20 Sprint 2 goyave 8 poire 20 raisin 12 Sprint 3 cacahute 10 beignet 8 oignon 10 pamplemousse 14 Sprint 4 papaye 4 myrtille pche Nom

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).

Adapter le plan de release

La ralit ne sadaptera pas un plan, cest plutt le cas inverse qui se passe. Aprs chaque sprint, nous regardons la vlocit effective pour ce sprint. Si la vlocit effective tait trs diffrente de la vlocit estime, nous revoyons la vlocit estime pour les futurs sprints et mettons jour le plan de release. Si cela devait nous mettre en situation difficile, le directeur de produit pourrait commencer soit ngocier avec le client, soit voir comment il peut rduire le primtre sans rompre le contrat. Ou peut-tre lui et lquipe trouvent le moyen daugmenter la vlocit ou le facteur de focalisation en supprimant des obstacles srieux qui ont t identifis durant le sprint. Le directeur de produit pourrait appeler le client et dire Bonjour, nous sommes un peu en retard mais je crois que nous pouvons livrer temps si nous enlevons la fonctionnalit Pacman embarqu qui prend beaucoup de temps dvelopper. Nous pourrons linclure dans une version qui sortira 3 semaines aprs la premire release si vous le souhaitez . Ce nest peut-tre pas une bonne nouvelle pour le client, mais au moins nous sommes honntes et nous laissons le choix au client tt dans le projet doit-on livrer les choses les plus importantes temps ou doit-on tout livrer aprs la date prvue ? Ce nest pas un choix si difficile en gnral :o)

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.

Le Dveloppement Dirig par les Tests (DDT)

Amen ! Ceci, pour moi, est plus important que Scrum et XP tous les deux. Vous pouvez prendre ma maison et ma tl et mon chien, mais nessayez pas de mempcher de faire du DDT ! Si vous naimez pas le DDT alors ne me laissez pas entrer dans votre btiment, parce que je vais essayer den introduire dune manire ou dune autre :o) Voici un rsum du DDT en 10 secondes: Le dveloppement dirig par les tests signifie que vous crivez un test automatis, puis vous crivez juste assez de code pour faire passer ce test, puis vous remaniez le code

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.

Le DDT sur du nouveau code

Nous pratiquons le DDT pour tous les nouveaux dveloppements, mme si cela signifie que la mise en place initiale du projet prend plus de temps (puisquil nous faut plus doutils et de support pour les harnais de test, etc). Il ny a pas vraiment de question se poser, les bnfices sont tellement importants quil ny a vraiment pas dexcuse pour ne pas faire du DDT.

Le DDT sur du vieux code

Le DDT est difficile, mais faire du DDT sur une base de code qui na pas t construite avec du DDT ds le dbut a cest vraiment difficile ! Pourquoi ? Eh bien, en fait, je pourrais crire beaucoup de pages sur ce sujet, alors je pense que je vais marrter ici. Je garde cela pour mon prochain papier le DDT depuis les tranches :o) Nous avons pass pas mal de temps essayer dautomatiser les tests dintgration de lun de nos systmes les plus complexes, une base de code qui existe depuis un moment et qui tait dans un tat de pagaille extrme et tait compltement dpourvue de tests. A chaque release du systme nous avions une quipe de testeurs ddis qui ralisaient un lot complet de tests de rgression et de performance. Les tests de rgression taient essentiellement manuels. Ceci ralentissait notablement notre cycle de dveloppement et release. Notre but tait dautomatiser ces tests. Aprs nous tre cogn la tte contre le mur pendant plusieurs mois, toutefois, nous navons pas beaucoup avanc. Aprs a nous avons chang dapproche. Nous avons accept le fait que nous tions obligs de vivre avec du test de rgression manuel, et nous avons plutt commenc nous demander comment pouvons-nous rendre le processus de test manuel moins consommateur de temps ? Ctait un systme de jeu, et nous avons ralis quune bonne partie du temps de lquipe de test tait consacre des tches de mise en place assez triviales, comme bricoler dans le back office pour mettre en place des tournois pour le test, ou attendre quun tournoi planifi dmarre. Donc nous avons cr des utilitaires pour cela. Des raccourcis et des scripts petits, facilement accessibles qui font tout le travail de base et permettent aux testeurs de se concentrer sur le vritable test. Cet effort a vraiment t rentable ! En fait, cest probablement ce que nous aurions d faire au dpart. Nous tions tellement impatients

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.

La proprit collective du code

Nous encourageons la proprit collective du code mais toutes les quipes ne lont pas encore adopte. Nous avons dcouvert que la programmation en binme avec rotations frquentes des duos conduit automatiquement un niveau lev de proprit collective du code. Les quipes avec ce niveau lev de proprit collective ont prouv quelles taient trs robustes, par exemple leur sprint ne meurt pas juste parce quune personne cl est malade.

Un espace de travail informatif

Toutes les quipes ont accs des tableaux blancs et de lespace sur des murs vides, et en font un assez bon usage. Dans la plupart des pices vous trouverez les murs couverts de toutes sortes dinformations sur le produit et le projet. Le plus gros problme est les vieux dchets qui saccumulent sur les murs, il faudra peut-tre introduire un rle de nettoyeur dans chaque quipe. Nous encourageons lutilisation de tableaux de tches, mais toutes les quipes ne les ont pas encore adopts. Voir page 68 comment nous organisons le bureau de lquipe.

Les normes de codage

Rcemment nous avons commenc dfinir des normes de codage. Trs utiles, nous aurions d le faire plus tt. Cela ne prend presque pas de temps du tout, il faut juste commencer simple et les laisser se dvelopper. Ecrivez juste les choses qui ne sont pas videntes pour tout le monde et reliez-les des supports existants chaque fois que cest possible.

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.

Le rythme soutenable / le travail nergis

Beaucoup de livres sur le dveloppement logiciel agile prtendent que le dpassement des horaires est contre-productif dans le dveloppement logiciel. Aprs quelques expriences non dsires sur la question, je ne peux qutre daccord de tout cur ! Il y a peu prs un an une de nos quipes (la plus grosse) faisait une quantit dmente dheures supplmentaires. La qualit de la base de code existante tait dprimante et ils devaient passer la plupart de leur temps teindre les incendies. Lquipe de test (qui faisait aussi des heures supplmentaires) navait aucune chance de faire srieusement le travail dassurance qualit. Nos utilisateurs taient mcontents et les tablodes nous mangeaient vivants.

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.

Vous ne pouvez probablement pas liminer la phase de tests dacceptation

Dans le monde Scrum idal, un sprint produit une version de votre systme potentiellement dployable. Alors il ny a qu le dployer, nestce-pas ?

106 | SCRUM ET XP DEPUIS LES TRANCHEES

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.

Minimisez la phase de tests dacceptation

La phase de tests dacceptation fait mal. On sent clairement quelle nest pas agile. Bien quil ne soit pas possible de lliminer, nous pouvons (et

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

Augmenter la qualit en mettant des testeurs dans lquipe Scrum

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.

Que fait le testeur quand il ny a rien tester ?

Cette question est pose sans arrt. M. T : H Scrum master, il ny a rien tester en ce moment, alors quest-ce que je dois faire ? Il peut falloir une semaine avant que lquipe ne termine la premire histoire, donc que devrait faire le testeur pendant ce temps ? Eh bien, tout dabord, il devrait prparer les tests. Cest--dire crire les spcifications de test, prparer un environnement de test, etc. Donc quand un dveloppeur a quelque chose de prt tester, il ne devrait pas y avoir dattente, M. T devrait commencer tester immdiatement. Si lquipe pratique le DDT alors des gens passent du temps crire du code de test depuis le premier jour. Le testeur devrait programmer en duo avec les dveloppeurs qui crivent du code de test. Si le testeur ne sait pas programmer, alors il devrait tout de mme programmer en duo avec les dveloppeurs, sauf quil devrait seulement jouer le rle du navigateur et laisser le clavier au dveloppeur. Un bon testeur imagine gnralement

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.

Augmenter la qualit en en faisant moins par sprint

On en revient la runion de planning de sprint. Pour faire court, nessayez pas de faire rentrer trop dhistoires dans le sprint. Si vous avez des problmes de qualit, ou de longs cycles de test dacceptation, faites en moins par sprint ! Cela va presque automatiquement conduire une qualit plus leve, des cycles de test dacceptation plus courts, moins de bugs affectant les utilisateurs finaux, et une productivit plus leve dans le long terme puisque lquipe peut se focaliser tout le temps sur de nouveaux trucs au lieu de corriger de vieux trucs qui cassent sans arrt. Cest presque toujours plus rentable de construire moins, mais de le construire stable, plutt que de construire beaucoup de choses et densuite avoir faire des hot-fix dans la panique.

Est-ce que les tests dacceptation devraient faire partie du sprint ?

Nous hsitons beaucoup ici. Certaines de nos quipes incluent les tests dacceptation dans le sprint. Toutefois la plupart de nos quipes ne le font pas, pour deux raisons : Un sprint est dure limite. Le test dacceptation (selon ma dfinition qui inclut le dbogage et les nouvelles releases) est trs difficile limiter dans le temps. Que faire si le dlai est dpass et que vous avez toujours un bug critique ? Allez-vous livrer le produit en production avec un bug critique ? Allez-vous attendre jusquau sprint suivant ? Dans la plupart des cas les deux solutions sont inacceptables. Donc nous ny incluons pas le test dacceptation manuel. Si vous avez plusieurs quipes Scrum travaillant sur le mme produit, le test dacceptation manuel doit tre effectu sur le rsultat combin des deux quipes. Si les deux quipes ont fait lacceptation manuelle durant le sprint, vous avez quand mme besoin dune quipe pour tester la release finale, qui est le build intgrant le travail des deux quipes.

COMMENT NOUS FAISONS LES TESTS | 111

Cela nest en aucune faon une solution parfaite mais elle est suffisamment bonne pour nous dans la plupart des cas.

Des cycles de sprints vs. des cycles de test dacceptation

Dans un monde McScrum parfait vous navez pas besoin de phases de test dacceptation puisque chaque quipe Scrum livre une nouvelle version de votre systme prte pour la production aprs chaque sprint.

Eh bien voici une image plus raliste :

112 | SCRUM ET XP DEPUIS LES TRANCHEES

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.

COMMENT NOUS FAISONS LES TESTS | 113

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 ? ).

COMMENT NOUS FAISONS LES TESTS | 115

Mauvaise approche se focaliser sur la construction de nouvelles choses

Cela signifie en effet se focaliser sur la construction de nouvelles choses plutt que darriver mettre les anciennes en production. Qui voudrait faire a ? Pourtant nous avons souvent fait cette erreur au dbut, et je suis sr que beaucoup dautres entreprises lont faite aussi. Cest une maladie lie au stress. Beaucoup de managers ne comprennent pas que, quand tout le codage est fini, vous tes gnralement encore loin de la release de production. Du moins pour les systmes complexes. Donc le manager (ou le directeur de produit) demande lquipe de continuer ajouter de nouvelles choses alors que le fardeau de vieux code presque-prt-pour-larelease devient de plus en plus lourd, et ralentit tout.

Ne distancez pas le maillon le plus lent de votre chane

Disons que le test dacceptation est votre maillon le plus lent. Vous navez pas assez de testeurs, ou la priode de test dacceptation dure longtemps cause la qualit lamentable du code. Disons que votre quipe de test dacceptation peut tester au plus 3 fonctionnalits par semaine (non, nous nutilisons pas les fonctionnalits par semaine comme mtrique ; jutilise le terme juste pour cet exemple). Et disons que vos dveloppeurs peuvent dvelopper 6 nouvelles fonctionnalits par semaine. Il va tre tentant pour les managers ou directeurs de produit (ou peut tre mme pour lquipe) de planifier le dveloppement de 6 nouvelles fonctionnalits par semaine. Ne le faites surtout pas ! La ralit va vous rattraper dune manire ou dune autre, et ca va faire mal. Plutt, planifiez 3 nouvelles fonctionnalits par semaine, et passez le reste du temps rduire le goulet dtranglement du test. Par exemple : Faire travailler quelques dveloppeurs comme testeurs (oh ils vont vous adorer pour cela). Implmenter des outils et scripts qui rendent le test plus facile. Ajouter plus de code de test automatis. Augmenter la longueur des sprints et inclure le test dacceptation dans les sprints.

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 ?

Combien dquipes faut-il crer

Si traiter avec plusieurs quipes Scrum est si dur, pourquoi sembter ? Pourquoi ne pas mettre tout le monde dans la mme quipe ? La plus grosse quipe Scrum que nous avons eu faisait environ 11 personnes. Ca fonctionnait, mais pas trs bien. Les mles quotidiennes avaient tendance trainer au-del de 15 minutes. Les membres de lquipe ne savaient pas ce que les autres faisaient, il pouvait y avoir de la confusion. Ctait difficile pour le Scrum master de garder tout le monde concentr sur lobjectif, et de trouver le temps dadresser tous les obstacles qui taient remonts. Lalternative est de diviser lquipe en deux. Mais est-ce mieux ? Pas ncessairement. Si lquipe est exprimente et confortable avec Scrum, et sil y a une approche logique de dcouper la feuille de route en deux pistes distinctes, et que les deux pistes ne concernent pas le mme code source, alors je

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.

La taille optimale de lquipe

La plupart des livres que jai lus affirment que la taille optimale de lquipe est quelque part autour de 5 9 personnes. Daprs ce que jai vu jusquici je ne peux qutre daccord. Mme si je dirai plutt 3 8 personnes. En fait, je crois que a vaut le cot datteindre des quipes de cette taille. Disons que vous avez une unique quipe Scrum de 10 personnes. Considrons que lon jecte les deux membres les plus mdiocres. Oups, ai-je vraiment dit a ?

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.

Sprints synchroniss ou non ?

Disons que vous avez trois quipes Scrum qui travaillent sur le mme projet. Leurs sprints devraient-ils tre synchroniss, cest--dire commencer ou finir ensemble ? Ou devraient-ils se chevaucher ? Notre premire approche tait les sprints qui se chevauchent (en respectant les dures).

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.

Pourquoi nous avons introduit le rle du meneur dquipe

Disons que nous avons un seul produit avec trois quipes.

122 | SCRUM ET XP DEPUIS LES TRANCHEES

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).

Comment nous affectons les personnes aux quipes

Il y a deux grandes stratgies pour affecter les personnes aux quipes, lorsque vous avez de multiples quipes sur le mme produit. Laisser une personne dsigne faire laffectation, par exemple le meneur dquipes que jai mentionn ci-dessus, le directeur de produit, ou le manager fonctionnel (sil est assez impliqu pour pouvoir prendre de bonnes dcisions). Laisser les quipes le faire eux-mmes. Nous les avons essayes toutes les trois. Trois ? Oui. Stratgie 1, Stratgie 2 et une combinaison des deux. Nous avons trouv que la combinaison des deux fonctionnait mieux. Avant la runion de planification de sprint, le meneur dquipes lance une runion daffectation des quipes avec le directeur de produit et tous les Scrum masters. Nous discutons du dernier sprint et dcidons si une raffectation est ncessaire. Peut-tre voulons-nous fusionner deux quipes, ou transfrer des personnes dune quipe vers une autre. Nous nous dcidons sur quelque chose et nous le mettons par crit comme une proposition daffectation dquipe, que nous apportons la runion de planification du sprint. La premire chose que nous faisons pendant la runion de planification de sprint est de parcourir les lments de plus haute priorit dans le backlog de produit. Le meneur dquipe dit ensuite quelque chose dans le genre : Bonjour tout le monde. Nous suggrons laffectation dquipe suivante pour le prochain sprint.

124 | SCRUM ET XP DEPUIS LES TRANCHEES

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.

Equipes spcialises ou non ?

Disons que votre technologie consiste en trois principaux composants :

COMMENT NOUS GERONS LES EQUIPES MULTI-SCRUM | 125

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 ?

Approche n quipes spcialises par composant 1:

Une approche est de crer des quipes spcialises par composant telles quune quipe client , une quipe serveur et une quipe BD .

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.

126 | SCRUM ET XP DEPUIS LES TRANCHEES

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.

Rarranger les quipes entre les sprints ou pas ?

Chaque sprint est gnralement assez diffrent des autres, selon le type des histoires qui ont la plus haute priorit ce moment particulier. Par consquent, la cration de lquipe optimale peut tre diffrente pour chaque sprint. En fait, presque tous les sprints nous disions quelque chose comme ce sprint ntait pas vraiment un sprint normal parce que (bla bla bla)..... Aprs quelques temps nous avons abandonn la notion de sprint normal . Il ny a pas de sprint normal. Comme il ny a pas de famille normale ou de personne normale . Sur un sprint ce peut tre une bonne ide davoir une quipe client seulement, constitue de tous ceux qui connaissent bien le code client. Au prochain sprint ce peut tre une bonne ide davoir deux quipes transversales en divisant le groupe client. Lun des aspects cls de Scrum est la formation de lquipe , cest-dire si une quipe apprend travailler ensemble au cours des sprints ils deviendront gnralement trs proches. Ils apprendront obtenir un flux de groupe et atteindront un niveau de productivit incroyable. Mais cela prend quelques sprints pour y parvenir. Si vous narrtez pas de changer les quipes nous nobtiendrez jamais une quipe vraiment soude.

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.

Les membres dquipe temps partiel

Je ne peux que confirmer ce que les livres Scrum disent avoir des membres dune quipe Scrum temps partiel nest gnralement pas une bonne ide. Disons que vous tes sur le point de prendre Joe en tant que membre temps partiel dans votre quipe Scrum. Rflchissez bien avant. Avezvous vraiment besoin de Joe dans votre quipe ? Etes-vous sr de ne pas pouvoir prendre Joe temps plein ? Quels sont ses autres engagements ? Est-ce que quelquun dautre peut prendre le relai sur les autres engagements de Joe et laisser Joe un rle plus passif, de support, tout en respectant ses engagements ? Est-ce que Joe peut rejoindre votre quipe plein temps pour le prochain sprint, et dans le mme temps transfrer ses autres responsabilits quelquun dautre ? Parfois il ny a pas de solution. Vous avez dsesprment besoin de Joe parce que cest le seul DBA de limmeuble, mais les autres quipes ont autant besoin de lui alors il ne sera jamais affect plein temps sur votre quipe, et la socit ne peut prendre plus de DBAs. Trs bien. Cest un cas valide pour lavoir temps partiel (cest dailleurs exactement ce qui sest pass pour nous). Mais assurez-vous de faire cette valuation chaque fois. En gnral je prfre avoir une quipe de 3 personnes plein temps que de 8 temps partiel. Si vous avez une personne qui va partager son temps entre plusieurs quipes, comme le DBA mentionn plus haut, cest une bonne ide de lassigner lorigine une quipe. Trouvez lquipe qui aura le plus besoin de lui, et faites-en son quipe maison . Quand personne dautre

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.

Comment nous faisons les Scrums-de-Scrums

Le Scrum-des-Scrums est simplement une runion rgulire dans laquelle tous les Scrum masters se rassemblent pour parler. A un moment donn, nous avions quatre produits, dont trois dentre eux avait une seule quipe Scrum, et le dernier avait 25 personnes rparties dans plusieurs quipes Scrum. Quelque chose comme ceci :

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.

Scrum-de-Scrums de niveau produit

Cette runion est trs importante. Nous en faisons une par semaine, parfois plus souvent. Nous y discutons des problmes dintgration, des problmes dquilibrage de la charge des quipes, des prparations pour la prochaine runion de planification de sprint, etc. Nous y allouons 30 minutes mais elles sont frquemment dpasses. Une alternative serait davoir le Scrum-de-Scrums tous les jours, mais nous navons jamais pu russir essayer a. Lordre du jour de notre Scrum-de-Scrums est :

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.

Scrum-de-Scrums de niveau global

Nous appelons cette runion Le pouls. Nous avons fait cette runion avec de nombreux format, avec diffrent types de participants. Tardivement nous avons laiss tomber le concept dans sa globalit et lavons remplac par une runion gnrale hebdomadaire (eh bien, toutes les personnes impliques dans le dveloppement) la place. 15 minutes. Comment ? 15 minutes ? Runion gnrale ? Tous les membres de toutes les quipes de tous les produits ? Est-ce que a marche ? Oui a marche si vous (ou qui que ce soit qui mne la runion) tes strict vis--vis de sa dure pour la garder courte. Le format de la runion est : 1) Les nouvelles rcentes du responsable du dveloppement. Des infos sur les vnements venir par exemple. 2) Tour de table. Une personne de chaque groupe dun produit indique ce quils ont fini la semaine passe, ce quils comptent finir cette semaine, et le moindre problme. Dautres personnes sexpriment aussi (responsable CM, responsable QA, etc.). 3) Nimporte qui dautre est libre dajouter de linformation ou de poser des questions. Il sagit dun forum pour de linformation brve, pas de discussion ni de cogitations. En le laissant comme cela, 15 minutes gnralement suffisent. Parfois nous dpassons, mais trs rarement plus de 30 minutes au total. Si des discussions intressantes surviennent je les suspends et invite ceux qui sont intresss poursuivre la discussion aprs la runion. Pourquoi faisons-nous une runion gnrale pouls ? Parce que nous avons remarqu que dans les Scrums-de-Scrums niveau global il tait question de reporting la plupart du temps. Nous avons rarement eu de vraies discussions dans ce groupe. De plus, de nombreuses personnes en

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.

Intercaler les mles quotidiennes

Si vous avez beaucoup dquipes Scrum pour un seul produit, et quils font tous la mle quotidienne en mme temps, vous avez un problme. Le directeur de produit (et les gens fouineurs comme moi) peuvent seulement assister une mle quotidienne par jour. Nous demandons alors aux quipes dviter davoir les mles quotidiennes en mme temps.

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.

Les quipes de pompiers

Nous avons eu une situation ou un gros produit tait incapable dadopter Scrum parce que les membres de lquipe passaient beaucoup trop de temps faire les pompiers, cest--dire corriger des bugs dans la panique dans leur systme livr prmaturment. Ctait un vrai cercle vicieux, ils taient si occups teindre les incendies quils navaient pas le temps de travailler proactivement pour prvenir les feux (cest--dire amliorer la conception, automatiser les tests, crer des outils de surveillance, des outils dalarme, etc.). Nous avons gr ce problme en crant une quipe de pompiers ddie, et une quipe Scrum ddie. Le travail de lquipe Scrum tait (avec la bndiction du directeur de produit) dessayer de stabiliser le systme, et effectivement de prvenir les incendies. Lquipe de pompiers (nous les appelons support en ralit) avait deux boulots : 1) Combattre les incendies. 2) Protger lquipe Scrum de toutes les sortes de perturbations, ce qui inclut des choses comme parer des demandes de nouvelles fonctionnalits ad-hoc provenant de nulle part. Lquipe de pompiers tait place au plus prs de la porte ; lquipe Scrum tait place au fond de la pice. Ainsi lquipe de pompiers pouvait en fait protger physiquement lquipe Scrum des perturbations venant par exemple de vendeurs impatients ou de clients mcontents. Des dveloppeurs seniors taient placs dans les deux quipes, de telle sorte quune quipe ne soit pas trop dpendante des comptences cls de lautre quipe. Ctait en fait une tentative de rsoudre un problme damorage de Scrum. Comment pouvons nous commencer Scrum si lquipe na aucune chance de planifier son travail plus dun jour lavance ? Notre stratgie a donc t, comme mentionn ci-dessus, de partager le groupe.

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.

Partager le backlog de produit ou pas ?

Disons que vous avez un produit et deux quipes Scrum. Combien de backlogs de produit devriez-vous avoir ? Combien de directeurs de produit ? Nous avons valu trois modles pour cela. Le choix a un gros effet sur la manire dont les runions de planning de sprint sont conduites.

Stratgie 1: un directeur de produit, un backlog

Cest le modle Il nen restera quUn . Notre modle prfr. Le bon ct de ce modle est quil laisse les quipes se former peu prs elles-mmes sur la base des priorits actuelles du directeur de produit. Le directeur de produit peut se concentrer sur ce dont il a besoin, et peut laisser les quipes dcider comment partager le travail.

134 | SCRUM ET XP DEPUIS LES TRANCHEES

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.

136 | SCRUM ET XP DEPUIS LES TRANCHEES

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.

Stratgie 2: un directeur de produit, plusieurs backlogs

Dans cette stratgie, le directeur de produit maintient plusieurs backlogs de produit, un par quipe. Nous navons pas vraiment essay cette approche, mais nous en avons t proches. Cest en fait notre plan de secours au cas o la premire approche choue. La faiblesse de cette stratgie est que le directeur de produit assigne les histoires aux quipes, un travail que les quipes sont probablement plus qualifies faire elles-mmes.

COMMENT NOUS GERONS LES EQUIPES MULTI-SCRUM | 137

Stratgie 3 : plusieurs directeurs de produit, un backlog par directeur

Cest comme la seconde stratgie, un backlog de produit par quipe, mais avec un directeur de produit par quipe galement !

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.

COMMENT NOUS GERONS LES EQUIPES DISPERSEES | 143

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 .

quipiers travaillant de la maison

Le travail accompli la maison peut tre quelquefois trs bon. Il arrive daccomplir plus de programmation en un jour la maison quen toute une semaine au bureau. Du moins si vous navez pas denfants :o) Pourtant, lun des fondements de Scrum est que toute lquipe devrait tre colocalise physiquement. Alors que fait-on ? En gros nous laissons les quipes dcider delles-mmes quand et quelle frquence il est acceptable de travailler de la maison. Certains quipiers travaillent rgulirement de la maison afin dviter les longs trajets. Nous encourageons cependant les quipes tre colocalises physiquement la plupart du temps. Lorsque les quipiers travaillent de la maison, ils participent la mle quotidienne via un appel Skype (quelquefois avec vido). Ils sont en ligne toute la journe via la messagerie instantane. Pas aussi bien que dtre dans la mme pice, mais suffisant. Nous avons une fois essay le concept de dsigner le mercredi comme tant le jour de focalisation. En gros cela voulait dire si vous aimeriez travailler de la maison, cest trs bien, mais faites-le le mercredi. Et restez en contact avec votre quipe . Cela a assez bien fonctionn avec lquipe sur laquelle nous lavons essay. En gnral la plupart des quipiers restaient chez eux le mercredi et taient productifs, tout en collaborant assez bien. Puisque cela ne durait quun jour, les quipiers restaient peu prs synchroniss entre eux. Mais pour une raison inconnue, ce concept na pas vraiment pris dans les autres quipes. En gnral, le fait que des personnes travaillent de chez eux ne nous a pas vraiment pos de problme.

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.

Tous les jours

Sassurer que la Mle quotidienne commence et finit lheure. Sassurer que les histoires sont ajoutes/supprimes du Sprint Backlog autant que ncessaire pour respecter le planning du Sprint. o Sassurer que le directeur de produit est inform de ces modifications.

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/

Ah oui, et noubliez pas Ce nest jamais quun boulot, non ?

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