Tour d’ho­ri­zon des diffé­rentes méthodes agiles

Méthode Scrum

Scrum est aujour­d’hui l’ap­proche agile la plus utili­sée. Elle se carac­té­rise par des itéra­tions courtes de quatre semaines maxi­mum (des sprints), ainsi que par la distri­bu­tion des rôles suivants au sein de l’équipe projet :

• le Scrum­Mas­ter, qui s’as­su­rera du respect de la métho­do­lo­gie Scrum et jouera un rôle de coach et de faci­li­ta­teur
• le Product Owner, qui portera la vision du produit et les attentes des utili­sa­teurs / clients
• l’équipe (i.e. les colla­bo­ra­teurs compo­sant l’équipe projet, par exemple des déve­lop­peurs dans un projet infor­ma­tique)

Son fonc­tion­ne­ment s’ar­ti­cule autour de “time­box” régu­lières, c’est à dire des périodes de temps limi­tées. Chacune d’elle est une itéra­tion de déve­lop­pe­ment limi­tée à une courte durée durant laquelle l’équipe devra se concen­trer sur des fonc­tion­na­li­tés précises et défi­nies en amont.  La méthode Scrum limite la docu­men­ta­tion, mais impose un unique docu­ment, le Product Back­log. Il contient les diffé­rentes fonc­tion­na­li­tés atten­dues et permet d’or­ga­ni­ser le travail.   

Envie de deve­nir un mana­ger Agile ? En 6 semaine formez-vous au Chal­lenge Scrum Master. Plus d’in­for­ma­tion sur la page Chal­lenge Scrum Master.

Extrem Progra­ming

Extrem progra­ming est une méthode de gestion de projet forte­ment axé sur l’as­pect réali­sa­tion. Les éléments clés de cette méthode sont : 

• la program­ma­tion en binôme (“pair program­ming” en anglais)
• la réin­gé­nie­rie logi­cielle, “refac­to­ring” en anglais, qui consiste à modi­fier le code afin de le rendre plus facile à main­te­nir et à lire sans chan­ger son fonc­tion­ne­ment
• l’inté­gra­tion conti­nue (“conti­nuous inte­gra­tion” en anglais) qui vise à véri­fier que chaque modi­fi­ca­tion de code source ne produit aucune régres­sion sur le logi­ciel.

De nombreuses équipes de déve­lop­pe­ment combinent Scrum et Extrem Progra­ming. Cette méthode mixte est à ce jour la deuxième approche agile la plus utili­sée au monde, derrière Scrum.   

Graphique illus­trant la popu­la­rité des diffé­rentes méthodes agiles, d’après l’enquête 2013 de Version One.

Méthode Kanban

Kanban (litté­ra­le­ment « panneau » en japo­nais) est une approche qui consiste à faci­li­ter au maxi­mum le work­flow d’une équipe et à adap­ter le volume du travail en cours aux capa­ci­tés de l’équipe de produc­tion.  Concrè­te­ment il s’agit de placer les items (ou tâches) du projet dans une colonne du tableau Kanban. Chacune des colonnes repré­sente un état (à évaluer, à faire, en cours, etc.). Géné­ra­le­ment, cette tech­nique est utili­sée en paral­lèle des autres méthodes et permet une tran­si­tion progres­sive des méthodes clas­siques aux méthodes agiles.  Le Kanban est une adap­ta­tion à l’uni­vers du logi­ciel d’une méthode conçue par Toyota dans les années 50 pour mettre en place un système produc­tion à flux tendus.  

Lean Deve­lop­ment

Tout comme le Kanban, le Lean Deve­lop­ment est l’ap­pli­ca­tion d’une méthode indus­trielle au secteur du logi­ciel. En plus des prin­cipes de l’agi­lité, le Lean Deve­lop­ment s’ap­puie sur deux autres préro­ga­tives clés : 

1. Élimi­ner les gaspillages
2. Amélio­rer l’ap­pren­tis­sage de l’équipe.

Feature Driven Deve­lop­ment (FDD)

Le Feature Driven Deve­lop­ment ou FDD s’axe prin­ci­pa­le­ment sur le design et le déve­lop­pe­ment. Le déve­lop­pe­ment est réalisé par plusieurs équipes, chacune en charge d’une à deux fonc­tion­na­li­tés du produit. La valeur prin­ci­pa­le­ment mise en avant par cette méthode est la qualité du produit fini.  

Quelle méthode choi­sir ?

Ces diffé­rentes méthodes répondent toutes à des problé­ma­tiques de déve­lop­pe­ment diffé­rentes. Il est donc impos­sible de les compa­rer “dans l’ab­solu”, il faut le faire rela­ti­ve­ment aux besoins de l’équipe projet.  Pour choi­sir une méthode, il est impor­tant de pondé­rer les critères suivants :

• Besoin rapide de mise à dispo­si­tion du produit
• Impré­vi­si­bi­lité des besoins du client
• Néces­sité de chan­ge­ments fréquents
• Besoin de visi­bi­lité du client sur l’avan­ce­ment des déve­lop­pe­ments
• Présence de l’uti­li­sa­teur assu­rant un feed­back immé­diat

De la même manière, certains critères sont suscep­tibles de venir inva­li­der l’uti­li­sa­tion de ces méthodes :

• Indis­po­ni­bi­lité du client ou de l’uti­li­sa­teur
• Disper­sion géogra­phique des ressources humaines
• Iner­tie des acteurs du projet ou refus des chan­ge­ments

Il peut s’avé­rer égale­ment qu’au­cune méthode agile ne puisse être appliquée au projet donné. Dans ce cas de figure, le recours aux méthodes tradi­tion­nelles comme le cycle en V ou encore le Water­fall s’im­pose.