guide des principes & des processus agile · 2017-07-10 · logiciel à livrer dans le langage...

Rappelez-vous,

l’objectif n’est pas de suivre

un processus agile mais, de

livrer constamment un logiciel de

grande qualité que vos clients et

vos utilisateurs aimeront.

Un graphique de type burn xxx permet de rendre visibles lesprogrès dans le temps. Un graphique de burn down permet demontrer le travail restant, alors qu’un burn up montre le travailréalisé. L’observation de la pente de la courbe du graphiquepermet de détecter au plus tôt si nous sommes dans les clouspour terminer le travail prévu dans les temps.

Jour del’itération

Points de storydans le

périmètre

Points de storyréalisés

Points de storyrestants

1 21 1 20

2 21 3 18

3 21 6 15

4 24 8 16

5 24 9 15

6 24 11 13

7 19 11 8

8 18 13 5

9 18 15 3

10 18 17 1

Les données quotidiennes sontstockées dans une feuille de calcul

20

15

10

5

1 2 3 4 5 6 7 8 9 10

Stories ajoutées

Stories supprimées

Graphique de Burn Down25

20

15

10

5

1 2 3 4 5 6 7 8 9 10

Stories ajoutées

Stories supprimées

Graphique de Burn Up

Un mur de tâches estutilisé pour visualiser letravail en cours durant leprocessus du cycle dedéveloppement. Ledéplacement des notesadhésives sur le murpermet d’aider l’équipe àse coordonner, et àsignaler son avancementau sein et à l’extérieur del’équipe.

Storiesprésentesdans la file

Tâchesen cours

Storiesprêtespour larevue

Stories finies

Tous les jours, généralement au début dela journée, l’équipe se rencontre pour unebrève réunion de suivi. La durée de réuniondoit rester inférieure à 15 minutes.Focalisez la réunion sur ce qu’il estnécessaire de faire pour atteindre lesobjectifs de l’itération.

Chaque personne réfléchit sur :1. Ce qu’elle a fait la veille2. Ce qu’elle pense faire aujourd’hui3. Quels sont les problèmes qui

l’empêchent d’accomplir son travail

Stand-upquotidien

ou mêléequotidienne

Mur de tâches

Graphiquede suivi

Backlogs produit & User Stories

Le Manifeste Agile : Nous découvrons comment mieux développerdes logiciels par la pratique et en aidant lesautres à le faire.

Ces expériences nous ont amenés à valoriser :

Les individus et leurs interactionsplus que les processus et les outils

Des logiciels opérationnelsplus qu’une documentation exhaustive

La collaboration avec les clientsplus que la négociation contractuelle

L’adaptation au changementplus que le suivi d’un plan

Nous reconnaissons la valeur des secondséléments, mais privilégions les premiers (en gras).

Le manifeste, ses valeurs et ses principes sontconsultables sur : http://agilemanifesto.org/

Les principes du développement agile

8. Accueillez positivement leschangements de besoins, mêmetard dans le projet. Les processusAgiles exploitent le changement pourdonner un avantage compétitif auclient.

9. Livrez fréquemment un logicielopérationnel avec des cycles dequelques semaines à quelques moiset une préférence pour les pluscourts.

10. Les utilisateurs ou leursreprésentants et les développeurs doivent travailler ensemblequotidiennement tout au long duprojet.

11. Réalisez les projets avec despersonnes motivées. Fournissez-leur l’environnement et le soutiendont ils ont besoin et faites-leurconfiance pour atteindre les objectifsfixés.

12. La méthode la plus simple et la plusefficace pour transmettre del’information à l'équipe dedéveloppement et à l’intérieur decelle-ci est le dialogue en face àface.

1. Un logiciel opérationnel est laprincipale mesure d’avancement.

2. Les processus Agiles encouragent unrythme de développementsoutenable. Ensemble, lescommanditaires, les développeurs etles utilisateurs devraient êtrecapables de maintenir indéfinimentun rythme constant.

3. Une attention continue à l'excellencetechnique et à une bonne conceptionrenforce l’Agilité.

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

5. Les meilleures architectures,spécifications et conceptionsémergent d'équipes auto-organisées.

