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

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

Agile en 15 minutes avec photos
La grande image s'ouvrira en cliquant dans une nouvelle fenêtre!

Développement agile de logiciels Les méthodes agiles (méthodes agiles) sont une série d'approches de développement de logiciels axées sur l'utilisation du développement itératif, la définition dynamique des exigences et la mise en œuvre de ces exigences, résultant d'une interaction constante au sein de groupes de travail auto-organisés composés de spécialistes de divers domaines. 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 de création homogène) en combinaison avec leur gestion par la méthode combinée (libérale et démocratique). La plupart des méthodologies flexibles visent à minimiser les risques en réduisant le développement à une série de cycles courts, appelés itérations, qui durent généralement de deux à trois semaines. Chaque itération en elle-même ressemble à un projet logiciel en miniature et inclut toutes les tâches nécessaires à l’émission d’un mini-gain de fonctionnalités: planification, analyse des exigences, conception, programmation, tests et documentation. Bien qu'une itération séparée ne soit généralement pas suffisante pour la publication d'une nouvelle version d'un produit, il est supposé 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 face à face. La plupart des équipes agiles sont situées dans le même bureau, parfois appelé anglais. enclos Au minimum, cela inclut les «clients» (le propriétaire du produit est le client ou son représentant autorisé, qui définit les exigences du produit; ce rôle peut être joué par le chef de projet, l'analyste métier ou le client). Le bureau peut également inclure des testeurs, des concepteurs d’interface, des rédacteurs techniques et des gestionnaires. La principale mesure des méthodes agiles est le produit du travail. En privilégiant la communication directe, les méthodes agiles réduisent la quantité de documentation écrite par rapport aux autres méthodes. Cela a conduit à la critique de ces méthodes comme indisciplinées.

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

"Toutes les affaires durent toujours plus longtemps que prévu, même si nous tenons compte de la loi de Hofstadter." - Loi de Hofstadter

Les 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 globale, elle sait pourquoi nous fabriquons le produit, quels problèmes il va résoudre et pour qui.

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

Ce sont des parties 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 souhaits des parties prenantes. Par exemple, "l'utilisateur doit effectuer une recherche de vol dans le système de réservation de billets".

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

Les intervenants ont beaucoup d'idées et Pat aide à créer des histoires personnalisées à partir d'idées.

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

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

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

Bande passante

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

Étant donné que l’équipe utilise une méthodologie de développement flexible, elle ne sauvegarde pas toutes ces histoires jusqu’à une sortie importante. Au contraire, elle les publie immédiatement et aussi souvent que possible. Habituellement, ils publient 4 à 6 user stories par semaine. C'est leur bande passante. Il est très facile à mesurer - le nombre de user stories en 7 jours.

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

Afin de maintenir ce rythme et de ne pas s'embourber dans des tests de régression manuels, l'équipe travaille d'arrache-pied sur les tests automatiques et l'intégration continue. Par conséquent, il est nécessaire d'écrire des autotests pour chaque fonctionnalité et la plupart du code est doté d'autotests intégrés.

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

Le problème est qu'il y a beaucoup d'intervenants et que leurs demandes ne peuvent être satisfaites avec 4 à 6 histoires par semaine.

Chaque fois que nous implémentons une user story, ils ont un peu plus d'idées, d'où partent encore plus de requêtes.

Qu'advient-il si nous faisons tout ce qu'ils nous demandent? Nous aurons une surcharge.

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

Supposons qu'une équipe prenne 10 nouvelles histoires cette semaine. Si vous saisissez les entrées 10 et 4 à 6, l'équipe sera surchargée. Il va se dépêcher, basculer d'une tâche à l'autre, perdre sa motivation, ce qui entraîne une baisse de productivité et de qualité. C'est une stratégie perdante.

Scrum et XP utilisent dans ce cas la méthode du «temps hier». L’équipe a déclaré: «Nous avons réalisé 4 à 6 films par semaine dernièrement. Quelles films 4 à 6 allons-nous faire la semaine prochaine?"

La tâche du propriétaire du produit est de sélectionner correctement les user stories à implémenter cette semaine.

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

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

Ces deux approches fonctionnent bien et créent une file d'attente de tâches qui s'appelle Backlog dans Scrum ou une liste de tâches classée par ordre de priorité.

Cette file d'attente doit également être gérée: si les parties intéressées demandent 10 histoires par semaine et que l'équipe implémente 4 à 6 histoires, cette file d'attente deviendra de plus en plus importante. Et bientôt, votre arriéré sera planifié dans six mois. C'est-à-dire qu'une histoire attendra la sortie de 6 mois.

Il n’ya qu’une façon de garder sous contrôle une liste de tâches: 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, c'est facile. Mais la tâche la plus importante est de décider quoi ne pas faire et d'en être responsable. Le propriétaire du produit détermine également la séquence de ce que nous faisons maintenant et de ce que nous ferons plus tard. C'est un travail difficile et devrait être fait avec l'équipe de développement et au moins une personne intéressée.

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

Afin de définir correctement les priorités, le responsable de produit doit comprendre la valeur de chaque récit et son volume.

Prise de décision

Certaines histoires sont indispensables, et certaines ne sont que des bonus. Il faudra quelques heures pour développer certaines histoires, des mois pour en développer d'autres.

Comment la taille de l'histoire et sa valeur sont-elles liées? Non

Ne signifie plus mieux. La valeur et la complexité de la tâche - c’est ce qui aide Pat à hiérarchiser ses priorités.

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

Ceci est un jeu de devinettes. Et il vaut mieux participer à tout cela. 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 quantité de travail, mais tout ceci n'est qu'une approximation approximative, aucun chiffre exact. Il y aura toujours des gaffes au début et c'est bien. La communication est beaucoup plus utile que les chiffres ultra-précis.

Chaque fois que les développeurs publient quelque chose de nouveau, nous en apprendrons plus et nous pourrons mieux naviguer.

Une priorisation ne suffit pas. Pour publier des histoires rapidement et souvent, vous devez définir des éléments qui peuvent être créés en quelques jours. Nous voulons des histoires petites et claires au début de l'entonnoir et des histoires volumineuses et indéfinies à la fin. À temps pour faire une telle ventilation, nous pouvons utiliser nos dernières découvertes concernant le produit et les besoins des utilisateurs. Tout cela s'appelle nettoyage de l'arriéré.

Pat tient une réunion pour nettoyer l'arriéré tous les mercredis de 11 à 12 heures. D'habitude, toute l'équipe et parfois plusieurs personnes intéressées s'y rassemblent. Le contenu des réunions est différent. Concentrez-vous sur l'évaluation, sur la répartition des histoires, sur les critères d'acceptation.

Le propriétaire du produit informatique doit communiquer constamment avec tout le monde.

Les propriétaires de produits solides identifient 2 composantes du succès: la passion du travail et la communication. Quelles tâches le propriétaire du produit résout l'endroit avec l'équipe.

Équilibre entre la complexité de la conception et la valeur de la user story

A un stade précoce, la balance est menacée par des incertitudes et plusieurs risques à la fois.

Les risques

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

  • Risque commercial: "Faisons-nous la bonne chose?"
  • Risque social: "Pouvons-nous faire ce dont nous avons besoin?"
  • Risque technique: “Le projet fonctionnera-t-il sur cette plateforme?”
  • Risques liés au coût et au calendrier de mise en œuvre: "Aurons-nous le temps et y aura-t-il 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 - des prototypes d'interface, des expériences techniques.

Le compromis entre les valeurs de connaissance et les valeurs du 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 du client. Nous savons quoi faire et comment. Il ne reste plus qu'à faire. Une fois les histoires principales mises en œuvre, nous créerons des bonus ou lancerons un nouveau projet.

Le compromis entre la réflexion à court terme et à long terme

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

Que mettre en œuvre en premier lieu? Corrigez rapidement les bugs ou commencez à développer une fonctionnalité étonnante qui étonnera les utilisateurs. Ou effectuez une mise à niveau complexe de la plate-forme qui accélérera les travaux à l'avenir. Il est nécessaire de maintenir en permanence un équilibre entre travail réactif et travail proactif.

Faire la bonne chose, faire la bonne chose ou le faire rapidement?

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

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

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

Supposons que nous sommes ici. Nous essayons de créer le produit parfait en utilisant l’architecture parfaite. Si nous passons beaucoup de temps, nous ne pouvons pas entrer dans la "fenêtre du marketing" et nous aurons des problèmes d'argent. Ou:

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

Nous fabriquons un prototype rapide du produit. Pour le court terme, ce n'est pas mal. À long terme, nous courons un risque technique. Et la vitesse de développement diminuera à zéro. Ou:

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

Nous sommes ici, créant un beau temple en un temps record. Mais l'utilisateur n'a pas besoin d'un temple, il a besoin d'une caravane.

Il y a une saine confrontation entre les rôles dans Scrum.

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

Le responsable produit se concentre sur la construction des bonnes choses. L'équipe se concentre sur la construction de bonnes choses. Un scrum master ou un formateur agile s'attache à réduire le cycle de feedback.

Séparément, il est important de souligner l’importance de la vitesse, car une courte boucle de rétroaction accélère l’apprentissage. Cela nous permet de déterminer rapidement ce qui va bien et comment le construire correctement.

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

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

Un produit ne peut jamais être entièrement terminé car il nécessite constamment des modifications. Quand une équipe commence à travailler sur un nouveau produit, qu'advient-il de l'ancien? Transférer un produit d'une équipe à une autre est très coûteux et risqué. Généralement, l’équipe prend en charge l’ancien produit en développant un nouveau. Par conséquent, le concept de «Backlog» fait plutôt référence au produit mais à l’équipe. Le carnet de commandes 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 ce qui convient pour la mise en œuvre.

Calendrier de destruction de l'histoire

De temps en temps, les parties intéressées demanderont à Pat: «Quand vont-elles publier mon long métrage?» Ou «Combien de fonctionnalités vont-elles sortir avant Noël?». Le propriétaire du produit doit être capable de gérer les attentes des utilisateurs. Et gérer les attentes réalistes.

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

Deux tendances - optimiste et pessimiste (vous pouvez le voir à l'œil). La distance entre les tendances montre l'instabilité de la vitesse de l'équipe. Avec le temps, ces tendances se stabiliseront et l'incertitude diminuera.

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

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

C'est une question à contenu fixe avec une période indéterminée. Pat utilise deux lignes de tendance pour répondre. La réponse est en avril ou en mai.

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

La partie intéressée demande à Pat: «Combien va être fait d'ici Noël?» Il s'agit d'une question à durée déterminée avec un contenu incertain. Les lignes de tendance coupent à l’échelle verticale le segment probable de ce qu’elles ont le temps de mettre en œuvre.

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

La personne intéressée demande: «Aurons-nous le temps de créer ces fonctionnalités d’ici Noël?» Il s’agit d’une question à délai fixe et contenu fixe. Se concentrant sur les tendances, Pat répond: «Non.» Ajout: "D'ici Noël, nous aurons le temps de faire beaucoup, mais il nous faudra beaucoup de temps pour terminer tout ce travail."

Il est généralement préférable de réduire le contenu du projet que d’augmenter le temps. Si nous réduisons le contenu, nous aurons la possibilité de reporter les délais. Nous pouvons libérer quelque chose ici et le reste plus tard.

Le propriétaire du produit effectue les calculs chaque semaine et utilise uniquement des données empiriques. Il n'émet aucun voeu pieux. Il parle honnêtement de l'incertitude. L’équipe maintient le rythme du travail et Pat n’appuie pas dessus pour les forcer à accélérer.

Plusieurs équipes

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

Laissez-nous avoir plusieurs 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 concernant le rejet des user stories. La vitesse est égale à la somme des vitesses de toutes les équipes. La prédiction peut être générale ou par équipe. Les propriétaires de produits ont un défi supplémentaire: communiquer avec les autres propriétaires de produits. Nous devons organiser le travail sur les backlogs de manière à minimiser les dépendances et à assurer la synchronisation. Dans les grands projets, le responsable de produit principal est nécessaire pour synchroniser tous les autres.

Vidéo en anglais

vidéo en russe

Via Agile Product Ownership en quelques mots & wiki