i

Aubry_54018 (Col. : InfoPro) 2009/12/1 16:03 page 9 #29

i i

2
Des sprints pour une release

Jai pris part des dizaines de projets, soit en tant que dveloppeur, soit en tant que consultant et il ny en a pas deux qui se soient drouls de la mme faon, bien que certains aient suivi le mme processus. Il y a une grande variation dans le droulement temporel dun projet, appel le cycle de dveloppement (ou cycle de vie). Un cycle est dni par des phases et des jalons. Les phases se succdent et un jalon permet de contrler le passage la phase suivante : une phase a des objectifs et le jalon est l pour vrier quil ny a pas de dviation par rapport ces objectifs.
Phase A Phase B

Phase C

Phase D

Temps

Figure 2.1 Dans un cycle traditionnel, chaque phase est diffrente

videmment le cycle est inuenc par le modle de cycle (ou processus) quon utilise. Un modle ancien, encore rpandu en France, est le cycle en V, mais le plus souvent une entreprise, surtout si elle grande, a dni son propre modle de cycle. Dans certaines entreprises, lapplication du modle est fortement recommande et dans dautres lquipe a plus de latitude. Bien souvent, et quel que soit le degr de recommandation, jai constat quil y avait un grand cart entre le modle et sa mise en uvre sur les projets.

i i i

i
Aubry_54018 (Col. : InfoPro) 2009/12/1 16:03 page 10 #30

i i

10

Chapitre 2. Des sprints pour une release

Il y a plusieurs raisons pour lexpliquer :

Le modle est bien souvent trop thorique, labor par des mthodologistes

loigns des ralits, et inapplicable sur le terrain. Les contrles sont difciles faire lors des jalons, parce quils portent souvent sur une multitude de documents. Les jalons tant franchis sans difcult, lquipe accumule les travaux non faits des phases prcdentes. Scrum fait partie des approches itratives et incrmentales, dont le modle de cycle de dveloppement est bas sur une phase qui se rpte plusieurs fois successivement. Cest la notion ditration, appele sprint avec Scrum. Tous les sprints se droulent selon le mme schma et on y fait chaque fois les mmes types de travaux.

Sprint

Sprint

Sprint

Sprint Temps

Figure 2.2 Avec Scrum, le processus se rpte chaque sprint

Cest une diffrence majeure avec les mthodes traditionnelles pour lesquelles les travaux sont de nature diffrente pour chaque phase. Cela a un effet sur les objectifs de chaque sprint : ils ne sont pas dnis par le cadre Scrum, cest lquipe qui sen charge. Cest de ce cycle de dveloppement et de ses implications dont il est question dans ce chapitre.
Dfinitions Sprint est le terme utilis dans Scrum pour itration. Dans le langage Scrum, un sprint est un bloc de temps fix aboutissant crer un incrment du produit potentiellement livrable. Release peut avoir plusieurs sens : Release comme version Le dictionnaire du jargon informatique franais dfinit une release comme suit : version dun logiciel effectivement diffuse, donc lche dans la nature. Synonyme de Mise sur le march . Exemple : Unix system V release 4 . Cette dfinition nonce clairement quil y a des versions qui ne constituent pas des releases. Release comme priode de temps Par extension, on appelle galement release la priode de temps qui permet de la produire. On devrait dire le cycle de production dune release, mais lusage en anglais, et maintenant en franais, est dutiliser release comme priode de temps, notamment dans lexpression plan de release. Cest ce sens, priode de temps compose de sprints, qui est utilis pour release dans ce livre.

i i i

i
Aubry_54018 (Col. : InfoPro) 2009/12/1 16:03 page 11 #31

i i

2.1 Lapproche itrative et incrmentale

11

2.1 LAPPROCHE ITRATIVE ET INCRMENTALE

2.1.1 Incrment et itration
Scrum utilise une approche itrative et incrmentale pour le dveloppement dun produit.