6. À intervalles réguliers, l'équiperéfléchit aux moyens de devenir plusefficace, puis règle et modifie soncomportement en conséquence.

7. Notre plus haute priorité est desatisfaire le client en livrant rapidement et régulièrement desfonctionnalités à grande valeurajoutée.

Les principes du développement agile de logiciel, écrits en même temps que leManifeste, énoncent des préceptes généraux pour nous guider dans nos choix dansnotre manière de travailler.

Suivi visuel

© 2015, Jeff Patton • jpattonassociates.com – Traduction : Nicolas MEREAUX – http://www.les-traducteurs-agiles.org

Tâchesliées à la

storyTâches

terminées

Développement Agile & Scrum Guide des principes & des processus

Processus & pratiquesDes valeurs comme « être capable de réagir rapidement au

changement » et des principes comme « l’excellencetechniques » sont secondées par des pratiques telles que le

développement piloté par les tests.Les processus combinent des pratiques qui s’entraident les unes

les autres et qui sont utilisées par les différents rôles.Les processus permettent d’aider les gens à coordonnerleurs activités en vue d’accomplir un objectif commun.

Votre contexte Le processus que vous suivez doit prendre en comptevotre contexte● Combien de personnes sont impliquées ?● Quel est le degré de risque du projet ?● Quel est le degré de sensibilité au regard du délai de

la livraison ?● Quel est le degré de difficulté du problème que vous

avez à résoudre ?● Que signifie la qualité dans votre contexte ?

Nouveaux savoirsNous continuons à découvrir de nouveaux concepts etnous les mettons à profit pour créer de nouveaux, demeilleurs outils et pratiques. Par exemple :● Le débit maximal d’un système correspond à son

étape la plus longue, par conséquent, nous utilisonsdes tableaux de suivi de type Kanban pour visualiserle flux de travail et trouver les goulots d’étranglementsplus rapidement.

● Les idées restent des hypothèses jusqu’à après leurlivraison, nous utilisons par conséquent des testsavec des PVM pour valider ces idées de produitsavant de livrer.

Les user stories décrivent des morceaux dulogiciel à livrer dans le langage de la personnequi va utiliser le logiciel. Un titre brefrésumant l’histoire est écrit sur une fichecartonnée, une note adhésive, ou sur une listecomme s’il s’agissait d’un signal de rappeld’une conversation. Les stories sont diviséesen stories plus petites, et s’enrichissent dedétails supplémentaires avec le temps et avecles conversations faites avec lescontributeurs des différents rôles concernés. Au minimum, une story nécessite :● Un titre concis● Une description● Des critères d’acceptation Ce modèle très connu nous aide à considérerles stories d’un point de vue utilisateur et desbénéfices qu’il est censé en retirer : en tant que [un type d’utilisateur] je veux [accomplir une certaine action] afin que je puisse [atteindre un certain objectif]

Utilisez ce modèle comme d’un outilde réflexion, pas comme d’un formatd’écriture.

Les stories n’ayant pas un titreconcis sont difficiles à organiser,discuter et prioriser.

Réfléchissez à qui utilisera lelogiciel, qu’est-ce qu’il fera avec(quoi) et pourquoi.

Capacités oufonctionnalités

● Nom● Client ou utilisateur cible● Valeur

Tailles acceptables destories pour une version● Ciblées pour une version donnée● Taille relative● Maquettes IHM● Tests d’acceptations à grosse maille

Stories pour lesitérations à venir

● Priorité● Conception IHM● Règles métiers● Tests d’acceptations

Petites stories tailléespour une itération● Tests d’acceptations détaillés● Suffisamment petites pour

pouvoir être réalisées en uneseule itération

Logiciel opérationneltesté

 ● En accord avec la définitionde fini énoncée par l’équipe

Partie validée du produit

Logicielminimal livrable

 ● Il génère de lavaleur dès lorsqu’il est utilisé

cycle de laversion

Organiser les user storiessous la forme d’une carte

Organisez les grosses fonctionnalitésgrosso modo dans l’ordre d’utilisationdes utilisateurs. Décomposez-les de

haut en bas. Cela rend le backlog plusfacile à comprendre et à prioriser.

