L'Institut enseigne les algorithmes, les structures de données, la POO. Dans un bon cas, ils peuvent parler de modèles de conception ou de programmation multi-thread. Mais je n'ai pas entendu comment évaluer correctement les coûts de main-d'œuvre.

Pendant ce temps, chaque programmeur a besoin de cette compétence chaque jour. Il y a toujours plus de travail que ce qui peut être fait. L'évaluation permet de prioriser correctement et d'abandonner complètement certaines tâches. Sans parler de problèmes familiaux tels que la budgétisation et la planification. Des estimations incorrectes, au contraire, créent un tas de problèmes: sous-estimés - situations de conflit, traitement et trous dans les budgets, surestimés - annulation de projets ou recherche d'autres interprètes.

En toute justice, il convient de noter que la sous-évaluation est beaucoup plus courante dans le développement. Pourquoi? Quelqu'un pense que les programmeurs sont de nature trop optimiste . J'ajouterai une raison supplémentaire à cela: être un bon programmeur et être un bon évaluateur n'est pas la même chose. Pour devenir un bon programmeur, un seul désir ne suffit pas. Besoin de connaissances et de pratique. Pourquoi l'évaluation serait-elle différente?

Dans l'article, je parlerai de la façon dont mon attitude envers l'évaluation des tâches a changé et de la manière dont les projets de notre entreprise sont évalués. Et je vais commencer par la façon dont vous n'avez pas besoin d'évaluer. Si vous savez déjà comment «ne pas faire», allez directement à la deuxième partie de l'article .

Modèles anti-évaluation

La plupart des évaluations de projets sont effectuées au début de leur cycle de vie. Et cela ne nous dérange pas tant que nous ne comprenons pas que les estimations ont été obtenues plus tôt que les besoins ont été déterminés et, par conséquent, plus tôt que la tâche elle-même n'a été étudiée. Par conséquent, une évaluation n'est généralement pas effectuée à temps. Ce processus est correctement appelé non évaluation, mais supposition ou prédiction, car chaque point des exigences est un jeu de devinettes. Dans quelle mesure cette incertitude affecte-t-elle les résultats finaux de l'évaluation et sa qualité?

Une bagatelle, mais désagréable

Supposons que vous développiez un système de saisie des commandes, mais que vous n'ayez pas encore été en mesure de définir des exigences pour la saisie des numéros de téléphone. Parmi les incertitudes qui peuvent affecter l'évaluation du programme, on peut immédiatement mettre en évidence les suivantes:

Le client a-t-il besoin de vérifier la validité du numéro de téléphone saisi?
Si le client a besoin d'un système de vérification des numéros de téléphone, quelle version préférera-t-il - bon marché ou cher?
Si vous implémentez une version bon marché de vérification des numéros de téléphone, le client voudra-t-il passer au plus cher plus tard?
Est-il possible d'utiliser un système prêt à l'emploi pour vérifier les numéros de téléphone ou, en raison de certaines restrictions de conception, vous devez développer le vôtre?
Comment le système de vérification sera-t-il conçu?
Combien de temps faut-il pour programmer un système de vérification des numéros de téléphone?

Et ce ne sont que quelques questions de la liste qui se posent à la tête d'un chef de projet expérimenté ... Comme le montre même cet exemple, les différences potentielles dans la définition, la conception et la mise en œuvre des mêmes opportunités peuvent s'accumuler et augmenter le temps de mise en œuvre par centaines ou plus. Et si nous les combinons dans des centaines et des milliers de fonctions d'un grand projet, nous obtenons une énorme incertitude dans l'évaluation du projet lui-même.

Un autre excellent exemple de «gonflement» semble être une exigence élémentaire, lu dans l'article « Comment vont deux semaines?! »

Cône d'incertitude