Incrmental
Incrmental est utilis pour mettre en vidence laccroissement du produit obtenu la n de chaque sprint. Un processus incrmental permet de construire un produit morceau par morceau, chaque nouvelle partie venant sajouter lexistant. Pour lcriture de ce livre, jai utilis une approche incrmentale : jai fait un plan initial et jai rdig chapitre par chapitre, sans respecter lordre du plan, dailleurs. La pratique dun cycle incrmental est rpandue dans les dveloppements de logiciel ; on parle souvent de lots pour les incrments qui font lobjet dun contrat.

Itratif
Itrer est laction de rpter. Dans le calcul scientique, litration est un procd de calcul rptitif qui permet, par exemple, de trouver la racine dun nombre, dune quation, par approximations successives. Dans le dveloppement de logiciel, le terme itration est utilis pour dsigner une priode de temps dans laquelle sont effectues des activits, qui seront rptes dans les prochaines itrations. Le terme est souvent associ processus.
Exemple : un article du Nouvel Observateur (grand public, donc) de juillet 2008 met en exergue les itrations du processus dAmazon, qui expliquent, selon lauteur, les succs de lentreprise.

Un processus itratif permet de revenir sur ce qui a t fait, dans le but de lamliorer ou de le complter. Cela part de lide quil est difcile, voire impossible, de bien faire la premire fois. Le feedback collect sur le rsultat dune itration permet de faire des amliorations dans la suivante. On cesse ditrer quand la qualit obtenue est juge satisfaisante. Pour lcriture de ce livre, jai utilis une approche itrative : jai diffus le premier jet des lecteurs et grce leur feedback, jai produit une nouvelle version.

i i i

i
Aubry_54018 (Col. : InfoPro) 2009/12/1 16:03 page 12 #32

i i

12

Chapitre 2. Des sprints pour une release

Itratif et incrmental
Scrum combine les deux approches avec la notion de sprint :
lissue du sprint, il y a un incrment de produit qui est ralis, le feedback sollicit sur cet incrment permet de le perfectionner dans un

prochain sprint. En rsum, un sprint est une itration qui produit un nouvel incrment (incrmental) et peut aussi enrichir un incrment dun sprint prcdent (itratif). Pour lcriture de ce livre, jai utilis une approche itrative et incrmentale : en fait, je nai pas diffus le premier jet de tout le livre mes lecteurs, mais celui dun chapitre. Comme jai suivi Scrum pour ce projet de rdaction, dans un sprint je travaillais sur la premire version dun nouveau chapitre et aussi sur la rvision dun chapitre suite au retour dun ou plusieurs lecteurs. Les organisations qui font des dveloppements de logiciel en passant par la production dune maquette, celles qui procdent par lots, celles qui produisent une ou plusieurs versions intermdiaires disent volontiers quelles appliquent un processus itratif et incrmental. Elles ne sont pas agiles pour autant.

Cycle agile
Quelles sont les caractristiques du cycle de vie Scrum, en plus dtre itratif et incrmental, qui justient le qualicatif dagile ?
Des itrations plus courtes : les sprints durent au maximum un mois. Une squence plus stricte : les sprints ne se chevauchent pas. Un rythme rgulier : les sprints ont toujours la mme dure.

Incrmental

Lot 1

Lot 2 Lot 3 Temps

Agile

Sprint

Sprint

Sprint

Sprint Temps

Figure 2.3 Diffrences entre incrmental et agile

i i i

i
Aubry_54018 (Col. : InfoPro) 2009/12/1 16:03 page 13 #33

i i

2.1 Lapproche itrative et incrmentale

13

2.1.2 Bloc de temps

Les sprints ont tous la mme dure : Scrum sappuie sur la notion de bloc de temps limit (timebox).
Il ny a pas que les sprints qui sont timeboxs avec Scrum : de nombreuses activits dun dveloppement sont bases sur cette notion. Cela se manifeste en particulier dans les runions qui constituent le crmonial.

Pas de sprint extensible

