Comment avons-nous fait SCRUM

Un terrible rêve d'une équipe de développement, c'est quand vous avez besoin de «plonger» dans un sujet inconnu et de «pro-estimer» une idée à moitié cuite avant de commencer le développement. Dans ce cas, vous devez littéralement « signer le sang » pour le résultat à l'heure fixée pour un montant fixe.

En fait, il n'est pas réaliste de donner une évaluation précise des exigences inexactes. Une manière typique dans la gestion de projet est de rédiger un mandat détaillé avant de commencer le développement. Et puis implémentez toutes les fonctionnalités en un seul gros morceau. Mais une telle approche «en cascade » menace d'autres risques: lancer un projet dans le style d'un « big bang » - lorsque vous obtenez le premier résultat à la toute fin du projet. Et cela peut être très loin des objectifs commerciaux réels et des besoins des utilisateurs.

Pourquoi prendre un tel risque si vous pouvez suivre une voie complètement différente?

Pourquoi SCRUM

Lorsque nous nous familiarisons avec le projet, il y a une compréhension «nous savons que nous ne savons pas cela» et même «nous ne savons pas où les limites de ce que nous ne savons pas» aident SCRUM



Les spécificités de SCRUM peuvent faire peur, si vous n'avez jamais travaillé avec ce framework, par le fait qu'au départ la longueur du chemin que vous devez parcourir pour obtenir un projet fonctionnel et 100% de satisfaction n'est pas encore connue.

C'est difficile pour le client - il ne peut PAS préparer un plan stratégique pour le développement du projet avec des dates de sortie fiables. L'inconnu fait peur, surtout lorsque vous devez payer de cette façon maintenant.

Mais il y a des avantages : au départ, le client ne doit pas décrire en détail et scrupuleusement toutes les fonctions et caractéristiques d'un énorme futur système. Et il peut également changer les priorités à tout moment et s'adapter à un marché extérieur concurrentiel.

À propos, c'était la même chose dans ce cas , mais bientôt vous verrez comment nous avons survécu à une situation difficile, quand avec le client nous avons compris quoi et comment mettre en œuvre déjà dans le processus.

SCRUM s'appuie sur le concept de petites étapes: publier régulièrement des versions du logiciel en cours d'exécution, aussi souvent que possible et plus tôt. Chaque itération est un micro-stade de développement, immédiatement vérifié par la pratique.

Cela signifie qu'après la première itération, le client reçoit des fonctionnalités assez utiles, bien que petites, mais fonctionnelles, les vérifie en pratique, donne immédiatement un retour.



Voyez comment nous avons organisé tout le travail: décisions clés importantes - quelle est la prochaine valeur à donner à l'entreprise - l'équipe prend avant chaque nouvelle itération, en conséquence, le système se développe le long d'un chemin critique optimal jusqu'à ce qu'il devienne le plus approprié pour l'entreprise. Le client ici fait partie de l'équipe. L'entrepreneur et le client sont responsables de la réussite du développement. Ils sont d'un côté des barricades.

C'était le cas avec nous, voyons?

Nous voulons parler de notre façon d'adapter le cadre SCRUM classique en travaillant sur un système de contrôle automatisé pour la «A + Academy of Modern Education» - c'est un centre éducatif moderne à Kiev, qui comprend une école, un jardin d'enfants, un centre de développement précoce, de la musique, de la danse et des sports écoles, studios d'art et un centre pour l'étude des langues étrangères. Au total, plus d'un millier d'enfants suivent près de 150 cours différents à l'Académie.

SCRUM est un cadre qui aide à résoudre les tâches qui changent au cours du processus de travail, afin de livrer de manière efficace et créative des produits aux clients avec la plus grande valeur possible

L'avantage de SCRUM et, pour certains, l'inconvénient est qu'il s'agit d'un cadre très léger. Il ne contient pas de réponses à toutes les questions et des instructions détaillées pour les membres de l'équipe. Scrum - "intentionnellement incomplet", et en raison de cet universel.

SCRUM doit être adapté à chaque projet spécifique

Comment les clients et les sous-traitants commencent-ils à travailler sur SCRUM?