Le développement de logiciels - et de nombreux autres projets - comprend des milliers de solutions. Les chercheurs ont constaté que les estimations du projet à différentes étapes inhérentes aux niveaux d'incertitude projetés. Le cône d'incertitude montre que les estimations deviennent plus précises au fur et à mesure de l'avancement du projet. Veuillez noter qu'au stade du concept initial (où des estimations sont souvent faites et des obligations sont faites), l'erreur peut être de 400% (quatre cent pour cent, Karl!). Il est optimal de prendre des engagements après l'achèvement de la conception détaillée.

Mois-homme mythique

Il y a encore des cadres qui pensent que si la fonctionnalité est fixée de manière rigide, une réduction de temps peut être obtenue à tout moment en ajoutant du personnel qui ferait plus de travail en moins de temps. L'erreur d'un tel raisonnement réside dans l'unité même de mesure utilisée dans l'évaluation et la planification: homme-mois. Le coût est vraiment mesuré comme le produit du nombre d'employés et du nombre de mois passés. Mais le résultat n'est pas atteint. Par conséquent, l'utilisation des hommes-mois comme unité de mesure du volume de travail est une idée fausse dangereuse. Tous les chercheurs ont convenu que la réduction de la période nominale augmente la quantité totale de travail. Si la durée nominale d'un groupe de 7 personnes est de 12 mois, une simple augmentation du personnel à 12 personnes ne réduira pas la période à 7 mois.

Dans les grands groupes, les coûts de coordination et de gestion augmentent et le nombre de voies de communication augmente. Si toutes les parties de la tâche doivent être coordonnées séparément entre elles, alors le coût de la communication augmente de façon quadratique et la «puissance» de l'équipe augmente de façon linéaire. Trois travailleurs ont besoin de trois fois plus de communication par paire que deux, quatre pour six.

L'équipe du projet essaie de faire face aux croupes // Ivan Aivazovsky, 1850

Si 8 personnes peuvent écrire un programme en 10 mois, 80 personnes peuvent-elles écrire le même programme en un mois? L'inefficacité des délais extrêmement serrés devient particulièrement évidente dans les cas extrêmes - comme 1 600 personnes qui ont besoin d'écrire un programme en une journée. Lisez plus à ce sujet dans le livre du même nom de Frederick Brooks .

Modèles d'évaluation

Donc, avec les problèmes, tout est clair. Que peut-on faire?

Décomposition

Au lieu d'évaluer une grande tâche, il est préférable de la diviser en plusieurs petites, de les évaluer et d'obtenir la note finale comme la somme des notes initiales. Ainsi, nous tuons immédiatement jusqu'à quatre oiseaux avec une pierre:

Nous comprenons mieux l'étendue des travaux. Pour décomposer une tâche, vous devez lire les exigences. Des lieux inexplicables émergeront immédiatement. Le risque de mauvaise interprétation des exigences est réduit.
Lors de l'analyse d'une analyse plus détaillée des besoins, le processus de réflexion de systématisation des connaissances démarre automatiquement. Cela réduit le risque d'oublier une partie du travail, comme la refactorisation, l'automatisation des tests ou l'effort supplémentaire de mise en page et de déploiement
Le résultat de la décomposition peut être utilisé pour la gestion de projet, à condition que pour les deux processus un seul outil ait été utilisé (cette question est discutée plus en détail plus loin dans le texte).
Si nous mesurons l'erreur moyenne de l'estimation de chaque problème obtenue lors de la décomposition et comparons cette erreur avec l'erreur de l'estimation totale, il s'avère que l'erreur totale est inférieure à la moyenne. En d'autres termes, une telle évaluation est plus précise (plus proche des coûts de main-d'œuvre réels). À première vue, cette affirmation est contre-intuitive. Comment l'évaluation finale peut-elle être plus précise si nous commettons une erreur dans l'évaluation de chaque problème décomposé? Prenons un exemple. Pour créer un nouveau formulaire, vous devez: a) écrire le code sur le backend, b) faire la mise en page et écrire le code sur le frontend, c) tester et mettre en page. La tâche A a été évaluée à 5 heures, les tâches B et C à 3 heures chacune. Le score total était de 11 heures. En réalité, le backend a été fait en 2 heures, le formulaire en a pris 4 et les tests et la correction des bogues en ont pris 5. La charge de travail totale était de 11 heures. Idéal pour être évalué. De plus, l'erreur dans l'évaluation de la tâche A est de 3 heures, la tâche B est de 1 heure et C est de 2 heures. L'erreur moyenne est de 3 heures. Le fait est que les erreurs de sous-estimation et de surestimation des estimations s’annulent. Les 3 heures économisées sur le backend ont compensé le décalage de 1 et 2 heures au niveau du front-end et des tests. Le travail réel est une variable aléatoire qui dépend de nombreux facteurs. Si vous tombez malade, il vous sera difficile de vous concentrer et au lieu de trois heures, cela peut prendre six heures. Ou un bug inattendu va apparaître qui devra être recherché et corrigé toute la journée. Ou, à l'inverse, il peut s'avérer qu'au lieu d'écrire votre propre composant, vous pouvez utiliser un composant existant, etc. Les écarts positifs et négatifs s'annuleront mutuellement. Ainsi, l'erreur totale diminuera.

