Les mthodes agiles reprsentent un mouvement qui vise apporter plus de valeur aux clients et aux utilisateurs, ainsi

i quune plus grande satisfaction da ns leur travail aux membres de l quipe. Le but affich dune mthode agile est de maximiser la valeur ajoute : le dveloppement seffectuant par itrations successives, il est possible, la fin de chaque itration, de changer les priorits en faisant en sorte que les lments apportant le plus de valeur soient raliss en premier. Un meilleur accomplissement des personnes impliques dans un dveloppement est rendu possible par la notion dquipe auto-organise. Une tentative de dfinition, adapte de Scott Ambler, pourrait-tre : Une mthode agile est une approche itrative et incrmentale pour le dveloppement de logiciel, ralis de manire trs collaborative par des quipes responsabilises, appliquant un crmonial minimal, qui produisent un logiciel de grande qualit dans un dlai contraint, rpondant aux besoins changeants des utilisateurs. Le crmonial cest ce qui dfinit les rgles sociales et conventionnelles rgissant la vue dune quipe ; sil est vrai que, pour une mthode agile, il est minimal pour la documentation, il existe bien pour le ct social, mais avec des rgles nouvelles. Avec ses valeurs et ses principes, on peut considrer lagilit comme une nou velle culture du dveloppement. Celles-ci ont t prcises ds 2001 avec le Manifeste agile, avant mme lapparition des premires mthodes agiles : Livrer frquemment et rgulirement le logiciel Faire des cycles de dveloppement courts et limits dans le temps Constituer une quipe complte pour un dveloppement Grer les membres de lquipe en les responsabilisant Avoir le reprsentant des utilisateurs sur le mme site que le reste de lquipe Produire des plans plusieurs niveaux : dtaills uniquement pour le court terme, et plus gnraux pour le moyen terme Dvelopper en intgrant le code de faon continue Faire des bilans de projet dans le but damliorer la faon de travailler.

Prises individuellement, ces pratiques sont dj efficaces. Insres dans le cadre cohrent dune approche agile, elles se renforcent mutuellement, et contribuent la qualit du produit et son utilit.

Les mthodes agiles existaient avant le Manifeste : Scrum et Extreme Programming datent des annes 1990. Il y a eu de nombreuses autres mthodes qualifies dagiles, le Manifeste en nonant les valeurs et les principes communs a contribu les fdrer toutes derrire la mme bannire de lagilit. Plus rcemment, lengouement pour Scrum a mis fin u ne hypothtique rivalit entre les mthodes agiles. Les tudes dopinion et les tendances des recherches sur le Web tendent montrer que Scrum est de loin la plus populaire des mthodes de gestion de projet agiles.

Scrum signifie mle au rugby. Scrum utilise le valeurs et lesprit du rugby et les adapte aux projets de dveloppement. Comme le pack lors dun ballon port au rugby, lquipe charge du dveloppement travaille de faon collective, soude vers un objectif prcis. Comme un demi de mle, le ScrumMaster aiguillonne les membres de lquipe, les repositionne dans la bonne direction et donne le tempo pour assurer la russite du projet.

On est naturellement tent de parler de mthode agile ou de processus agile pour parler de Scrum. En fait, la dfinition officielle, celle donne par la Scrum Alliance et son fondateur Ken Schawaber est lgrement diffrente. Le plus souvent, K. Schawaber dcrit Scrum comme un cadre (framework) ; dautres occasions il en parle comme dune voie suivre (path). De manire concrte, Scrum dfinit des lments qui feront partie du processus appliqu pour dvelopper un produit. Ces lments sont en petit nombre, le cadre impos par Scrum tant trs lger : gure plus que des itrations, des runions en dbut et la fin de chacune, un inventaire des tches (backlog) et trois rles. Ce ct minimaliste est sans conteste une des forces de Scrum, facilitant normment son implmentation en entreprise.

