This page has been robot translated, sorry for typos if any. Original content here.

Comment expliquer à grand-mère ce qui est Agile en 15 minutes avec des images

Agile en 15 minutes avec des images
La grande image s'ouvrira en appuyant sur dans une nouvelle fenêtre!

Méthodologie de développement souple (Agile software development, agile-methods) est une série d'approches de développement de logiciel axées sur l'utilisation du développement itératif, la formation dynamique des exigences et la mise en œuvre de leur implémentation par des groupes de travail auto-organisés. Il existe plusieurs méthodes liées à la classe des méthodologies de développement flexibles, en particulier, la programmation extrême, DSDM, Scrum, FDD.

Il est utilisé comme une pratique efficace pour organiser le travail de petits groupes (qui font un travail créatif homogène) en combinant avec leur gestion une méthode combinée (libérale et démocratique). Les méthodologies les plus souples visent à minimiser les risques en amenant le développement à une série de cycles courts, appelés itérations, qui durent généralement deux à trois semaines. Chaque itération en elle-même ressemble à un projet logiciel en miniature et comprend toutes les tâches nécessaires pour fournir une mini-augmentation des fonctionnalités: planification, analyse des besoins, conception, programmation, tests et documentation. Bien qu'une seule itération ne soit généralement pas suffisante pour publier une nouvelle version du produit, il est entendu qu'un projet logiciel flexible est prêt à être publié à la fin de chaque itération. À la fin de chaque itération, l'équipe réévalue les priorités de développement.

Les méthodes agiles mettent l'accent sur la communication directe en face-à-face. La plupart des équipes agiles sont situées dans le même bureau, parfois appelé anglais. enclos. Au minimum, cela inclut également les «propriétaires de produits» (le client ou son représentant autorisé qui définit les exigences du produit, quel rôle peut être rempli par le chef de projet, l'analyste commercial ou le client). Le bureau peut également inclure des testeurs, des concepteurs d'interface, des rédacteurs techniques et des gestionnaires. La métrique principale des méthodes agiles est le produit de travail. Préférant la communication directe, les méthodes agiles réduisent la quantité de documentation écrite en comparaison avec d'autres méthodes. Cela a conduit à la critique de ces méthodes comme indisciplinés.

La vidéo la plus regardée sur YouTube sur agile. 744 625 vues au moment de la publication de cet article. Style de présentation facile, photos et seulement 15 minutes - le meilleur que j'ai vu. TED repose.

"Toute affaire dure toujours plus longtemps que prévu, même si l'on tient compte de la loi de Hofstadter." - La loi de Hofstadter

Rôles

Agile за 15 минут с картинками

C'est Pat, le propriétaire du produit. Elle ne connaît pas les détails techniques, mais elle a une vision de l'image globale, elle sait pourquoi nous fabriquons le produit, quels problèmes il va résoudre et pour qui.

Agile за 15 минут с картинками

Ce sont des personnes intéressées. Ils utiliseront le produit, le soutiendront ou participeront d'une manière ou d'une autre au développement.

Agile за 15 минут с картинками

Ce sont des histoires d'utilisateurs. Ils ont exprimé les voeux des personnes intéressées. Par exemple, "le système de réservation de la compagnie aérienne doit avoir une recherche de vols".

Agile за 15 минут с картинками

Les parties prenantes ont beaucoup d'idées et Pat aide à faire des histoires personnalisées à partir d'idées.

Agile за 15 минут с картинками

C'est l'équipe de développement. Ceux qui vont construire un système de travail.

Agile за 15 минут с картинками

Débit

Agile за 15 минут с картинками

Puisque l'équipe utilise une méthodologie de développement flexible, ils ne sauvegardent pas toutes ces histoires dans la grande version, au contraire, ils les libèrent immédiatement et aussi souvent que possible. Habituellement, ils publient 4-6 histoires d'utilisateurs par semaine. C'est leur bande passante. C'est très facile à mesurer - le nombre d'user stories en 7 jours.

