guide des principes & des processus agile · 2017-07-10 · logiciel à livrer dans le langage...
TRANSCRIPT
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