Si la vraie nature de Scrum est difficile dfinir, il est beaucoup plus simple dexpliquer la mcanique de mise en uvre : Scrum sert dvelopper des produits, gnralement en quelques mois. Les fonctionnalits souhaites sont collectes dans le backlog de produit et classes par priorit. Cest le product Owner qui est responsable de la gestion de ce backlog. Une version (release) est produite par une srie ditrations appeles des sprints. Le contenu dun sprint est dfini par lquipe, avec le P roduct Owner, en tenant compte des priorits et de la capacit de lquipe. A partir de ce contenu, lquipe identifie les tches ncessaires et sengage pour raliser fonctionnalits slectionnes pour le sprint. Pendant un sprint, des points de contrle sur le droulement des tches sont effectues lors des mles quotidiennes (Scrum Meeting). Cela permet au ScrumMaster, lanimateur charg de faire appliquer Scrum, de dterminer lavancement par rapport aux engagements et dappliquer, avec lquipe, des ajustements pour assurer le succs du sprint. A la fin de chaque sprint, lquipe obtient un produit partiel (un incrment) qui fonctionne. Cet incrment du produit est potentiellement livrable et son valuation permet dajuster le backlog pour le sprint suivant.

Les 3 piliers de la thorie sont la transparence, linspection et ladaptation du processus dont Scrum fournit le cadre :

Transparence : Elle garantit que tous les indicateurs relatifs ltat du dveloppement sont visibles par
tous ceux qui sont intresss par le rsultat du produit.

Inspection : Les diffrentes facettes du dveloppement doivent tre inspectes suffisamment souvent
pour que des variations excessives dans les indicateurs puissent tre dtectes temps.

Adaptation : Si linspection met en vidence que certains indicateurs sont en dehors des limites
acceptables, il est probable que le produit rsultat sera galement inacceptable si on ne ragit pas. Le processus doit donc tre ajust rapidement pour minimiser les futures dviations.

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 mme types de travaux.

Dans les approches classiques de la gestion de projet, un cycle dit en V est couramment utilis. Il permet, en cas d'anomalie, de limiter un retour aux tapes prcdentes. Les phases de la partie montante doivent renvoyer de l'information sur les phases en vis--vis lorsque des dfauts sont dtects, afin d'amliorer le logiciel.

Scrum va lencontre de cette pratique en offrant une app roche itrative et incrmentale pour le dveloppement dun produit.

Incrmental :
Est utilis pour mettre en vidence laccroissement du produit obtenu la fin de chaque sprint. Un processus incrmental permet de construire un produit morceau par morceau, chaque nouvelle partie venant sajouter lexistant. Cest une pratique rependue dans les dveloppement de logiciel ; on parle souvent de lots pour les incrments.

Itratif :
Itrer est laction de rpter. Le terme itration est utilise pour dsigner une priode de temps dans laquelle sont effectues des activits, qui seront rptes dans les prochaines itrations. Un processus itratif permet de revenir sur ce qui a t fait, dans le but de lmaliorer ou de le complter. Cela part de lide quil est difficile, 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 dans la qualit obtenue est juge satisfaisante.

Itratif et Incrmental
Scrum combine les deux approches avec la notion de sprint : A lissu 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.

Dans chaque processus de dveloppement, il existe des jalons majeurs et des jalons mineurs. Avec Scrum, le jalon mineur et la fin dun sprint, et le jalon majeur est la production de la release. Une release est une srie de sprints qui se termine quand les incrments successifs constituent un produit qui prsente suffisamment de valeurs ses utilisateurs.

Release

Sprint 1

Sprint 2

Sprint 3

Un sprint dure habituellement entre 2 et 4 semaines. Sur le projet AVEA, la dure du sprint a t fix 2 semaines, et les sprints senchainent sans dlai : le nouveau dmarre immdiatement aprs le prcdent. Le cycle de dveloppement se prsente come un enchanement de phases dans lesquelles on effectue des activits, qui dans le dveloppement de logiciels suivent le schma suivant : Spcifications fonctionnelles Architecture ( conception ) Codage et tests unitaires Tests ( dintgration et de recette )