Pour travailler dans un paradigme inconnu, le client doit parfois changer de pensée habituelle. Être dans le même contexte que l'interprète. Par conséquent, avant de développer le système pour l'Académie, nous avons organisé une formation conjointe avec les gars de Scrum Ukraine . Ses principaux objectifs sont les suivants: se connaître, comprendre la terminologie, élaborer toutes les techniques sous forme de jeu, simuler les principales activités, comprendre par où commencer, répartir les rôles et enregistrer les responsabilités.









Au cours d'une formation conjointe de trois jours, nous avons, à l'aide de la vue dite hélicoptère , formé le futur système à grands coups et l'avons fixé sur une ligne temporaire sous la forme de Project RoadMap.

vue en hélicoptère - une description générale ou une opinion d'une situation, plutôt qu'une description détaillée


Carte routière mondiale des produits

Quelles sont nos conclusions après cette étape?

1. La formation conjointe contribue à changer la pensée du client et de l'équipe.
2. Product RoadMap vous permet de visualiser un plan de développement de haut niveau et de planifier approximativement les versions. Il est important de comprendre qu'il s'agit d'une «feuille de route en direct» qui changera à mesure que la découverte de nouveaux détails de développement
3. L'accord sur les règles mondiales du jeu est nécessaire «sur le rivage»: le propriétaire du produit après chaque sprint reçoit de la valeur - un système qui doit être utilisé immédiatement, puis donner un retour.

Le troisième paragraphe est obligatoire, sans quoi rien ne fonctionnera. Étant donné que les espoirs de lancement après une préparation totale abstraite en finale conduisent à des déceptions, des deux côtés:

• De la part du client: "C'est ce que nous avons demandé, mais ce n'est pas ce dont nous avons besoin."
• De la part de l'interprète: «Nous avons clairement fait ce que vous avez demandé. Et maintenant, vos exigences nous semblent complètement différentes. Nous nous engageons à tout refaire, mais à vos frais. En général, il y a tellement de changements que l'achèvement prendra encore six mois. »

Propriétaire du produit - le propriétaire du produit est responsable d'atteindre la valeur maximale du produit à la suite du travail effectué par l'équipe de développement. La seule personne responsable du développement de produits

Tous nos arrangements dans une courte liste.

Étape # 1: Analyse d'affaires et adaptation de la méthodologie

Nous commençons le développement de tout projet par une analyse commerciale: vous devez comprendre les spécificités. Il y a toujours beaucoup de processus dans une entreprise, et notre tâche dans l'étude est de découvrir comment les participants au système interagissent entre eux avant de construire le système.

Après une série d'entretiens problématiques et le traitement des informations reçues, nous avons reçu une description du sujet sous forme d'exemples d'utilisation.



Bien que SCRUM ne nécessite pas de spécification de développement, le fait que nous ayons une description du sujet prêt était un gros plus. Ce document a constitué la base du backlog produit - la base du lancement de SCRUM. Backlog de produit - une liste d'exigences, d'histoires, de fonctionnalités, qui sont classées par ordre d'importance. Avec une telle liste, tout commence. De plus, toutes les exigences sont décrites dans un langage compréhensible pour le client. Les éléments de cette liste sont la user story , les "user stories".

La user story est une description des scénarios utilisateur les plus simples pour utiliser le système, dont l'essence peut être formulée comme suit: «qui, quoi, pour quoi, quelles sont les fonctionnalités et les limites».









Notre carnet de produits de 203 histoires, regroupées de manière pratique par segment


Exemple de user story

Quelles sont nos conclusions après cette étape?

1. Nos sprints dureront 2 semaines. Pourquoi ? Les sprints courts sont confortables. Ils permettent à l'équipe d'être aussi «flexible» que possible: prête à ajuster souvent ses plans. Un sprint court signifie une courte boucle de rétroaction, conduisant à des sorties fréquentes. Versions fréquentes = critiques rapides des clients = moins de temps pour travailler dans la mauvaise direction = formation rapide, amélioration, etc.
2. Les sprints longs ont leurs avantages - moins de frais généraux, tels que la planification de sprints, les démos, etc. Mais nous avons choisi des modèles courts pour être flexibles et prendre moins de risques.

Sprint - la période de temps pendant laquelle le "Ready" est créé, c'est-à-dire un produit adapté à l'utilisation et à la libération

Étape # 2: planification du sprint. Comment nous avons adapté la planification de Sprint