Certaines histoires sont grandes, elles peuvent être comptées comme deux, d'autres sont petites, elles peuvent être comptées comme la moitié.

Afin de maintenir ce rythme et de ne pas s'enliser dans les tests de régression manuelle, l'équipe travaille dur sur les tests automatiques de l'intégration constante. Par conséquent, pour chaque fonctionnalité, vous devez écrire des autotests, et la majeure partie du code a des autotests intégrés.

Agile за 15 минут с картинками

Le problème est qu'il y a beaucoup de personnes intéressées et leurs demandes ne peuvent pas être satisfaites avec 4-6 histoires par semaine.

Chaque fois que nous mettons en œuvre une histoire personnalisée, ils ont quelques idées supplémentaires, à partir de laquelle plus de demandes suivent.

Que se passe-t-il si nous faisons tout ce qu'ils nous demandent? Nous aurons une surcharge.

Agile за 15 минут с картинками

Disons que l'équipe prendra 10 nouvelles histoires pour cette semaine, si à l'entrée 10 et à la sortie de 4-6, la commande sera surchargée. Il va se dépêcher, basculer entre les tâches, perdre la motivation, à la fin la productivité et la baisse de la qualité. C'est évidemment une stratégie perdante.

Scrum et XP dans ce cas utilisent la méthode "météo d'hier". L'équipe dit: "Dernièrement, nous avons fait 4 à 6 fonctionnalités par semaine, dont 4 à 6 fonctionnalités la semaine prochaine?"

La tâche du propriétaire du produit est de sélectionner avec compétence les user stories qui seront implémentées cette semaine.

Kanban vous recommande de vous limiter à plusieurs tâches - limite WIP. Supposons que l'équipe décide que 5 est un nombre acceptable d'histoires d'utilisateurs, sur lesquelles elles peuvent travailler simultanément sans surcharger, sans passer de l'une à l'autre.

Agile за 15 минут с картинками

Ces deux approches fonctionnent bien et créent une file d'attente de tâches, appelée Backlog dans Scrum, ou une liste de tâches prioritaires.

Cette file d'attente est également nécessaire pour gérer.Si les personnes intéressées demandent 10 histoires par semaine, et l'équipe implémente 4-6 histoires, alors cette file deviendra de plus en plus. Et bientôt votre Backlog sera peint pour six mois à venir. C'est-à-dire qu'une histoire attendra 6 mois.

Il n'y a qu'une seule façon de garder une liste de tâches sous contrôle - c'est le mot "non"

Agile за 15 минут с картинками

C'est le mot le plus important pour le propriétaire du produit. Il doit l'entraîner tous les jours devant le miroir.

Dire "oui" est facile. Mais une tâche plus importante consiste à décider ce qu'il ne faut pas faire et à en assumer la responsabilité. Le propriétaire du produit détermine également la séquence de ce que nous faisons maintenant, et ce qui se passe plus tard. C'est un travail difficile et cela devrait être fait avec l'équipe de développement et au moins une personne intéressée.

Agile за 15 минут с картинками

Afin de prioriser correctement, le propriétaire du produit doit comprendre la valeur de chaque histoire et sa portée.

Prise de décision

Certaines histoires sont extrêmement nécessaires et d'autres ne sont que des bonus. Le développement de certaines histoires prendra quelques heures, le développement d'autres mois.

Comment la taille de l'histoire est-elle en corrélation avec sa valeur? Pas moyen.

Cela ne veut pas dire mieux. La valeur et la complexité de la tâche sont ce qui aide Pat à hiérarchiser.

Comment le propriétaire du produit détermine-t-il la valeur et le volume de l'histoire? Pas moyen.

C'est un jeu de devinettes. Et il vaut mieux y participer. Pat communique constamment avec les parties prenantes pour connaître la valeur de chaque histoire, communique avec l'équipe de développement pour connaître la portée du travail, mais tout cela est approximatif, pas de chiffres exacts. Au début, il y aura toujours des ratés et c'est normal. La communication a beaucoup plus de valeur que des chiffres super précis.