Caractéristiques et tâches

Au cœur de la décomposition que nous avons est la caractéristique. Une fonctionnalité est une unité de livraison de fonctionnalités qui peut être mise en production indépendamment des autres. Parfois, ce niveau est appelé User Story, mais nous sommes arrivés à la conclusion que User Story n'est pas toujours bien adapté pour définir des tâches, nous avons donc décidé d'utiliser une formulation plus générale.

Un membre est responsable d'une fonction. Quelqu'un peut l'aider dans la mise en œuvre, mais une personne passe les tests. La tâche lui est également renvoyée pour révision. Selon l'organisation de l'équipe, il peut s'agir d'un chef d'équipe ou directement d'un développeur.

Malheureusement, il existe parfois de grandes fonctionnalités. Il faudra très longtemps pour travailler seul sur un tel volume. Et pendant longtemps, vous devrez tester et mettre en œuvre le processus d'acceptation. Ensuite, nous changeons le type de tâche en Epic. Epic est juste une fonctionnalité très épaisse. Nous ne commençons rien de plus qu'une épopée. C'est-à-dire les épopées peuvent être simplement grandes, énormes ou gigantesques. Dans tous les cas, l'épopée est envoyée en pièces (fonctionnalités) à l'acceptation.

Afin d'évaluer plus précisément, les fonctionnalités sont décomposées en sous-tâches distinctes (tâche). Par exemple, une caractéristique pourrait être le développement d'une nouvelle interface CRUD. La structure des tâches peut ressembler à ceci: «afficher une table avec des données», «accélérer le filtrage et la recherche», «développer un nouveau composant», «ajouter de nouvelles tables à la base de données». La structure des tâches n'est généralement pas du tout intéressante pour les entreprises, mais elle est extrêmement importante pour le développeur.

Évaluation en groupe, planification de poker

Les programmeurs sont trop optimistes quant à la quantité de travail. Selon diverses sources, la sous-évaluation varie le plus souvent de 20 à 30%. Cependant, dans les groupes, l'erreur est réduite. Cela est dû à une meilleure analyse due à différents points de vue et à l'évaluation du tempérament.
La pratique la plus courante avec la popularité croissante d'Agile est la pratique de la " planification de poker ". Cependant, deux problèmes sont associés à l'évaluation de groupe:

Pression sociale
Coûts de temps

Pression sociale