Notre première valeur commerciale a été un magazine électronique. Pour les développeurs les plus expérimentés, cela semblera utopique: nous avons une feuille vierge, il n'y a pas un répertoire, une interface utilisateur, un système d'autorisation ou une entité commerciale unique, et nous nous engageons à fournir l'une des fonctions les plus complexes du système.



C'était comment. Pour nous, il fallait obtenir 2 choses: l' objectif déclaré du sprint et le backlog de sprint approuvé.

Notre propriétaire de produit a toujours commencé à planifier le sprint avec une description de ce qui doit être fait en premier, les histoires les plus importantes. Après cela, l'équipe a évalué les coûts de main-d'œuvre pour toutes les user stories, en commençant par la plus importante. Dans le processus, l'équipe a eu beaucoup de questions sur la façon dont cela devrait fonctionner.

La planification de sprint est une activité SCRUM très importante. Chacun est conscient de la responsabilité d'une évaluation correcte, car:

• cela permet à l'entreprise de comprendre à quelle fonctionnalité elle peut s'attendre à la fin du sprint. Permet d'être une équipe prévisible et d'être «sur la même longueur d'onde» avec le client
• la valeur d'une demi-histoire réalisée est nulle, donc toutes les histoires planifiées dans le cadre d'un sprint doivent être décidées.
• tout changement de score pendant le sprint est ignoré;

Le but du sprint est sa raison d'être. Plus important encore, l'objectif doit être indiqué en termes commerciaux et non techniques. C'est-à-dire dans un langage compréhensible même pour les personnes extérieures à l'équipe, et le backlog de Sprint est une sélection d'histoires du backlog de produit . Il s'agit d'une liste d'histoires que l'équipe a identifiées comme les plus importantes à ce stade et s'est engagée à terminer pendant le sprint.


Exemple de backlog de sprint

E-magazine après le premier sprint

Simplifications et hypothèses pour le premier sprint . Dans le système - 2 utilisateurs: enseignant et parent; une classe - 5 "A"; la composition réelle de la classe, saisie manuellement directement via des requêtes SQL; le calendrier actuel pour 5 "A", également formé directement par l'entrée dans le tableau.

User story # 1 : l'enseignant se connecte au système et donne des notes pour n'importe quel sujet à partir du calendrier des cours de la journée. Un système avec une fonction simple mais déjà fonctionnelle. Déjà lors de la démonstration de sprint, l'enseignant a dit quoi utiliser commodément et quoi ne pas, afin que dans les prochains sprints l'équipe puisse planifier les corrections et donner un outil mis à jour.

Quelle valeur réelle donne: les performances numérisées de la classe réelle, les évaluations actuelles, la perspective de la préparation automatique des rapports mensuels, semestriels et trimestriels.

User story # 2 : Un rapport hebdomadaire aux parents sur les performances par la poste.

Quelle valeur ajoutée: informer les parents des performances actuelles; commentaires des enseignants sur les devoirs; analyse minimale mais réelle.

Après plusieurs sprints, j'ai décidé qu'il y avait suffisamment de fonctionnalités pour que les enseignants puissent travailler avec un journal électronique. Par conséquent, nous avons suspendu le développement de cet outil et déplacé le focus vers le concepteur de planning. C'est normal pour SCRUM. Après une douzaine de sprints, je suis retourné dans le magazine électronique pour me concentrer sur le développement et, après avoir partiellement éliminé la fonctionnalité simplifiée, nous avons amené le journal électronique à l'état nécessaire à l'analyse des performances annuelles. Nous avions besoin de cette fonctionnalité à ce moment-là. Nous avons acquis une valeur suffisante et basculé le développement actif vers des parties plus prioritaires du système.

Svyatoslav, propriétaire du produit

Pour référence : afin de fixer la version finale (idéale), nous avons dû revenir au journal électronique pour plusieurs sprints.


Voilà à quoi ressemblait le magazine après le premier sprint, mais il était déjà possible de travailler avec.


Cette version du magazine électronique a été reçue après 12 sprints et pourrait être montrée aux parents.

Un autre exemple frappant d'une approche SCRUM itérative est le constructeur de programme.