Le risque de l’approche en cascadeDans un article de 1970, Winston Royce est crédité pouravoir esquisser le modèle auquel nous faisonscommunément référence sous le nom de « modèle encascade ». Mais il a esquissé ce diagramme comme uneétape vers des modèles plus sophistiqués. Il fit remarquerque vous devriez avoir des boucles de retoursd’informations entre chaque phase ainsi qu’un retourd’informations qui remontent des tests jusqu’aux exigences.Royce était en train d’essayer de démontrer un cycle dedéveloppement itératif et NON un processus séquentiel.

« Je crois à concept, mais son implémentation telleque décrite ci-dessus est risquée et est uneinvitation à l’échec. » --Royce

Il n’y a rien de nouveau avec le développement agileLes origines du concept d’agilité sont aussi anciennes que le développement logiciel. Ce quenous appelons « Développement Agile » est une expression contemporaine appliquée à un stylede processus qui a commencé dans les années 1970.

Davantage comme une équipesportive, moins comme une chaînede fabrication En 1986 dans un article intitulé « The New New ProductDevelopment Game », Takeuchi et Nonaka ont étudiéplusieurs équipes de conceptions produits et ont trouvé quela meilleure équipe avait modifié un processus qui pouvaitsembler chaotique de l’extérieur mais qui était incomparablepour sa vitesse et son efficacité à créer de super produits.Ils ont comparé la manière de travailler de ces équipes à lapratique du rugby. « Dans l’approche du rugby, le processus dedéveloppement du produit émerge de l’interactionconstante d’une poignée de personnes formant uneéquipe pluridisciplinaire dont les membrestravaillent ensemble du début à la fin. » – Takeuchi& Nonaka

Scrum

Crystal

FDD (Feature Driven Development)

Extreme Programming

Adaptive Software Development

DSDM (Dynamic Systems

Development Methodology)

Lean Software Development

agile Agile est un style de processus et un terme

fourre-tout pour un ensemble de processus différents

“Agile” met en avant des valeurset des principes spécifiques

En 2001, 17 professionnels en informatique se sontrassemblés pour discuter de ce qu’ils avaient en commun.

Ils s’inquiétaient de l’importance croissante du style trèsformalisé de la gestion de projets en cascade. Ces

professionnels ne se mirent pas d’accord sur unprocessus spécifique mais se mirent d’accord sur des

valeurs et des principes qui sous-tendent la création deprocessus.

Scrum était l’un de ces processus agiles. Aujourd’hui

Scrum a gagné en popularité. Même si les équipes disentque leur processus est Scrum. Leurs manières de

travailler empruntent des pratiques issues de plusieursprocessus agiles.

Le manifeste agile décrit les valeurs et lesprincipes guidant le processus de décision.

Guide des valeurs, principes & processus

Valeurs & principes

Les Valeurs décrivent ce qui est importantindividuellement pour les personnes et collectivement pour

les organisations.

Les Principes sont des règles empiriques que nouscréons et que nous avons l’habitude d’utiliser lors de nos

processus de décisions quotidiens.

Le nom de Scr

um

est tiré d

e cet

article !

itération

Grosse fonctionnalité

Étape utilisateur

Les plus petits éléments :●Petites étapes●Détails IHM●Détails techniques

Boucle de retourd’informations destests jusqu’auxexigences

Bouclesde retourd’infor-mations

entre lesphases

Exigence

Concept°

Déploie-ment

Séquen-tiel

La plupart desphases sechevauchent &

courent surune pluslongue durée

Chevauchement

● Après enquête approfondie menée auprès desparties prenantes, des clients et des utilisateurs

● Vérification des conditions permettantdéterminer si la livraison est possible

Rôles

Processus

Scrum Master ou CoachLe scrum master se focalise sur la réussitedu processus

Le Scrum Master se focalise sur le respect du bonfonctionnement du processus, et s’assure que chacunpuisse comprendre et remplir son rôle, qu’il y ait unecollaboration efficace, que la transparence demeureélevée, et que l’équipe reste focalisée sur les objectifsdu sprint, de l’itération ou de la livraison du produit en cours.

Trois grands rôles existent dans les processus Agile et Scrumafin de répondre aux difficultés de faire le bon produit, de bien lefaire et d’ajuster le processus pour que les personnes puissenttravailler de leur mieux. Les rôles existants dans ledéveloppement traditionnel de logiciels peuvent correspondre àun ou à plusieurs des grands rôles décrits ici.

