GDP Agile avec SCRUM

L'anglicisme scrum signifie "mêlée de rugby".

 

Chapitre 1 : Qu'est-ce qu'une approche agile?

C'est une approche (qui est une alternative à l'approche traditionelle ou "cycle en v") utilisant une ou plusieurs partageant des points communs avec un document sorti en 2001 : "Le manifeste pour le développement agile de logiciels" qui valorise:

• Les individus et leurs interactions plus que les processus et les outils
• Des logiciels opérationnels plus qu'une documentation exhaustive
• La collaboration avec les clients plus que la négociation contractuelle
• L'adaptation au changement plus que le suivi d'un plan

Ces 4 valeurs s'appuient sur 12 principes:

Notre plus haute priorité est de satisfaire le client
en livrant rapidement et régulièrement des fonctionnalités
à grande valeur ajoutée.

Accueillez positivement les changements de besoins,
même tard dans le projet. Les processus Agiles
exploitent le changement pour donner un avantage
compétitif au client.

Livrez fréquemment un logiciel opérationnel avec des
cycles de quelques semaines à quelques mois et une
préférence pour les plus courts.

Les utilisateurs ou leurs représentants et les
développeurs doivent travailler ensemble quotidiennement
tout au long du projet.

Réalisez les projets avec des personnes motivées.
Fournissez-leur l’environnement et le soutien dont ils
ont besoin et faites-leur confiance pour atteindre les
objectifs fixés.

La méthode la plus simple et la plus efficace pour
transmettre de l’information à l'équipe de développement
et à l’intérieur de celle-ci est le dialogue en face à face.

Un logiciel opérationnel est la principale mesure d’avancement.

Les processus Agiles encouragent un rythme de développement
soutenable. Ensemble, les commanditaires, les développeurs
et les utilisateurs devraient être capables de maintenir
indéfiniment un rythme constant.

Une attention continue à l'excellence technique et
à une bonne conception renforce l’Agilité.

La simplicité – c’est-à-dire l’art de minimiser la
quantité de travail inutile – est essentielle.

Les meilleures architectures, spécifications et
conceptions émergent d'équipes autoorganisées.

À intervalles réguliers, l'équipe réfléchit aux moyens
de devenir plus efficace, puis règle et modifie son
comportement en conséquence.

 

Ce manifeste illustre "l'état d'esprit agile". Ces méthodes sont nées du constat que les procédures étant si complexe dans le monde du logiciel, les incertitudes sont grandes; de plus, puisqu'on ne peut connaître complètement le besoin tant que les utilisateurs n'ont pas utilisé, il fallait de nouvelles approches. SCRUM est le cadre méthodologique le plus utilisé.

Les méthodes agiles prônent le fait que chercher à donner tous les détails du projet avant de se lancer est contre-productif, car on devra faire face à des imprévus. La planification et les spécifications peuvent vite devenir obsolètes : on va plutôt commencer par un premier objectif, et adapter son itinéraire une fois celui-ci atteint. On pourra alors faire une projection basée sur l'expérience acquise, pas exacte mais meilleure qu'avec une approche traditionelle : on parle d'approche empirique.

Jean-Pierre Chardon : "L'entreprise doit avoir l'agilité du banc de poisson qui agit et réagit avec vitesse, simultanéité et précision". (lol)

Une entreprise doit savoir s'adapter rapidement et utiliser une intelligence collective.

Pour faire simple, la méthode agile passe d'une approche prédictive à une approche empirique et pragmatique.

 

Chapitre 2 Fonctionnement de SCRUM : une démarche itérative et incrémentale.

SCRUM est basé sur un processus empirique basé sur 3 piliers; scrum privilégie la légèreté méthodologique et l'approche empirique (acquérir des connaissances en se basant sur l'expérience et prendre des décisions basées sur des faits connus).

3 piliers:

• Transparence, pour donner de la visibilité aux responsables du projet
• L'inspection, pour détecter les écarts indésirables
• L'adaptation pour rectifier ces écarts.