Le client a reçu le premier concepteur de planning 2 mois après le début du projet. C'était un «éditeur brutal» pour un utilisateur très avancé. Mais il nous a permis d'introduire un calendrier pour toutes les classes de cinquième et de tester le système sur un véritable calendrier en direct.

Il a fallu trois sprints pour le raffiner à «l'éditeur visuel». L'orientation du développement a été changée à plusieurs reprises, mais au début de l'année scolaire, le client a reçu un concepteur d'horaire entièrement fonctionnel, avec l'aide duquel il a présenté l'horaire du premier (A, B, C, D) aux élèves de huitième année en seulement une heure.

Suivons l'itinéraire "éditeur brutal pour un vrai administrateur" - "éditeur visuel" - "concepteur d'horaire"

Et comment avez-vous fait le programme avant?

Le programme a été établi sur des feuilles de papier Whatman A1 collées manuellement: peintes, surlignées avec des marqueurs colorés, collées. Le directeur a mis des semaines et des mois pour le faire.


La toute première version de l'éditeur: «éditeur brutal pour l'administrateur» - qui a fait le calendrier pour 2018


La deuxième version améliorée, à l'aide de laquelle le calendrier 2018/2019 a été établi


Schedule Designer - Version finale

Quelles sont nos conclusions après cette étape?

1. Chaque sprint doit avoir un objectif clairement défini.
2. Simplifier la fonctionnalité puis la développer est normal. Pourquoi SCRUM est si bon: il n'y a pas une seule bonne façon de développer un produit. Ce n'est pas un tutoriel avec des devoirs et des réponses correctes à la fin. Vous pouvez toujours envisager de nombreuses options alternatives et les exécuter dans différentes séquences. Si à la fin du sprint, le client reçoit une valeur complète avec laquelle il peut travailler, tester, entrer de nouvelles données, et cela passe à la tâche finale globale, c'est la bonne façon.
3. La philosophie principale de SCRUM: ne pas chercher un beau code au départ, mais se concentrer sur la mise à disposition du client d'un outil de travail. Par conséquent, vous pouvez accepter des erreurs au cours du travail, mais vous devez comprendre: la meilleure façon d'identifier ces erreurs est d'arrêter de penser au code idéal au niveau de l'architecture et de la conception, et de donner d'abord à l'entreprise un prototype fonctionnel.
4. Il est important au cours de la discussion d'apporter des modifications à la user story, de sauvegarder et de joindre tous les artefacts aux cartes.

Comment faire en sorte qu'une équipe évalue la user story de manière réaliste

L'équipe évaluera toujours adéquatement l'histoire de l'utilisateur si les conditions sont remplies: le comportement de l'utilisateur réel est décrit en détail, les limites d'utilisation et les hypothèses sont indiquées, les critères d'acceptation sont répertoriés. Autrement dit, l'équipe comprend le «quoi» doit être fait et suggère grosso modo le «comment».

Pourquoi il est important de formuler des «critères d'acceptation» et des «limites d'utilisation» - cela donne la même compréhension de la portée du travail pour les histoires du propriétaire du produit et de l'équipe.

Échelle de notation, ou SCRUM-poker

Dans SCRUM, l'évaluation de l'histoire a lieu non pas en heures ou en jours, mais en points d'histoire. Il s'agit d'un mélange de complexité, de risques et d'efforts qu'une équipe doit dépenser pour terminer une histoire. Pour chaque équipe, 1 point d'histoire est une valeur empirique individuelle, mais chaque membre de l'équipe le ressent.

Notez que la séquence de valeurs sur les cartes n'est pas linéaire. Par exemple, il n'y a rien entre 13 et 21. Pourquoi



Tout d'abord, cela est nécessaire pour éviter l'apparition d'un faux sentiment de précision pour les notes importantes. Si l'histoire est estimée à environ 17 points d'histoire, il ne sert à rien de discuter si elle devrait être 15, ou 18, ou 21. Tout ce que nous devons savoir, c'est l'histoire, c'est difficile à évaluer. Par conséquent, nous lui attribuons une note de 21. En gros.

