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

Éléments fournis : une entreprise qui utilise le cadre Scaled Agile (SAFe) pour étendre le développement Agile à l'ensemble de l'organisation; 10 équipes de développement, combinées en une seule grande équipe (Agile Release Train, selon la terminologie SAFe), offrant 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, la distance entre les plus éloignés dépasse 6 mille kilomètres avec une différence correspondante de 5 heures de temps de travail; expérience de planification antérieure, impliquant la présence physique de collègues clés dans la même pièce et l'utilisation de tableaux / tableaux blancs / marqueurs / notes autocollantes analogiques.

* La construction lourde "Plan de travail de l'équipe informatique pour les 3 prochains mois" menace d'augmenter sérieusement le volume du texte, donc à l'avenir je prévois d'écrire simplement - "commenter" à la place. En conséquence, élaborer et adopter un plan de travail - «s'engager».

Pourquoi est-ce nécessaire?

1) Fatigue due aux méthodes de travail analogiques. Alors que les vaisseaux spatiaux sillonnent les espaces ouverts et qu'Elon Musk creuse des tunnels, nous, spécialistes des TI, écrivons constamment avec des marqueurs sur des morceaux de papier collant et les sculptons sur les planches - c'est une sorte de dissonance. Voici à quoi ressemblait notre commentaire il y a un moment:


Oui, c'est un morceau de papier d'environ 2x5 mètres, et après la planification, chaque morceau de papier devrait être transformé en tâche dans la Jira ...

2) La fatigue des autres nomades. Malgré le fait que notre siège social soit situé dans un pays plutôt accueillant et chaleureux, à ma grande surprise l'année dernière, j'ai découvert qu'ils n'étaient pas du tout satisfaits d'une vie aussi nomade, et mes arguments dans le style de «viens, nage dans la mer, se prélasser au soleil », que j’ai eu l’imprudence d’exprimer, n’ont pas été accueillis très chaleureusement - tout le monde n’est pas prêt pour de fréquents voyages d’affaires, leurs ménages ne l’accueillent pas toujours bien, quelqu'un ne réagit pas très bien aux vols fréquents.

3) Connecter plus de collègues des TI au processus de planification. Comme il ressort clairement du paragraphe précédent, nous ne pouvions pas nous permettre d'envoyer tout le bureau pour la planification, nous n'avons donc envoyé que les élus, excluant ainsi le reste du processus, ce qui n'ajoutait aucun avantage à la morale générale.

4) Optimisation des coûts financiers. Oui, c'est un moment sensible - il y a beaucoup de personnes clés, et les transporter dans les deux sens quatre fois par an est une surcharge.

Part Zero, ou Portfolio-Backlog

