CH2- Agilité et agilité à l'échelle (PDF)

CH2- Agilité et agilité à l’echelle Introduction Introduction introduction Qu'est-ce que l'agilité ? En février 2001, aux États-Unis, dix-sept spécialistes du développement logiciel se sont réunis pour débattre du thème unificateur de leurs méthodes respectives, jusqu'alors appelées sans...

CH2- Agilité et agilité à l’echelle Introduction Introduction introduction Qu'est-ce que l'agilité ? En février 2001, aux États-Unis, dix-sept spécialistes du développement logiciel se sont réunis pour débattre du thème unificateur de leurs méthodes respectives, jusqu'alors appelées sans consensus méthodes lights, les plus connus d'entre eux étaient Ward Cunningham l'inventeur du Wiki , Kent Beck, père de l' eXtreme Programming et cofondateur de JUnit, Ken Schwaber et Jeff Sutherland, fondateurs de Scrum, Jim Highsmith prônant l'ASD, Alistair Cockburn pour la méthode Crystal clear, Martin Fowler, et Dave Thomas ainsi qu'Arie van Bennekum pour DSDM (Dynamic System Development Method) la version anglaise du RAD ( développement rapide d'applications), Robert Cecil Martin pour Clean Architecture, parmi les autres signataires, Andy Hunt1, Jared Richardson (fondateur ultérieurement de la méthode GROWS) ou Ron Jeffries. Ces dix-sept experts venant tous d'horizons différents réussirent à déclarer le Manifeste agile, considéré comme la définition canonique du développement agile et de ses principes sous-jacents. Le Manifeste agile est constitué de quatre valeurs et de douze principes fondateurs. Leur intention est bien de remettre le « bon sens » au cœur du projet. La notion de manifeste sous-entend l’idée d’une déclaration, d’un programme. il s’agit de la représentation d'un idéal à atteindre. “Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.“ Extrait du Manifeste Agile.  Qu'est-ce que l'agilité ? « L’agilité est, un ensemble des valeurs et principes, donnant la capacité à toute organisation à fournir tôt et souvent des produits ou services impactant ses utilisateurs tout en s’adaptant à temps aux changements dans son environnement. » AGILE is a mindset: De ce fait, une nouvelle culture est nécessaire, La culture agile, Les valeurs et les principes de l’agilité présentent le guide de référence pour une telle transformation. Il importe de tenir compte des aspects culturels dans la formation et la transition à l’agilité : on ne change pas si facilement de culture. Au-delà des idées, l’agilité, en particulier avec Scrum et SAFe, véhicule un vocabulaire nouveau. En quelque sorte, Ce vocabulaire contribue à renforcer l’idée du changement de culture et qui sera le langage commun reconnu, maitrisé et appliqué par  Qu'est-ce que l'agilité ? Le Manifeste pour le développement agile de logiciels (The Manifesto for Agile Software Development) est un texte rédigé par dix-sept experts du développement d'applications informatiques. Ces experts estimaient que le traditionnel cycle de développement en cascad e ne correspondait plus aux contraintes et aux exigences des organisations en évolution rapide. Les méthodes agiles ne sont pas apparues avec le Manifeste en 2001 mais celui-ci détermine leurs dénominateurs communs et consacre le terme d'« agile » pour les référencer. Qu'est-ce que l'agilité ? Quatre valeurs « Nous découvrons de meilleures approches du développement logiciel en le pratiquant et en aidant les autres à le pratiquer ». Ce travail nous a amené à accorder de l'importance : aux individus et leurs interactions plutôt qu'aux processus et aux outils ; à un logiciel fonctionnel plutôt qu’à une documentation exhaustive ; à la collaboration avec les clients plutôt qu'à la négociation contractuelle ; à l’adaptation au changement plutôt qu'à l'exécution d’un plan. Cela signifie que, bien qu'il y ait de la valeur dans les éléments situés à la fin, la préférence se porte sur les éléments qui se trouvent en première partie de phrase.  Qu'est-ce que l'agilité 12? principes Les 4 valeurs de l'agilité: “1) Les individus et les interactions plus que les processus et les outils Qui construit la valeur d’une entreprise, qui crée les produits ? Ce sont bien les équipes. Une entreprise avec des équipes passionnées sera une entreprise à succès. Des équipes engagées et passionnées sauront créer un produit de valeur. Encore plus si elle utilise de bons processus. 2) Des logiciels opérationnels plus qu’une documentation exhaustive Ce qu’il faut comprendre ici, c’est que la documentation est essentielle. Pourtant, une équipe de développement devrait se concentrer sur la production de fonctionnalités et non sur la rédaction de documents. Avec les méthodes classiques, les chefs de projet peuvent passer des heures à mettre à jour des présentations ou des calendriers. La méthode Agile permet d’avoir des modèles de documents, qui sont toujours les mêmes, qui se complètent rapidement avec l’essentiel des informations. On trouvera deux sortes de documentation pour le développement Agile :  La documentation sur les exigences du produit telle que la vision produit, la roadmap produit, les besoins utilisateurs et les spécifications fonctionnelles.  Les spécifications techniques qui regroupent la documentation de type architecture (logicielle ou matérielle), les procédures d’installations etc. Les 4 valeurs de l'agilité: 3) La collaboration avec les clients plus que la négociation contractuelle La culture Agile demande de placer les utilisateurs au centre du processus de création de produit. Les intégrer à chaque itération, et donc à toutes les phases de développement, permet de récolter leurs retours. Les feedbacks sont un aspect essentiel de la construction de produits de valeur. Avec les méthodes traditionnelles de gestion de projet, le moindre changement budgétaire, fonctionnel ou dans les délais, nécessitent de revoir totalement le projet. Elles incitent à fortement négocier avec le client. Avec la méthode Agile, il est facile de faire des modifications dans un produit, La collaboration est simplifiée. 4) L’adaptation au changement plus que le suivi d’un plan La 4ieme valeur du manifeste agile est l'acceptation des demandes de changements même tard dans le développement du produit. Les approches agiles de planification et de hiérarchisation permettent aux équipes produit de réagir rapidement au changement. La flexibilité des approches agiles augmente la stabilité du projet. En effet, le changement dans les produits agiles est prévisible. Si de nouveaux événements adviennent, l’équipe produit intègre ces modifications dans les backlogs. Tout nouvel élément devient une possibilité d’apporter une valeur ajoutée au lieu d’un Les 12 principes de l'agilité: 1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. 2. 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. 3. Livrez fréquemment un logiciel fonctionnel, dans des cycles de quelques semaines à quelques mois, avec une préférence pour les plus courts. 4. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. 5. Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont elles ont besoin et faites-leur confiance pour atteindre les objectifs fixés. 6. 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. 7. Un logiciel fonctionnel est la principale mesure de progression d'un projet. 8. 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. 9. Une attention continue à l'excellence technique et à un bon design. 10. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle. 11. Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées. 12. À intervalles réguliers, l'équipe réfléchit aux moyens possibles de devenir plus efficace. Puis elle s'adapte et modifie son fonctionnement en conséquence Les 12 principes de l'agilité: Les 12 principes de l'agilité: des exemples concrets de la manière dont un produit Agile doit se construire. 1) Livrer de la valeur au client En raccourcissant le temps entre le cadrage et le début des développements, on raccourcit aussi le temps avant l’utilisation des fonctionnalités. Le fonctionnement en itérations permet de délivrer plus vite le produit aux utilisateurs. 2) Intégrer les demandes de changement Pour le Manifeste Agile, le changement n’est pas négatif. Il est même positif. Il vaut mieux se tromper tôt et de réparer ses erreurs rapidement que de se rendre compte trop tard que le chemin emprunté n’était pas le bon. 3) Livrer fréquemment une version opérationnelle Si vous souhaitez adopter le Manifeste Agile, vous devrez abandonner certaines mauvaises habitudes telles que graver un diagramme de Gantt pour une durée d’un an sur le marbre. Découper votre produit en petits morceaux et vos développements en itérations courtes de deux à trois semaines. À la fin de chaque itération, livrez les nouvelles fonctionnalités développées et testez-les. 4) Assurer une coopération entre le client et l’équipe Cela peut sembler difficile au premier abord. En effet, c’est comme si les deux parlaient deux langues différentes. Dans un sens, c’est le cas. Mais l’agilité permet de construire une sorte de pont entre les deux parties, leur permettant de se Les 12 principes de l'agilité: 5) Réaliser les projets avec des personnes motivées La confiance mutuelle est un point essentiel du Manifeste Agile. En d’autres termes, le management d’une équipe agile doit se baser sur la transparence. Le micro-management, ici, est à bannir. Contrôler étroitement une équipe de développeur ne va ni les engager, ni les motiver. L’agilité ne veut pas non plus dire aucun contrôle. Cela signifie qu’une équipe s’auto-organise. Dans une équipe agile, chacun a un rôle précis et le rôle de manager n’en fait pas partie. Il devra rester un peu à l’écart et s’appuyer sur les bons KPIs et les résultats des itérations pour mesurer le succès. 6) Privilégier le dialogue en face à face La rédaction de documentation, les résumés de réunions, les présentations prennent du temps et diminuent la productivité d’une équipe Agile. Il n’y a rien de plus efficace que d’avoir une équipe travaillant sur le même produit dans un même espace de travail. Les membres peuvent alors se poser directement les questions, obtenir les réponses dans la seconde. D’autant plus qu’en posant ses questions dans un open-space, sans même prêter attention, chaque membre aura conscience des problématiques que son voisin rencontre. 7) Mesurer l'avancement sur la base d'un produit opérationnel Vous ne mesurez pas les progrès en cochant les tâches et en vous déplaçant sur votre calendrier, mais par le taux d’utilisation des fonctionnalités par vos utilisateurs. L’objectif du produit n’est pas le processus, c’est sa valeur. Le processus est ce qui vous Les 12 principes de l'agilité: 8) Faire avancer le projet à un rythme soutenable et constant La raison de découper un produit en petites tâches est de garder vos équipes motivées. Si vous travaillez sur un projet pendant une longue période, vos équipes rencontreront une lassitude. C’est inévitable. Ne surchargez pas non plus l’équipe avec trop d’heures supplémentaires. Cela aura un impact sur la qualité de votre projet. 9) Contrôler l’excellence technique et à la conception Que ce soit dans le code ou dans la méthodologie, la rigueur va favoriser la construction d’un produit de valeur. Assurez-vous de bien respecter le Manifeste Agile. 10) Minimiser la quantité de travail inutile L’objectif est de produire rapidement un produit fonctionnel, il faut veiller à ne pas se noyer sous les tâches complexes et inutiles. Gardez vos documentations simples, ne vous embarrassez pas de réunions parasites. 11) Construire le projet avec des équipes auto-organisées Le Manifeste Agile favorise la responsabilisation des équipes. Il est conseillé de donner aux équipes l’autonomie d’agir de manière indépendante. Ils pourront alors prendre des décisions rapidement en cas d’imprévus. En fait, ils peuvent tout faire avec une plus grande agilité parce que vous leur avez donné la confiance nécessaire pour agir. Une équipe responsabilisée est une équipe qui fera de son mieux pour atteindre son objectif. 12) Améliorer constamment l'efficacité de l'équipe À intervalles réguliers, l'équipe réfléchit aux moyens possibles de devenir plus efficace. Puis elle s'adapte et modifie son Le pyramide Agile: frameWork Scrum Scrum ? C'est en 2010 qu'est née la première version du guide Scrum. Depuis lors, Ken Schwaber & Jeff Sutherland ont écrit pas moins de 6 versions de ce guide. La toute dernière version a été éditée en Novembre 2020. Elle est d'ailleurs gratuitement accessible sur le site officiel de Scrum.org. Chaque nouvelle édition est le reflet de la mise en pratique de ce cadre de travail : simplification, valeur ajoutée, amélioration. l'intention de la méthodologie est de proposer une manière de faire, d'accompagner les équipes projets vers plus d'Agilité. Le menu se repose sur le manifeste agile et Les ingrédients seraient essentiellement les composantes du cadre Scrum ( les rôles, les évènements et les artefacts) Scrum ? D’après Le Guide Scrum, une définition de la méthodologie Scrum est un cadre de travail léger qui aide les personnes, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes. Scrum repose sur l'intelligence collective des personnes qui l'utilisent. Plutôt que de fournir aux gens des instructions détaillées, les règles de Scrum guident leurs relations et leurs interactions. Scrum est fondé sur l'empirisme et la pensée Lean. L'empirisme affirme que la connaissance provient de l'expérience et que la prise de décision s’appuie sur l’observation de faits. La pensée Lean réduit le gaspillage et se focalise sur l'essentiel les piliers empiriques de Scrum: Inspection Les artefacts Scrum et les progrès vers les objectifs convenus doivent être inspectés fréquemment et avec diligence pour détecter des écarts ou des problèmes potentiellement indésirables. Pour faciliter l'inspection, Scrum fournit une cadence sous la forme de ses cinq événements Si Adaptation certains aspects d'un processus s'écartent des limites Transparence Le processus et le travail émergents acceptables ou si le produit doivent être visibles pour ceux qui effectuent le résultant est inacceptable, travail ainsi que pour ceux qui le reçoivent. Avec alors le processus appliqué ou Scrum, les décisions importantes sont fondées sur les éléments produits doivent l'état perçu de ses trois artefacts formels. Des être adaptés. L'adaptation doit artefacts peu transparents peuvent mener à des être effectuée le plus décisions qui diminuent la valeur et augmentent les rapidement possible afin de risques. minimiser tout écart Valeurs Scrum L'application réussie de Scrum dépend de la capacité des personnes à mieux vivre ces cinq valeurs : Engagement, Focus, Ouverture, Respect et Courage La Scrum Team s'engage à atteindre ses objectifs et à se soutenir mutuellement. Le focus sur, le but principal, la réalisation du Sprint pour progresser le plus possible vers ces objectifs. La Scrum Team et ses parties prenantes sont ouvertes sur le travail et les défis à relever. Les membres de la Scrum Team se respectent mutuellement pour être des personnes compétentes et indépendantes et, sont respectés en tant que tels par les personnes avec lesquelles ils travaillent. Les membres de la Scrum Team ont le courage de mener les bonnes actions et de travailler sur des problèmes difficiles. Ces valeurs orientent le travail, les actions et l’attitude de la Scrum Team. Les décisions et les mesures prises, ainsi que la façon dont Scrum est utilisé, doivent renforcer ces valeurs, ne pas les diminuer ni les saper. Les membres de la Scrum Team apprennent et explorent ces valeurs tout en travaillant avec les événements et les artefacts Scrum.  Lorsque ces valeurs sont incarnées par la Scrum Team et les personnes avec Scrum ? Scrum Team L’unité fondamentale de Scrum est une petite équipe, la Scrum Team. La Scrum Team se compose d'un Scrum Master, d'un Product Owner et de Developers. Il n’y a pas d’équipe dans l’équipe ni de hiérarchies. Il s'agit d’une seule et même unité stable, composée de professionnels focalisés sur un seul objectif à la fois, l'Objectif de Produit. Les Scrum Teams sont pluridisciplinaires, leurs membres ont toutes les compétences nécessaires pour créer de la valeur à chaque Sprint. Elles sont également autogérées, elles décident en interne qui fait quoi, quand et comment. La Scrum Team doit être suffisamment petite pour rester réactive et assez grande pour accomplir un travail significatif durant le Sprint, habituellement dix personnes au plus. En général, les petites équipes communiquent mieux et sont plus productives. Si les Scrum Teams deviennent trop grandes, elles devraient envisager de se réorganiser en plusieurs Scrum Teams cohérentes, chacune axée sur le même produit. Par conséquent, elles doivent partager le même Objectif de Produit, le même Product Backlog et le même Product Owner. La Scrum Team est responsable de toutes les activités liées au produit : collaboration des parties prenantes, vérification, maintenance, exploitation, expérimentation, recherche et développement, ainsi que tout ce qui pourrait être nécessaire. Elles sont structurées et habilitées par l'organisation à gérer leur propre travail. Travailler sur des Sprints à un rythme soutenable améliore le focus et la cohérence de la Scrum Team. Toute la Scrum Team est responsable de la création d'un Increment qui ait de la valeur et Developers Les Developers sont les membres de la Scrum Team qui s'engagent à traiter tout ou partie utile d’un Increment à chaque Sprint. Les compétences spécifiques requises pour les Developerssont souvent larges et varient selon le domaine d’activité. Toutefois, les Developers sont toujours redevables de : Créer un plan de Sprint, un Sprint Backlog ; Inculquer la notion de qualité en adhérant à une Definition of Done ; Adapter leur plan chaque jour par rapport à l'Objectif de Sprint ; Se tenir mutuellement responsables en tant que professionnels Product Owner Le Product Owner est redevable de maximiser la valeur du produit résultant du travail de la Scrum Team. La manière de procéder peut varier considérablement selon les organisations, les Scrum Teams et les individus. Le Product Owner est également redevable de la gestion efficace du Product Backlog. Ce qui inclut : Formuler et communiquer explicitement l'Objectif de Produit ; Créer et communiquer clairement les éléments du Product Backlog ; Ordonner les éléments dans le Product Backlog ; et S'assurer que le Product Backlog est transparent, visible et compris. Le Product Owner peut effectuer le travail ci‐dessus ou peut déléguer ce travail à d'autres. Quoi qu’il en soit, le Product Owner en demeure redevable. Pour que les Product Owners réussissent, toute l'organisation doit respecter leurs décisions. Ces décisions sont visibles dans le contenu et dans l'ordre du Product Backlog et, via un Increment inspectable lors de la Sprint Review. Le Product Owner est une personne et non un comité. Le Product Owner peut représenter les besoins de nombreuses parties prenantes dans le Product Backlog. Ceux qui souhaitent modifier le Product Backlog peuvent le faire en essayant de convaincre le Product Owner Scrum Master Le Scrum Master est redevable de la mise en place de Scrum tel que défini dans le Guide Scrum. Pour ce faire, il se doit d’aider tout un chacun, l’équipe et l’organisation à comprendre la théorie et la pratique Scrum. Le Scrum Master est redevable de l’efficacité de la Scrum Team. Il permet à la Scrum Team d'améliorer ses pratiques en suivant le cadre de travail Scrum. Le Scrum Master est, avant tout, un véritable leader au service de la Scrum Team et de l'ensemble de l'organisation. Le Scrum Master rend service à la Scrum Team de plusieurs façons : Accompagner les membres de l'équipe en matière d'autogestion et de pluridisciplinarité ; Aider la Scrum Team à se focaliser sur la création d'Increments de grande valeur qui répondent à la Definition of Done ; Faire en sorte qu’il n’y ait pas d’obstacles pouvant entraver la progression de la Scrum Team ; et S'assurer que tous les événements Scrum ont bien lieu et sont efficients, productifs et respectent bien les temps impartis (timeboxés : gardés dans une boîte de temps). Scrum Master Le Scrum Master rend service au Product Owner de plusieurs façons : L’aider à trouver des techniques pour définir efficacement l'Objectif de Produit et gérer efficacement du Product Backlog ; Sensibiliser la Scrum Team à la nécessité de bien comprendre le besoin d’avoir des éléments du Product Backlog clairs et concis ; Encourager l’application de la planification produit empirique dans un environnement complexe ; et Faciliter la collaboration des parties prenantes, selon les demandes ou les besoins. Le Scrum Master rend service à l'organisation de plusieurs façons : Accompagner, former et encadrer l'organisation dans son adoption de Scrum ; Planifier et apporter conseils sur les implémentations de Scrum au sein de l’organisation ; Faciliter la compréhension de l’approche empirique en environnement complexe des employés et des parties prenantes ; et Contribuer à lever les obstacles qui peuvent se dresser entre les parties Événements Scrum  Le Sprint est un conteneur pour tous les autres événements.  Chaque événement dans Scrum est une occasion formelle pour inspecter et adapter les artefacts Scrum. Ces événements sont spécifiquement conçus pour permettre la transparence requise. L’incapacité d’organiser les évènements conformément à leur prescription est une occasion perdue pour inspecter et s’adapter.  Les événements sont utilisés dans Scrum dans le but de créer de la régularité, minimisant le besoin d’avoir d’autres réunions non définies par Scrum.  Idéalement, tous les événements se Sprint Les Sprints sont au cœur de Scrum, où les idées sont transformées en valeur. Ce sont des événements d'une durée fixe, d'un mois ou moins, pour créer une cohérence. Un nouveau Sprint commence immédiatement après la fin du précédent. Durant le Sprint : Aucun changement n’est permis, qui pourrait remettre en cause l’Objectif de Sprint ; Les objectifs de qualité ne sont jamais revus à la baisse ; Le Product Backlog est affiné si nécessaire ; et Le périmètre peut être clarifié et renégocié avec le Product Owner selon ce qu'on en apprend  Tout le travail nécessaire pour atteindre l'Objectif de Produit, y compris le Sprint Planning, les Daily Scrums, la Sprint Review et la Sprint Retrospective, se fait dans le cadre des Sprints.  Diverses pratiques existent pour évaluer la progression, telles que les courbes du « burn‐down », ou celles du « burn‐up » ou les diagrammes de flux cumulatifs. Bien que leur utilité soit prouvée, ces courbes ne remplacent pas Sprint Planning Le Sprint Planning lance le Sprint en présentant le travail à effectuer durant le Sprint. Le plan qui en résulte est créé par le travail collaboratif de toute la Scrum Team. Le Product Owner veille à ce que les participants soient prêts à discuter les éléments les plus importants du Product Backlog et de comment ces éléments représentent l'Objectif de Produit. La Scrum Team peut également inviter d'autres personnes à participer au Sprint Planning pour donner des conseils. Le Sprint Planning aborde les thèmes suivants : Thème 1 : Pourquoi ce Sprint est‐il important ? Thème 2 : Que peut‐on faire durant ce Sprint ? Thème 3 : Comment le travail choisi sera‐t‐il réalisé ? Daily Scrum L'objectif du Daily Scrum est d'inspecter la progression vers l'Objectif de Sprint et d'adapter le Sprint Backlog si nécessaire, en ajustant les futurs travaux planifiés. Le Daily Scrum est un événement de 15 minutes, pour les Developers de la Scrum Team. Pour réduire la complexité, il est tenu à la même heure et au même lieu, chaque jour ouvré du Sprint. Si le Product Owner et / ou le Scrum Master travaillent activement sur des éléments du Sprint Backlog, ils participent en tant que Developers. Les Developers peuvent choisir la structure et les techniques qu’ils souhaitent, à condition que leur Daily Scrum se focalise sur la progression vers l'Objectif de Sprint et produise un plan d'action pour la prochaine journée de travail. Cela leur permet de se focaliser et d'améliorer l'autogestion. Les Daily Scrums améliorent la communication, aident à identifier les obstacles, favorisent la prise de décision rapide et, par conséquent, éliminent la nécessité de faire d'autres réunions. Le Daily Scrum n'est pas le seul moment où les Developers sont autorisés à ajuster leur plan. Ils se réunissent souvent tout au long de la journée pour des discussions plus détaillées sur l’adaptation ou la re‐planification du reste du travail du Sprint. Sprint Review L'objectif de la Sprint Review est d'inspecter le résultat du Sprint et de déterminer les adaptations futures. La Scrum Team présente les résultats de son travail aux principales parties prenantes et les progressions vers l'Objectif de Produit sont discutées. Pendant l'événement, la Scrum Team et les parties prenantes passent en revue ce qui a été accompli durant le Sprint et ce qui a changé dans leur environnement. Sur la base de ces informations, les participants collaborent sur la marche à suivre et sur les décisions à prendre. Le Product Backlog peut également être ajusté pour répondre à de nouvelles opportunités. La Sprint Review est une session de travail et la Scrum Team doit éviter de la limiter à une session de présentation. La Sprint Review est l'avant‐dernier événement du Sprint et se limite dans le temps à un maximum de quatre heures pour un Sprint d'un mois. Pour les Sprints plus courts, l'événement est généralement plus court Sprint Retrospective L'objectif de la Sprint Retrospective consiste à réfléchir à des pistes pour améliorer la qualité et l'efficacité. La Scrum Team inspecte le déroulement du dernier Sprint en ce qui concerne les individus, les interactions, les processus, les outils et leur Definition of Done. Les éléments inspectés varient souvent selon le domaine d’activité. Les hypothèses qui les ont fait dévier sont identifiées et leurs origines explorées. La Scrum Team discute de ce qui s'est bien passé durant le Sprint, des problèmes rencontrés et de la manière dont ces problèmes ont été (ou n'ont pas été) résolus. La Scrum Team identifie les changements les plus utiles pour améliorer son efficacité. Les améliorations ayant le plus d'impact sont abordées dès que possible. Elles peuvent même être ajoutées au Sprint Backlog pour le prochain Sprint. La Sprint Retrospective conclut le Sprint. Elle est limitée dans le temps à un maximum de trois heures pour un Sprint d'un mois. Pour les Sprints plus courts, l'événement est généralement plus court. Les Artefacts de Scrum Les artefacts de Scrum représentent un travail ou une valeur. Ils sont conçus pour maximiser la transparence des informations clés. Ainsi, tous ceux qui les inspectent ont la même base d'adaptation. Chaque artefact contient un engagement qui apporte l’information nécessaire à la transparence et au focus rendant possible la mesure de la progression : Pour le Product Backlog, il s'agit de l'Objectif de Produit. Pour le Sprint Backlog, c'est l'Objectif de Sprint. Pour l'Increment, c'est la Definition of Done (définition de Fini). Ces engagements existent pour renforcer l'empirisme et les valeurs Scrum au sein de la Scrum Team etses parties prenantes Product Backlog Le Product Backlog est une liste ordonnée et émergente de ce qui est nécessaire pour améliorer le produit. C'est l’unique source du travail entrepris par la Scrum Team. Les éléments du Product Backlog qui sont susceptibles d’être réalisés dans un seul Sprint par la Scrum Team sont considérés comme prêts à être traités en Sprint Planning. Ils acquièrent généralement ce degré de transparence après avoir été affinés. L'affinement du Product Backlog consiste à décomposer et à définir davantage les éléments du Backlog en éléments plus fins et plus précis. Il s'agit d'une activité continue visant à ajouter des détails, tels qu'une description, un ordre et une taille. Les attributs varient souvent en fonction du domaine d’activité. Les Developers qui effectueront le travailsont responsables du dimensionnement. Le Product Owner peut influencer les Developers en clarifiant ses explications et les aider à trouver des compromis. Engagement : Objectif de Produit L'Objectif de Produit décrit un état futur du produit qui peut servir de cible à la Scrum Team pour planifier. L'Objectif de Produit est dans le Product Backlog. Le reste du Product Backlog émerge pour définir « ce qui » permettra d'atteindre l'Objectif de Produit. Un produit est un vecteur de valeur. Il a une limite claire, des parties prenantes connues, des utilisateurs ou des clients bien définis. Un produit peut être un service, un  L'Objectif de Sprint, les éléments du Product Sprint Backlog Backlog sélectionnés pour le Sprint, ainsi que le plan pour les livrer, correspondent à un ensemble appelé le Sprint Backlog Le Sprint Backlog est composé de l'Objectif de Sprint (le « pourquoi »), de l'ensemble des éléments du Product Backlog choisis pour le Sprint (le « quoi »), ainsi que d'un plan d'action pour la réalisation de l'Increment (le « comment »). Le Sprint Backlog est un plan élaboré par et pour les Developers. Il s'agit d'une image très visible et en temps réel du travail que les Developers prévoient d'accomplir durant le Sprint afin d'atteindre l'Objectif de Sprint. Par conséquent, le Sprint Backlog est mis à jourtout au long du Sprintselon ce qu'on en apprend. Il devrait être suffisamment détaillé pour que les Developers puissent inspecter leur progression durant le Daily Scrum. Engagement : Objectif de Sprint L'Objectif de Sprint est l’unique but du Sprint. Bien que l'Objectif de Sprint soit un engagement fait par les Developers, il offre une certaine flexibilité en termes de travail nécessaire pour atteindre cet objectif. L'Objectif de Sprint crée également de la cohérence et du focus, tout en encourageant la Scrum Team à travailler ensemble plutôt que sur des initiatives séparées. L'Objectif de Sprint est créé pendant l'événement de Sprint Planning, puis ajouté au Sprint Backlog. Lorsque les Developers travaillent pendant le Sprint, ils Increment Un Increment est une première étape concrète vers l'Objectif de Produit. Chaque Increment s'ajoute à tous les Increments précédents et fait l'objet d'une vérification approfondie, ce qui garantit que tous les Increments fonctionnent ensemble. Afin de fournir une valeur, l'Increment doit être utilisable. Plusieurs Increments peuvent être créés durant un Sprint. La somme des Increments est présentée lors de la Sprint Review, ce qui permet de démontrer l’utilité de l'empirisme. Toutefois, un Increment peut être livré aux parties prenantes avant la fin du Sprint. La Sprint Review ne doit jamais être considérée comme le seul moment pour délivrer de la valeur. Un travail qui ne remplirait pas les conditions de la Definition of Done ne peut pas être considéré comme un Increment. Engagement : Definition of Done (Définition de Fini) La Definition of Done (Définition de Fini) est une description formelle de l'état de l'Increment lorsqu'il satisfait les mesures de qualité requises pour le produit. Dès qu’un élément du Product Backlog satisfait à la Definition of Done, il se transforme en Increment. La Definition of Done apporte de la transparence en permettant à chacun une compréhension commune du travail Fini dans le cadre de l'Increment. Si un élément du Product Backlog n’est pas conforme à la Definition of Done, il ne peut pas être publié ni même présenté lors de la Sprint Review. Il est alorsrenvoyé au Product Backlog pour être pris en compte ultérieurement. 13 Si la Definition of Done pour un Increment fait partie des standards de l'organisation, toutes les Scrum Teams doivent Annexes Backlog, Métriques scrum le backlog: Avec Scrum, la démarche est fondamentalement différente : les spécifications émergent progressivement par une collaboration continue entre les membres de l’équipe et le Product Owner, et grâce aux feedbacks réguliers donnés par les parties prenantes. L’outil de collecte et de partage s’appelle le backlog. En première approche, un backlog est simplement une liste ordonnée des choses à faire par l’équipe Le backlog indique l’ordre dans lequel seront réalisés les éléments qu’il contient. Priorité ordinale Dans un backlog, les éléments sont rangés selon l’ordre envisagé pour leur réalisation. Cette notion de priorité ordinale, qui n’est pas usuelle dans les documents de spécification, est adaptée au développement itératif : l’ordre est celui de réalisation. Critères pour définir l’ordre: Les méthodes agiles ont pour but de maximiser la valeur. La notion de valeur va donc être un critère majeur pour définir l’ordre. La valeur donne une idée de combien ça va « rapporter » aux parties prenantes. Combien ça va « coûter » en développement est aussi un critère important. Pour définir l’ordre d’un élément par rapport à un autre, l’idée est de maximiser la valeur rapportée au coût, en tenant compte des dépendances.  Le backlog n’est pas figé, il n’est jamais complet ou fini tant que vit le produit. Il est élaboré dans une forme initiale pendant le sprint zéro, puis il évolue constamment : des éléments sont ajoutés, d’autres sont supprimés, certains sont décomposés et l’ordre ajusté. Ce changement continuel n’a pas d’impact immédiat sur les réalisations en cours ; pendant un sprint, la partie du backlog sur laquelle l’équipe travaille n’est pas modifiable la story, feature et EPIC Une user story est un petit morceau de fonctionnalité visible d’un utilisateur et qui doit être développé en un sprint. Dans la vie de la story, le moment structurant est le sprint, c’est pourquoi son contenu est vérifié au départ et à l’arrivée de ce sprint. Pour que la story prenne le départ avec de bonnes chances d’arriver au bout du sprint, l’équipe doit s’assurer qu’elle est prête. Les vérifications à faire sont listées dans la définition de prêt. Une story commencée est normalement finie avant la fin du sprint. Sa définition de fini liste les points à vérifier pour s’en assurer. Une feature est un service ou une fonction d’un produit dont l’énoncé est clair pour les parties prenantes ; une feature contribue à un impact et se décompose en stories. Une feature n’est pas rythmée par le sprint comme la story. Elle peut être non finie à la fin d’un sprint. En revanche, elle doit être finie à la fin de la release, au plus tard. Une feature sera réalisée par plusieurs stories. On pourrait la mettre dans le même backlog que les stories, mais, en général, il est préférable de les mettre ailleurs, pour y voir plus clair. L’epic (ou story épique) est une story dont l’équipe considère qu’elle ne peut pas entrer dans un sprint en l’état. Elle ne peut pas passer au statut « prête ». La raison pour laquelle une story est épique, c’est qu’elle est trop grosse. C’est aussi le cas quand elle est mal connue, car on ne sait pas encore ce qu’elle cache. Une story épique doit donc être décomposée ou étudiée : elle a besoin d’affinage. La story épique cohabite avec la story élémentaire dans le backlog. Une fois décomposée, elle disparaît. Son usage est optionnel, il est utile pour identifier clairement le travail de décomposition à faire et pour limiter le nombre d’éléments. Le backlog, C’est l’élément pivot d’un développement avec Scrum, qui permet de définir le produit et de faire la planification. C’est une liste unique des choses à faire, ordonnée, est au cœur de la mécanique de mise en œuvre de Scrum lors des sprints. Le backlog de produit contribue beaucoup à l’élégance et à la simplicité du cadre de développement que constitue Scrum. La structure du backlog se base sur trois notions : la hiérarchie des éléments (feature, story), la vie de ces éléments représentée avec les bacs et leur type, selon les parties prenantes auxquelles ils apportent de la valeur L’affinage est une pratique qui permet de conserver un backlog prêt à l’emploi, avec des stories prêtes. La définition de prêt permet d’affermir la confiance de l’équipe à finir une story dans un sprint. Elle se base sur des vérifications, par exemple les « 6D ». L’affinage se pratique en équipe, lors des réunions d’affinage du backlog, avec des conversations sur les stories. Il a lieu pendant un sprint et influence le contenu des sprints suivants. Il consiste à détailler, décomposer, ordonner, approvisionner, estimer et purger.  WF du story: En 2001, Ron Jeffries définissait la vie de la story avec trois phases : la carte comme moyen de l’identifier, puis une conversation et enfin une confirmation. Cela est connu comme les « 3C ». En fait, l’équipe déroule deux cycles de conversation et confirmation : un premier pour obtenir une story prête, un second pour qu’elle soit finie : 1- Un jour, quelqu’un a une idée de story et la note sur une Carte (maintenant on utilise plutôt un Post-it®). 2- Le Product Owner et l’équipe affinent cette story, afin qu’elle puisse être réalisée en un sprint, au cours d’une Conversation. 3-L’équipe apporte sa Confirmation qu’elle est prête. 4- L’équipe réalise la story pendant un sprint, en tenant une nouvelle Conversation avec le PO, sur son acceptation. 5- Le Product Owner apporte sa Confirmation qu’elle est finie. Story Prête: C’est Finalement, l’équipe nous avonsqui décide donc si » « 5C une story dans la est vieprête. de la Pour prendre sa décision, elle story. pourra s’appuyer sur une liste de vérifications, qu’on appelle la définition de prêt. Vérifier les « 6D » La définition de prêt est élaborée par l’équipe et dépend du contexte. Une façon simple pour démarrer est de vérifier si la story est « 6D » : Décomposée : ce n’est plus une story épique. Débattue : elle a été discutée en équipe lors des séances d’affinage, au cours de conversations. Dérisquée : néologisme pour signifier que les risques sur cette story sont réduits. Done:Elle possède une définition de fini : pour qu’elle soit prête, c’est bien de savoir ce qui permettra de dire qu’elle est finie. Démontrable : on saura la montrer à la revue, lors de la démo. Désirable : pour être sûr que la story apporte de la valeur.  les métriques Scrum sont des points de données spécifiques que les équipes Scrum suivent et utilisent pour améliorer leur efficacité et destiné à elle seule.. Elles permettent de prendre des décisions plus éclairées, de gagner en efficacité dans la planification et l'exécution et de définir Lors de la mesure des des objectifs et des plans performances d'une d'amélioration. équipe Scrum, il est important de prendre en compte des métriques non liées à Scrum Métriques Mal utilisées, sont à l’origine d’une pression accrue sur l’équipe et sa démotivation. « ne doit pas être utilisée par le management » Une fois la vélocité agile stabilisée, il est donc possible de prévoir assez fidèlement le nombre de points d’effort que pourra réaliser l’équipe, et donc d’optimiser la sélection des US à réaliser durant le prochain sprint.