Deuxièmement, les gens ont tendance à exagérer leurs capacités et l'échelle ne permet pas de se tromper sur l'évaluation du temps et des ressources. Par exemple, l'équipe a convenu que 6 points d'histoire sont suffisants pour l'une des tâches. Mais si vous n'êtes pas sûr que 5 soit suffisant, alors il vaut mieux en choisir 8. Cela vous permet de définir les termes réels dans lesquels l'équipe s'intégrera exactement. De plus, cela aide à entamer un dialogue entre les participants, à partager votre vision de la mise en œuvre de l' histoire , à exprimer les risques et à parvenir à un consensus.

Très important : chaque membre de l'équipe doit donner une évaluation. Pourquoi?

• Pour une évaluation raisonnée, chaque participant doit parfaitement comprendre l'essence de cette histoire. En recevant une évaluation de chaque membre de l'équipe, nous nous assurons que tout le monde est au courant des enjeux. Cela augmente la probabilité d'entraide pendant le sprint. Et le plus important: les questions les plus importantes sur cette histoire se poseront le plus tôt possible.
• Une vision globale du problème conduit à une large diffusion des évaluations. Ces désaccords sont mieux identifiés et discutés dès que possible. Après discussion des désaccords - réévaluation, vote. Habituellement, quelques cycles d'évaluation suffisent pour clarifier les principaux points et créer une compréhension commune.

Nous le montrons par l'exemple d'une grande variation de l'estimation pour l'une des histoires. L'histoire s'appelait Buzz .

Important : Lors de la planification, nous ne savons généralement pas qui exécutera telle ou telle partie. La mise en œuvre de la user story nécessite la participation de spécialistes pour différents types de travaux: architecture, front-end, back-end, tests, préparation de données réelles. Séparément, il existe un groupe d'œuvres comme la conception et la conception d'interface utilisateur.

Bright Case: Buzz

Dans le système de gestion scolaire, de nombreux événements d'importance variable se produisent. Par exemple, un étudiant a reçu une note; un remplacement s'est produit et, au lieu des mathématiques, il y aura de la biologie avec un autre enseignant; Un incident gênant s'est produit avec l'élève et les parents doivent en être informés immédiatement; L'enseignant a écrit un commentaire important sur la DZ.

Il n'est pas pratique pour les utilisateurs d'envoyer ces données par des méthodes standard aux messageries instantanées ou par courrier, et même hier. De plus, les messages peuvent concerner plusieurs personnes à la fois: l'enseignant doit envoyer au parent que l'élève a quitté l'école pendant la leçon. Dans le document d'origine, ces règles sont regroupées sur 10 pages


Buzz dans la mise en œuvre finale

Bright Case: Buzz

Nous discutons parmi les développeurs de combien nous estimons la quantité de travail sur l'histoire de Buzz.



Tout le monde dit combien de points d'histoire sont nécessaires. Il s'est avéré que nous avons de grandes différences d'opinion et a attiré l'attention sur des opinions extrêmes: pourquoi quelqu'un a évalué 50, et son collègue est confiant en 5 points d'histoire. Nous avons donc immédiatement découvert des exigences non détectées qui ont été remarquées par un développeur plus prudent. De plus, des tâches globales liées à la personnalisation ont été révélées. C'est un excellent exemple de la façon dont une équipe peut anticiper les difficultés.

Quelles conclusions avons-nous tirées concernant la méthodologie d'évaluation

1. Oui, il est normal que le concepteur QA et UX donne une évaluation de l'historique technique.
2. story points, «» . , , story points.
3. 2-3 , — 1 story point

story point — , , .

№3: . sprint execution SCRUM

La réunion SCRUM quotidienne, ou stand-up, et l'ensemble du SCRUM est une histoire de communications efficaces qui permettent d'économiser du temps et des efforts. Ce ne sont pas seulement des «réunions» et des «conversations». Ils ne prennent pas de temps qui pourrait être consacré au travail, mais contribuent à optimiser les efforts. L'un des principes de SCRUM est: «Les personnes et l'interaction sont plus importantes que les processus et les outils.»



Chaque membre de l'équipe rapporte brièvement, selon une liste de contrôle spécialement conçue, ce qu'il a fait, quels problèmes il a rencontrés, ce qu'il fera ensuite. Une personne n'est pas laissée seule avec un problème, elle est rapidement aidée à le résoudre de la manière la plus efficace. Ainsi, un ingénieur ne passe pas de temps sur les tentatives infructueuses, après quoi vous devrez peut-être le refaire à partir de zéro, économisant ainsi les ressources de toute l'équipe.

