Scrum est en quelques sortes une méthodolo­gie, une approche, un sys­tème pour pilot­er la con­cep­tion logi­cielle et sa livrai­son, mais pas seule­ment. Toute créa­tion de pro­duit peut, en théorie, utilis­er cette approche — l’idée étant bien enten­du de tra­vailler à plusieurs. C’est con­nu, l’en­fer, c’est les autres !

Cette méthodolo­gie est apparue en 1996. Scrum utilise les valeurs du Rug­by pour les adapter à l’industrie du logiciel.

Mon objec­tif n’est pas de vous faire un exposé com­plet sur Scrum, mais de vous en par­ler, éventuelle­ment de vous don­ner envie de vous laiss­er ensuite dévor­er toute la lit­téra­ture exis­tante sur le sujet sur Inter­net. Je vais vous en par­ler dans le cadre de développe­ment de logi­ciels ou de jeux, mais cela peut-être util­isé dans un cadre plus large.

Méthodes dites “Agiles”

Elle se classe par­mi les méth­odes « agiles ». C’est à dire, une approche plus « directe », plus sou­ple, plus réac­tive et qui implique d’avantage le client. Ces méth­odes Elles reposent sur un cycle de développe­ment itératif, incré­men­tal et adaptatif.

C’est quoi le prob­lème avec les méth­odes tra­di­tion­nelles ? Quand on réalise un cahi­er des charges le plus com­plet pos­si­ble, antic­i­pant au mieux tout prob­lème éventuel, en lev­ant toute incer­ti­tude, en réal­isant suff­isam­ment de recherch­es pour qu’il ne reste plus d’inconnus. Oui, mais voilà, en théorie c’est beau, mais en pra­tique, on est rapi­de­ment à coté de la plaque sur de gros pro­jets com­plex­es. En effet, dans le monde réel, des incon­nues sub­sis­tent le plus sou­vent, des élé­ments externes au pro­jet vien­nent per­turber l’ensemble et il est par­fois néces­saire de chang­er de cap en cours de développement.

Per­son­nelle­ment, c’est une approche qui me con­vient mieux : j’ai tou­jours remar­qué qu’il était plus effi­cace de créer un noy­au de pro­gramme et de le faire évoluer par couch­es suc­ces­sives… quitte à devoir réécrire quelques fois une par­tie du code.

Les méth­odes agiles per­me­t­tent de mieux sat­is­faire le client, accueil­lir favor­able­ment les deman­des de change­ment et livr­er le plus sou­vent pos­si­ble des élé­ments fonc­tion­nels. Le client peut ain­si arrêter le pro­jet quand il le souhaite (si c’est con­venu ain­si bien entendu).

Pourquoi utiliser Scrum ?

Scrum est adap­té aux pro­jets com­plex­es. Il est sim­ple à com­pren­dre, mais reste dif­fi­cile à maîtris­er. Ce n’est pas vrai­ment une méthodolo­gie com­plète, mais plus un cadre de tra­vail régi par un cer­tain nom­bre de règles.

Bref, il faut savoir appren­dre « con­stam­ment », être l’écoute, réac­t­if et impli­quer le client dans la prise de déci­sion. La trans­parence est le maître mot.

Scrum per­met d’éviter :

• Le manque de com­mu­ni­ca­tion au sein de l’équipe de dev
• La mau­vaise com­préhen­sion des besoins client
• La dif­fi­culté à pren­dre en compte les change­ments en cours de projet
• l’insuffisance de testes et de suivi

C’est quoi précisément ?

Divis­er pour régn­er : On va divis­er le temps, le besoin et l’équipe.

Pour cela, Scrum a choisi de découper le pro­jet en briques de temps qu’on appelle « Sprint » ou itéra­tions (entre quelques heures et 1 mois).

Chaque sprint com­mence par

• une réu­nion de plan­i­fi­ca­tion : Le PO présente à l’équipe les fonc­tion­nal­ités à réalis­er durant le sprint (Sprint Back­log). L’équipe s’engage sur une durée et sur un contenu. 
• une phase de réal­i­sa­tion avec ses réu­nions quo­ti­di­ennes de 15 min­utes max (mêlée quo­ti­di­enne ou dai­ly scrum) – Cha­cun doit répon­dre à « qu’ai-je fait hier », « qu’ai-je prévu aujourd’hui », « est-ce que je ren­con­tre des difficultés ? ».
• une revue de sprint (voir ce qui a été pro­duit, ce qui s’est bien déroulé ou non – c’est la présen­ta­tion au client/product own­er) et 
• une rétro­spec­tive (pareil, mais pour l’organisation Scrum, pas le pro­duit, com­ment amélior­er l’organisation). Quels sont nos forces, nos faib­less­es, nos blocages, nos axes d’amélioration pour la prochaine itération.