Pour le sprint, la notion de timebox sapplique de la faon suivante : on ne change pas la date de n une fois que le sprint a commenc. Mme si on na pas ni tout ce quon voulait faire, on garde la date de n prvue. Pourquoi ? Cela permet dviter le syndrome du presque ni (ou ni 90 %), o, nalement, la date de n est repousse plusieurs fois. Jai accompagn de nombreux projets, agiles ou pas. Jai eu trs souvent des demandes dquipes venant ngocier la date dun jalon. Ces quipes me disent quelles ont un tout petit peu de retard et demandent repousser la date dune revue de deux ou trois jours. Jur, avec ce dlai, ce serait mieux et on aurait tout ce qui tait prvu. videmment la plupart du temps, aprs ce laps de temps supplmentaire, il en aurait fallu encore un peu... Les dveloppeurs ont tendance tre optimistes. La notion de bloc de temps vite les drives : la date prvue, on fait une inspection objective de lavancement et on ajuste en consquence la planication des prochains sprints.

Rythme rgulier
La dure des sprints est toujours la mme, dans la mesure du possible. Lintrt est de donner un rythme lquipe, qui va apprendre produire rgulirement. Lobjectif est dviter des situations de sur-rgime que lquipe ne pourra pas tenir bien longtemps. Pousser une quipe travailler au-del de son rgime de croisire a des effets de bord ngatifs sur la qualit de son travail : le nombre de dfauts augmente, la motivation diminue, les pratiques dingnierie sont ngliges... Au contraire, un rythme rgulier peut tre conserv longtemps, voire indniment. Il prsente dautres avantages : comme on connat les dates de dbut et de sprint lavance, les revues sont plus faciles organiser et les intervenants peuvent planier leur participation.

Ressources rgulires
Le bloc de temps dlimite la quantit de travail faite pendant le sprint. Il est le mme pour tous les sprints : il dpend de la dure du sprint et de la taille de lquipe qui sont xes toutes les deux, au moins sur une certaine priode.

i i i

i
Aubry_54018 (Col. : InfoPro) 2009/12/1 16:03 page 14 #34

i i

14

Chapitre 2. Des sprints pour une release

Ressources

Timebox

Dure

Figure 2.4 Le bloc de temps

Comme pour le dveloppement de logiciel, le cot est directement corrl aux ressources, le budget dun sprint peut tre dduit de la timebox. Il est prfrable que la composition de lquipe reste stable pendant un sprint. Il est aussi souhaitable de garder une quipe stable pour une release, ce qui permet davoir des timeboxes quivalentes pour tous les sprints.

2.1.3 Dure du sprint

La dure dun mois ou moins correspond lhorizon de prdictibilit : la n du sprint, les prvisions sont ajustes en fonction du contrle effectu sur les rsultats obtenus. Pour les dveloppements complexes qui sont la cible privilgie de Scrum, on considre que ne pas rguler le processus pendant plus dun mois, ce serait prendre trop de risques. Aux dbuts de Scrum, la rgle tait de faire des sprints dun mois, sans variation. Par exemple, si le dveloppement commenait avec une anne calendaire :
premier sprint du premier au 31 janvier, deuxime sprint du premier au 28 (ou 29) fvrier, troisime sprint du premier au 31 mars...

Aujourdhui, on constate une tendance faire des sprints plus courts : en effet, pour le dveloppement de logiciel, les pratiques dingnierie, comme lintgration continue et les outils associs, permettent de produire des versions partielles plus frquemment.
Quelques infos pratiques Une enqute faite en avril 2009 sur mon blog (www.aubryconseil.com) auprs dune centaine de personnes donnait les rsultats prsents figure 2.5. Les sprints de deux ou trois semaines reprsentent la majorit des rponses.

i i i

i
Aubry_54018 (Col. : InfoPro) 2009/12/1 16:03 page 15 #35

i i

2.2 Cycle de dveloppement Scrum

15

Figure 2.5 Sondage sur la dure des sprints

2.2 CYCLE DE DVELOPPEMENT SCRUM

2.2.1 Laspect temporel
Phases et jalons
Dans chaque processus de dveloppement, il existe des jalons majeurs et des jalons mineurs. Avec Scrum le jalon mineur est la n du sprint et le jalon majeur est la production de la release.
Release Sprint 1 Sprint 2 Sprint 3 Sprint 4

Figure 2.6 Une release et ses sprints