Chaque sprint se compose donc de ses 4 activits, et met en vidence la diffrence avec un cycle squentiel traditionnel :

Sprint 1
Scrum
Spcifications Architecture Codage Test

Sprint 2
Spcifications Architecture Codage Test

Sprint 3
Spcifications Architecture Codage Test

Sprint 4
Spcifications Architecture Codage Test

Squentiel

Spcif.

Archite cture

Codage

Test

Avec une mthode agile comme Scrum, les activits de spcifications 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.

La hirarchie classique chef de projet / dveloppeurs est remise en cause dans la mthode Scrum. Celleci prconise en effet la suppression de tou te forme dautorit au sein dune quipe, mais prvoit en lieu et place des rles complmentaires et indpendants. Les 3 rles dfinis sont celui de ScrumMaster (Animateur ou Facilitateur), de Product Owner (Directeur de produit) ainsi que lquipe. Les propositions de traduction franaises de ces rles tant source de conflit dans la communaut, les termes originaux seront prfrs. Lorsquon voque un projet dvelopp par un groupe de personnes, une pense trs rependue est de considrer quune personne identifier doit tre responsable de lquipe. Traditionnellement, ce rle est appel chef de projet. Dans Scrum, ce rle est tout simplement limin. Le travail et les responsabilits dun chef de projet ne disparaissent pas pour autant. Une grande partie est dvolue au Product Owner, une autre est laisse lquipe elle -mme. Un des principes de Scrum est lauto-organisation : il signifie que les membres de lquipe sorganisent eux- mmes, et nont pas besoin dun chef qui leur assigne le travail faire.

Le ScrumMaster nest donc pas le nouveau nom donn au chef de projet, il est tel le demi de ml dune quipe de rugby, un guide qui sache faire avancer son quipe vers la victoire. Il a pour responsabilit essentielle daider lquipe appliquer Scrum et ladapter au contexte. A ce titre, il doit : veiller en lapplication de Scrum, par exemple en faisant en sorte que les diffrentes runions aient lieu et quelles se fassent dans le respect des rgles. Encourage lquipe apprendre, et progression Faire en sorte d liminer les obstacles qui pourraient freiner lavancement, par exemple en protgeant lquipe des interfrences extrieures pendant le droulement dun sprint Inciter lquipe devenir autonome.

Il influence lquipe et cest un meneur dhomme qui sait motiver une quipe, pour quelle arrive au rsultat. Mais il doit arriver ses fins par la persuasion, sans imposer ses dcisions : un ScrumMaster ne dispose daucune autorit hirarchique sur l quipe. Son travail le plus important est dliminer les obstacles, qui peuvent tre dorigine technique, environnementaux, personnels, etc. Il joue le rle de mdiateur entre les membres de lquipe, mais surtout avec le client lorsque cela savre ncess aire. Un client mcontent aura toujours affaire au ScrumMaster qui sefforcera de trouver un compromis pour les deux parties, pendant que les dveloppeurs resteront dans un environnement optimal pour avancer leur travail.

Le Product Owner est responsable de dfinir lobjectif du produit et de le partager avec lquipe qui le dveloppe. Il doit absolument avoir une bonne vision du produit, qui se construit au dbut du dveloppement dun nouveau produit et se consoli de ensuite.