Comme pour une bataille, les plans sont inutiles mais la planification est capitale : il ne faut pas chercher à tout prévoir mais plutôt chercher à planifier au fur et à mesure.

Comment ce mécanisme se traduit-il en termes de processus?

Cela commence avec le product owner, qui représente les utilisateurs et a la vision du produit que l'on souhaite réaliser.

• Il travaille sur la vision du produit (Quel produit, pour quoi faire?)
• Il met l'ensemble de ses besoins dans le product backlog, mais sans aller dans le détail; de plus il sollicite l'équipe de dev pour estimer chaque fonction notamment d'un point de vue technique.
• Une fois que cela est fait il ordonnance son product backlog, avec en haut les élements très importants ou a forte valeur, et en bas les élements moins importants. Il peut s'appuyer pour ça sur d'autres acteurs (devs, etc...)

Une fois que cela est fait, on peut démarrer le SPRINT (les itérations) en procédant à la réunion de planification de sprint; on va choisir un sous-ensemble d'élements dans le product backlog qui seront réalisés dans le sprint en cours. Cette réunion a surtout le client et l'équipe de dev, et on essaie d'avluer la difficulté du projet (l'estimation sera de plus en plus précise au fur et à mesure des réunions de sprint).

Les élements sélectionnés vont dans le sprint backlog, qui détermine le périmètre du sprint et le plan d'action associé à l'atteinte de l'objectif. Il peut aussi faire l'objet d'un découpage en sous-tâches pour répartir le travail et améliorer la mesure de l'avancement. La réunion de planification de sprint est "timeboxée", ie elle doit s'arrêter avant la fin de la deadline afin de rester concentré sur l'objectif (en général 8 heures max pour 1 mois de sprint). Ca permet de se concentrer sur l'objectif.

Une fois cela fait, les travaux commencent, avec la conception détaillée, mise en oeuvre et test des fonctionnalités. Chaque jour au cours de la "mêlée quotidienne" l'équipe se synchronise vis-à-vis de l'objectif du sprint pour la journée avec un stand-up meeting de 15 minutes, et on ne regarde pas les problèmes (on fait plutôt ça après les mêlées avec les personnes concernées).

Le sprint est timeboxé, il se termine par la revue de sprint (le produit incrémenté avec ses nouvelles fonctionnalités est présenté aux parties prenantes comme users, sponsors, service marketing... dont les retours serviront, on choisit aussi la direction à prendre). La retrospective de sprint sert elle à revenir sur le sprint pour améliorer le processus dès le sprint suivant. Cette réunion est limitée à 3h pour 1 mois de sprint et rassemble tout le monde : Product owner, Devs et scrum master. C'est un genre de post-mortem, mais qui permet de tenir compte des remarques tout de suite.

Le Scrum master s'assure que tout le monde reste dans la méthodologie de Scrum.

 

Chapitre 3 : Les 8 leviers de la réussite.

Un projet réussi ne mène pas forcément à un produit respectant toutes les spécifications prévues : un projet "cycle en v" même très réussi peut ne pas coller aux besoins de l'utilisateur.

Un projet réussi respecte-t'il forcément le triangle "budget - périmètre - délai"? Cela peut faire partie de la réussite, mais respecter le périmètre peut nuire en offuscant certaines idées émergentes. Selon Florent Lothon, un projet réussi est un projet qui "donne le sourire à tout le monde" : utilisateurs, sponsors, commanditaires, actionnaires... et surtout l'équipe projet fière de son travail. En gros (définition du suiccès ici) : il faut faire le produit que les utilisateurs attendent, au bon moment et au meilleur coût.

Quels leviers permettent ce genre de réussite?

