Comment mener une planification trimestrielle distribuée sans papier et ne pas la gâcher?

Éléments fournis : une entreprise qui utilise le Scaled Agile Framework (SAFe) pour étendre le développement Agile à l'ensemble de l'organisation; 10 équipes de développement réunies en une seule grande équipe (Agile Release Train, selon la terminologie SAFe) pour livrer un produit commun; la nécessité d'une planification trimestrielle de deux jours (PI Planning) pour déterminer le plan de travail des équipes informatiques pour les 3 prochains mois *; trois bureaux de développement dont la distance entre les plus éloignés dépasse 6 000 kilomètres et la différence de temps de travail correspondante de 5 heures; expérience de planification antérieure qui impliquait l'utilisation de tableaux analogiques / tableaux blancs / surligneurs / notes autocollantes et la présence physique respective de tous les employés clés dans la même pièce.

* Cette construction lourde "Le plan de travail des équipes informatiques pour les 3 prochains mois" menace d'augmenter considérablement la taille du texte, je vais donc le remplacer par "l'engagement". En conséquence, élaborer et adopter un plan de travail sera «s'engager».

Pourquoi en avons-nous besoin?

1) Fatigue avec des méthodes de travail analogiques. Alors que les vaisseaux spatiaux labourent l'espace et qu'Elon Musk ennuie ses tunnels, nous, les gars de l'informatique, avons constamment écrit avec des surligneurs sur des notes autocollantes les collant sur les planches - il y a vraiment une sorte de dissonance dans tout cela, n'est-ce pas ? Voilà à quoi ressemblait notre engagement il y a quelque temps:



Oui, il s'agit d'une feuille de papier d'environ 2 mètres sur 5, chaque note autocollante devant être transformée en tâche JIRA après la planification ...

2) Fatigue de nos collègues nomades. Malgré le fait que notre siège social soit situé dans un pays plutôt agréable et chaleureux, j'ai été surpris de découvrir l'an dernier qu'ils étaient loin d'être satisfaits de tous les allers-retours. Mes arguments "Eh bien, vous pouvez simplement vous amuser à vous détendre au soleil au bord de la mer" n'ont pas été reçus très chaleureusement. Comme il s'est avéré que tout le monde n'est pas prêt pour de fréquents voyages d'affaires, qui ne sont souvent pas les bienvenus dans leur famille, certains collègues ne pouvaient tout simplement pas supporter tout le temps dans les airs compte tenu des distances entre les bureaux et de la fréquence des réunions.

3) Impliquer davantage de collègues IT dans le processus de planification. Comme il ressort clairement du paragraphe ci-dessus, nous ne pouvions guère nous permettre de faire venir tout le personnel informatique des trois bureaux pour la planification, de sorte que seuls les élus ont été sélectionnés, ce qui a exclu les autres du processus. Ce n'était guère bénéfique pour l'esprit d'équipe en général.

4) Optimisation des coûts. Oui, c'est un moment sensible - il y a beaucoup de personnes clés et les faire voyager dans les deux sens quatre fois par an n'est pas bon marché.

Partie zéro: Utilisation du portefeuille en attente

Tout commence bien plus tôt que la planification réelle. Afin de travailler de manière productive sur l'engagement pendant la planification, vous devez avoir quelque chose pour vous engager. Pour cela, je dois «charger» les chefs d'entreprise de travaux sur des initiatives probables (ou, dans la terminologie SAFe, Epics, mais je vais utiliser ci-après notre terme habituel) le plus tôt possible. Idéalement, ce processus devrait être complètement dissocié de la nature itérative de la planification trimestrielle et suivre sa propre voie Kanban. Nous avons pris SAFe Portfolio Kanban comme base:



Nous avons un projet JIRA distinct avec trois types de problèmes: Epics, Business Initiatives et Architectural Initiatives; ainsi que le tableau Kanban correspondant. L'algorithme pour le propriétaire d'entreprise de l'initiative est simple: il ajoute un problème à ce projet, et il va à Backlog par défaut, qui est le premier état de notre flux Kanban - Entonnoir:



Ici sont stockées les initiatives qui ne sont pas encore prêtes à être examinées. Le propriétaire d'entreprise travaille sur le contenu de l'initiative jusqu'à ce qu'il se sente prêt pour la prochaine étape. Le minimum requis à ce stade est d'avoir rempli les champs de l'énoncé du problème, du résultat souhaité et de la mesure du succès, ainsi qu'une présentation légèrement plus détaillée, mais simple et claire. À ce stade, il est important de laisser de côté les solutions techniques et de se concentrer sur les paramètres commerciaux. Lorsque toutes les données sont collectées, le propriétaire de l'entreprise déplace la tâche au statut suivant - Révision.

