🤦 👌🏻 🧦 Projets simultanés Ajile (sous-prison) et Waterfall ⬇️ 💸 👨🏾‍🔧

Il existe de nombreux cadres prédéfinis et éprouvés pour organiser le flux de travail, dans lesquels les méthodes et les principes sont bien décrits. Si nous assemblons une voiture, utilisez Kanban, préparez une tarte - Lean, développez un site Web personnalisé - PMBoK. Il est important de considérer que chaque projet est unique et nécessite une adaptation des approches, mais en général, pour votre cas, il y a très probablement déjà suffisamment de solutions utiles. Construisant des processus pour moi, j'ai pris un peu de tout.

C'était

Il a travaillé dans une startup. Un produit, une petite équipe, il n'y a pas de délais stricts. Utilisé Scrum et Kanban dans sa forme la plus pure, pour ainsi dire. Nous avons écrit des tâches dans Trello et les avons glissées sur 4 tableaux: des idées, nous devons le faire, au travail, c'est prêt. Pour discuter de l'avancement des travaux, ils ont appelé tous les jours et une fois par semaine, ils ont planifié des tâches pour le prochain sprint. Tout est comme les gens.

Est devenu

Ayant un peu changé le cours du développement, je suis parti pour une nouvelle expérience dans un studio web. Là, tout d'abord, il a été surpris de la flexibilité de travailler avec les clients et, si ce n'est sans sarcasme, de l'absence de tout système.

Pour montrer la situation dans son ensemble, je vais donner un exemple très simplifié.
Client A: J'ai besoin de développer une page de destination pour un événement de telle ou telle date.
Chef de projet (MP): d'accord, nous le ferons avant une certaine date.
Client B: apporter d'urgence les modifications suivantes au site.
MP: OK, ajoutez dès que possible.

Ensuite, le député approuve l'estimation pour le client A, écrit les tâches dans le tracker, créant des projets séparés et des tableaux non connectés. Dit à l'équipe quoi faire. Les développeurs commencent à couper, et à la fin, le gestionnaire montre le résultat aux clients.

Les entrées dans le système ressemblent à ceci:

Problèmes

L'approche de la maintenance est assez logique, mais les problèmes suivants se posent:

Manque de connexion visible entre les
tâches du client et celles de l'équipe . Les tâches métier se trouvent généralement dans le tableau et sont décompilées dans Jira. Lorsqu'un développeur écrit une autre méthode API, pour comprendre qui l'utilisera, vous devez vous adresser au gestionnaire et clarifier à nouveau.
Le
concepteur de hiérarchisation incorrect signale la fin prématurée de la mise en page (oui, cela se produit également). Il demande: que faire ensuite? MP définit la tâche du quatrième projet, le premier de la liste. À la fin de la journée, il se rend compte que la quatrième tâche du premier projet était plus importante.
Il n'y a pas de représentation visuelle de l'étendue des travaux.
Tâches dans différents projets. Personne ne veut les garder dans la tête ou faire des recherches dans les catalogues. C’est plus facile, quand j’ai fini, de demander: que faire ensuite?
Répartition inégale de la charge par temps et par employé
Il est clair ce que Vasya et Petya font en ce moment, il est plus difficile de dire qui sera occupé après 2 semaines et si leurs tâches seront équivalentes.
Lors de la planification du temps de réalisation, les tâches des autres projets ne sont pas prises en compte. Il nous a été
demandé de modifier le lien sur le site. Oh, c'est facile, faisons-le aujourd'hui. Ensuite, le gestionnaire rappelle qu'il existe des bogues super critiques sur un autre site. En conséquence, le changement de lien, selon le client, l'équipe s'est étalée sur une semaine.

Peut-être que dans cet exemple avec les modifications et la page de destination, cela n'a pas l'air effrayant, car tout cela est facile à garder à l'esprit, mais en pratique, il pourrait y avoir 5 projets avec 40 tâches dans chacun. De nombreux projets sont venus d'autres managers. Les tableaux, les types de tâches, les méthodologies qu'ils ont choisies ont été choisis en fonction de leur humeur.

Convertir le melon

Pour créer un système, il fallait d'abord amener les données dans un format unique. En transformant la masse d'entités transférées à ma disposition, j'ai réussi à arriver au concept suivant:

je pense que tout est clair d'après la photo, mais il y a de petites nuances associées à l'implémentation dans Jira. Analysons chaque entité à l'aide d'exemples.

Avec le concept de projet, tout est sans ambiguïté à la fois dans l'esprit de la communauté et d'Atlassian. Il s'agit d'une séquence d'actions visant à obtenir des résultats en un temps limité. Par exemple: développer un site web, supporter l'application pour toute la durée de vie, créer une régie publicitaire.

Epic (sortie)- grandes pièces isolées du projet: compte personnel, panier, catalogue de produits. Ici, les désaccords commencent déjà. Jira a une entité - épique, mais j'ai quand même utilisé la libération.

Le fait est que pour implémenter la structure correcte, il est nécessaire d'avoir 3 niveaux d'imbrication, Jira au moment de la rédaction de l'article a 2 + 1 (l'historique et la tâche sont situés au même niveau). +1 est une sous-tâche, je n'en prends pas en compte, car il porte la fonction de complément plutôt que d'imbrication à cause du manque de flexibilité et de forte liaison au parent.

Au lieu de la sortie, vous pouvez utiliser un composant ou un sprint, mais à mes fins, ils semblaient moins réussis. Pour la même raison, l'épopée est utilisée pour enregistrer des histoires.

L'histoire (épique) dans cette structure est la tâche de l'entreprise (le désir du client). Tâche- actions compréhensibles pour résoudre les problèmes commerciaux.