• Réduire l'effet tunnel aide à trouver le bon moment : ici on réduit le délai entre l'expression de besoin et la concrétisation de fonctionnalité associée. Ici, un sprint dure 4 semaines max, on peut vite s'adapter et améliorer la visibilité.
• S'ouvrir au changement pour les voir comme des opportunités plutôt que des problèmes. Chaque fonctionnalité peut arriver au sprint d'après.
• Optimiser la communication : l'écrit, asynchrone et soumis à interprétation, n'est pas la plus efficace. Rien ne vaut la parole, surtout sur des projets compliqués. Mais il FAUT documenter. En plus, on a pas d'intermédiaire entre l'équipe de dev et le product owner qui représente les clients.
• Se montrer minimaliste aide à rendre le projet au bon moment : on cherche à enlever des choses pour atteindre la perfection. On commence par les grosses fonctionnalités pour donner rapidement aux utilisateurs un produit utilisable, minimaliste au début.
• L'amélioration continue aide optimiser les coûts. On peut augmenter tôt et fréquemment l'efficacité de l'équipe et du projet; on se rapproche du produit idéal sans jamais le considérer comme étant parfait.
• Détecter les défaut au plus tôt aide à réduire les coûts. Un défaut detecté tard coûte cher. Un défaut sur un produit en vente peut coûter des milliards ou pire, des vies humaines. Intégration continue, programmation en binôme, pilotage des développements par les tests sont des choses qui aident.
• Utiliser une architecture souple et émergente aide à réduire les coûts, surtout en logiciel. Définir les composant techniques du logiciel et leurs interactions prend beaucoup de temps en dev de logiciel; des fonctionnalités émergentes n'ont alors plus de place, ou coûtent cher. Il faut donc une archi souple qui va émerger au fil des sprints en même temps que les fonctionnalités : on ne construit pas une maison !
• La motivation aide dans tout le projet. Le management doit croire en son équipe et aider son équipe; l'environnement doit être motivant et le rythme de travail soutenable. L'équipe doit avoir la liberté d'innover et le droit à l'erreur, avoir un sentiment d'appartenance et de fierté collective.

Chapitre 4 : Le rôle de SCRUM Master.

Il est différent d'un chef de projet. Les rôles au sein d'une équipe scrum sont:

• Product owner, qui porte la vision du produit et des utilisateurs, et gère le product backlog
• L'équipe de développement, pluridisciplinaire qui réalise le produit et autoorganisée, de 9 personnes max par équipe
• Le scrum master, qui maîtrise Scrum et en est le garant. Il peut coacher les nouveaux.

Le qutodien du chef de projet traditionel consiste à jongler avec un tas de variables (coûts, risque etc), mais aussi à être un leader motivant autrement qu'avec du pognon. Il doit aussi gérer le planning. Il estime et affecte les tâches. Il doit être omniscient, omniprésent et omnipotent, ce qui est généralement usant, entre protéger son équipe et tenir les engagaments : on appelle ce genre de managers des managers héros. Quand c'est complexe, ça ne marche pas trop.

Le scrum master lui, s'assure que l'équipe adhère au rôle, et est un leader au service de l'orga et des autres; c'est un "servant leader". Il s'assure des interactions entre tout le monde. Il coache aussi l'équipe de dev pour aboutir à la fin de chaque sprint à un incrément utilisable. Il peut protéger l'équipe de dev des perturbations qui la freineraient. L'équipe est auto-organisée et n'as pas à subir un chef de projet qui lui dit comment travailler.

Psychologiquement, les humains n'aiment pas qu'on leur dise comment se comporter car c'est ce que l'on fait avec les enfants. C'est parfois confortable (on se repose sur le chef) mais on ne va pas loin comme ça. Le chef de projet n'est plus seul, si les responsabilités sont bien réparties.

Scrum n'as pas de chef de projet; mais scrum master signifie quand même manager. Il doit pouvoir agir sur l'organisationen cas de besoin. Quand on bascule de chef de projet à scrum master, il faut supprimer certains réflexes, par exemple supprimer le "je commande et maîtrise tout" pour aller vers du coaching. L'auto-orga ne doit pas signifier que le manager démissionne : il est là pour soutenir. Il doit aussi assurer un environnement motivant, droit à l'erreur et durée du travail. Les mauvais choix seront limités au sprint concerné.