Et tout commence beaucoup plus tôt - pour travailler fructueusement sur le commentaire lors de la planification, il faut qu'il y ait quelque chose à commettre. Pour ce faire, je dois «charger» les chefs d'entreprise de travailler sur les initiatives proposées (ou, dans la terminologie SAFe, Epicam, mais j'utiliserai le terme familier) le plus tôt possible. Idéalement, ce processus devrait être complètement dissocié de la nature cyclique de la planification trimestrielle et suivre sa propre voie kanban. Comme base, nous avons pris le portefeuille SAFe Kanban:



Nous avons un projet JIRA distinct avec trois types de tâches: épopées, initiatives commerciales et initiatives architecturales; ainsi que le tableau Kanban correspondant. L'algorithme pour le chef d'entreprise de l'initiative est simple: il ajoute la tâche à ce projet, et par défaut elle tombe dans le Backlog - c'est le premier statut de notre kanban - Funnel:



Il stocke les initiatives qui ne sont pas encore prêtes à être examinées. Le propriétaire de l'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 l'énoncé du problème rempli, le résultat souhaité et 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 ne plus mentionner les solutions techniques et de se concentrer sur les paramètres commerciaux. Lorsque toutes les données sont collectées, le propriétaire déplace la tâche au statut suivant - Révision.

Nous effectuons une revue hebdomadaire, tant pour les initiatives commerciales que pour les architectes. Idéalement, il s'agit d'une présentation de cinq minutes avec des réponses ultérieures aux questions. Le résultat de l'examen est une décision sur le sort de l'initiative. Elle peut:

• revenir à l'arriéré pour révision
• abolir sans aucune chance de vie (pour cela, j'utilise un statut obsolète distinct, caché sur le tableau Kanban)
• obtenir l'approbation et passer à l'étape suivante - Analyser.

À ce stade, nous sommes à votre santé! - nous pouvons attirer des employés de l'informatique: analystes, architectes, prospects, n'importe qui. Par «nous», je veux dire moi-même en tant qu'ingénieur du train de lancement, mais dans le cas idéal, les propriétaires d'entreprise qui ont déjà acquis une certaine expérience et l'indépendance nécessaires pour attirer les bonnes équipes et démarrer le processus d'analyse de leur propre chef. J'écris sur un cas idéal, car le niveau d'auto-organisation de nos collègues est flottant, et dans certains cas, ils demandent de l'aide sous la forme d'un facilitateur spécialement désigné, mais j'essaie de prendre un peu de recul par rapport à cette pratique.

Le but de cette étape est l'analyse préliminaire, ou, comme nous l'appelons, la pré-découverte. À la sortie, nous devrions obtenir le minimum qui nous permettra de nous engager: les solutions proposées, les risques et les dépendances, les exigences non fonctionnelles et infrastructurelles, les cartes des utilisateurs, les 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.

Pour chaque initiative, un tableau Kanban personnel est créé, dans lequel, au fur et à mesure que vous les créez, vous pouvez voir les fonctionnalités et les histoires, avec une liaison initiale à une certaine itération, qui est fournie par un flux de travail distinct sous la forme d'itérations futures. Dans les tableaux, les équipes personnalisées sont configurées en fonction des équipes de développement. Étant donné que l'é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 de commandes:



De plus, au stade de l'analyse, les architectes sont impliqués dans ce processus ou, comme il est de coutume récemment, leurs personnes de confiance sont des «ambassadeurs» (EA Ambassadors). Leur tâche est de transmettre la vision du département d'architecture aux participants du processus, d'aider à trouver la meilleure solution et, au final, de coordonner cette décision avec l'architecte en chef de l'entreprise (chef de l'architecture d'entreprise).

Lorsque les équipes estiment que l'initiative est bien développée et prête pour la prochaine étape, elles la font passer au statut suivant - Portefeuille en attente.

À ce stade, une étape importante consiste à effectuer la priorisation WSJF ( Weighted Shortest Job First ). Pour ce faire, 3 semaines avant la planification, nous organisons une grande réunion, qui, malheureusement, prend de nombreuses heures, et pendant cette réunion, en utilisant le score de poker de Fibonacci, les membres du conseil d'administration évaluent la valeur commerciale, la criticité du temps ( Temps critique), réduction potentielle des risques et opportunité:



Pour pouvoir suivre l'historique des initiatives, j'ajoute à chacune d'elles une étiquette dans le gabarit avec des données sur le trimestre: 2018Q4, 2019Q1, etc.

Pour l'avenir, je décrirai les statuts possibles suivants. Après l'engagement, les initiatives qui ont été prises avec succès pour passer au statut de mise en œuvre , tandis que les «non-aptes» obtiennent le statut de parc et à l'avenir ont la possibilité d'être prises en compte pour les prochains trimestres. Les initiatives livrées passent à Terminé .

Par conséquent, nous avons approximativement l'image suivante sur le tableau Kanban:



Bien sûr, nous ne sommes même pas au milieu du voyage, mais pour le moment je peux déjà noter que grâce à l'utilisation de Kanban au niveau Portfolio-Backlog

• Les propriétaires d'entreprise ont commencé à élaborer des initiatives en détail et à se préparer sérieusement à un examen
• L'examen est devenu plus méticuleux dans le bon sens
• Les équipes ont plus de temps avant la découverte
• Je ne perds pas mes anciennes initiatives - vous pouvez toujours revenir à des initiatives parquées, non livrées ou oubliées et continuer à travailler dessus

Outils utilisés à ce stade:

• Serveur logiciel Atlassian Jira
• Couleurs pour le plugin Jira - pour mettre en évidence les initiatives commerciales et architecturales
• Plugin 'Structure - Project Management at Scale' - pour visualiser la structure des initiatives avec des fonctionnalités qui leur sont liées et leur priorisation WSJF
• Atlassian Confluence - Source de documentation interne
• Lucidchart et ses plugins pour Jira et Confluence - pour la cartographie

Partie I. Préparer la planification

Quelque part un mois avant la planification, c'est un moment chaud pour la préparation. Il y a trop de choses à considérer, et pour ne rien oublier, il faut créer une table Google «logistique» multi-pages. Je vais essayer de décrire les onglets les plus importants de ce tableau et l'activité qui les entoure.

Rétroaction. Quelques jours après chaque planification, nous menons une rétrospective et pour ajuster le cours, il est important de ne pas oublier à quelles conclusions nous sommes arrivés et comment nous devons ajuster le cours. Il s'agit d'un élément important dans le contexte de l'amélioration continue des processus.

Formation technique. Avec le passage à la planification à distance, des demandes spécifiques ont surgi, telles que la qualité de la connexion Internet (priorisation et optimisation des itinéraires pour JIRA et Confluence) et la présence télévisuelle et audio (nous utilisons les kits Logitec Group, les microphones Jabbra et les écouteurs personnels dans diverses combinaisons, webcams, Logiciel de zoom pour la visioconférence).

Facilitateurs. Voici une liste des 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.

Le public. En conséquence, une liste complète de tous les invités.

Liste de contrôle. Une liste complète des tâches importantes avec les délais et les responsables. Pour une plus grande immersion, je donnerai plusieurs exemples des tâches les plus caractéristiques et les plus importantes qui sont répétées pour chaque planification: formation des facilitateurs (un manuel de formation a été préparé pour les facilitateurs avec toutes les étapes nécessaires depuis l'organisation d'une équipe de travail, le calendrier des réunions pour explorer les options de solutions techniques et le processus de décomposition de l'initiative en une liste de fonctionnalités) ; mise à jour des plans de localisation des groupes de travail pour chaque bureau; contrôle de la mise à jour de Velocity pour toutes les équipes de développement; commande de déjeuner; rapports sur les trimestres précédents; impression de listes d'initiatives (à portée de main) et de calendriers.

Partie II Planification et commentaires

Après tous les préparatifs qui courent, arrive enfin ce moment - le début de la planification trimestrielle. Dans deux jours, nous devrions avoir le temps de trier toutes les initiatives, de nous assurer qu'il y a suffisamment d'informations et de nous engager. Après quelques discours courts mais incendiaires, les groupes de travail se dispersent à leur place et se mettent au travail. À l'heure actuelle, le nombre de groupes est réparti entre les trois bureaux selon la formule 4x4x4, et les utilisateurs distants se connectent à la table nécessaire via un canal Zoom dédié.

À la fin de la découverte de chacune des initiatives, le facilitateur, s'assurant que toutes les données nécessaires - telles que les critères d'acceptation, une description de la solution technique, les risques, les dépendances, le besoin d'une nouvelle infrastructure - sont présentes, marque l'initiative avec la case IT Session Finished pour la transparence des progrès et le groupe de travail peut passer au suivant.

Après une dizaine de plans, le sentiment de tension nerveuse constante et de pression temporelle temporaire qui nous accompagnait depuis le tout début s'est en grande partie résolu, et maintenant l'atmosphère ressemble plus à un travail tranquille. Dans la seconde moitié des premier et deuxième jours, le moment est venu de faire un commentaire tranquille conformément aux priorités. Pour exécuter le commit, j'ai plusieurs structures distinctes. Le premier d'entre eux est une structure contenant une liste de fonctionnalités et de chemins prévus pour le commentaire:


Malheureusement, cette structure contient les restes de matériel qui ne correspondaient pas aux commentaires du trimestre en cours, de sorte que l'échantillon n'est pas représentatif. Dans tous les cas, dans la recherche, je peux sélectionner l'initiative qui m'intéresse par ordre de priorité par numéro, qui pendant le processus de découverte est placé dans un champ séparé pour chaque fonctionnalité et histoire, changer le statut des tâches nécessaires de Planifié à Engagé et le mettre dans la bonne itération, s'engageant ainsi:



En conséquence, la tâche disparaîtra de cette structure et apparaîtra dans une nouvelle, reflétant le commentaire croissant:



Comme vous pouvez le voir sur la capture d'écran, dans cette structure, les histoires se retrouvent dans le dossier de l'équipe de développement à laquelle elles appartiennent et sont regroupées par itération. Ici, je vois la vélocité globale de l'équipe dans le nom du dossier, ainsi que dans la colonne Engagement, en utilisant la formule, le dépassement pour chaque groupe est automatiquement déterminé et nous signale en rouge.

Bien sûr, si les premières initiatives et les plus prioritaires entrent en commentaire sans problème, bientôt, avec l'apparition des premières équipes qui ont rempli leur arriéré à l'échec, les problèmes commencent et certaines initiatives ne sont pas sans débat, mais elles doivent être reportées.

À la fin de ce processus simple, les équipes sur le drapeau de l'entreprise jurent solennellement de livrer un commentaire (une blague) et de se disperser à la maison (également une blague - tout le monde se disperse à travers les barreaux).

Outils utilisés à ce stade:

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

Partie III. Clonage de tâches dans un écosystème JIRA fonctionnel d'une entreprise

Tandis que tout le monde boit de la vodka, RTE travaille à la création d'un commentaire sous la forme dans lequel il peut être distribué aux backlogs de l'équipe de développement et suivi tout au long du trimestre. Pour ce faire, j'utilise le plugin 'Bulk Clone Professional for Jira' - il ajoute un élément qui fournit le clonage collectif dans le menu Bulk Change, et a pour moi des fonctionnalités nécessaires comme les liens de clonage, la mise à jour des liens entre les clones fraîchement créés, la mise à jour des liens épiques, l'ajout préfixe dans l'en-tête et ajoutez automatiquement un raccourci:



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 et, par conséquent, je vois immédiatement dans l'en-tête lorsque nous prévoyons de terminer une fonctionnalité ou une histoire.

Tout d'abord, je clone absolument toutes les tâches dans un projet Global Backlog distinct, car nous y stockons des épopées, et j'ai besoin d'avoir des connexions épiques pertinentes dans des tâches fraîchement clonées. Et dans un deuxième temps, je fais des demandes pour chaque équipe de développement séparément et je déplace les histoires vers les projets finaux des équipes.

En conséquence, je crée une structure qui reflète le commentaire actuel et se compose de tâches finales, que j'utilise ensuite pour le suivi:


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

• Cela peut sembler ringard, mais il est plus facile pour une personne de l'informatique d'imprimer de nouvelles fonctionnalités et histoires que d'écrire avec un marqueur sur une feuille de papier collante.
• De nombreuses choses, comme le solde de capacité et la mise à jour WSJF, selon les notes, sont calculées automatiquement à l'aide de formules.
• Grâce au clonage, la distribution originale du commit est préservée pour l'histoire et vous pouvez toujours y revenir.
• On économise beaucoup de temps et d'énergie lors de la préparation de la planification - travailler avec du papier demande des forces.
• Bien sûr, c'est super que vous n'ayez plus besoin de farcir des puzzles dans une gira.

Outils utilisés à ce stade:

• Serveur logiciel Atlassian Jira
• Plugin 'Bulk Clone Professional for Jira' - pour cloner des fonctionnalités et des histoires dans des projets JIRA finaux.
• Plugin 'Structure - Project Management at Scale' - pour créer la structure finale.

Épilogue

Mes amis, bien sûr, je comprends que la description est assez superficielle et beaucoup de choses pourraient être révélées plus en détail - surveiller la répartition du capital entre les initiatives commerciales et architecturales et les tâches opérationnelles, calculer les formules dans les structures, la gestion des risques, et bien plus encore. Mais il n'est pas encore clair pour moi si ce sujet est intéressant pour le public, et si oui, quoi exactement. Si je vois de l'intérêt, je serai prêt à révéler les sujets nécessaires.

Et encore une chose - il est difficile de croire que cela est possible, mais je voudrais éviter tous les problèmes liés à Edge, aux cadres, aux gestionnaires efficaces et «efficients». N'oubliez pas que j'ai décrit l'ensemble du processus dans l'espoir de personnes intéressantes qui sont proches de lui avec sa mise en œuvre technique, et j'ai vraiment hâte aux discussions pertinentes.

A bientôt dans les commentaires!