Rappelez-vous ces rôles représentent des responsabilitéspartagées par chacun d’entre nous et non par des individusen tant que tel. Dans les équipes agiles matures, lespersonnes passent d’un rôle à un autre comme on peutchanger de chemise.

Appropriationdu produit

Faire le bonproduit

Équipe Bien faire le

produit

Scrum Master Apporte son aide à

quiconque et est garantdu bon fonctionnement du

processus

Scrum Master

Sprint Une période de temps fixe de 1 à 4 semaines engénéral pour livrer un morceau du logiciel

Mêlée quotidienneRéfléchissez sur ce que vous avez fait la veillePlanifiez ce que vous ferez aujourd’huiRemontez les problèmes qui vous empêche d’avancer

Jour Le plus petit cycle de

travail possible –impossible à rallonger

même si vous nefinissez pas tout ceque vous auriez pu

planifier

Incrément logicielpotentiellement livrablePlusieurs incréments seront peut êtreindispensables afin d’avoir quelque chosed’intéressant pour les utilisateurs, maissans qu’il soit nécessairement obligatoirequ’il y ait davantage de tests ou descorrections d’anomalies.

Revue de Sprint &RétrospectiveFaites la démonstration d’unProduit opérationnel et faites-en la critique. Discutez de son avancement par rapport au projet.Réfléchissez sur la manièredont vous avez travaillé (votreprocessus et changez-le sinécessaire)

Atelier de storiesLes membres de l’équipeproduit et de l’équipe delivraison se réunissentrégulièrement pour travaillersur le détail des stories et semettre d’accord sur lescritères d’acceptation.

Planification del’équipe produitL’équipe produit se réunitrégulièrement pour discuter del’avancement de la livraison, de lasélection des stories pour lessprints à venir et pour planifier letravail nécessaire à la préparationles stories pour l’équipe delivraison.

Validation duproduit par lesutilisateurs & lesclientsValidez de manièrerégulière le logicielopérationnel avec devrais clients et de vraisutilisateurs.

Suivi dulogiciel livréTrès régulièrement, jetezun coup d’oeil auxindicateurs, aux rapportsd’anomalies et auxretours d’informations desclients sur le logiciel quevous venez de livrer.

Revue duproduit par lespartiesprenantesRendez visiblel’avancement du produitaux parties prenantes endehors de l’équipe.

Backlog de sprint Liste des tâches de

livraison permettant detransformer les items du

backlog en logicielopérationnel

Planification de sprintLors de cet événement, le productowner vient avec les items qui sontprêts, détaillés et qui ont la priorité laplus élevée dans le backlog. L’équipe y élabore son planning ets’engage.

Backlogd’opportunités

Liste des idées àexplorer et des

problèmes à résoudre.Considérer la

feuille deroute de votreorganisation

non pascomme une

liste fixed’items à

livrer, maiscomme une

liste d’idées àexplorer et à

valider.

Backlog duproduitListe de morceauxlivrables d’unproduit ou d’uneexpérimentationque nous voudrionsque l’équiperéalise.

Découvertedu produit

À travers une étroite collaboration, l’utilisation du designthinking, et la validation des connaissances, vous pourrezalors répondre aux questions suivantes :1. Quels sont les problèmes que nous allons résoudre et pour

qui ?2. Qu’est ce qui pourrait avoir de la valeur aux yeux des

clients et des utilisateurs ?3. Que font les utilisateurs pour atteindre leurs objectifs ? 4. Qu’est-ce qui est faisable pour construire les outils

souhaités et de combien de temps disposons-nous ?

Le processus de démarrage ci-dessous s’appuie sur le cadre de travail même de Scrumet y ajoute des pratiques autour du sprint pour découvrir mieux encore le produit, pourfaire en sorte qu’il soit prêt, et prêt être livrer.

Rappelez-vous que processus n’est pas synonyme de compétence. La réussite oul’échec est entre les mains de l’équipe tout entière. Un bon processus donne justesuffisamment de structure aux équipes afin qu’elles puissent collaborer efficacement.