Le besoin est découpé en sous-besoins appelés « User Sto­ries ». Ces dernières doivent être assez petites pour être réal­isées durant un itération.

Chaque équipe Scrum est com­posée d’un « prod­uct Own­er », respon­s­able du pro­duit. Cela peut-être le client ou un représen­tant. Il y a l’équipe de dev, les opéra­tionnels en quelques sortes – ça peut-être des graphistes ou des ingénieurs son – et un Scrum Mas­ter, sorte de gar­di­en de la bonne pra­tique de Scrum ! Il pro­tège l’équipe des per­tur­ba­tions extérieures. Ce n’est pas un chef de pro­jet, car le but recher­ché est l’auto-organisation. Il n’y a aucune hier­ar­chie entre ces 3 fonctions.

Divis­er l’équipe per­met de lim­iter la taille et d’avoir ain­si une meilleure syn­ergie (5–10 personnes).

Quelques termes à connaitre

Il y a d’autres ter­mes à con­naître comme le Back­log Pro­duit : Liste ordon­née de tous les élé­ments iden­ti­fiés comme néces­saires au pro­duit. J’appelle cela le cahi­er des fonc­tion­nal­ités quelques fois. Un Back­log Pro­duit n’est jamais com­plet. Ses toutes pre­mières mou­tures ne font qu’esquisser les besoins tels qu’initialement con­nus et com­pris. Même en terme de fonc­tion­nal­ités, on se dit que c’est en faisant qu’on les appréhen­dera au mieux… C’est impor­tant de com­pren­dre l’esprit der­rière l’approche. On ajoutera au Back­log toutes les fonc­tion­nal­ités, les fonc­tions, les exi­gences, les amélio­ra­tions et les cor­rec­tions qui con­stituent des mod­i­fi­ca­tions à apporter au pro­duit dans les ver­sions futures. En gros, cela va grossir… grossir… Grossir ! A mesure que le logi­ciel est util­isé bien évidemment.

Le back­log Sprint, comme son nom le laisse présager, c’est une extrac­tion du BP pour le Sprint.

On qual­i­fie d’incrément tout élé­ment qui aura été ter­miné durant un sprint. Il s’agit d’une fonc­tion­nal­ité qui peut répon­dre par­tielle­ment au besoin, mais elle doit rester livrable et fonctionnelle.

Conclusion

Voilà, vous avez un aperçu du prin­ci­pal. Si vous souhaitez met­tre en place cette approche dans la con­cep­tion de vos pro­duits, le mieux serait d’intégrer à votre équipe un « Scrum Mas­ter ». L’autre solu­tion, c’est d’en for­mer un. Pour cela, il y a des for­ma­tions, et des livres. En voici quelques un :

1. Scrum — 5e éd.- Pour une pra­tique vivante de l’agilité de Claude Aubry aux édi­tions DUNOD (2018)
2. Scrum, de la théorie à la pra­tique: Ini­ti­a­tion. Per­fec­tion­nement. Agilité. De Bassem El Had­dad aux édi­tions EYROLLES (2017)
3. Scrum pour les Nuls de Mark C. Lay­ton (2016)
4. Scrum, méth­ode Agile de David Chap­lin aux édi­tions ENI (2016) — épli­ant aide-mémoire de 12 pages autour de SCRUM (6€).

Un guide gra­tu­it en français : guide en français. (16 pages).

Main­tenant, ce qui paraît opti­mal sur le papi­er ne l’est pas en pra­tique. On reproche notam­ment à Scrum son manque de flex­i­bil­ité dans l’approche, de présen­ter un risque d’augmentation indéfinie des fonc­tion­nal­ités, d’un glisse­ment… son manque d’adéquation avec les out­ils de dev exis­tant… Bref, c’est une méth­ode qui a aus­si ses incon­vénients. A vous de vous faire une opinion.

As-tu déjà util­isé une méth­ode agile de ges­tion de pro­jet ? Scrum ? Qu’en as-tu pen­sé, ses qual­ités, ses incon­vénients ? Et sinon, après avoir lu cet arti­cle, trou­ves-tu l’approche intéressante ?