Une release est une srie de sprints qui se termine quand les incrments successifs constituent un produit qui prsente sufsamment de valeur ses utilisateurs. La dure des releases est dnie par lquipe et le Product Owner. La tendance est raccourcir ces dures : pour de nombreuses quipes, une release dure environ trois mois, avec des sprints de deux ou trois semaines. Cela permet de drouler de quatre six sprints dans une release. Il ny a pas de chevauchements : on ne commence pas un sprint tant que le prcdent nest pas termin et, en principe, le nouveau dmarre immdiatement aprs le prcdent. Les sprints senchanent sans dlai : le nouveau dmarre immdiatement aprs le prcdent.

i i i

i
Aubry_54018 (Col. : InfoPro) 2009/12/1 16:03 page 16 #36

i i

16

Chapitre 2. Des sprints pour une release

Sprint 1 Sprint 2

Sprint 3

Sprint 4

Figure 2.7 Les sprints sont squentiels

Sprint 1 Dlai

Sprint 2

Sprint 3

Figure 2.8 Les sprints senchanent

Arrter le sprint plutt que ltendre

La date de n du sprint est xe au dbut du sprint (elle est mme dnie avant). Elle ne change pas, mme si lquipe ne ralise pas tout ce quelle imaginait faire. Lvaluation de n de sprint permettra dinspecter ce qui a t fait et den tirer des consquences pour la suite. Il peut arriver que lquipe narrive pas produire un incrment potentiellement livrable la n du sprint et nait rien de montrable. Heureusement, cest trs rare. Cela peut tre d des difcults techniques ou des perturbations importantes qui changent le but du sprint. Dans ce cas, lorsque lquipe se rend compte quelle ne pourra pas prsenter quelque chose la n du sprint, une possibilit est darrter immdiatement le sprint en cours. Lquipe repart aussitt dans un nouveau sprint, avec un primtre adapt qui tient compte des difcults rencontres.
Ce conseil peut tre suivi pour une quipe qui fait des sprints dun mois et se rend compte de son impasse au milieu du sprint. Pour des dures de sprint plus courtes, il est plus simple dattendre la fin normale du sprint et de tirer les enseignements lors de la rtrospective.

2.2.2 Activits et cycle de dveloppement

Un cycle de dveloppement se prsente comme un enchanement de phases dans lesquelles on effectue des activits. Pour un dveloppement de logiciel, les activits sont gnralement :
Spcication fonctionnelle (requirements) Architecture (conception) Codage (et test unitaire) Test (dintgration et de recette)

Pour simplier, je vais utiliser les lettres S A C T pour dsigner ces activits dans les schmas.

i i i

i
Aubry_54018 (Col. : InfoPro) 2009/12/1 16:03 page 17 #37

i i

2.2 Cycle de dveloppement Scrum

17

Avec Scrum, chacun des sprints a un objectif qui porte sur un produit qui fonctionne (et pas seulement sur des documents), ce qui ncessite du travail dans toutes les activits de dveloppement pendant un sprint. Les activits se droulent en parallle pendant le sprint (gure 2.9) :
Toutes les activits
Sprint 1 S A C T S A C T S A C T S A C T S A C T 5

Cycle Scrum

Figure 2.9 Des sprints et leurs activits en parallle

lautre extrme, un processus dit squentiel droule les activits en squence, avec une activit par phase (gure 2.10) :

Cycle squentiel

Une activit par phase

Figure 2.10 Phases avec des activits squentielles

Avec un processus activits squentielles, une phase est dnie avec un objectif exprim par une liste de documents produire ; elle dure assez longtemps quelques mois et sa dure est variable (lquipe sarrte lorsque les objectifs sont atteints) ; le rsultat porte uniquement sur des documents au dbut, et mme assez tard dans le dveloppement : le logiciel test nest obtenu qu la n. Suivre au pied de la lettre cette approche revient avoir :
100 % de la spcication fonctionnelle dtaille avant de commencer le code, 100 % de la conception avant de commencer le code, 100 % du code pour commencer les tests.

Cest un modle idal mais utopique : dans la ralit on revient toujours sur les activits des phases prcdentes, et en particulier dans la phase de test, on revient sur les spcications, la conception et le code (gure 2.11).
T S A C T
C
A
S

