Préambule
L'une, une banque russe de taille moyenne, possède une banque Internet pour les physiciens et les avocats, des sites Web et des applications mobiles. Et il y a aussi une subdivision qui accompagne et développe toute cette économie. Voici le jeune Leader, qui a travaillé dans cette organisation pendant plus de 3 ans, au nom de qui cette histoire sera.
Contexte
La banque est moderne, les processus sont construits selon ITIL, à première vue tout ressemble à un manuel. Comme vous pouvez le voir dans le titre de l'article, nous n'aborderons qu'une partie du processus «Faire des changements» qui nous intéresse.
Problème
Tout dans ce processus était excellent sauf un moment, à savoir, l'Analyste a convenu du calendrier de développement avec le Client - le propriétaire du produit "Banque Internet des personnes morales, web + canaux mobiles", ci-après nous l'appellerons simplement le Client. Le client a toujours compris et accepté les travaux qui ont eu lieu devant lui ou avec sa participation, à savoir:
- Clarification et formalisation de ses exigences. Il a directement vu comment une histoire de client, un prototype, et enfin une déclaration pour un développeur sont nés de ses 2 lignes de texte.
- Tous types de tests. Il a vu d'énormes listes de tests.
- Documenter. Il pouvait regarder le nombre de pages de texte et d'images (diagrammes).
- Mais en termes de développement, le client a toujours ressenti un piège, il lui a semblé qu'un chef d'équipe barbu maléfique (et en fait, une personne de bon cœur) qui a donné son évaluation, ne voit que comment y entrer 50% d'heures supplémentaires, sans prendre la peine de rencontrer le SL et d'obtenir motivation par KPI. C'est ce problème que le jeune leader a dû résoudre.
Décision
Étape 1. Comment calculer la durée de développement en termes absolus Il y
avait beaucoup d'idées, l'une d'entre elles: faire une estimation basée sur des tâches déjà terminées vaut mieux que rien, mais:
- laborieux de faire une analyse rétrospective à chaque fois
- Toutes les tâches ne peuvent pas être associées à des analogues.
Que se passe-t-il si vous ne prenez pas toute la tâche, mais divisez chacun d'eux en composants finaux de travail pour notre système (tout au long de l'article, nous appellerons la banque Internet des entités juridiques, canaux web + mobiles)?
Dans notre cas, il s'est avéré comme ceci:
- Changer la mise en page
- Créer une nouvelle page de document
- Finaliser le formulaire, afficher un nouveau champ de formulaire depuis la base de données
- Contrôle typique
- Contrôle complexe (algorithme complexe non trivial)
- Extension de schéma de base de données
- Script d'envoi par SMS
- Script pour l'envoi par signature électronique
etc. au début, il y avait environ 20 postes, et par conséquent un peu plus de 80.
Pour estimer l'intensité de travail de chaque bloc, une unité a été inventée - une unité standard de coûts de main-d'œuvre (TEC, s). SET est une mesure abstraite de l'intensité du travail, elle n'a aucune signification physique, elle peut être appelée comme vous voulez. Grâce à une analyse rétrospective (pour les 3 derniers mois), nous (moi-même, un analyste système et un chef d'équipe) avons divisé toutes les tâches en composantes finales et estimé proportionnellement la complexité de chacune d'elles (si), le résultat est dans le tableau (Tableau 1).
Maintenant, nous pouvons évaluer chaque tâche dans SET, par exemple:
- Objectif: mettre en place un formulaire de feedback sur la page principale du système, qui apparaît pour les clients qui n'ont pas donné de feedback. Le formulaire affiche:
- échelle de notation sous forme d'étoiles, en cliquant sur laquelle vous pouvez donner une note de 1 à 5,
- un champ de saisie de forme libre d'une longueur de 500 caractères,
- le bouton d'envoi, en cliquant sur lequel les données sont écrites dans la table de base de données correspondante, le formulaire se ferme sans recharger la page.
- Détermination sur les actions les plus simples, selon le tableau 1.:
- Créer une table dans une base de données existante, écrire une logique d'affichage de formulaire - 0,2 CET
- Mise en page du formulaire, 2 champs + vérification de l'exhaustivité - 1 HEC
- Ecriture d'une requête asynchrone côté serveur, écriture d'une fonction serveur pour l'écriture dans la base de données, - 1 SET
- Calcul de la main-d'œuvre dans les SET: 1 + 1 + 0,2 = 2,2 CET
Après cela, le terme productivité (p) a été introduit, qui définit la productivité de chaque catégorie de développeur (Tableau 2)
Il est maintenant possible d'estimer la durée de développement de chaque tâche à l'aide de la formule:
continuons notre exemple
4. Détermination de la durée de travail d'un salarié de la catégorie Senior:
2,2 (CET) / 1,5 (CET / jour) = 1,6 jour
Durée 1,6 jour
Nous faisons des hypothèses: ayant des développeurs full-stack, un seul d'entre eux est impliqué dans la résolution de chaque problème individuel.
Le client a tellement aimé la méthode d'évaluation qu'il a proposé d'évaluer le reste des étapes de travail:
- clarification des exigences
- planification de la mise en œuvre
- tests et documentation
au prorata du temps de développement, les coefficients suivants ont été introduits (tableau 3):
Il était désormais possible d'estimer la durée de chaque étape: la
durée totale des modifications du système, selon la formule:
par exemple:
4. Détermination de la durée de travail d’un salarié (analyste et développeur) de la catégorie Senior:
0,2 * 2,2 / 1,5 + 0,3 * 2,2 / 1,5 + 2,2 / 1,5 + 0, 2 * 2,2 / 1,5 = 0,3 + 0,44 + 1,6 + 0,3 = 2,64 jours
Durée 2,64 jours
Du coup, nous avons obtenu une méthodologie assez compréhensible, l'assemblée générale (le client, moi, l'analyste système et le chef d'équipe) a décidé de l'essayer, les premiers résultats seront poursuivis ...