Chaque fois que les développeurs publient quelque chose de nouveau, nous apprenons plus d'informations et pouvons mieux naviguer.

Une hiérarchisation ne suffit pas. Pour publier des histoires rapidement et souvent, vous devez diviser en morceaux que vous pouvez faire dans quelques jours. Nous voulons que les entonnoirs au début aient des histoires petites et claires et à la fin - grandes et vagues. À temps pour faire une telle panne, nous pouvons profiter de nos dernières découvertes concernant le produit et les besoins de l'utilisateur. C'est tout ce qu'on appelle le nettoyage du Backlog.

Pat tient une réunion pour nettoyer le Backlog tous les mercredis de 11 à 12. Habituellement, il va à l'ensemble de l'équipe et parfois plusieurs parties prenantes. Le contenu des réunions est différent. Mettre l'accent sur l'évaluation, sur la rupture des histoires, sur les critères d'acceptation.

Le propriétaire du produit informatique doit constamment communiquer avec tous

Les propriétaires matures du produit distinguent 2 composantes du succès: une passion pour le travail et la communication. Quelles tâches le propriétaire du produit décide de placer avec l'équipe.

L'équilibre entre la complexité du développement et la valeur de l'historique de l'utilisateur

À un stade précoce, l'équilibre est menacé par l'incertitude et plusieurs risques à la fois.

Les risques

Agile за 15 минут с картинками

  • Risque commercial: "Faisons-nous ce qu'il faut?"
  • Risque social: "Pouvons-nous faire ce dont nous avons besoin?"
  • Risque technique: "Le projet fonctionnera-t-il sur cette plate-forme?"
  • Risques avec le coût et le calendrier de la mise en œuvre: "Allons-nous le faire et aurons-nous assez d'argent?"

La connaissance peut être considérée comme le contraire du risque. Lorsque l'incertitude est grande, nous nous concentrons sur l'acquisition de connaissances - prototypes d'interfaces, expériences techniques.

Compromis entre les valeurs de la connaissance et les valeurs pour le client

Du point de vue du client, la courbe ressemble à ceci:

Agile за 15 минут с картинками

En termes de valeur pour le client, cette courbe ressemble à ceci.

Agile за 15 минут с картинками

À mesure que les incertitudes diminuent, nous pouvons nous concentrer sur les valeurs pour le client. Nous savons quoi et comment faire. Il ne reste plus qu'à faire. Après avoir implémenté les histoires principales, nous ferons des fonctionnalités bonus ou lancerons un nouveau projet.

Compromis entre la pensée à court terme et à long terme

Agile за 15 минут с картинками

Que mettre en œuvre en premier lieu? Corrigez d'urgence les erreurs ou commencez à développer une fonctionnalité étonnante qui étonnera les utilisateurs. Ou faites une mise à niveau sophistiquée de la plate-forme qui accélérera le travail dans le futur. Il est nécessaire de maintenir constamment un équilibre entre travail réactif et proactif.

Faire les bonnes choses, faire les choses correctement ou faire vite?

Agile за 15 минут с картинками

Idéalement - tous les trois en même temps, mais en réalité vous devez choisir.

Agile за 15 минут с картинками

Supposons que nous sommes ici. Nous essayons de créer un produit idéal avec l'aide d'une architecture idéale. Si nous passons beaucoup de temps, nous risquons de ne pas entrer dans la «fenêtre marketing» et nous aurons des problèmes avec l'argent. Ou:

Agile за 15 минут с картинками

Nous fabriquons un produit prototype rapide. Pour une perspective à court terme, ce n'est pas mauvais. À long terme, nous avons des risques techniques. Et la vitesse de développement va tomber à zéro. Ou:

Agile за 15 минут с картинками

Nous sommes ici, nous créons un temple merveilleux en un temps record. Mais l'utilisateur n'avait pas besoin d'un temple, il avait besoin d'une camionnette vivante.

Entre les rôles dans Scrum il y a une confrontation saine

Agile за 15 минут с картинками