Figure 2.11 Retour sur les activits prcdentes pendant le test

i i i

i
Aubry_54018 (Col. : InfoPro) 2009/12/1 16:03 page 18 #38

i i

18

Chapitre 2. Des sprints pour une release

Ce dcalage entre le modle et la ralit est une des raisons du retard des projets et de leur qualit mdiocre.

Avec une mthode agile comme Scrum, les activits de spcication et de conception sont continues. On part du principe que larchitecture va voluer, dans une certaine limite, pendant la vie du projet. Lapproche est plus raliste et pragmatique. Lautre principe important est que les tests sont pratiqus ds le premier sprint. Il existe aussi de nombreux dveloppements qui sont mens de faon chaotique, sans suivre de processus ou en le suivant larrache 1 . Le plus souvent, il ny a mme pas de spcication ni de conception. Lquipe se lance directement dans le codage, qui est suivi dune longue priode de test et de corrections de bugs. Avec Scrum, la qualit nest pas nglige, et la conception fait partie des activits de chaque sprint.

2.2.3 Le rsultat dun sprint

Linspection2 , an de faire des adaptations, est la base de la thorie de Scrum. la n dun sprint, le rsultat attendu est un incrment du produit nal, qui est potentiellement livrable. Cest ce que montre le clbre schma de Mike Cohn que javais traduit en franais en 2005 (gure 2.12).

livrable

Figure 2.12 Cycle de vie Scrum simplifi lpoque du schma, en 2005, javais (mal !) traduit potentially shippable par potentiellement utilisable. Cest potentiellement livrable.

1. La mthode larrache est bien connue, voir http://www.la-rache.com 2. Linspection du produit est dcrite dans le chapitre 9 La revue de sprint. Linspection du processus est dcrite dans le chapitre 10 La rtrospective de sprint.

i i i

i
Aubry_54018 (Col. : InfoPro) 2009/12/1 16:03 page 19 #39

i i

2.3 Guides pour les sprints et releases

19

Le produit ne doit pas tre seulement potentiellement utilisable la n dun sprint, il doit simplement tre utilisable. Certes, il nest pas complet par rapport ce qui est prvu dans la release, mais il est livrable, au moins des utilisateurs privilgis. Dans le cas dun dveloppement de logiciel, le minimum est davoir dploy, la n dun sprint, le produit potentiellement livrable, avec si ncessaire la documentation permettant de lutiliser.

2.2.4 Le rsultat dune release

Le rsultat de la release est le produit livrable, fourni ses utilisateurs. La faon dont il est fourni dpend de la nature du dploiement de ce produit. La distinction avec le rsultat du sprint se fait sur le potentiellement. Le but est de faire en sorte que cette distinction soit la plus tnue possible voire quelle disparaisse. Cest trs variable selon le contexte du projet : des dploiements trs frquents sont possibles pour des applications web hberges...
Exemple : eBay re-dploie ses applications tous les quinze jours et pour Amazon cest du dploiement continu.

...mais pas pour des applications internes ajoutes un gros systme dinformation, ni pour des systmes embarqus. Souvent, le jalon majeur que reprsente la release correspond une annonce marketing : loccasion de la sortie du produit, les quipes marketing prparent un matriel pour sa promotion.

2.3 GUIDES POUR LES SPRINTS ET RELEASES

Avec Scrum, la notion de cycle de vie est peu mise en vidence. Le premier article de Ken Schwaber voquait trois phases : une premire Planning & Architecture, la deuxime constitue des sprints et une dernire phase appele Closure. Ces notions sont aujourdhui abandonnes. Nanmoins, il y a bien trois priodes distinctes dans une release (gure 2.13) :
La priode centrale, celle des sprints. La priode avant le premier sprint. Une priode aprs le dernier sprint et avant la n de la release.

i i i

i
Aubry_54018 (Col. : InfoPro) 2009/12/1 16:03 page 20 #40

i i

20

Chapitre 2. Des sprints pour une release

Release Sprint1 Sprint2 Sprint3 Sprint4