Dans presque tous les groupes, l'expérience et l'efficacité personnelle des participants varieront. Si l'équipe a une équipe / technologie solide - le chef / programmeur principal, les autres membres peuvent se sentir mal à l'aise et sous-estimer délibérément les notes: «Eh bien, comment Vasya peut-il le faire, mais suis-je pire? Je peux aussi faire ça! " Les raisons peuvent être différentes: l'envie de paraître meilleure qu'elle ne l'est réellement, la compétition ou tout simplement le conformisme. Le résultat est un: une évaluation de groupe perd tous ses avantages et devient individuelle. Timlid donne des notes et les autres lui donnent simplement leur accord.

J'ai longtemps mis la pression sur l'équipe afin d'obtenir des notes plus conformes à mes attentes. Cela a invariablement entraîné une baisse de la qualité et une dégradation des termes. En conséquence, j'ai changé d'attitude et maintenant ma note est souvent la plus élevée. Au cours de la discussion, je signale les problèmes potentiels qui me viennent à l'esprit: «ici, le refactoring ne ferait pas de mal, ici la structure de notre base de données évolue, il faudrait faire un test de régression».

Il existe plusieurs recommandations principales:

La plupart des notes sont sous-estimées. Vous ne pouvez pas choisir entre deux classements? Prenez celui qui est le plus gros.
Vous n'êtes pas sûr de l'évaluation - jetez la carte "?" ou une excellente note. Peut-être ne porte presque jamais.
Comparez toujours le plan et les faits. Si vous savez que vous ne rentrez pas deux fois, donnez une estimation deux fois supérieure à ce que vous pensez. Vous avez commencé à surestimer? Multipliez dans votre esprit par un an et demi. Après quelques itérations, la qualité de vos notes devrait s'améliorer considérablement.

Coûts de temps

Vous connaissez la phrase «Voulez-vous travailler?» Réunissez-vous! ” Non seulement un programmeur essaie de prédire l'avenir au lieu d'écrire du code. Maintenant, tout le groupe le fait. De plus, l'élaboration d'une décision en groupe est un processus beaucoup plus long que la prise de décisions individuelles. L'évaluation de groupe est donc un processus extrêmement coûteux. Il vaut la peine d'examiner ces coûts de l'autre côté. Tout d'abord, dans le processus d'évaluation, le groupe est obligé de discuter des exigences. Cela signifie que vous devez les lire. Déjà pas mal. Deuxièmement, comparons ces coûts avec ceux que l'entreprise engage en raison de la sous-estimation du projet.

Il y a plusieurs années, un jour de novembre, j'ai changé d'emploi pour une grande entreprise. Il est immédiatement devenu clair pour moi que le travail battait son plein. La moitié de l'entreprise a travaillé pour commercialiser le produit avant la fin de l'année. Mais après environ une semaine, il me semblait qu'à la fin de l'année, ils n'auraient pas le temps. Avec chaque jour suivant, les chances de succès de cette entreprise devenaient de plus en plus illusoires ... Le projet a vraiment été livré en décembre, mais dès l'année prochaine. J'ai appris cela beaucoup plus tard, car pendant l'été, les problèmes ont commencé avec le paiement des salaires des employés et j'ai démissionné avec environ la moitié du personnel. Vous pouvez dire "eh bien, bien sûr, les managers sont des imbéciles, vous avez dû jouer prudemment". Ils se sont assurés. Six mois, aucun problème de paiement n'a été constaté. Garder un stock de fonds de roulement pendant six mois de financement n'est pas une tâche facile. Je pense que si l'évaluation était plus précise, il y aurait d'autres décisions de gestion au niveau de la haute direction.

Si nous considérons l'investissement dans l'évaluation comme un investissement dans l'adoption de bonnes décisions de gestion, alors elles cessent de paraître si chères. La taille du groupe est une autre affaire. Bien sûr, il n'est pas nécessaire de forcer toute l'équipe à évaluer la quantité totale de travail. Il est beaucoup plus raisonnable de diviser la tâche en ~~modules~~ , ahem, micro-services et de donner aux équipes une autonomie. Et à un niveau supérieur, utilisez les estimations obtenues par chaque équipe pour établir un plan de projet. Ce qui nous amène en douceur au sujet du paragraphe suivant.