Nous effectuons des revues hebdomadaires pour les initiatives commerciales et architecturales. Idéalement, il s'agit d'une présentation de cinq minutes avec des questions et réponses ultérieures. À la suite de l'examen, une décision est prise sur ce qui arrivera à l'Initiative ensuite. Il peut:

• être retourné à Funnel pour révision,
• être aboli sans aucune chance de vie (dans ce cas, j'utilise un statut spécial obsolète caché sur le tableau Kanban),
• être approuvé et passer à l'étape suivante - Analyse.

A ce stade, nous - Yippee !!! - peut enfin engager les informaticiens: analystes, architectes, leads, tout le monde. Par «nous», je veux dire moi-même en tant qu'ingénieur de Release Train. Mais idéalement, il devrait également s'agir de chefs d'entreprise, qui ont déjà acquis une certaine expérience et l'autonomie nécessaires pour engager les bonnes équipes et lancer indépendamment des analyses. Encore une fois, j'écris sur le cas idéal ici. En fait, le niveau d'auto-organisation de nos collègues est flottant et, dans certains cas, ils demandent l'aide d'un facilitateur spécialement désigné, mais j'essaie de prendre du recul par rapport à cette pratique.

Le but de cette étape est l'analyse préliminaire, ou, comme nous l'appelons, la pré-découverte. En conséquence, nous devrions obtenir un minimum qui nous permettrait de nous engager: solutions proposées, risques et dépendances, exigences non fonctionnelles et d'infrastructure, cartes d'utilisateurs, schémas architecturaux. De plus, nous demandons aux équipes de donner une évaluation préliminaire des points d'histoire au niveau des fonctionnalités - cela nous permettra de déterminer les priorités à la fin du trimestre.

Un tableau Kanban personnel est créé à ce stade pour chaque initiative, dans lequel les fonctionnalités et les histoires peuvent être vues, avec un lien préliminaire vers une itération spécifique, qui est fournie par un flux de travail JIRA distinct. Ainsi, en changeant le statut, nous pouvons attribuer le problème à une certaine itération. Les couloirs dans les tableaux Kanban sont configurés par les équipes de développement. Étant donné que notre écosystème JIRA est assez compliqué, pendant la pré-découverte et la découverte, nous créons des tâches dans des projets séparés afin de ne pas encombrer les arriérés des équipes:



Toujours au stade de la pré-découverte, nous impliquons des architectes ou, comme cela a souvent été pratiqué récemment, leurs personnes de confiance - les «ambassadeurs EA». Leur tâche est de transmettre la vision du département d'architecture à tous les participants, d'aider à trouver la meilleure solution, et enfin d'approuver cette solution avec le responsable de l'architecture d'entreprise de l'entreprise.

Lorsque toutes les personnes impliquées estiment que l'Initiative a été suffisamment analysée et est prête pour la prochaine étape, elle passe au statut suivant - Portefeuille en attente.

À ce stade, il est important de procéder à une priorisation WSJF ( Weighted Shortest Job First ). Pour ce faire, nous avons une grande réunion 3 semaines avant la planification, qui malheureusement a jusqu'à présent toujours duré plusieurs heures. Au cours de cette réunion, les membres du conseil d'administration évaluent la valeur commerciale, la criticité temporelle, la réduction des risques et l'activation des opportunités à l'aide du poker de planification aligné sur Fibonacci:



Pour pouvoir suivre l'historique des Initiatives, pour chacune d'entre elles j'ajoute un label dans JIRA avec des données trimestrielles: 2018T4, 2019T1, etc.

Pour l'avenir, permettez-moi de décrire tous les statuts possibles. Après l'engagement final à PI Planning, les initiatives mises en œuvre avec succès sont déplacées vers le statut de mise en œuvre , tandis que celles «non adaptées» reçoivent le statut de parc et peuvent être envisagées pour les prochains trimestres. Les initiatives livrées passent au statut Terminé .

En conséquence, nous avons l'image suivante sur le tableau Kanban:



Bien sûr, nous ne sommes pas encore au milieu de notre chemin, mais pour le moment, je peux déjà noter que grâce à la mise en œuvre du portefeuille Backlog

• Les propriétaires d'entreprise ont commencé à travailler en détail sur leurs initiatives et à bien se préparer pour l'examen.
• Les examens sont devenus plus méticuleux dans le bon sens.
• Les équipes ont plus de temps pour la pré-découverte.
• Je ne perds pas les anciennes Initiatives - je peux toujours revenir aux Initiatives Parquées, non livrées ou oubliées et y travailler plus avant.

Outils utilisés à ce stade:

• Serveur logiciel Atlassian Jira
• Couleurs du plugin pour Jira - pour mettre en évidence les initiatives commerciales et architecturales
• Le plugin 'Structure - Project Management at Scale' - pour visualiser la structure des Initiatives et fonctionnalités qui leur appartiennent, et leur priorisation WSJF
• Atlassian Confluence - source de documentation interne
• Lucidchart et ses plugins pour Jira et Confluence - pour le dessin de diagrammes

Partie I. Préparation à la planification de l'IP

Un mois avant PI Planning, c'est le moment le plus chargé. Trop de choses doivent être prises en compte, et pour ne rien laisser de côté, je dois créer un formulaire Google «logistique» multipage. Permettez-moi de décrire les onglets les plus importants de ce formulaire et les activités qui les entourent.

Rétroaction Quelques jours après chaque planification d'IP, nous réalisons une rétrospective, qui nous aide à ne pas oublier les conclusions auxquelles nous sommes parvenus et comment nous devons ajuster le cours. Il s'agit d'un élément important en termes d'amélioration continue.

Préparation technique. Avec la transition vers la planification à distance, des demandes spécifiques sont apparues, telles que la qualité de la connexion Internet (priorisation et optimisation des itinéraires pour JIRA et Confluence) et la présence vidéo et audio (nous utilisons les kits Logitec Group, les microphones Jabbra et les écouteurs personnels dans diverses combinaisons , webcams, logiciel Zoom pour la visioconférence).

Facilitateurs. Il s'agit d'une liste d'employés chargés de l'animation dans chacun des groupes de travail, indiquant leur emplacement et un lien vers le canal Zoom permanent du groupe de travail.

Audience La liste complète de tous les invités.

Liste de contrôle La liste complète des tâches importantes avec des délais et des personnes responsables. Pour vous donner un aperçu ci-dessous, vous pouvez trouver plusieurs exemples des tâches les plus typiques et vitales pertinentes pour chaque PI Planning: formation des facilitateurs (un manuel de formation a été préparé avec toutes les étapes nécessaires telles que l'organisation d'une équipe de travail, le calendrier des réunions et décomposer l'initiative en une liste de caractéristiques); mise à jour des plans de localisation des groupes de travail pour chaque bureau; contrôle de la mise à jour Velocity pour toutes les équipes de développement; commander des repas; créer des rapports des trimestres précédents; impression de listes d'initiatives et de calendriers.

Partie II. Planification PI et processus d'engagement

Après tous les préparatifs, ce moment arrive enfin - le début de PI Planning. En deux jours, nous devons découvrir toutes les initiatives, nous assurer que les informations sont suffisantes et s'engager. Après quelques discours d'encouragement, les groupes de travail se rendent chez eux et se mettent au travail. Actuellement, le nombre de groupes est réparti entre les trois bureaux en 4x4x2 et les utilisateurs distants sont connectés au groupe requis via un canal Zoom dédié.

À la fin de la découverte de chacune de ces initiatives, le facilitateur s'assure que toutes les données nécessaires, telles que les critères d'acceptation, la solution technique, les risques, les dépendances, la nécessité d'une nouvelle infrastructure, sont disponibles et marque l'initiative avec le 'IT' Case Session Finished pour un suivi facile de la progression. Après cela, le groupe de travail peut passer à la prochaine initiative.

Après une douzaine de PI Plannings, le sentiment d'être soumis à un stress constant et à une pression du temps, qui était avec nous depuis le tout début, s'est considérablement estompé, et maintenant, cela ressemble plus à du travail comme d'habitude. Dans l'après-midi des premier et deuxième jours de la planification, c'est le moment de s'engager sans précipitation en fonction des priorités. Pour réaliser un engagement, j'ai plusieurs structures distinctes. Le premier est une structure contenant une liste de fonctionnalités et d'histoires prévues pour l'engagement:



Malheureusement, cette structure sur la capture d'écran ne contient que des tâches qui ne correspondaient pas à l'engagement du trimestre en cours, de sorte que l'échantillon n'est pas représentatif. Dans tous les cas, dans le champ de recherche, je peux sélectionner l'Initiative nécessaire par ordre de priorité par numéro, qui est placé dans un champ distinct pour chaque fonctionnalité et histoire, changer le statut des problèmes de Planifié à Engagé et les mettre à l'itération souhaitée , s'engageant ainsi pour eux:



En conséquence, la question disparaîtra de cette structure et apparaîtra dans une nouvelle, qui reflète l'engagement croissant:



Comme vous pouvez le voir sur la capture d'écran, dans cette structure, les histoires tombent dans le dossier de l'équipe de développement à laquelle elles appartiennent et sont regroupées par itération. Ici, je vois la vitesse totale de l'équipe dans le nom du dossier, et en plus dans la colonne Engagement, le surengagement est automatiquement déterminé et mis en évidence pour chaque équipe, en utilisant une formule personnalisée.

Bien sûr, si les initiatives de première et de plus haute priorité sont incluses dans un engagement la plupart du temps facilement, dès que de plus en plus d'équipes rempliront leurs arriérés à la fin, il pourrait y avoir des problèmes respectifs avec certaines des initiatives, après certains arguments et discussions, étant reporté (parqué) en conséquence.

À la fin de ce processus plutôt simple, les équipes jurent de tenir leur engagement sur le drapeau de l'entreprise (ok, pas vraiment) et se précipitent chez elles (enfin, encore une fois, pas vraiment, la plupart s'enfuient dans un bar pour célébrer).

Outils utilisés à ce stade:

• Serveur logiciel Atlassian Jira
• Le plugin 'Structure - Project Management at Scale' - pour suivre le processus de découverte et pendant l'exécution de l'engagement.

Partie III. Problèmes de clonage dans l'écosystème JIRA de l'entreprise

Tandis que tout le monde boit, le RTE travaille à la création d'engagements sous la forme d'une distribution aux backlogs des équipes de développement et d'un suivi tout au long du trimestre. Pour ce faire, j'utilise le plugin 'Bulk Clone Professional for Jira' - il ajoute un élément faisant du clonage collectif au menu Bulk Change et a des fonctionnalités nécessaires comme le clonage de liens, la mise à jour des liens entre les clones nouvellement créés, la mise à jour des liens Epic, l'ajout de résumé préfixe et étiquetage automatique:



J'ajoute le statut en tant que préfixe, car au stade de la planification, les statuts reflètent l'itération planifiée de l'achèvement. En conséquence, je peux voir tout de suite dans le résumé lorsque nous prévoyons de terminer la fonctionnalité ou l'histoire.

Au début, je clone absolument tous les problèmes dans un projet Global Backlog distinct, car nous y conservons des épopées, et j'ai besoin d'avoir de véritables connexions d'histoires épiques dans les tâches nouvellement clonées. Et déjà dans une deuxième étape, je fais des requêtes JQL pour chaque équipe de développement séparément et déplace les histoires dans les projets de travail des équipes.

En conséquence, je crée une structure qui reflète l'engagement actuel et se compose d'histoires finales, que j'utilise ensuite pour le suivi:



En général, les avantages de cette approche sont les suivants:

• Il est plus facile pour un informaticien de taper de nouvelles fonctionnalités et histoires plutôt que de les écrire avec un surligneur sur un pense-bête.
• De nombreuses choses, telles que la capacité restante et la mise à jour WSJF en fonction des estimations des histoires, sont calculées automatiquement à l'aide de formules personnalisées.
• Grâce au clonage, l'engagement d'origine est préservé pour l'histoire et nous pouvons toujours y revenir.
• Cela nous permet d'économiser du temps et de l'énergie au stade de la préparation de la planification - la gestion du papier prend de l'énergie.
• Bien sûr, c'est formidable que nous n'ayons plus besoin d'ajouter de problèmes à JIRA en tapant des notes autocollantes.

Outils utilisés à ce stade:

• Serveur logiciel Atlassian Jira
• Le plugin «Bulk Clone Professional for Jira» - pour cloner des fonctionnalités et des histoires dans des projets JIRA fonctionnels.
• Le plugin «Structure - Project Management at Scale» - pour la création de la structure finale de l'engagement.

Épilogue

Chers amis, bien sûr, je comprends que la vue d'ensemble ci-dessus est plutôt superficielle, et beaucoup de choses pourraient être révélées de manière plus détaillée - surveiller la répartition des capacités entre les initiatives commerciales et architecturales et les tâches opérationnelles, calculer des formules personnalisées dans les structures, gérer les risques et bien plus. Mais je ne sais toujours pas si ce sujet est intéressant pour le public, et si oui, quoi exactement. Si je constate un intérêt, je serai heureux de partager mes idées sur les sujets pertinents.

Et encore une chose - il est difficile de croire que ce serait possible, mais je voudrais quand même vraiment éviter les problèmes liés à Agile, aux cadres, aux gestionnaires efficaces et «efficaces» dans les commentaires. N'oubliez pas que j'ai décrit la partie technique de l'ensemble du processus dans l'espoir de susciter l'intérêt des personnes proches du sujet, et j'attends avec impatience les discussions pertinentes.

A bientôt dans les commentaires!