Un développement sur 2 axes Le travail de découverte se déroule simultanément au travail de développement.

Les opportunités pilotent ladécouverte Axe découverte

La durée des cycles de découverte estvariable. Ils commencent avec des

idées et s’achèvent par l’acquisitiond’un savoir. Plusieurs cycles de

découverte peuvent se dérouler en uneseule semaine.

Axe développementQuand vous travaillez en Scrum, vous

avez, toutes les 1 à 4 semaines, unelivraison prévisible d’un logiciel

opérationnel.

À l’issu d’un cycle dedécouverte, le backlogpeut se voir enrichitd’items voués à devenirdes sujets d’expéri-mentation ou à devenirdes logiciels à partentière.

Une livraison peut donnersoit des résultatsd’expérimentationutilisables soit deslogiciels bien livrables.

De l’appropriation du produitLes product owners se focalisent sur laréussite du produit

Une seule personne est amenée à avoir le titre de« product owner » mais avant tout le product owneridéal est un leader. Un produit réussi est un produitvalable, utilisable et faisable, un product owner mèneune petite équipe d’appropriation du produit qui doitavoir en son sein tous les rôles et toutes lescompétences pour bien réussir :● Responsable produit ou représentant

du métier● Concepteur UX● Ingénieur, architecte & testeur

L’équipe de livraisonL’équipe se focalise sur laréalisation d’un produit de grandequalité

L’équipe inclut tous les rôles et toutes lescompétences nécessaires pour réaliser, testeret documenter le logiciel avec une qualitésuffisante afin qu’il puisse être livré. Elle estcomposée de : ● Ingénieurs, ● Architectes, ● Testeurs,● Analystes métiers,● Concepteurs d’IHM,● Rédacteurs techniques

Burndown de sprintPermet de rendre visible l’avancement.Faisons-nous des progrès ?

Burndown de version Rend visible l’avancement de la version.Quelle quantité de choses reste t’il à faireavant que nous puissions livrer ?

Sprint Se préparerAfin d’aider l’équipe a réagir rapidement et a être en capacitéd’anticiper, votre équipe produit conduite par un product ownerdevra mieux comprendre et mieux décrire le détail de ce qu’il y aà réaliser.

● L’équipe produit planifie en identifiant des user stories 1 à 3itérations à l’avance. L’équipe produit identifie le travail qu’elledoit faire pour concevoir et décrire le logiciel à construire.

● Collaborer avec l’équipe à travers des ateliers pour bâtir unecompréhension mutuelle de ce qu’il y a à réaliser. Lesmembres de l’équipe produit et de l’équipe de livraisontravaillent ensemble pour répondre aux trois questionssuivantes : Qu’est-ce qui est à construire exactement ?Comment pourrons-nous savoir que nous avons terminé ?Comment pourrons-nous faire la démonstration du nouveaulogiciel aux autres ?

Travaillez ensemble afin d’explorer les détails etpour obtenir la description du logiciel que vousvoulez réalisez dans la prochaine période de temps.

Être prêt à publierL’équipe est sans doute confiante dans ce qu’elle vient de réalisermais nous devons valider avec les clients, les utilisateurs et lesparties prenantes. ● Donnez le logiciel à tester aux clients et aux utilisateurs. Est-il

valable ? Est-il utilisable ? ● Faites un suivi de l’avancement et des retours des utilisateurs

visibles des parties prenantes

Faites de la validation continue du logiciel avec lesclients, les utilisateurs,et les parties prenantes pouréviter les surprises au moment de la publication.

Découverte du produitÀ partir des éléments présents dans le backlog d’opportunités,faites donc un travail de découverte pour identifier le produit quevous devriez réaliser.

● Comprenez ce qui incite le métier à construire le produit● Comprenez les motivations des clients et des utilisateurs qui

utiliseront votre produit et comprenez les problèmes que votreproduit résoudra pour eux

● Faites preuve d’idéation : considérez les multiples solutionspour résoudre les problèmes de vos clients

● Construisez et testez de manière itérative des prototypes encollaboration étroite avec vos clients et vos utilisateurs

● Quand vous devrez faire votre travail de développement,basez-vous sur les items du backlog pour créer des prototypesle plus fidèle possible avec des données crédibles

