Voir la source de GDP Agile avec SCRUM


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


&nbsp;

= Chapitre 1&nbsp;: 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&nbsp;: "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:

<span style="font-size:small">Notre plus haute priorité est de satisfaire le client<br/> en livrant rapidement et régulièrement des fonctionnalités<br/> à grande valeur ajoutée.</span>

<span style="font-size:small">Accueillez positivement les changements de besoins,<br/> même tard dans le projet. Les processus Agiles<br/> exploitent le changement pour donner un avantage<br/> compétitif au client.</span>

<span style="font-size:small">Livrez fréquemment un logiciel opérationnel avec des<br/> cycles de quelques semaines à quelques mois et une<br/> préférence pour les plus courts.</span>

<span style="font-size:small">Les utilisateurs ou leurs représentants et les<br/> développeurs doivent travailler ensemble quotidiennement<br/> tout au long du projet.</span>

<span style="font-size:small">Réalisez les projets avec des personnes motivées.<br/> Fournissez-leur l’environnement et le soutien dont ils<br/> ont besoin et faites-leur confiance pour atteindre les<br/> objectifs fixés.</span>

<span style="font-size:small">La méthode la plus simple et la plus efficace pour<br/> transmettre de l’information à l'équipe de développement<br/> et à l’intérieur de celle-ci est le dialogue en face à face.</span>

<span style="font-size:small">Un logiciel opérationnel est la principale mesure d’avancement.</span>

<span style="font-size:small">Les processus Agiles encouragent un rythme de développement<br/> soutenable. Ensemble, les commanditaires, les développeurs<br/> et les utilisateurs devraient être capables de maintenir<br/> indéfiniment un rythme constant.</span>

<span style="font-size:small">Une attention continue à l'excellence technique et<br/> à une bonne conception renforce l’Agilité.</span>

<span style="font-size:small">La simplicité – c’est-à-dire l’art de minimiser la<br/> quantité de travail inutile – est essentielle.</span>

<span style="font-size:small">Les meilleures architectures, spécifications et<br/> conceptions émergent d'équipes autoorganisées.</span>

<span style="font-size:small">À intervalles réguliers, l'équipe réfléchit aux moyens<br/> de devenir plus efficace, puis règle et modifie son<br/> comportement en conséquence.</span>

&nbsp;

<span style="font-size:small">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é.</span>

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&nbsp;: 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&nbsp;: on parle d'approche empirique.

Jean-Pierre Chardon&nbsp;: "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.

&nbsp;

= Chapitre 2 Fonctionnement de SCRUM&nbsp;: 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&nbsp;: 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&nbsp;: 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.

&nbsp;

= 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. Ses 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