Comment mettre en place un processus de gestion de projet efficace dans des conditions où «bien» et «quoi de mieux» ne peut pas être fait, mais doit encore l'être? L'article donne un aperçu de l'utilisation de JIRA pour gérer un projet de développement de logiciels dans l'intérêt d'un grand client gouvernemental. Je serai heureux si les approches décrites vous aideront à augmenter personnellement l'efficacité de votre équipe et à réduire la tension sur le projet. Toute critique est la bienvenue.
SourceFils d'erreurs difficiles
À en juger par le grand nombre d'articles modèles sur Internet sur la façon d'appliquer correctement les systèmes de gestion de projet dans le développement de logiciels, il s'agit d'une entreprise simple et reconnaissante. Cependant, l'utilisation réelle de systèmes de contrôle automatisés dans des projets auxquels j'ai eu la chance de participer n'était pas aussi "rose" qu'on pourrait s'y attendre. Plusieurs cas typiques ont été rencontrés dans la pratique.
Les meilleures options se sont résumées à l'utilisation par l'équipe de projet de l'un des nombreux systèmes de suivi des bogues. La structure des tâches et des processus commerciaux d'un projet se développait généralement «prête à l'emploi». Ces systèmes étaient principalement utilisés par des équipes de programmeurs et de testeurs. Une telle organisation de développement a bien payé sur de petits projets avec des clients privés, ou si les tâches des artistes interprètes ou exécutants ne comprenaient que le support de garantie pour le produit logiciel (correction des erreurs détectées). Cependant, avec la croissance de nouvelles exigences, cette approche a commencé à glisser. Cela s'est manifesté par une augmentation du temps passé à comparer les besoins des clients et les informations stockées dans le bugtracker (et à compiler manuellement les rapports intégrés), ainsi qu'à diviser l'équipe en deux camps (les «bons» programmeurs et les «mauvais» analystes).
D'autres situations se résumaient à des inspirations «brillantes» des dirigeants, lorsque, à l'aide de leviers administratifs, les meilleures méthodologies de développement logiciel étaient «introduites» dans les activités des équipes de projet. Il est vrai que ces dirigeants pensaient que leurs actions se limitaient uniquement au processus de recherche de cette «solution miracle». Ils ne se sont pas souciés de concepts tels que «
sprint », «
diagramme de combustion de tâche » ou «
diagramme de flux cumulatif ». Et même si cela les dérangeait, les documents de rapport qui devaient être préparés sur l'état du projet (encore une fois manuellement) étaient vaguement liés à cette meilleure méthodologie. Les tentatives de familiariser les clients avec ces méthodes ont conduit au fait que les conditions du projet n'ont pas changé et aux anciens rapports, il a en outre été nécessaire de générer de nouveaux rapports supplémentaires (selon la nouvelle méthode). De telles contradictions étaient particulièrement prononcées sur les projets de marchés publics, dont les conditions d'organisation étaient directement en conflit avec l'application réussie d'
Agile ,
RUP ou
PMBOK .
L'apothéose de l'automatisation de la gestion était le projet visant à affiner le système d'information au niveau fédéral dans l'intérêt d'un grand client d'État. Dans le cadre de ce projet, le client lui-même a utilisé
HP Service Manager et
JIRA . HP Service Manager a été utilisé pour collecter et analyser les erreurs logicielles. Avec l'aide de JIRA, le client a planifié les activités de ses employés liées à la correction de ces erreurs et au développement ultérieur du système. La liste des états de tâche dans ces systèmes prévoyait toute la gamme d'options possibles pour leur traitement. Les procédures détaillées de prise en charge de ces tâches, formées par le bureau de projet du client (c'est-à-dire les personnes qui ne sont pas responsables de la maintenance et du développement), ont été publiées sur la plateforme
Confluence . Les employés de l'entrepreneur ont été autorisés à utiliser les deux systèmes, et ils ont été chargés de prendre en charge les incidents et les exigences (avec des directives temporaires pour le traitement des tâches et une échelle progressive des amendes). En outre, une copie de JIRA a été déployée sur le site du contractant, avec l'aide de laquelle les activités de l'équipe de projet ont été planifiées. La synchronisation des activités des trois systèmes a été effectuée manuellement (pour cela j'ai dû garder une «feuille» dans Excel, dans laquelle la relation des tâches et leur état actuel ont été notés). En outre, les rapports générés par JIRA ne convenaient pas à la direction, et l'équipe de projet a donc dû fournir des rapports horaires sur leurs activités, qu'ils ont également créés manuellement dans Excel. La situation n'était pas rare lorsque le chef de l'équipe de développement ou le chef des groupes de soutien «suspendaient» le travail jusque tard dans la nuit, générant des rapports de synthèse sur l'état du projet sur la base des résultats de l'équipe de projet. Ce projet a été achevé avec succès dans les délais et a été retenu, à l'exception d'une productivité record, d'une augmentation du nombre de dépressions nerveuses, d'un épuisement professionnel rapide et, à en juger par les primes des employés «survivants», d'une marge étonnamment faible. Après de tels projets, la pensée nous hante depuis longtemps: «Si nous créons des outils qui facilitent grandement la vie des clients, alors pourquoi, à cause de ces outils, nous aggravons-nous si sophistiqué nos vies?»
Caractéristiques du développement national
En résumant l'expérience, nous pouvons conclure que les plus grands problèmes avec l'automatisation de la gestion du développement logiciel se sont produits sur les projets pour les commandes de l'État.
SourceDe plus, des tentatives répétées pour résoudre ces problèmes conformément aux meilleures pratiques de développement de logiciels ont conduit à la conclusion: ce ne sont pas des problèmes, mais des conditions inévitables pour la mise en œuvre du projet pour le client de l'État. Une analyse de plusieurs projets a permis d'identifier les traits caractéristiques généralisés suivants de telles conditions:
- souvent les exigences initiales des spécifications techniques sont formulées de manière vague, le client investit dans ces exigences toutes les nouvelles significations au fur et à mesure que le projet se développe (ce qui est associé, entre autres, à un changement du cadre réglementaire actuel régissant les processus commerciaux automatisés);
- l'éventail des exigences enregistrées dans les termes de référence va de «corriger l'inscription» à «mettre en œuvre un sous-système de suivi et d'analyse de tous les processus», tandis que toutes les exigences doivent être mises en œuvre sans condition (en règle générale, les propositions visant à affiner la formulation ne sont pas acceptées, vous ne pouvez influencer que certains limites de la méthode de mise en œuvre);
- parfois, le client, n'ayant aucune idée de la façon de résoudre le problème, «pousse» ces problèmes sur le contractant, y compris les exigences qui sont, pour le moins, «ésotériques» (quelque chose comme «... le sous-système devrait fournir une prévision du taux de change des principales devises pour court, moyen et long terme ... ");
- dans le cas où le contrat est lié à l'amélioration du système existant, le client exige l'introduction de composants individuels avant l'opération d'essai avec la garantie du fonctionnement ininterrompu de l'ensemble du système (peut être comparé à l'achèvement d'un moteur de voiture sur le pouce)
- le client est représenté par plusieurs unités (organisations) dont les exigences sont souvent contradictoires;
- le budget et les délais du projet restent inchangés malgré le changement et l'ajout d'exigences;
- les clients ne recherchent pas la coopération avec les développeurs (la coopération est basée sur le principe «vous le faites d'abord, puis nous verrons»); les représentants des clients évitent la responsabilité de prendre des décisions concernant la spécification des exigences, le calendrier de la coordination des problèmes problématiques est ignoré, il est inutile d'exiger une coordination avant le début du développement, car le fait que l'équipe ne respecte pas les délais ne concerne pas le client (c'est-à-dire que ce sont nos problèmes d'interprètes);
- d'une part, le client exige la conformité exacte de l'ensemble de la documentation avec les exigences formelles de GOST, d'autre part, l'élaboration d'instructions supplémentaires pour l'utilisation du produit dans la résolution de problèmes particuliers.
En règle générale, tous ces facteurs provoquent l'indignation de l'équipe de projet face aux «clients inadéquats» et à la «mauvaise gestion du projet». Cependant, compte tenu de l'objectivité et de la répétabilité des conditions ci-dessus, les plaintes de l'équipe de projet concernant la "complexité" du client de l'État s'apparentent aux plaintes de l'équipe du navire concernant le froid et l'obscurité de la nuit polaire, après que la compagnie maritime a remporté un grand appel d'offres pour le transport le long de la
route de la mer du Nord .
En plus des conditions externes, il s'est avéré que les caractéristiques communes sont partagées par les équipes d'employés impliqués dans le projet logiciel.
- Le noyau de l'équipe de projet peut comprendre de 5 à 12 employés: chef de projet, analystes, testeurs, rédacteurs techniques, programmeurs. Malgré le fait que certains employés puissent parfois jouer plusieurs rôles, ces équipes de projet se caractérisent généralement par un faible « facteur bus ». Cela en soi impose également des restrictions sur l'utilisation des méthodes Agiles (par exemple, il est peu probable que l'utilisation de la programmation de poker dans de telles conditions soit utile).
- L'équipe de projet, ainsi que les processus de développement de logiciels, doivent fournir simultanément un support de garantie (correction des erreurs logicielles) et un support étendu (achèvement opérationnel des modules système individuels pour les changements en cours dans les processus commerciaux du client).
- Dans le cadre de l'exécution de tâches individuelles, des employés de services adjacents de l'entreprise sont impliqués, ainsi que des sous-traitants (entreprises externes imposées par le client), pour lesquels les tâches du projet sont généralement de priorité secondaire.
Victoire d'espoir
Le deuxième mariage est la victoire de l'espoir sur l'expérience de vie.
Samuel Johnson
Il y a deux ans, j'ai été invité en tant qu'analyste de premier plan à un projet réalisé par
LANIT sur ordre du gouvernement. L'équipe de projet a été formée plus tôt, le projet consistait en un raffinement substantiel du système automatisé qui existe depuis plus d'une décennie. En général, les conditions du projet étaient telles que décrites ci-dessus. À cette époque, l'équipe de développement n'utilisait aucun des systèmes de gestion de projet existants dans son travail (bien que presque tous les employés aient participé à des projets où de tels systèmes étaient utilisés et avaient une opinion plutôt sceptique quant à la nécessité d'une automatisation de la gestion). Cependant, la situation initiale actuelle a permis de tester l'automatisation de la gestion de projet «à partir de zéro».
JIRA a été choisie comme plate-forme d'automatisation. Une combinaison des facteurs suivants a contribué à ce choix:
- la capacité d'enregistrer les relations entre les tâches plusieurs à plusieurs;
- flexibilité des paramètres pour la version en boîte;
- sauvegarde de l'historique de toutes les modifications du projet;
- architecture partiellement ouverte, possibilité de raffinement selon vos besoins;
- la capacité d'interfacer avec des systèmes externes déjà utilisés par l'équipe de projet (SharePoint, Git, SVN, etc.);
- la possibilité d'utiliser sur votre serveur (pour les projets fermés);
- la présence dans l'unité d'un employé ayant une expérience significative dans l'administration de ce système et souhaitant unifier son application.
Historiquement, JIRA version 6.4 a été prise pour une utilisation dans le travail, cependant, les éléments individuels des solutions qui ont été implémentées sur cette version dans notre projet sont apparus partiellement dans les nouvelles versions JIRA prêtes à l'emploi (ce qui a confirmé indirectement l'exactitude des décisions prises).
L'automatisation de la gestion de projet a initialement poursuivi les objectifs suivants:
- améliorer la qualité du sommeil des employés de l'équipe de projet (comme vous le savez, une personne reposée travaille beaucoup plus efficacement);
- assurer une répartition transparente des responsabilités pour la mise en œuvre des tâches du projet;
- assurer le «multithreading» de l'équipe de projet, c'est-à-dire paralléliser le travail dans la mesure du possible;
- fournir une formation automatique de l'état actuel des choses concernant la mise en œuvre de chacune des exigences du client;
- assurer le suivi de l'état actuel du projet, permettant d'identifier les problèmes et les risques du projet dès les premières étapes;
- pour former des approches unifiées pour la comptabilité, des méthodes pour évaluer et comparer l'état de divers projets de développement de logiciels (similaires aux services Google Analytics ou Yandex.Metrica , qui vous permettent d'évaluer n'importe quel site avec les mêmes indicateurs);
- pour augmenter la précision de l'estimation du calendrier des tâches, sur la base des statistiques collectées.
Pour éviter «l'automatisation pour l'automatisation», les considérations (limitations) suivantes ont également été prises en compte lors de la conception d'un modèle de comptabilité des données dans JIRA:
L'automatisation de la gestion de projet ne devrait pas ennuyer l'équipe de projet. Compte tenu de l'expérience négative antérieure dans l'automatisation de la gestion de projet, l'un des principaux facteurs de mise en œuvre a été la création de telles conditions que chaque employé de l'équipe de projet a perçu JIRA non pas comme une charge supplémentaire dans le bateau du projet, mais comme un système de navigation collectif qui avertira l'équipe en temps opportun d'un danger imminent et contribuera à atteindre l'objectif. projet de la manière la plus courte et la plus sûre. De plus, l'utilisation de ce système de navigation devrait faciliter la vie de tous les membres de l'équipe, et pas seulement la gestion de projet. Pour ce faire, la procédure de travail avec JIRA a été initialement planifiée en tenant compte de la minimisation de la quantité de données enregistrées par les programmeurs, les testeurs et les rédacteurs techniques. D'un autre côté, l'objectif était de créer un environnement de travail confortable dans JIRA pour tous les employés du projet, ce qui les aiderait à planifier efficacement leur journée de travail.
Garantie de continuité. L'un des objectifs de l'automatisation de la gestion de projet est d'assurer la continuité afin que tout employé qualifié puisse «reprendre» les fonctions d'un membre de l'équipe partant à la retraite sans «période d'essai» et avec un minimum de maux de tête, afin que «l'escouade ne remarque pas la perte d'un combattant». À cet égard, j'ai rappelé un cas que l'un des clients m'a dit. Une fois qu'il est resté pour le patron, qui, étant parti en vacances, lui a dit le mot de passe de son ordinateur avec une réplique: "Eh bien, tout est clair là-bas, vous comprendrez si quelque chose se passe ...". Cet employé a passé plusieurs nuits blanches à comprendre le contenu de plusieurs dossiers portant les noms «xxxxx1», «xxxxx11» et «xxxxx111» (les noms des dossiers ont été modifiés dans un souci de décence). La prévention de telles situations nécessite l'enregistrement des résultats du travail de tous les employés de l'équipe de projet, y compris le chef de projet, auprès de JIRA.
Minimalisme Le but de l'automatisation de la gestion de projet n'était pas de calculer, en moins d'une minute, combien un employé particulier consacrait du temps de travail à la résolution des tâches qui lui étaient assignées, mais de s'assurer que les tâches d'une qualité donnée étaient résolues dans le temps requis. Par conséquent, lors du déploiement d'un projet dans JIRA, le principe de minimisation des données enregistrées dans le système a été adopté. C'est-à-dire l'ensemble des paramètres enregistrés dans le système de contrôle aurait dû être minimalement nécessaire pour prendre des décisions éclairées ("La
perfection n'est pas atteinte lorsqu'il n'y a rien à ajouter, mais lorsqu'il n'y a rien à supprimer "). Il était entendu que le modèle adopté d'automatisation de la gestion de projet devrait fonctionner dans des conditions d'incertitude et d'incohérence élevées (par exemple, vous pouvez connaître la date du document, mais pas son numéro et vice versa). Lors de la saisie des informations enregistrées, nous avons utilisé, dans la mesure du possible,
la règle de Miller , qui stipule que le nombre optimal de types (états) doit se situer entre «sept plus ou moins deux» (ce qui simplifie considérablement la compréhension du travail du système par les employés). Ainsi, par exemple, lors de la conception du cycle de vie des tâches (workflow), il était initialement supposé que le nombre d'états devait respecter cette règle.
Cohérence. L'automatisation de la gestion de projet doit contribuer à la cohérence et à la cohérence des actions de l'ensemble des collaborateurs de l'équipe projet (prévention de la situation "cygne, cancer et brochet").
Dans l'un des projets auxquels j'ai participé, une équipe d'analystes a développé un modèle d'activité automatisée en notation
IDEF0 en un mois. Il semblait que l'utilisation même de la méthodologie créée par l'US Air Force (!) Garantissait le succès de cette approche. Cependant, lorsque le chef du département de programmation a étudié le rapport analytique de plusieurs pages, sa première question était: "Alors, que faut-il faire exactement?". Le modèle généré s'est avéré impropre à être utilisé comme description de l'énoncé du problème pour les programmeurs. Les représentants du client ont admiré à plusieurs reprises, échappant à de nombreux schémas, mais n'ont pas non plus trouvé d'application de ce modèle pour optimiser leurs activités. En fin de compte, ces schémas ont orné la description des processus technologiques, donnant à ce document une épaisseur et une solidité sans précédent, mais l'effet positif de l'analyse a été épuisé à ce sujet. Les résultats du mois de travail de plusieurs analystes n'ont pratiquement pas été réclamés par le projet.
Compte tenu de cette expérience, lors de l'automatisation de la gestion de projet, il était censé créer un
convoyeur de tâches unique qui assurerait une conversion coordonnée des besoins des clients en un produit logiciel final dans les plus brefs délais et à un coût minimal. Parallèlement, sur la base du suivi des
paramètres disponibles
de ce convoyeur, il était censé identifier, mesurer et développer les propriétés émergentes de l'équipe projet, grâce auxquelles il était possible de juger de l'état du projet à toutes ses étapes.
Tableau Kanban à l'envers
À mon avis, le succès de l'automatisation du contrôle dépend dans une large mesure de la précision avec laquelle l'objet de contrôle est modélisé dans un système automatisé.
Comme il était censé automatiser la gestion du processus de création de logiciels, une analyse de ce processus a été réalisée. À mon avis, le processus de création de modules logiciels séparés représente toujours le cycle de vie en cascade classique. Tout d'abord, une liste des exigences pour le produit créé apparaît. Les exigences peuvent provenir de différentes sources et avoir différents degrés de détail. Certaines exigences sont interconnectées, une autre partie est relativement indépendante. Pour les besoins individuels, vous pouvez immédiatement formuler une tâche de développement, tandis que d'autres nécessitent une clarification et une concrétisation. C'est-à-dire
il y a toujours des travaux liés à la collecte, au tri et à la clarification des besoins des clients (alors que le libellé des besoins individuels peut être ambigu jusqu'à la fin du projet). Une fois que les exigences sont aussi spécifiques que possible, en règle générale, des définitions de tâches sont formées pour des groupes d'exigences interconnectées, qui détaillent les spécificités de la mise en œuvre de ces exigences et sont le matériel source pour les programmeurs pour commencer à travailler. Après la programmation, les modules créés sont testés de manière autonome, intégrés dans le système et retestés. Selon les mises à jour logicielles terminées, des modifications appropriées sont apportées à la documentation de conception et d'exploitation, après quoi un certain nombre d'activités sont effectuées,visant à reconnaître l'achèvement des aspirations (exigences) du client et la mise en œuvre ultérieure des fonctionnalités développées dans l'exploitation commerciale.SourceLa principale différence entre la vraie vie et le beau schéma de la cascade est son caractère aléatoire (tout se passe pas par étapes et de manière incohérente). En réalité, la transition d'une phase de développement à une autre ne se produit pas nécessairement seulement après l'achèvement complet et réussi de la phase précédente. La vraie cascade a ses propres backwaters de contradictions, backwaters et shallows d'indifférence, des marécages de verbiage, des rapides et des tourbillons d'ambiguïté, des rapides et des pierres glissantes d'imagination débridée, et, souvent, des fontaines et même des geysers de nouvelles exigences. Il n'est pas possible de refaire cet élément dans le cadre du projet, tout comme il est impossible pour l'équipe du navire de refaire la rivière le long de laquelle il est nécessaire d'assurer la livraison de la cargaison du client.Pour la transparence de la répartition des responsabilités dans l'automatisation de la gestion de projet, le principe "1 tâche - 1 exécuteur" a été mis en œuvre. C'est-à-dire
le processus de réalisation d'une tâche n'impliquait évidemment pas son transfert à d'autres interprètes. Ce principe a permis d'appliquer le même processus de gestion à tous les types de tâches, car le statut du travail était déterminé principalement du point de vue de l'exécutant de cette tâche. Le workflow JIRA standard a été légèrement modifié. Le principal changement a été le remplacement du statut «redécouvert» par le statut «en attente», c'est-à-dire indique quand le travail sur une tâche est suspendu pour une raison quelconque. Pour enregistrer les tâches redécouvertes, le champ utilisateur "Compteur de redécouverte" a été utilisé. Dans le même temps, les types de raisons du transfert de tâches en prévision d'une solution ont été détaillés:- coordination avec le client;
- demande d'informations complémentaires auprès du client;
- attendre la solution des tâches / sous-tâches connexes;
- une clarification de l'énoncé du problème est nécessaire.
Il convient de noter que l'introduction du statut «en attente» a effectivement mis en œuvre le « bouton d'arrêt du convoyeur » pour les employés de l'équipe de projet , ce qui a permis à son tour d'identifier collectivement les problèmes dans les premières phases du projet.
À la suite de l'analyse, le modèle suivant d'enregistrement des informations du projet auprès de JIRA a été mis en œuvre. L'approche standard de partage des tâches représentée par JIRA n'a pas été utilisée dans le projet. Six types de tâches ont été créées, qui correspondent essentiellement aux principales étapes du développement logiciel:- «Exigence» - type de tâche pour enregistrer les exigences des clients (similaire dans les nouvelles versions de JIRA - epic);
- «» – , ( ) ( ) ( JIRA – story);
- «» – ;
- «» – , ;
- «» – , ;
- La «mise en œuvre» est le type de tâche pour enregistrer les résultats des travaux visant à introduire les logiciels développés dans les activités du client (effectuer des tests, des démonstrations, publier une version / un correctif / un correctif de données, déployer des logiciels sur les serveurs du client, former les utilisateurs, etc.).
Des sous-tâches ont été utilisées pour résoudre des problèmes particuliers (dont le temps ne dépasse pas deux heures) pendant l'exécution de la tâche principale (par exemple, pour coordonner une décision de conception avec un programmeur ou un chef de projet, effectuer des revues de code, préparer des données de test, etc.).Conformément aux règles établies sur le projet, l'enregistrement d'une exigence est une base obligatoire pour planifier d'autres tâches. Après enregistrement de l'exigence et sa clarification auprès du client (si nécessaire), d'autres types de tâches sont formées, visant à mettre en œuvre cette exigence. En d'autres termes, dans le cadre du modèle adopté, d'autres tâches devraient toujours être associées à l'exigence dans l'intérêt de laquelle elles sont remplies (en utilisant le type de connexion «cause» -> «action»). Dans l'intérêt de la mise en œuvre d'une exigence, plusieurs tâches de développement peuvent être créées, d'autre part, une tâche (pour l'analyse, le développement, les tests, la documentation, la mise en œuvre) peut être créée dans l'intérêt de plusieurs exigences (contrairement à l'approche JIRA standard, lorsqu'elle est supposéequ'une tâche ne peut être associée qu'à une seule tâche de type épique). Dans le cadre du modèle proposé, il est également possible de relier d'autres tâches dépendantes. D'une part, cette approche assurait la cohérence des décisions prises, d'autre part, elle offrait la possibilité d'une réflexion assez précise de l'état réel des choses sur le projet. Dans ce cas, différentes options d'organisation du travail sont possibles, dont la confusion semble très difficile.
- bleu - la tâche est incluse dans le plan de travail;
- bleu - la tâche est en cours;
- rose - la tâche n'a pas d'exécuteur testamentaire;
- jaune - la tâche est en attente, nécessite une solution;
- gris - la tâche est fermée (vous pouvez l'oublier);
- orange - les délais pour terminer la tâche ont été interrompus.
L'apparition d'inscriptions et de marques rouges sur la fiche de tâche indique la nécessité d'une action immédiate par rapport à la tâche (par exemple, l'inscription est affichée en rouge si la date limite n'a pas été fixée).En plus des couleurs, au fur et à mesure du développement du projet, les fiches de tâches du tableau de bord sont entourées de balises supplémentaires qui vous permettent d'évaluer en un coup d'œil l'état d'avancement du travail sur le projet.Étiquettes de priorité:
- Normal;
- important;
- critique;
- blocage.Labels sur le cadre d'exigences:
- développement (exigences dans le cadre de projets visant à une révision substantielle des systèmes existants);
- assistance étendue (exigences pour l'achèvement opérationnel des modules système individuels pour les changements en cours dans les processus commerciaux du client);
- support de garantie (erreurs logicielles détectées);
- activités hors projet (exigences du chef de projet liées aux activités d'avant projet, refactoring , prévente , développement de nouvelles technologies, formation du personnel, etc.).Étiquettes du motif de l'attente:
- demande d'informations complémentaires auprès du client;
- coordination avec le client;
- attendre la solution des tâches / sous-tâches associées;
- une clarification de la formulation est requise.Balises spéciales:
- la base de données a été finalisée dans la tâche;
- le nombre d'exigences liées à la tâche (plus les exigences sont liées, plus la tâche est importante);
- le nombre de sous-tâches non résolues;
- la tâche est redécouverte.En fait, ce tableau de bord est devenu le principal outil pour recevoir quotidiennement une réponse à la question de la gestion de projet: «Qu'est-ce qui est le plus important aujourd'hui?», Ce qui nous a permis de répondre en temps opportun aux problèmes. Du point de vue du modèle proposé, pour éviter les problèmes sur le projet, il est nécessaire d'assurer une réduction quotidienne de la quantité de rouge, orange et jaune dans le tableau de bord proposé. D'un autre côté, le manque de tâches connexes pour le besoin (c.-à-d. La situation lorsque le besoin est planifié et qu'il n'y a pas de travail pour le mettre en œuvre) était également une source de préoccupation.L'utilisation de filtres pour le tableau de bord créé a permis dans le complexe de refléter la situation en fonction de la liste d'exigences sélectionnée. Grâce à son aide, il a été possible de coordonner rapidement les actions de toute l'équipe du projet, en concentrant les efforts sur les domaines les plus problématiques, sans perdre une image globale du projet.La cascade ne peut pas être agile
Afin d'enregistrer les résultats des travaux sur tous les types de tâches, deux référentiels ont été déployés (pour la documentation du projet et pour le code logiciel). L'ajout (modification) de matériaux dans ces référentiels se reflétait automatiquement dans les tâches connexes de JIRA et constituait le principal type de rapport par les artistes interprètes.L'organisation du travail selon l'approche proposée pour l'enregistrement des tâches dans JIRA a été réduite au schéma suivant.- JIRA ( ) . (, ) . (/), . , ( , ), , ( ) . ( ) . .
- , . , , , . () .
- , , . , , ( ), () , , , ( ).
- ( ) , , . . , . «» , ( ).
- Idéalement, les tâches de test doivent être formées avant d'enregistrer les tâches de développement (qui spécifient les objectifs des programmeurs). Pendant le test, le testeur responsable tient non seulement un journal des erreurs détectées, mais corrige également les inexactitudes détectées dans la tâche de test et le manuel de l'utilisateur.
- Selon les exigences, selon lesquelles une liste complète des travaux était prévue, des tâches de mise en œuvre sont formées (lors de l'enregistrement dont la priorité et les délais de mise en œuvre des exigences sont à nouveau précisés dans JIRA).
- Après livraison au client, la demande peut être transférée au statut «clôturé» avec l'indication obligatoire des détails du document d'acceptation.
Il convient de noter que la formation de tâches de tous types pour la mise en œuvre d'une exigence unique n'est pas une condition préalable à une planification réussie. Par exemple, une exigence simple telle que «corriger une erreur dans un nom de champ» peut être affectée directement à un programmeur. Dans le même temps, lors de la mise en œuvre du projet, il a été noté que la part du lion des commentaires lors des tests préliminaires et de l'opération d'essai représentait des exigences pour lesquelles aucune décision de conception n'était prise.
Dans le cadre de la démarche proposée, la planification des travaux à
l' aide de
la méthode de planification des vagues déferlantes a fait ses preuves. Dans le même temps, en partie grâce au tableau de bord décrit ci-dessus, il a été possible d'éviter la fragmentation et l'incohérence des travaux prévus. Aux stades initiaux de l'enregistrement, la sélection selon les exigences ressemblait à un
parapluie rouge , lorsque pour la plupart des exigences, les dates de disponibilité et les cadres responsables n'étaient pas déterminés, et le travail n'était prévu que pour une petite partie d'entre eux. Cependant, le tableau de bord des exigences s'est progressivement transformé en tapis bleu-vert. Les taches rouges et oranges apparaissant sur ce tapis nous ont obligés à effectuer des ajustements quotidiens aux tâches prévues, ce qui a permis de réduire les risques du projet.
Le modèle d'organisation des données proposé a montré une bonne évolutivité. Initialement, seuls trois employés de l'équipe de projet (un analyste et deux programmeurs) ont utilisé JIRA dans leur travail, tandis que les exigences pour les sous-systèmes individuels étaient enregistrées. Cependant, à la fin du projet, 100% des exigences de développement et de support étendu ont été enregistrées et suivies chez JIRA avec la participation de tous les employés de l'équipe de projet.
Malgré le fait que l'idée d'automatisation de la gestion de projet était basée sur un modèle de développement en cascade (cascade), il s'est avéré que dans le cadre de l'approche proposée, si souhaité, les éléments Agiles peuvent être utilisés sans douleur. Et qui, en général, a dit que la cascade n'était pas flexible? Par exemple, pour appliquer
Scrum , dans le cadre du modèle proposé, il suffit d'assurer la régularité des événements (tâches) pour l'implémentation du logiciel, puis, en conséquence, tous les travaux associés à cet événement seront «forcés» d'obéir aux règles de sprint ainsi définies.
En outre, la méthode proposée pour l'enregistrement des tâches ne limite pas le chef de projet à appliquer l'approche Kanban et à utiliser toute la variété des
tableaux de bord Agile que JIRA propose «prêts à l'emploi».
À suivre
Quel est le résultat? Le logiciel développé a été mis en service commercial. Lors des tests préliminaires, du fonctionnement d'essai et des tests d'acceptation, le client a enregistré de nombreux commentaires sur le produit logiciel implémenté. Cependant, par la suite, sur la base de documents clarifiant les exigences stockées dans JIRA, le client a été contraint de reconnaître 25% des commentaires comme de nouvelles exigences qui dépassaient la portée du projet (la complexité prévue pour répondre à ces exigences était proportionnelle à la tâche technique achevée). Les problèmes liés à la mise en œuvre du contrat de commandes publiques n'ont pas disparu, cependant, le suivi du respect des exigences à l'aide de JIRA a permis d'identifier les risques de perturbation au stade de l'initiation et d'y répondre rapidement. Ceci, à son tour, a assuré la dynamique positive du projet à toutes ses étapes, malgré les particularités du développement logiciel national. Il a été noté que si les exigences des clients étaient enregistrées auprès de JIRA et que des tâches d'analyse, de développement et de test étaient formées à leur sujet, il y aurait alors beaucoup moins de désaccords et de différends concernant ces exigences.
Au stade actuel (phase de maintenance), toutes les exigences sont reflétées dans JIRA. Tous les employés de l'équipe de projet d'une manière ou d'une autre utilisent JIRA dans leur travail. Le coût des programmeurs pour enregistrer les résultats de leur travail dans JIRA prend moins de 1% de leur temps de travail. Pour les analystes, en revanche, JIRA est devenu l'un des principaux outils de travail. Trouver un ensemble complet d'informations pour l'une des exigences du client est moins d'une minute. Les documents de rapport basés sur les résultats des travaux effectués sont générés automatiquement sur la base des données contenues dans JIRA. En outre, sur la base de ces données, la documentation d'accompagnement pour les versions est formée (une liste de modifications et un programme de test de version).
Deux ans d'expérience dans l'application de JIRA en vertu des nouvelles règles ont confirmé d'anciennes vérités:
- JIRA ne remplace pas la gestion de projet, mais elle permet de naviguer rapidement dans le flux de diverses tâches;
- JIRA vous aidera à concentrer votre projet au bon endroit au bon moment, mais il ne le fera pas pour vous;
- JIRA ne résoudra pas les problèmes du projet pour vous, mais aidera à les identifier déjà dans les premiers stades (en même temps, il identifiera les problèmes que vous espériez cacher);
- comme tout système automatisé, JIRA vous aidera à mettre en œuvre rapidement toutes vos décisions, qu'elles soient bonnes ou mauvaises;
- JIRA ne remplace pas la communication des employés de l'équipe de projet, mais aidera à résoudre les différends sans douleur;
- JIRA ne sauvera pas un employé du licenciement, mais aidera un autre, qui a pris la place du retraité, à se mettre rapidement au courant;
- JIRA vous aidera à générer des documents de rapport de projet, mais uniquement sur la base des informations pour lesquelles vous avez fourni l'enregistrement.
Et surtout - JIRA ne décidera pas pour vous si vous utiliserez son aide ou non.
Jobs LANIT pour les intéressés