JIRA: règles pour la préparation en temps opportun de délicieux logiciels. TLDR 1: Limites des opportunités

Plus tôt dans l'article « JIRA comme remède contre l'insomnie et les dépressions nerveuses », une option a été proposée d'utiliser JIRA pour gérer un projet de développement logiciel dans l'intérêt d'un grand client de l'État. Cependant, une manipulation imprudente des équipements d'automatisation de contrôle dans la «cuisine numérique» peut non seulement gâcher le produit, mais également entraîner de nombreuses blessures. Dans une série d'articles "Règles pour la préparation en temps opportun de délicieux logiciels", il est proposé d'étudier en détail les règles d'organisation du travail sur un projet logiciel en utilisant un catalyseur appelé JIRA. Toute critique est la bienvenue.

Source

Secrets généraux

L'intelligence est la capacité d'éviter de faire du travail, mais pour que cela se fasse.
Linus Tordvalds

Après la publication de l'article « JIRA comme remède contre l'insomnie et les dépressions nerveuses », plusieurs dirigeants se sont intéressés à notre expérience d'utilisation de JIRA et ont décidé d'introduire un schéma similaire d'automatisation de la gestion de leurs projets. Par conséquent, à la suite de la rédaction de cet essai, il était censé «attraper simultanément quelques lapins»:

- considérer séquentiellement chaque type de tâches JIRA comme un sous-processus du projet, lors de la présentation:

• unifier les spécifications de ces sous-processus;
• normaliser les règles commerciales pour le travail organisé;
• compiler des cartes des "pièges" typiques et des endroits nécessitant une "litière de paille";
• déterminer des indicateurs de performance mesurables et réalisables pour chaque type de tâche.

- formuler un énoncé du problème pour l'administrateur JIRA afin de déployer de nouveaux projets conformément à l'approche proposée;
- obtenir une réglementation informelle, mais néanmoins compréhensible et transparente sur la répartition des responsabilités de tous les employés des équipes de projet;
- formaliser les meilleures recettes trouvées lors de la résolution de situations problématiques («hacks de vie» du chef de projet);
- identifier les faiblesses jusque-là non remarquées de l'approche proposée lors de la discussion des détails de sa mise en œuvre avec les lecteurs Habr.

Je voudrais noter tout de suite: certaines des techniques décrites ont fait leurs preuves dans l'une des cuisines numériques LANIT pour la gestion de projet pour le développement et la maintenance de logiciels personnalisés dans l'intérêt d'un grand client d'État. Cependant, ce n'est pas du tout un fait que ces recommandations seront également utiles sur votre projet. D'un autre côté, nous entrons dans la terra incognita. Certaines des considérations exprimées ne sont prévues que pour la mise en œuvre. Par conséquent, si vous voyez des faiblesses dans l'approche proposée ou s'il existe des propositions constructives d'optimisation, bienvenue à la discussion dans les commentaires.

On suppose qu'après l'unification dans l'intérêt de différents dirigeants, la technologie de gestion décrite sera appliquée avec succès à des projets logiciels de différentes orientations et de différentes échelles. À son tour, l'utilisation d'un espace conceptuel unique lors de l'enregistrement des tâches JIRA crée les conditions préalables à l' évaluation automatisée de la situation actuelle dans le cadre du portefeuille de projets . En outre, il est supposé qu'une approche unifiée de l'enregistrement des résultats du travail dans JIRA simplifiera la mobilité des employés entre plusieurs groupes de projet, ce qui contribuera également à accroître la réussite des projets.

Limites du projet

Toute tâche difficile a une solution simple, facile à comprendre et incorrecte.
Arthur Bloch

Étant donné que l' algorithme d' application JIRA proposé a commencé à se «propager» à d'autres projets, il était nécessaire de repenser la question: «Qu'est-ce qui détermine exactement les limites d'un projet logiciel dans JIRA?»

Selon les adeptes du PMBoK sans nuages , la réponse à cette question est élémentaire: "Bien sûr, les limites du projet sont déterminées par la charte (passeport) du projet ." De ce point de vue, pour chaque contrat avec le client, un projet distinct doit être formé dans JIRA. De plus, le développement d'un progiciel peut souvent inclure plusieurs domaines d'activité, dans lesquels, en règle générale, plusieurs contrats sont conclus:

• développement - exigences des contrats pour la création de nouveaux systèmes (sous-systèmes);
• développement - exigences dans le cadre de contrats visant à une révision substantielle des sous-systèmes existants;
• assistance étendue - les exigences des contrats pour l'achèvement opérationnel des modules système individuels pour les changements actuels dans les processus d'affaires du client;
• support de garantie - élimination des erreurs logicielles identifiées pendant la période de garantie;
• support de base - élimination des erreurs logicielles identifiées après la fin de la période de garantie.

De plus, dans le cadre de la création du logiciel, l'équipe de projet doit résoudre des exigences qui ne sont définies par aucun des contrats. Ce sont les exigences du chef de projet liées aux activités d'avant-projet, au refactoring, à la prévente, à l'élimination des erreurs identifiées de manière indépendante, à la formation du personnel, etc.

Cependant, comme la pratique l'a montré, dans le développement réel d'un produit logiciel à long terme, il est difficile de séparer les travaux de développement et de maintenance. L'opération d'essai n'est pas encore terminée (le contrat de développement n'est pas clôturé) et le client est déjà en pleine force pour formuler des exigences pour une prise en charge étendue des composants du système qui n'ont pas encore été mis en service commercial. Le client peut être compris, car le monde change plus vite que prévu dans les contrats approuvés. Parallèlement, l'identification de nouveaux défauts logiciels se poursuit. Et l'utilisateur qui a découvert le défaut ne se soucie pas du tout sous quel contrat cette erreur doit être corrigée. De son point de vue - cela n'aurait tout simplement pas dû l'être. Afin d'attribuer l'erreur identifiée à l'un ou l'autre contrat, il faut du temps pour l'analyser, et si les projets JIRA sont répartis sur la base des contrats, un dilemme se pose: «Et dans quel projet JIRA ce défaut doit-il être enregistré?». De plus, il est nécessaire d'organiser le transfert de tâches d'un projet à un autre, en cas d'erreur de classification. Si vous affectez tous les défauts logiciels détectés à un projet distinct du groupe de support, les risques de problèmes surviennent lors de la résolution des problèmes de paiement pour les travaux à l'étape du contrat de développement ou de l'examen des plaintes concernant le non-respect du contrat de niveau de service ( SLA ).

En revanche, les chefs de service jaloux proposent que dans le cadre du projet, des projets distincts soient créés pour l'équipe support, le service analytique et le service développement et tests. Tout le monde veut être un maître à part entière dans son diocèse et ne pas être responsable des "bancs" de voisins. De plus, l'incroyable flexibilité de JIRA vous permet de créer des liens entre les tâches de différents projets.

Source

À mon avis, les approches ci-dessus pour enregistrer des projets dans JIRA sont similaires à essayer de cuisiner une soupe dans plusieurs casseroles différentes situées dans différentes cuisines. L'objectif principal du projet est la création en temps opportun d'un produit logiciel d'une qualité donnée. Du point de vue du client, la qualité du produit est déterminée par l'ensemble des capacités fonctionnelles de ce produit, à l'aide desquelles le client peut résoudre (c'est-à-dire de manière fiable) ses problèmes. Et peu importe pour le client fonctionnel final en vertu de quelles relations contractuelles la fonctionnalité requise a été créée. De même qu'il n'est pas important pour le pilote de connaître la liste des sous-traitants impliqués dans la création de son avion.

Dans cet esprit, la définition des limites d'un projet JIRA devrait assurer l'harmonie entre les deux considérations suivantes.