:

- , . .

.

, . : - , .

, : , , sprint backlog , , , , . , , , , . .

, Scrum Master

sprint running

1. , , , .
2. Il est nécessaire de changer l'accent et de comprendre qu'un SCRUM quotidien est nécessaire pour la communication, et non pour l'administration.
3. Chaque sprint suivant devrait prendre en compte l'expérience des précédents.

Comment organiser une réunion SCRUM quotidienne

Étape numéro 4: Comment nous avons effectué une démonstration des résultats. Notre adaptation de la démonstration de sprint

Les développeurs démontrent à tour de rôle de nouvelles fonctionnalités en direct sur des données réelles. L'accent est mis sur CE QUE nous avons fait et non sur COMMENT nous l'avons fait. En général, nous nous efforçons constamment de faire de notre démo une activité commerciale, sans mentionner les détails techniques.

Comment savoir si une solution convient au client

Là encore, le but du sprint vient au premier plan . Nos démos étaient souvent suivies par des professeurs spécialement invités et des chefs d'établissement qui ne planifiaient pas. Ils ne connaissaient le produit qu'en termes généraux. Nous nous sommes toujours félicités qu'après chaque histoire démontrée, les clients eux-mêmes aient essayé de faire quelque chose dans le système. L'utilisateur final vérifie ensuite chaque élément du critère d'acceptation. Il dit ce qui convient et ce qui ne fonctionne pas, quels aspects peuvent être améliorés. Et donc - pour chaque user story prévue pour ce sprint.





Quelles conclusions avons-nous tirées sur la méthodologie de démonstration des résultats

1. Composition obligatoire pour la démo: Product Owner, Scrum Master, représentants clients et utilisateurs finaux qui travailleront avec l'outil, équipe.
2. , .
3. , . -.
4. , . .
5. . , ,

—

№5: retrospective

— sprint demo. , - . , .





— . . , , 5 story points, , 13story points , , — - . — .

: . Scrum Master sprint backlog, . , , — — . , . . , , :

• Lorsqu'un développeur crée un front-end et que nous commençons à l'implémenter, il est nécessaire que les concepteurs soient 100% accessibles.
• Discutez avec PO de l'inclusion d'heures méthodologiques.
• En ergonomie, il est important d'obtenir le plus de documentation.
• La dette technique ne doit pas être accumulée. Alignez 10% pour les articles techniques sur le bon de commande.
• Il devrait y avoir un spécialiste qui résoudra les problèmes techniques à mesure qu'ils surviennent.
• Avant chaque planification de sprint, il est impératif de procéder au toilettage de sprint.

«Après que l'équipe aura réfléchi à tous les autocollants problématiques, je procéderai à un« vote ponctuel »: chaque membre de l'équipe a trois votes (trois marqueurs sur les autocollants). Il peut exprimer tous ses votes à la fois sur un seul problème, ou il peut répartir différemment. Sur la base de ce vote d'équipe, nous sélectionnons 2-3 améliorations sur lesquelles nous nous concentrerons dans le prochain sprint. Et au début de la prochaine rétrospective, nous vérifierons ce qui s'est passé. Donc pour dire "vérifier les devoirs" :) "

Pavel Kamyshov , entraîneur agile

Oui, SCRUM nécessite l'inclusion active de tous les membres de l'équipe. Pour des activités telles que le toilettage, la planification, le SCRUM quotidien, cela nous a pris environ 12% du temps payé - c'est une sorte de prix pour la transparence, la prévisibilité et la réduction des risques.

Une semaine de travail peut économiser une heure de planification.

Pavel Kamyshov , entraîneur agile de Scrum Ukraine

12%, c'est beaucoup, mais cela en vaut la peine, car dans la «cascade» classique, le prix de l'utilisation de la méthodologie est un rôle distinct pour le chef de projet. En moyenne, environ 15% des coûts de développement sont consacrés à la gestion de notre segment de marché.

Quelles conclusions avons-nous tirées sur la méthodologie rétrospective

1. Pour nous, la rétrospective est le deuxième événement le plus important de SCRUM après la planification du sprint.
2. Chaque membre de l'équipe s'exprime pour que tout le monde soit dans le même champ d'information.
3. Chaque changement a un prix. Vous devez accepter avec PO d'inclure des histoires techniques et des heures méthodologiques dans le carnet de sprint.
4. Les heures méthodologiques sont payées par le client.