Définition du manager agile : "Manager qui met son pouvoir au service du développement des compétences et de la réussite de son équipe de développement". On est plus serein malgré les difficultés, et on a plus de temps pour cultiver son leadership.

Un bon scrum master doit :

• Être quelqu'un de responsable pour garantir la bonne compréhension et application de SCRUM
• Il faut être humble (et collaboratif) et reconnaître que l'équipe de développement peut avoir de meilleures idées, et aussi ne pas s'attribuer les victoires de toute l'équipe : on est plus un manager héros.
• Il faut être engagé et déterminé face à la résistance au changement qui caractérise les être humains
• Il faut être omniscient, ie parfaitement connaître Scrum et les pratiques agiles pour transmettre ses connaissances
• Avoir foi en l'humain

Chapitre 5 : Animation de la rétrospective

On commence par la durée : 90 minutes max pour 2 semaines de sprint; 3h pour 1 mois de sprint.

On fixe un objectif : par exemple "Améliorer l'efficacité du processus de développement", mais on peut améliorer des choses plus précises.

On précise l'ordre du jour : ici trois parties:

• 20 minutes sur les choses à conserver
• 30 minutes sur les choses à améliorer
• 40 minutes sur le plan d'action

On peut rajouter la prise de température (comment chacun a vécu le sprint?) et aussi à la fin un ROTI (Return Of Time Invested, de 0 à 5 le degré de valeur ajoutée perçu par la personne vis-à-vis de la rétrospective en elle-même).

Première étape : les choses positives à conserver et cultiver peuvent être par exemple :

• L'esprit d'équipe/entraide
• La préparation de la démonstration aux users
• Revue par les pairs des fonctionnalités accomplies
• Programmation en binôme
• Soutien du sponsor au projet

On peut y ajouter plein de choses, bien sûr. Pendant 20 minutes tout le monde parle pour apporter des élements. On peut aussi dès le début amener l'équipe à pondérer les points positifs : par exemple allouer à chacun trois points qu'ils peuvent répartir comme ils veulent sur les sujets pour donner les élements positifs.

Deuxième partie, les axes d'amélioration, par exemple:

• Trop de fonctionnalités pas terminées
• Pas de documentation
• Product Owner peu dispo
• Trop de tests manuels répétitifs
• La mếlée qui dépasse trop souvent les 15 minutes
• Manque de matériels
• Etc...

Il faut éviter d'instruire chaque problème quand il arrive pour ne pas dépasser la durée prévue; l'animateur doit pouvoir couper court aux personnes voulant amener tout de suite une solution.

On peut pondérer de la même façon.

Troisième partie, le plan d'action : Cela peut prendre du temps. À la fin il faut que des personnes aient envie de s'approprier les actions, souvent les personnes ayant le problème à coeur. Il faut éviter de désigner des volontaires ! Exemples d'actions:

• Clarifier la définition de "terminé"
• Alerter le management par rapport au matériel manquant et travailler en binôme en attendant
• Élaborer un modèle de spécification agile
• Automatiser un premier test fonctionnel simple et répétitif

Mieux vaut deux ou trois actions sûres que dix qui serait insurmontables.

Mieux vaut commencer par les points positifs et les remerciements pour la motivation.

Une autre façon de faire quand les gens n'osent pas parler, est de tracer un axe orthonormé du style :

• En haut à gauche, points positifs
• En haut à droite points négatifs
• En bas à gauche les idées d'amélioration
• En bas à droite le plan d'action

Chacun inscrit une idée par post-it et le colle au bon endroit.

 

Conclusion

Scrum est un simple cadre méthodologique, léger et ouvert. L'approche itérative et incrémentale aide à maîtriser les risques. On sait également comment animer une retrospective, adaptable à tout projet. Il aide à améliorer le bien-être au travail, et demande à être pratiqué.