De plus, certains compteurs et champs ont été ajoutés aux entités. Le plus important d'entre eux est une échelle pour évaluer la complexité d'une tâche de 1 à 10 en unités arbitraires (point d'histoire).

Création de système

Il y a des données, alors vous devez décider sous quelle forme et comment les afficher. J'ai créé un projet commun pour l'équipe et écrit une requête JQL pour y extraire des tâches de tous nos projets (la requête est facile à générer dans la section problèmes). Ajout de tableaux Kanban et de statuts correspondant à notre processus technique: Backlog → À faire → Faire → Révision → Test → Correspondance → Terminé.

L'image suivante s'est avérée:

Maintenant, toutes les tâches passent par un seul cycle de production, ce qui est assez universel (vous ne pouvez pas tester la conception, mais la transférer immédiatement en accord). En cas d'échec d'une étape, un commentaire est ajouté à la tâche et renvoyé à To Do. Chaque tâche a des liens visibles avec le projet, l'historique du client (épopée) et l'épopée (version).

En utilisant la même requête JQL avec le plugin BigGantt (ou tout autre) pour Jira, les tâches peuvent être visualisées sous la forme d'un diagramme de Gantt. Modifiez le délai, les délais, enregistrez les dépendances, voyez la charge sur les interprètes. Réduire les tâches dans l'histoire, l'histoire dans les épopées, c'est-à-dire visualiser une feuille de route ou un plan de travail détaillé.

Partie administrative

Parmi les méthodologies, le Lean est utilisé (une séquence d'actions est déterminée, alors que la possibilité d'exécution parallèle des tâches reste), le Kanban (les tâches vont de spécialiste en spécialiste, un goulot d'étranglement est facilement identifié). De Scrum a pris des réunions quotidiennes pour maintenir une compréhension de qui fait quoi. Ils ont également évalué la complexité des nouvelles tâches dans les récits. Je voulais, mais je ne pouvais pas utiliser les sprints, car le client a parfois modifié la priorité des tâches, et il n'est plus possible de réguler la quantité de travail après le début du sprint.

Après la réunion, les tâches sont hiérarchisées dans un carnet de commandes, un exécuteur testamentaire est affecté et transféré vers À faire. Le développeur crée une branche dans BitBucket, la tâche passe automatiquement à Doing. Une fois terminé, le «développeur» passe à Review, l'artiste passe à un autre développeur. Si tout va bien, le «réviseur» fait une fusion et le code est sur le serveur de test. Jira envoie la tâche au testeur. Après vérification, QA le transfère au gestionnaire. Cela montre le client. Le client est satisfait - le code est envoyé au serveur de combat sous la surveillance étroite des tests automatiques quotidiens.

Merci pour cette automatisation, merci à nos ingénieurs devops. Je viens de configurer le changement de statuts et d'exécuteurs pour les événements de git. Cela se fait dans les paramètres des processus métier, si vous travaillez au sein de l'écosystème atlasien. Et lors de l'utilisation de GitLab, Bitrix, Redmine devra bricoler.

Solutions

Voyons ce que nous avons réussi à réaliser:

L'absence de lien visible entre les tâches du client et l'équipe. Les
tâches commerciales sont enregistrées dans Jira sous forme d'histoires (épiques), elles peuvent être visualisées avec un pourcentage d'achèvement et un diagramme de Gantt. Le développeur, effectuant la tâche, voit à quelle histoire il appartient, peut aller lire la description.
Hiérarchisation incorrecte Le
concepteur, ayant terminé la tâche plus tôt, en prend une nouvelle en haut de la liste des tâches, où elles sont hiérarchisées par le rapport du point de l'histoire au coût (tâches commerciales en roubles).
Il n'y a pas de représentation visuelle de l'étendue des travaux.
Tâches dans un projet. Chaque membre de l'équipe voit comment ils se déplacent le long du tableau Kanban, le déroulement général du travail. Ce qui a été fait et ce qui reste à faire.
La répartition inégale de la charge selon le temps et les
diagrammes de Gantt des employés vous permet de planifier le travail sur un horizon long (avec une mise à jour constante). Il y a une projection sur les interprètes. Cela peut être vu lorsque l'exécuteur testamentaire a 2 tâches à la fois, alors que quelqu'un ne les a pas.
Lors de la planification des délais d'exécution, les tâches des autres projets ne sont pas prises en compte.
L'ajout d'une nouvelle tâche à n'importe quel projet peut être vu dans le backlog général. La priorité par rapport aux autres tâches lui est fixée dans une seule métrique.

Des plans

Certains processus ont été réduits ou automatisés, mais beaucoup plus sont restés dans les plans:

Génération d'estimations pour le temps et le matériel des projets

Lors de l'exécution de chaque tâche, l'employé note l'heure. Connaissant les taux horaires de chaque personne, sa position, le facteur de correction (par combien multiplier pour tenir compte des coûts de l'entreprise), vous pouvez générer un tableau avec une liste des emplois et des coûts.

Règlements automatiques entre gestionnaires

Si j'ai des tâches, mais qu'il n'y a pas assez de ressources pour les terminer, je demande à un autre gestionnaire de l'entrepreneur. Quand vient le temps des rapports, j'inclus comme dépenses les heures d'argent dépensé de l'employé dans mon plan et comme revenu dans le plan d'un autre gestionnaire.

Chaque mois, je devais augmenter tout le travail, vérifier avec les gestionnaires, multiplier et soustraire sans aucune création. Si tous les employés passaient à un seul format de données (la façon de mener des projets à Jira), tous les calculs seraient possibles sans intervention humaine.

Projets simultanés Ajile (sous-prison) et Waterfall