Le propriétaire du produit se concentre sur la construction des bonnes choses. L'équipe se concentre sur la construction des choses correctement. Scrum-master ou agile-trainer se concentre sur la réduction du cycle de feedback.

Séparément, il est important de souligner l'importance de la vitesse, de sorte qu'une courte boucle de rétroaction accélère l'entraînement. Cela nous permet de savoir rapidement quelles sont les bonnes choses et comment les construire correctement.

Compromis entre le développement d'un nouveau produit et l'amélioration de l'ancien

Agile за 15 минут с картинками

Le produit ne peut jamais être complètement terminé, car il a constamment besoin de modifications. Quand l'équipe commence à travailler sur un nouveau produit, qu'arrive-t-il à l'ancien? Le transfert du produit d'une équipe à une autre est très coûteux et risqué. Habituellement, l'équipe prend en charge l'ancien produit, en développant un nouveau. Par conséquent, le concept d '«arriéré» renvoie plutôt au produit qu'à l'équipe. Backlog est une liste de choses qu'un propriétaire de produit veut d'une équipe. Et un ensemble d'histoires pour différents produits. Le propriétaire du produit doit constamment choisir le réel pour la mise en œuvre.

Calendrier des histoires destructrices

De temps en temps, les personnes intéressées demandent à Pat: «Quand vont-elles publier ma fonctionnalité?» Ou «Combien de fonctionnalités seront publiées à Noël?». Le propriétaire du produit doit être capable de gérer les attentes de l'utilisateur. Et gérer les attentes de manière réaliste.

Agile за 15 минут с картинками

Deux tendances - optimiste et pessimiste (vous pouvez à l'oeil). La distance entre les tendances montre à quel point la vitesse de l'équipe est instable. Avec le temps, ces tendances se stabiliseront et le cône d'incertitude diminuera.

Supposons qu'une personne intéressée demande quand cette fonctionnalité sera faite?

Agile за 15 минут с картинками

C'est une question à contenu fixe et une période indéfinie. Pour répondre, Pat utilise deux lignes de tendance. La réponse est en avril ou mai.

Agile за 15 минут с картинками

La personne intéressée demande à Pat: «Combien de temps cela va-t-il se passer à Noël?» Il s'agit d'un problème à durée déterminée dont le contenu est incertain. Les lignes de tendance coupent sur l'échelle verticale un segment possible de ce qu'ils pourront réaliser.

Agile за 15 минут с картинками

La personne intéressée demande: «Serons-nous capables de faire ces fonctionnalités pour Noël?» C'est une question avec des délais fixes et un contenu fixe. En se concentrant sur les tendances, Pat répond: "Non". Ajoutant: "A Noël nous aurons le temps de faire tellement de choses, mais pour si longtemps nous aurons besoin de compléter complètement ce travail."

Il est généralement préférable de réduire le contenu d'un projet que d'augmenter le temps. Si nous réduisons le contenu, nous aurons l'occasion de reporter l'heure. Nous pouvons libérer quelque chose ici, et le reste plus tard.

Le propriétaire du produit fait les calculs hebdomadaires et utilise uniquement des données empiriques, et ne donne pas de vœu pieux. Il est honnête au sujet de l'incertitude. L'équipe maintient le rythme de travail et Pat ne fait pas pression sur eux, les forçant à accélérer.

Plusieurs commandes

Agile за 15 минут с картинками

Ayons quelques propriétaires de produits et plusieurs équipes. Le modèle est le même: gestion de la bande passante, communication avec les parties prenantes, prise de décision sur la déviation des histoires des utilisateurs. La vitesse est la somme des vitesses de toutes les équipes. Les prévisions peuvent être générales ou pour chaque équipe. Les propriétaires de produits ont une tâche supplémentaire: communiquer avec les autres propriétaires du produit. Il est nécessaire d'organiser le travail sur les Backlogs afin de minimiser les dépendances et de fournir une synchronisation. Dans les grands projets, le chef de produit (CPO) doit synchroniser tous les autres.

Vidéo en anglais

vidéo en russe

Via Agile Product Ownership en quelques mots & habrahabr.ru & wiki