Dbut de release

Les sprints

Fin de release

Figure 2.13 Les trois priodes dune release

2.3.1 Dmarrer le premier sprint au bon moment

Le dveloppement dune release commence par des travaux particuliers faire avant de lancer les sprints successifs, comme constituer lquipe, dnir la vision, produire un backlog initial et une premire planication de la release. Si la release en question est la premire dans la vie du produit, il conviendra galement de faire des travaux de dnition de produit1 et darchitecture avant de lancer les sprints.

Figure 2.14 Le lancement des sprints se prpare

La priode de temps en dbut de release est parfois appele le sprint zro. Sprint zro est trompeur parce que cette priode nest pas un sprint comme les autres : sa dure est variable, les tches quon y fait sont spciques de cette phase, il ny a pas le crmonial habituel des sprints, on ne produit pas une version potentiellement utilisable la n, on ne mesure pas de vlocit... lusage je trouve que cest une trs mauvaise appellation, dangereuse. Au-del du vocabulaire, ce quil faut bien comprendre cest quil sagit dune phase diffrente de la srie des sprints qui va suivre. Elle est prdictive alors que la phase des sprints est empirique, le but nest pas de produire un incrment de produit comme pour
1. Voir aussi, le chapitre 13 De la vision aux stories.

i i i

i
Aubry_54018 (Col. : InfoPro) 2009/12/1 16:03 page 21 #41

i i

2.3 Guides pour les sprints et releases

21

chaque sprint. Le risque avec sprint zro est que cette distinction ne soit pas perue et que cette phase prparatoire soit nglige. Le premier sprint ne doit pas dmarrer trop longtemps aprs le dbut de la release (il ne sagit pas dy caser les activits de spcication et de conception dtailles), mais cela dpend du contexte : il faut videmment plus de temps dans le cas dune premire release dun nouveau projet sappuyant sur une nouvelle technologie que pour sa nime release. Ce nest pas non plus une bonne chose de dmarrer trop vite : avant que la planication de release ne soit labore, cest prmatur de commencer le premier sprint.

2.3.2 Produire des micro-incrments

Un sprint ne se droule pas en travaillant successivement sur les activits (spcication puis conception puis codage puis test) : un sprint nest pas un mini-cycle en V . Lquipe travaille pour dvelopper des fonctionnalits ds le dbut du sprint, ce qui permet de produire pendant le sprint ce quon peut appeler des micro-incrments (gure 2.15).
Incrment de fin de sprint Micro-incrments

Sprint n  1

Sprint n

Figure 2.15 Production de micro-incrments

Dans le cadre dun dveloppement logiciel, ces micro-incrments sont des versions intermdiaires produites pendant le sprint. Elles sont utilises par lquipe de dveloppement et le Product Owner pour passer les tests fonctionnels.

2.3.3 Enchaner les sprints

Si on se rfre lathltisme, objet de la mtaphore, on ne peut pas sprinter pendant toute la dure de la course de fond que constitue une release, il faut des phases de rcuprations. Ce nest pas moi qui vais dire le contraire : jai couru en longue distance. Jai encore le souvenir des entranements en fractionn : par exemple une srie de dix fois 200 m avec 30 secondes de rcupration entre chaque.

i i i

i
Aubry_54018 (Col. : InfoPro) 2009/12/1 16:03 page 22 #42

i i

22

Chapitre 2. Des sprints pour une release

Figure 2.16 La fatigue de lquipe aprs un sprint fond

Certains membres de lquipe le font savoir lors des rtrospectives : ils souhaitent des jours de rcupration entre les sprints. Parmi toutes les quipes que jai suivies depuis cinq ans, la plupart se contentent dun week-end avant de repartir sur un nouveau sprint : la revue et la rtrospective se font le vendredi (mais ce nest pas obligatoire de caler les sprints sur les semaines) et le prochain sprint dmarre le lundi qui suit par la runion de planication. Dautres consacrent un jour entre chaque sprint des activits hors projet ; une quipe a instaur un bug day intercalaire. Jai aussi connu des quipes qui choisissaient de sarrter une semaine tous les trois ou quatre sprints. Et puis certaines quipes enchanent directement : par exemple, n de sprint le mardi, dbut du sprint suivant le mercredi matin, par exemple. Cest le mode de fonctionnement optimal. Les situations o les quipes prouvent le besoin de sarrter entre les sprints sont souvent le reet dun dysfonctionnement. Le terme sprint, quon court fond et aprs lequel on rcupre, est trompeur. Un dveloppement avec Scrum sapparente plus une course un rythme rgulier, sans pause chaque tape.