1. Il est nécessaire que le projet reflète tout le travail effectué lors de la création / modification du produit logiciel (ou de son sous-système). Le projet doit être considéré comme un processus unique pour la création d'un produit logiciel (un «avion»). Par conséquent, le principe principal: un produit logiciel - un projet JIRA. Il est important de ne pas oublier ce que votre entreprise produit - un «avion» ou un «moteur pour avions». Dans tous les cas, les créateurs de logiciels ne doivent pas être éloignés des conséquences de leurs décisions.
   
   Quel que soit le type de relation contractuelle avec le client, le point d'entrée dans le processus de création d'un produit logiciel est toute exigence pour sa modification. L'événement final est la réception de la confirmation du client que cette exigence a été mise en œuvre (ou déclarée insolvable). Cette règle est la principale pour évaluer l'exhaustivité de la planification et l'exhaustivité des tâches dans le projet JIRA.
   
   Il est souhaitable que le projet JIRA trouve également une place pour les travaux auxiliaires qui ont été initiés dans le but de répondre aux exigences du client. Au cours du développement du logiciel, de nombreux événements ont lieu qui, en règle générale, restent «en coulisses»: réunions régulières pour clarifier les délais, déployer des serveurs de test, préparer des données de test, générer des instructions supplémentaires, etc. JIRA peut être d'une grande aide pour détecter les trous à travers lesquels le temps de travail des employés de l'équipe de projet s'écoule généreusement et irrévocablement. Mais seulement à condition que ces œuvres soient enregistrées dans le projet JIRA.
2. Dans le cas du développement de très gros systèmes logiciels, vous ne devez pas tout regrouper dans un seul projet JIRA, ce qui augmente considérablement le risque de perturbation. Dans de tels cas, dans un projet JIRA distinct, il est conseillé de regrouper par fonctions logicielles qui prennent en charge l'un des processus commerciaux du client (en règle générale, ces fonctions sont attribuées à des sous-systèmes distincts déjà au stade de la conception).

Source: Sergey Arkhipenkov. Évaluation de projet: charlatanisme ou chamanisme

Il convient de réfléchir à la formation de projets JIRA individuels pour enregistrer les résultats des travaux régulièrement réalisés dans le cadre de plusieurs logiciels (par exemple, prendre en compte le temps passé par les salariés à étudier les nouvelles technologies ou les travaux liés aux sauvegardes).

L'une des restrictions d'un projet JIRA peut être le nombre maximum d'employés de l'équipe de projet. L'expérience personnelle suggère la conclusion suivante: la composition maximale de l'équipe de développement sur un seul projet JIRA suit la règle Miller (dans les meilleures traditions d'Agile). Le groupe de développement se réfère ici aux programmeurs et analystes qui formulent les tâches pour eux. Et, bien sûr, le chef de projet. (Comme vous pourriez le penser! C'est sacré!) De plus, si le budget du projet le permet, les 80% restants des employés de l' équipe de projet, composés de filles de l'équipe de soutien amicale, de testeurs grincheux, de rédacteurs techniques ennuyeux et d'un administrateur de système amusant, peuvent être inclus en toute sécurité et harmonieusement dans le projet JIRA.

Comment mettre des tâches sur les étagères

Dans mon grenier, il n'y a que les outils dont j'ai besoin. Ils sont nombreux, mais ils sont en parfait état et toujours à portée de main.
Sherlock holmes

Sur tout projet, la navigation des collaborateurs dans le flux de tâches à résoudre est l'une des composantes importantes de la réussite. Cependant, à mesure que le volume du projet augmente, il devient de plus en plus difficile de comprendre ce flux, qui peut devenir, en soi, l'un des problèmes de gestion d'un grand projet. Par conséquent, la définition d'un système de coordonnées unique dans lequel tous les participants clés pourraient également naviguer facilement fait partie intégrante de l'automatisation de la gestion de projet.

La base d'un tel système de coordonnées dans notre projet était les considérations suivantes: un produit logiciel, en règle générale, peut être imaginé comme une boîte noire qui communique avec le monde extérieur de trois manières principales:

• via l' interface utilisateur ;
• grâce à des documents formés pour l'impression sur papier;
• via des protocoles d'échange de données électroniques ( API / EDI ).

C'est dans l'espace de ces trois dimensions que les utilisateurs finaux voient les logiciels. D'autre part, la création de logiciels vise précisément la formation et le traitement de ces flux de données.

Source

De plus, les principaux objets de la base de données et les processus commerciaux automatisés ont été adoptés comme coordonnées supplémentaires au sein du projet. Pour naviguer dans cet espace de coordonnées, des classificateurs appropriés ont été formés, dont le soutien a été fourni par le chef de projet et les analystes. Chaque élément du classificateur consistait en un code et sa définition.