Disposition des dépendances, diagrammes de Gantt

Si les programmeurs donnent généralement des évaluations, l'élaboration d'un plan de projet est le lot des cadres intermédiaires. Rappelez-vous, j'ai écrit que ces gars peuvent être aidés si un seul outil est utilisé pour la décomposition et la gestion de projet. L'évaluation et le calendrier ne sont pas la même chose. Par exemple, pour afficher un simple tableau de données, vous aurez besoin de:

Table DB
Code backend
Code frontal

Il est plus facile d'effectuer des tâches dans cet ordre d'un point de vue technique. Cependant, en réalité, il existe différentes spécialisations. Un spécialiste front-end peut être programmé pour libérer plus tôt. Au lieu d'être inactif, il est plus logique de commencer à développer l'interface utilisateur en remplaçant la demande du serveur par des données factices ou codées en dur. Puis au moment où l'API est prête, il ne reste plus qu'à remplacer le code par un appel à une vraie méthode ... en théorie. En pratique, le niveau maximal de parallélisme peut être atteint comme suit:

D'abord, nous swagger rapidement pour convenir de la spécification API
Puis codez en dur les données à l'arrière ou à l'avant, selon qui est à portée de main.
Dans le même temps, nous faisons de la base de données, du backend et du front-end. La base de données et le backend se bloquent partiellement, mais le plus souvent ces compétences sont combinées en une seule personne et le travail se déroule en fait séquentiellement: d'abord une base de données, puis un backend
Nous collectons tout et testons
Nous corrigeons des bugs et testons à nouveau

Il est important que les étapes 1, 4 et 5 soient exécutées le plus rapidement possible pour réduire le nombre de verrous. En plus des limites technologiques et des restrictions sur la disponibilité de spécialistes de la compétence nécessaire, il y a encore des priorités commerciales! Et cela signifie qu'après trois semaines, une démonstration a été programmée pour un client important et il a voulu cracher sur la première moitié de votre plan de projet. Il veut voir le résultat final, qui sera disponible au plus tôt deux mois plus tard. Eh bien, alors vous devez préparer un plan distinct pour cette démonstration. Nous ajoutons au plan de marteler dans les données de base de données nécessaires, insérer de nouveaux liens pour les transitions vers l'interface utilisateur, etc. Il est également souhaitable qu'en fin de compte, il ait été nécessaire de jeter 20% du code, et pas toute cette démonstration.

La découpe artistique d'un tel plan n'est pas une tâche facile. La création de dépendances simplifie considérablement le processus. Avant de passer au module de rapport, vous devez créer un module d'entrée de données. Est-ce logique? Ajoutez une dépendance. Répétez pour toutes les tâches connexes. Croyez-moi, beaucoup de dépendances vous surprendront.

Dans les tâches d'automatisation des processus métier, on obtient généralement plusieurs longs «serpents» de tâches connexes avec plusieurs gros nœuds de verrouillage. Le plus souvent, le plan initial n'est pas efficace en termes d'utilisation des ressources et / ou trop long en termes de calendrier. La révision de l'évaluation des coûts de main-d'œuvre se fera plus rapidement - pas une option. L'évaluation est donc très probablement optimiste. Il faut revenir à la décomposition, rechercher des chaînes trop longues et ajouter des «fourches» supplémentaires pour augmenter le degré de parallélisme. Ainsi, en raison d'une augmentation du coût total de la main-d'œuvre (davantage de personnes travaillent simultanément sur un même projet), la période civile du projet est réduite. Vous vous souvenez du "mois-homme mythique"? Il est peu probable qu'un plan diminue de plus de 30%. Afin que le budget et le délai soient convenus, le plan peut être révisé plusieurs fois. Il existe plusieurs astuces pour rendre le processus plus rapide et plus facile.