2.3.4 Utiliser le produit partiel

En plus de sa prsentation la revue de sprint, on peut identier trois usages de la version produite en n de sprint, pour un dveloppement de logiciel.
Utilisation interne La version nest pas utilise en dehors de lquipe de

dveloppement. Elle a t produite pour chercher minimiser les risques lis la technologie et la capacit de lquipe intgrer diffrents composants.

i i i

i
Aubry_54018 (Col. : InfoPro) 2009/12/1 16:03 page 23 #43

i i

2.3 Guides pour les sprints et releases

23

Elle nest pas livre lextrieur de lquipe. Cela est frquent au dbut dun nouveau dveloppement. Utilisation pour feedback par des utilisateurs slectionns La version est utilise par un client ou des utilisateurs privilgis. Cela leur donne la possibilit de la prendre en main, ce qui permet de rduire les risques portant sur linterface. Ces utilisateurs pourront valuer la facilit dutilisation des fonctionnalits et en proposer de nouvelles. Les retours faits iront alimenter le backlog pour prise en compte ultrieure. Mise en production La version est mise en production ou en exploitation et utilise par ses utilisateurs naux. Cest videmment ce quil faut viser puisque chaque nouvelle version apporte de la valeur. Autant lapporter le plus tt possible, ds quelle est disponible. Mais ce nest gnralement pas faisable de mettre en production la n de chaque sprint : trop de temps serait pris, par rapport la dure du sprint, pour passer les tests de recette sur tout le systme, pour dployer sur lenvironnement de production, pour crire les manuels utilisateurs, pour prparer et donner la formation aux utilisateurs... Cest pourquoi, dans la plupart des cas, ltat du produit la n1 de chaque sprint est distingu de celui souhait la n dune release. Mais si on russit automatiser le dploiement et limiter le temps pour le faire, on peut alors mettre en production plus souvent qu la n des releases. Dans ce cas-l, le produit nest plus simplement potentiellement livrable la n de chaque sprint, il est livr. Le terme de release garde son sens de priode de temps pour la planication.

2.3.5 Savoir finir la release

Faire le plus possible pendant les sprints vite de devoir poursuivre le travail aprs le dernier sprint. Si ltat du produit partiel en n de sprint est quivalent ltat attendu en n de release, la n du dernier sprint concidera avec la n de la release. Ce nest pas possible dans tous les contextes et dans certains cas, il faut une priode de temps entre la n du dernier sprint et la n de la release pour faire des travaux ncessaires avant la mise en production. Ces travaux varient selon le type de dploiement : mise en production chaud, packaging du produit, mise disposition par tlchargement en ligne... Cette priode tait auparavant appele sprint de stabilisation. Ce ntait pas une bonne ide, cela laissait entendre que le logiciel ntait pas stable avant. Les termes de sprint de release ou de sprint de durcissement parfois voqus sont tout aussi discutables :
il vaut mieux rendre le produit plus robuste chaque sprint plutt que de le faire

la n,
si malgr tout, il y a des travaux de durcissement faire avant de livrer la release,

cela ne rentre pas dans le cadre dun sprint.

1. La signication de ni fait lobjet du chapitre 11 .

i i i

i
Aubry_54018 (Col. : InfoPro) 2009/12/1 16:03 page 24 #44

i i

24

Chapitre 2. Des sprints pour une release

En rsum
Avec Scrum, un produit est dvelopp selon une approche itrative et incrmentale. Le sprint donne le rythme auquel sont produites des versions partielles potentiellement livrables du produit. La release est la squence de sprints lissue de laquelle le produit est livr aux utilisateurs.

i i i