Au fil de mes projets, pour chaque classificateur, ses propres caractéristiques se sont progressivement révélées, à prendre en compte si vous décidez d'appliquer une approche similaire.

• Dans notre cas, les codes des formulaires imprimés ne répétaient pas la numérotation des formulaires selon les documents du client. De plus, les formulaires individuels avaient plusieurs options d'impression. Ainsi, par exemple, tout au long de l'existence d'un logiciel, la forme de l'un des rapports a changé plusieurs fois en fonction des modifications apportées aux documents réglementaires (le nom et l'essence du rapport n'ont pas changé). Dans le même temps, pour les anciennes données, il était nécessaire de conserver l'impression de ce rapport dans les anciens formulaires. Les mêmes considérations s'appliquent à la classification dans les projets de protocoles pour l'échange électronique de données.
• Dans la hiérarchie des formulaires, les éléments individuels peuvent inclure des panneaux de navigation (menus), des formulaires de liste, des fiches d'objets, des onglets, des panneaux de filtrage, des formulaires de chargement / déchargement de données, ainsi que des formes d'opérations de groupe complexes.
• Il est souhaitable de «faire croître» les «arbres» des processus technologiques afin qu'ils aient des opérations technologiques atomiques (indivisibles), sur la base desquelles, à leur tour, il est possible d'assurer le fonctionnement du sous-système de distribution d'accès (sous-système de sécurité).
• Étant donné que tous les éléments de classification avec cette approche sont affichés sur les écrans JIRA dans un seul champ, il est nécessaire de fournir au moins une codification primitive en plus des noms des composants pour distinguer le formulaire «Inscription des employés» du processus «Inscription des employés».

Pour ceux qui ne recherchent pas des moyens simples, les tâches JIRA peuvent être marquées sur la base de l'enregistrement des codes correspondants dans le champ «Composants». Lors de l'enregistrement de tâches de tout type dans JIRA, dans le champ "Composants", il vous suffit d'indiquer la liste des codes objets pour lesquels le travail prévu vise à changer / former. Sur la base des résultats de la résolution de chaque problème, l'exécuteur testamentaire responsable devrait clarifier la composition des composants (si nécessaire). Les classificateurs de composants eux-mêmes sont ensuite conservés en dehors de JIRA.

Pour les amateurs de confort à cet égard, les sous- composants du plugin JIRA peuvent peut-être beaucoup aider.

Il convient de noter que l'utilisation de classificateurs correctement compilés de composants logiciels standardise implicitement la conscience collective et le langage de communication de l'équipe de projet, entraînant une augmentation du niveau général de compréhension mutuelle. D'un autre côté, cette approche est l'une des méthodes de coercition non violente des analystes à des tâches plus détaillées, ce qui, à son tour, augmente la précision de l'estimation du calendrier de mise en œuvre des exigences du projet.

Les règles de classification adoptées pour les tâches réduisent non seulement le temps consacré à la recherche, mais offrent également la possibilité d'automatiser:

• une estimation de l'apport total de main-d'œuvre prévu (ou coûts réels de main-d'œuvre) pour les travaux visant à la mise en œuvre de certains éléments logiciels
• évaluation de la répartition réelle des priorités - à un certain stade du projet, son gestionnaire peut être surpris de constater que la majeure partie du travail n'est pas effectuée par rapport aux composantes prioritaires,
• analyse de la qualité du développement de la documentation ,
• évaluation de la qualité de la gestion de projet en termes de planification. D'une part, il n'est pas logique de planifier des tâches dans lesquelles les composants ne sont pas formés (sont modifiés) et, d'autre part, la planification des tâches, au cours du développement de laquelle des dizaines d'objets changent, indique que le problème n'est pas énoncé de manière approfondie.

Lorsque vous attachez des tâches, ne vous attachez pas les mains

Lors de la description des principes généraux de notre modèle , il a été dit d'utiliser un seul type de connexion «raison» -> «action» (et dans le cadre du projet décrit, cette connexion était tout à fait suffisante). Cependant, le désir d'utiliser les mêmes mécanismes JIRA pour automatiser la gestion dans plusieurs projets différents a nécessité d'augmenter le nombre de types de relations utilisées et d'unifier les approches de leur application.

Source

JIRA «prêt à l'emploi» offre à l'utilisateur plusieurs types de connexions entre les tâches, et une utilisation incontrôlée de ces connexions peut entraîner de tristes conséquences. Afin de ne pas confondre nous-mêmes et les autres, nous avons convenu des règles de base suivantes pour la liaison des tâches JIRA.

• La fermeture du même type de lien dans la boucle est inacceptable (bien que JIRA le permette).
• Une relation supplémentaire «dépendante» («raison» => «action») est utilisée uniquement pour connecter des tâches de différents types, et uniquement dans le sens du «flux» du modèle en cascade classique (cascade): exigence => analyse => développement => test => documentation => implémentation. Il est inacceptable de spécifier ces connexions dans l'ordre inverse et de lier des tâches du même type à l'aide de celles-ci. Si de nouvelles exigences sont nées pendant la mise en œuvre, alors lorsque ces exigences sont enregistrées auprès de JIRA, la connexion entre elles et la tâche de mise en œuvre, au cours de laquelle elles sont apparues, n'est pas établie.
• La connexion « Blocs » («blocs» => «blocs») peut être utilisée dans n'importe quel type de tâches pour créer des séquences de workflow (par exemple, pour composer un script d'exécution de test).
• La relation « Cloners » («parent» => «enfant») est utilisée uniquement pour la communication des tâches de type «exigence». Associe le document original du client contenant plusieurs exigences («parent») à des tâches contenant des exigences atomiques «descendants».
• La relation "Supplément" ( Relatif ) ("compléments" => "est complété") n'est utilisée que pour les relations dans le cadre de tâches de type "exigence". Il est utilisé pour enregistrer la relation entre la tâche de l'exigence principale et les tâches dans lesquelles les erreurs, les commentaires et les clarifications identifiés lors des tests sont enregistrés. En fait, en utilisant ce type de communication, l'enregistrement de l'historique des changements d'exigences est fourni.
• La relation «Dupliquer» («duplicate» => «duplicate») est utilisée uniquement pour la communication des tâches de type «exigence». Lors de la spécification de doublons, il est nécessaire de déterminer l'exigence de base, dans le cadre de laquelle des travaux seront prévus sur sa mise en œuvre. En ce qui concerne les doublons, les communications avec les tâches de mise en œuvre ne sont pas créées.

Flux de travail pour toutes les occasions

La raison de nombreux problèmes est que nous définissons autant de tâches que nécessaire, et pas autant que nous pouvons le faire.
Maxim Dorofeev

, JIRA, . , JIRA (workflow). .

. «» . , JIRA . , .

, «» «», «» ( , ).






, .
*

, :

— ;

— ;

— .


« » «» . , . «». , . «» ( ).

BPM ( business process management ), . BPM «» , :

• - ( BPM CBOK );
• ( PM BOK );
• ( ITIL );
• ISO 9000 ;
• ( CMMI SEI );
• , , / 12207-2010 « . . ».

PMP ITIL . , , BPM , , . BPMS . - BPM ( , , Agile ). BPM « » ( , ). «» «» ( ). «»?

BPM . , , , BPM , .

Source

JIRA . , JIRA , , . BPM. , JIRA BPMS. Toutes les autres suggestions d'utilisation de JIRA pour automatiser la gestion de projets logiciels seront faites en tenant compte de cette considération clé.

L'une des premières étapes de l'échelle CMMI consiste à identifier, documenter et unifier les processus organisationnels. Par conséquent, dans le cadre de la série d'articles «JIRA: les règles pour la préparation en temps opportun de logiciels savoureux», il est censé formuler de manière cohérente des spécifications pour tous les types de tâches à résoudre et essayer de formuler l'appareil de critères pour leur évaluation complète du point de vue de l'approche processus. Le prochain article sera consacré aux caractéristiques de l'enregistrement des tâches de type «exigence» et aux processus métier pour leur mise en œuvre.