Verrouillage des tâches

Nous avons déjà considéré la première raison du blocage - les dépendances.De plus, il peut simplement y avoir des exigences incompréhensibles / inexactes. Un outil est nécessaire pour bloquer les tâches et poser des questions. Avec la spécification des exigences, vous pouvez débloquer des tâches et ajuster la note. Soit dit en passant, ce processus se poursuit presque toujours pendant le projet, et non avant lui.

Le chemin critique, les risques à venir

. , ( ), , , , . , , , , , , . , .

En bref, si vous vous trompez avec la structure de la base de données, vous devez réécrire le dos, ne pas calculer la charge, vous devrez peut-être changer complètement la technologie. J'ai écrit en détail sur les risques du travail de conception dans l'article " Cost Effective Code ". Plus tôt les risques sur le chemin critique se matérialisent, mieux c'est. Après tout, il est encore temps et quelque chose peut être fait. Encore mieux s'ils ne se matérialisent pas du tout, mais soyons réalistes.

Par conséquent, vous devez commencer par les tâches les plus boueuses, complexes et désagréables, les mettre dans un état "bloqué" et clarifier, réévaluer et supprimer les dépendances dans la mesure du possible.

Critères d'acceptation, cas de test

Langue naturelle: russe, anglais ou chinois - peu importe - elle peut être à la fois redondante et inexacte. Les cas de test surmontent ces limitations. C'est également un bon outil de communication entre les développeurs, les utilisateurs métiers et le service qualité.

Gestion de projet

Voulez-vous faire rire Dieu? Parlez-lui de vos plans. Même si un miracle s'est produit et que vous avez collecté et clarifié toutes les exigences avant de commencer à travailler, vous avez suffisamment de personnes compétentes, le plan vous permet de faire la plupart du travail en parallèle, vous n'êtes toujours pas à l'abri des maladies des employés, des erreurs dans l'évaluation et la matérialisation d'autres risques. Par conséquent, il est nécessaire de mettre à jour régulièrement le plan et de le comparer avec le fait. Et pour cela, la prise en compte du temps de travail est importante.

Suivi du temps aka suivi du temps

Le temps et la fréquentation sont depuis longtemps la norme de facto dans l'industrie. Il est hautement souhaitable qu'il soit produit dans le même outil que l'évaluation. Cela vous permet de suivre l'écart du temps réel passé par rapport à l'estimation. C'est bien si cet outil est également utilisé par le chef de projet. Tous les retards du chemin critique seront alors immédiatement perceptibles. Une variante avec différents outils est également possible, mais elle nécessitera des coûts de main-d'œuvre significativement plus élevés pour l'entretien du processus, ce qui signifie qu'il y aura une tentation de jouer. Nous savons déjà comment cela se termine. Nous utilisons YouTrack . Tout ce que j'ai écrit dans l'article est actuellement disponible, même si cela nécessite un petit ajustement.

Conclusion

L'évaluation est difficile
La décomposition vous permet de trouver des lacunes dans les exigences et d'améliorer la qualité de l'évaluation
Les scores de groupe sont plus précis que les scores individuels, utilisez le poker
Les bloqueurs, les cas de test et les critères d'acceptation formels améliorent la communication, ce qui augmente les chances de succès du projet
Vous devez commencer par les tâches les plus risquées sur le chemin critique du projet
L'évaluation n'est pas une action ponctuelle, mais un processus indissociable de la gestion de projet
Sans prendre en compte le temps de travail, il est impossible de maintenir l'état du projet à jour et d'ajuster vos estimations

Vous voulez en savoir plus sur l'évaluation de projet?

Lisez le livre de Steve McConnell " Combien coûte un projet logiciel " et d'autres articles sur ce sujet sur Habré:

À propos de l'évaluation et de la gestion du développement de produits logiciels