La rétrospective de Sprint est l'occasion pour une équipe de mener une inspection visant à elle-même et de créer un plan pour améliorer le travail d'équipe lors du prochain Sprint.

Étape numéro 6: comment nous avons adapté le raffinement du backlog de produit, ou le toilettage

De nombreux collègues qui connaissent les spécificités de l'informatique doutent: comment cela peut être si clair pour une équipe lors de la planification du sprint qu'elle est prête à évaluer toutes les histoires d'utilisateurs.



Oui, en effet, sans la préparation d'une telle cohérence ne fonctionnera pas. Pour que cela fonctionne de cette façon, il existe une activité SCRUM spéciale: affinement du carnet de produit. Pour le réaliser, vous devez demander au propriétaire du produit de vous donner un horizon de planification: décrivez quelles histoires peuvent être candidates pour le prochain sprint. S'il y a des histoires parmi elles qui nécessitent une étude approfondie ou des compétences spéciales que l'équipe n'a pas, une réunion est appelée - toilettage / pré-planification.


Résultats de toilettage

Notre propriétaire de produit était très compétent, nous avions donc toujours un horizon de vision suffisant sur la façon dont le système évoluerait et nous procédions régulièrement à des améliorations. En effet, la transparence est l'un des principes fondamentaux de SCRUM.


Cela ressemble à un plan de toilettage

Quelles conclusions avons-nous tirées sur la méthodologie du raffinement

1. Il s'agit d'un événement important qui nous permet de clarifier ce que nous ne savons pas, quelles compétences nous manquent. Ainsi, une fois qu'il a été décidé d'attirer un développeur-consultant tiers sur des questions spécifiques, dont nous n'avions pas la solution à l'époque.
2. Ces discussions ont été très efficaces avec nous, nous avons envisagé de nombreuses alternatives et options, ce qui nous a permis de garder le problème à l'esprit, et pour la planification du sprint, l'histoire la plus compliquée était déjà «tracée».
3. Des problèmes complexes, apparemment insolubles, trouvent des solutions claires. Parfois, il suffit d’acheter une bibliothèque que de développer vous-même un site complexe.

Le raffinement est le fondement pour être prêt à évaluer la complexité des histoires dans différentes conditions de mise en œuvre lors de la planification du sprint, car nous devons comprendre leur volume et leur complexité.

Échoue

Oui, nous sommes franchement ravis du développement de la méthodologie SCRUM, mais cela ne signifie pas que tout s'est bien passé. Voici trois points où nous poserions des pailles si nous savions à l'avance que cela se passerait ainsi.

Travailler sur des modèles familiers

Dans l'une des rétrospectives, nous avons analysé en détail la raison de l'écart anormal de la "productivité réelle" de l'équipe dans toutes les histoires impliquant des designers. Les performances réelles sont généralement calculées à l'aide de la formule: performances projetées / performances réelles.

Nous avons découvert par habitude qu'ils s'organisaient en une cascade séquentielle familière.

En conséquence: les tâches ont été exécutées séquentiellement, les développeurs ont passé du temps sur la mise en marche séquentielle à différentes étapes avec des retards dus à la nécessité de terminer les tâches déjà commencées.

Conclusion: L'histoire peut-être la plus douloureuse pour nous, qui a fait le plus de mal et n'a pas été révélée immédiatement. Il est nécessaire de vérifier régulièrement si tous les membres de l'équipe sont passés au travail conformément aux nouvelles normes.

Travail supplémentaire sur les fonctionnalités inutiles

Au deuxième sprint, le propriétaire du produit a succombé à l'avis d'un des directeurs d'école, qui pensait que le «journal du conservateur» était une fonctionnalité extrêmement importante. Nous avons pris cette histoire dans un sprint, nous y avons consacré nos efforts.

Pourquoi une erreur: cet outil n'a pu être testé que dans les étapes ultérieures, car il avait besoin de données accumulées, qui à l'époque n'étaient pas là.

Résultat: il n'a pas été testé, ni utilisé, ni développé. Les fonctions nécessaires ont été résolues différemment et pas du tout de la façon dont le directeur d'école le pensait, grâce à des outils complètement différents. Conclusion: n'utilisez au travail que ce que vous allez immédiatement commencer à utiliser.