● Décrivez votre solution qui a été validée en vous basant sur lesstories du backlog de produit, vous pourrez l’utiliser pour gérerla livraison de votre logiciel.

Travaillez ensemble afin d’explorer les détails etpour obtenir la description du logiciel que vousvoulez réalisez dans la prochaine période de temps.

Tirer les leçonsAprès la livraison, jetez donc un coup d’œil aux indicateurs, etobservez bien les personnes qui utilisent votre produit. Souvenez-vous que bien que votre projet soit fini, la vie de votre produit nefait que commencer.

Les améliorations les plus valables pour votreproduit proviennent de l’observation de l’utilisationqu’en font les gens.

Pendant que vous êtes enphase de découverte,

transformez les items debacklog en prototype grandeur

nature ou avec des donnéesmanipulables en prenant le

temps de développementnécessaire pour les créer.

Livraison d’un produit viableEn construisant à chaque sprint de manière itérative

et incrémentale, vous aurez le produit qui vouspermettra d’atteindre le dénouement souhaité pour

les utilisateurs ciblés.

Équipe de découverteIl s’agit d’une équipe composée d’individuspossédant la connaissance et lescompétences pour identifier un produitvalable, utilisable et faisable menée par unproduct owner.

Les personnes tels que les ingénieurs enchef peuvent faire partie à la fois del’équipe de découverte et de l’équipe delivraison

opportunités& Items dubacklog

items debacklogfractionnés etaffinés

backlogitems

opportunité

item dubacklog àtravailler

tâches de l’équipede découverte

Livraison du produitL’équipe de livraison produit lutte pour aboutir à des livraisons prévisibles et de très bonne qualité.

Tableau de tâches de l’équipe produitEst utilisé régulièrement pour planifier et re-planifier letravail de découverte et le travail pour préparer lesitems pour la livraison.

à faireen

cours terminéitems dubacklog

items dubacklogterminés

tâches del’équipe delivraison

Tableau de tâches del’équipe de livraison

Utilisez-le pourplanifier et re-planifier réguliè-rement le travailde livraison.

Artefacts Il s’agit de choses que nous pouvons voir et toucher. Les artefacts nousaident à rendre visible les informations, les idées et leurs statuts àl’ensemble de l’équipe. Les artefacts essentiels sont les backlogs, lesgraphiques de burndown, et les tableaux de tâches.

Si personne n’utilise les artéfacts, supprimez-les car il estprobable qu’ils ne donnent pas satisfaction.

Réaliserdes expériences

Mesurer& observer

Apprendresi votre solution est viable

La vitesse de ladécouverte est

mesurer par la duréedu cercle

d’apprentissage.Essayez donc

d’expérimenter etd’apprendre

plusieurs fois parsemaine.

à faire

en cours

ter-miné

(Itération ou période fixe de développement)Les itérations (les Sprints dans Scrum) sont de brèves périodesde temps fixe de 1 à 4 semaines généralement. À la fin dechaque itération, une démonstration d’un logiciel de bonnequalité, fini et testé est faite. Même s’il est essentiel d’obtenir unlogiciel de bonne qualité, ne vous attendez pas à ce qu’il soitlivrable après les toutes premières itérations. L’équipe planifie lesprint en partant du niveau de détails qu’elle a pu approfondir etqui sera nécessaire pour pouvoir réaliser quelque chose.

● L’équipe planifie le sprint en étudiant les informations détailléesdu produit qu’elle doit réaliser.

● Utiliser un mur d’informations ou un graphique de suivi pourmaintenir un niveau élevé de visibilité.

● Maintenir une visibilité élevé entre l’équipe produit et l’équipede livraison.

● À la fin de l’itération, faire une revue du produit pour évaluer leproduit et discuter du rythme de la livraison ou de la vélocité

● Faire une rétrospective du rythme cardiaque pour ajustervotre processus.

Utilisez les sprints pour réaliser le logiciel, mesureret apprendre. Utilisez ce que vous avez appris pouraméliorer votre produit, et la manière dont voustravaillez.

© 2015, Jeff Patton • jpattonassociates.com – Traduction : Nicolas MEREAUX – http://www.les-traducteurs-agiles.org