Il va a se titre rdiger en collaboration avec le client un document permettant de dcrire le contenu du produit. Pour cela, il identifie les fonctionnalits requises et les collecte dans une liste appele le backlog de produit. Par la suite, il va dfinir lordre dans lequel les parties du produit seront dveloppes. Il doit alimenter lquipe avec les fonctionnalits dvelopper, selon ses priorits dfinies, en fonction de la valeur quelles apportent, ou de lurgence de leur intgration. E n rsum, le Product Owner dfini lobjectif dune release et prend les dcisions sur son contenu et sa date de mise disposition. Une bonne connaissance du domaine mtier est fondamentale pour le Product Owner, puisquil est le reprsentant dans lquipe de toutes les personnes qui utilisent le produit. Cela sacquire notamment par des changes continues avec le client et ses utilisateurs finaux. Avec une approche agile, la spcification des exigences nest pas dtaille ds le dbut du dveloppement. Il doit donc savoir, en fonction de lavancement, quel moment dtailler des lments du backlog de produit. Cela se fait gnralement dans un autre document nomm tests dacceptations qui dfinit pour chaque user story, c'est--dire pour chaque tche lmentaire, comment la vrifier une fois finie.

Lquipe est donc compose des techniciens qui vont travailler sur le projet, guids par le ScrumMaster et aid par le Product Owner. Elle a le rle essentiel, cest elle qui va raliser le produit, en dveloppant un incrment chaque sprint. Elle est investie avec le pouvoir et lautorit pour le faire de faon la plus efficace. Pour cela, elle sorganise elle-mme et doit avoir toutes les comptences ncessaires au dveloppement du produit. Chaque membre de lquipe apportant son expertise, la synergie amliore lefficacit globale, et chaque dveloppeur se trouve individuellement responsable du produit quil cre.

Les runions reprsentent pour bon nombre de dveloppeurs une perte de temps en raison de leur inefficacit ou de leur frquence trop importante. En rponse se sentiment gnral, la mthodologie Scrum ne dfinit quun nombre limit de crmoniaux qui ont tous un objectif cl airement dfinis et une mthodologie dapplication, permettant ainsi doptimiser le temps de tous les collaborateurs tout en gagnant en efficacit. Sur lensemble du cycle de vie dun projet, ils sont au nombre de 5.

Release Sprint 1 Sprint N

Rtrospective de sprint Revue de sprint

Scrum meeting (quotidient)

Planification de sprint Planification de release