Égal aux utilisateurs avancés

À un moment donné, nous avons intégré l'histoire avec «l'éditeur de remplacement» au développement, auquel un enseignant, un utilisateur d'ordinateur très expérimenté, a participé. En conséquence, nous avons obtenu un excellent outil, mais il ne pouvait pas être utilisé par des enseignants ordinaires qui n'étaient pas si avancés.

Conclusion: confirmez l'histoire chez les clients réguliers.

Conclusions générales

Conclusion numéro 1

Flexibilité professionnelle: SCRUM vous permet d'être une équipe efficace

Les résultats de chaque sprint dépendent des tâches d'introduction, de l'efficacité, de la coordination, de la responsabilité de l'équipe et du feedback de qualité.

L'entrée est donnée par le propriétaire du produit. Il est également responsable du contexte dans lequel la fonctionnalité sera utilisée, la qualité de la formulation des exigences, fournit une profondeur de détail suffisante.

SCRUM oblige l'équipe à effectuer un travail complètement tangible, ce qui lui permet d'obtenir de la valeur, c'est-à-dire un outil qui peut être fourni à l'utilisateur à la fin de chaque itération. Cela aide à voir la solution à l'œuvre et dans les étapes initiales pour comprendre ce qui doit être changé pour aller de l'avant.

Conclusion numéro 2

À propos de l'utilisation la plus efficace des ressources

SCRUM - une forme d'organisation du travail qui profite au client et à l'entrepreneur. Quoi?
Travailler avec des itérations déjà au début vous permet de comprendre ce qui ne va pas, ce qui signifie que vous devez effectuer des ajustements dans le temps. La préparation de chaque sprint et les spécificités de son organisation permettent à chaque fois de ne faire que ce dont le client a besoin et de ne pas s'en aller. Et cela donne une EFFICACITÉ énorme des ressources dépensées, du temps et des efforts.
Aux étapes initiales, le client reçoit une partie fonctionnelle du système: après les premiers sprints, il intègre les fonctionnalités qu'il a apportées et les teste en pratique.

SCRUM - lorsque les deux parties sont assurées contre les risques

Voyez comment la responsabilité est partagée entre le client et l'entrepreneur
La barricade disparaît, des deux côtés dont l'entrepreneur et le client sont dans la gestion de projet classique. En principe, les postes clients et sous-traitants disparaissent, l'équipe reste. Et il n'y a pas de conditions pour une éventuelle confrontation.

CLIENT

Le client ne paie que si tous les objectifs de sprint ont été atteints. Si un outil n'est pas développé que le client peut exécuter en pratique demain, le sprint ne compte pas.

Le client paie un montant fixe pour chaque sprint et rend son activité plus efficace

Interprète

L'entrepreneur est intéressé à préparer un nouvel outil, une nouvelle valeur pour le client lors de chaque sprint, car cela donnera une nouvelle série de retours et d'informations / d'expérience. Qui peut être utilisé pour poursuivre le développement de produits.

Chaque sprint augmente le niveau de compétence de l'interprète, l'accélère dans la mise en œuvre du projet.

Au total, en seulement 7 mois, nous avons réalisé un système qui fonctionnait et était totalement satisfaisant pour le client, testé par lui dans la pratique et reflétant tous les souhaits, et n'a pas donné un système théoriquement conçu selon les spécifications techniques, qui devrait être complété quelques mois de plus, car la pratique apporterait inévitablement ses propres corrections.

Globalement, ce cas concerne une technique de gestion de projet correctement sélectionnée dans des conditions de haut degré d'incertitude et de temps limité avant le lancement.

Avec un client aussi exigeant, avec des normes de qualité élevées, c'était parfois très difficile pour nous, mais en même temps très intéressant. Ces défis que nous avons surmontés, les erreurs commises dans le temps, conscientes et corrigées, les conclusions tirées, ont changé à jamais la culture de notre équipe

Pendant longtemps, tout le monde était probablement intéressé à connaître le produit lui-même, ce qui s'est avéré.

Le client a reçu un excellent produit: un ensemble d'outils pour une école moderne qui peut rapidement le transformer en école du futur