Dans tous les projets, on fait des plans, pour essayer de prvoir ce que va contenir un produit ou quelle date il sortira sur le march. Avec Scrum, la planification de release a les mmes objectifs : fournir lquipe et aux parties intresses des informations sur le contenu des sprints constituant la release. A cette tape, le Product Owner a en sa possession le backlog de produit contenant les diffrentes tches raliser en priorit, ainsi que la capacit de lquipe ( c'est--dire le nombre de jours homme disponible dans le sprint ). La planification de release consiste alors dfinir quels sont les User Story qui seront incluses dans cette release. Une grande partie de leffort ncessaire pour produire le plan de release est consacre lestimation. Avec Scrum et les mthodes agiles, celle-ci est collective, elle slabore lors de runions o toute lquipe participe. Cest un point fondamental que lquipe soccupe des estimations, car cest elle qui va par la suite excuter les tches de ralisation , et sest donc elle qui est la mieux place pour en connatre les difficults. Ma mthode de planification prconise par Scrum est elle seule signi ficatrice de lesprit de cette mthode. Il nest ici pas question destimer le temps ncessaire au dveloppement de chaque tche, mais bien leffort fournir pour y arriver. Bien que la technique ne soit pas impose par Scrum, la plus frquente est de faire une estimation collective au cours dune sance appele planning poker et destimer plutt la taille que la dure.

Le planning Poker
Il sagit dune sance destimation en groupe, avec des cartes, qui combine la jugement dexpert et lestimation par analogie. Pour commencer la sance, il faut dfinir un talon, cest simplement une user story connue par tous, pour laquelle lquipe dcide en commun dune valeur arbitraire.
Comme il est plus facile de faire des estimations sur une chelle prdfinie plu tt que davoir sa disposition tous les entiers, la suite de Fibonacci est gnralement utilise :

Pour chaque autre tche, les membre de lquipe posent des questions au Product Owner pour bien la comprendre et dbattent brivement. Tous les participants prsentent en mme temps la carte choisie pour lestimation et la valeur moyenne est prise en compte.

Une des caractristiques importante des mthodes agiles est leur capacit prendre en compte les changements. Cela implique que les plans sont remi s jour rgulirement. Cest particulirement vrai pour le plan de release, qui est actualis chaque sprint, dont les priorit et la liste des tches peuvent varier.

Cette runion met en vidence le rle essentiel de lquipe dans llaboration des plans. Le travail du sprint appartient lquipe : ce nest pas un chef qui dfinit ce quil y a faire, cest lquipe qui sorganise elle-mme. Au-del de sa fonction premire de planification, la runion est un rituel qui pr pare lquipe travailler de faon collective pendant le sprint, comme les prparatifs dans les vestiaires qui amnent une quipe de rugby rentrer dans son match. A ce niveau, lquipe a dj dfinie les user story qui seront effectuer dans le sprint. Aprs que le Product Owner ai prsent lquipe de faon dtaille une storie, lquipe va ltudier pour parvenir identifier les tches atomiques ncessaires sa ralisation. Le but tant de parvenir sparer les tches de manire optimale, en pensant paralllisassions notamment. Celles-ci sont alors estims en terme de temps de dveloppement.

Des tches annexes sont souvent rajouts tel que : criture des plans de tests (PT), criture de tests unitaires, prendre contact avec X pour demander plus d informations, etc.

Chaque jour, et heure fixe, lquipe complte se runit durant un quart dheure pour effectuer la runion davancement. Chaque participant doit alors rpondre 3 questions : Quas-tu fait depuis la dernire runion ? Que prvois-tu de faire jusqu la prochaine runion ? Quels sont les obstacles qui te freinent dans ton travail.

Cest loccasion pour les dveloppeurs de prvoir la meilleur faon de parallliser leur travaux ou de demander de laide si une tche savre plus dlicate que prvue ( le travail en binme est conseill dans les mthodes agiles ). Pour les quipes qui utilisent un tableau des tches mural, comme cest le cas chez IOcean, cest aussi loccasion de dplacer physiquement la carte corres pondante dans la ligne : en cours ( je prend en charge cette tche ), tester ( un autre collaborateur doit tester cette user story ) ou fini.

La revue de sprint est une dmonstration de lincrment en prsence de toutes les parties prenante ( hirarchie pour un produit interne, client ). Elle a pour objectif de montrer le rsultat du travail de lquipe durant le sprint. Dans un premier temps le Product Owner va rappeler le but du sprint dfini dans la runion de planification, puis lquipe prsente le produit partiel, rsultat de ses travaux, en faisant une dmonstration des stories ralises. Les participants la runion sont invits poser des questions lquipe et donner leur impression sur le produit montr. Leur feedback se concrtise en propositions et demandes de changement, qui seront prisent en compte dans le backlog de produit. La difficult de cette runion est dviter quelle ne tourne en chasse au bug avec un client difficile, le rle de modrateur du ScrumMaster est alors indispensable pour rappeler la chane de remonte des bugs, et ne pas retarder la revue de sprint.

En reprenant lanalogie dun match de rugby, on peut comparer la rtrospective de sprint la discussio n daprs match . A partir des expriences tires du dveloppement du sprint courant, lquipe identifie ce qui marche bien pour elle, ce qui marche moins bien, et trouve collectivement ce quil faut modifier au processus quelle utilise. Cest une pratique damlioration continue amenant ladaptation des processus, la capitalisation des connaissances et lchange de points de vues. Elle prend gnralement la forme dun brainstorming entre tous les acteurs de lquipe. Une fois tous les points voqu s, lquipe dcide de trois choses faire pour amliorer litration suivante (par exemple : travailler en binme une heure par jour, raliser les tests dacceptations plus tt dans le cycle, impliquer davantage le client).