Pourquoi et quand choisir FFF? Jetons un coup d'oeil.
1. Trois combinaisons
Chacune des approches de la gestion de projet diffère essentiellement en ce qu'elle fixe ou ne fixe pas les valeurs suivantes: budget, périmètre de travail, délai et qualité interne du système.
Une combinaison spécifique crée certaines conditions de travail, présente des avantages et des inconvénients:
- Prix fixe
- Trois points du triangle du projet sont fixes: le temps, l'argent et la quantité de travail.
- Les principaux risques sont assumés par le contractant et, par conséquent, ces risques sont reflétés dans l'évaluation. De plus, des risques sont créés pour le client, j'ai écrit à ce sujet dans l'article 12 problèmes lors d'un travail sur une mission technique dans un produit informatique .
- Un gros plus de cette approche est les paramètres du projet prédéfinis avant le début des travaux. Très souvent, l'entreprise / le gouvernement doit spécifier la durée, l'argent et la quantité de travail dans le contrat.
- . , . , .
- .
- Time and Materials (T&M)
- , - .
- .
- , .
- , . , , .
- .
- ( , Product Owner'), , , , .
- Fix Time and Budget, Flex Scope (FFF)
- : , .
- .
- , , .
- , .
- , , . .
- : , / , .
- , .. . , , , , , , .
– , . , «», , , . . , , SonarQube. Podlodka.
2.
Pourquoi ces trois combinaisons se forment-elles? Pourquoi ne pouvons-nous pas tout réparer? Après tout, le plus simple est de fixer le budget, la portée des travaux, la date de sortie et la qualité interne du système, de signer un accord (si le client est interne, puis de passer par la procédure d'approbation avec les parties prenantes) et de faire le travail avec un résultat précis dans les quatre valeurs. Mais, comme le montre la pratique, il existe un problème fondamental qui ne permet pas de suivre facilement cette voie sans distorsion.
Personne n'a de problèmes avec le calcul du budget, il est assez facile de calculer la date de sortie et il existe de nombreuses métriques et listes de contrôle pour définir un niveau de qualité spécifique pour un produit informatique. Tout est simple si vous pouvez estimer avec précision la portée des travaux. En d'autres termes, s'il existe une liste détaillée des tâches et une estimation précise de cette quantité de travail, les trois autres valeurs sont facilement calculées. À l'inverse, s'il n'y a pas d'estimation exacte, les autres valeurs seront également inexactes, car elles sont basées sur une estimation de la quantité de travail.
L'estimation de la portée des travaux est toujours un problème, car il n'y a pas de méthodologie d'estimation unique qui fonctionnerait avec une précision acceptable. Toutes les méthodes sont basées sur l'expérience précédente d'une équipe qui a fait des choses similaires, ce qui signifie finalement des inexactitudes, car les gens sont inexacts: émotifs, optimistes, oublieux. L'absence d'une méthodologie d'évaluation précise est le premier facteur qui nous empêche d'entrer dans l'évaluation de la quantité de travail.
J'ai écrit plus sur ce problème dans l'article Satisfaction client pour les programmeurs: tous les programmeurs sont optimistes . Il y a un lien vers le rapport 36 de Vadim Makishvili, où il suggère simplement de multiplier le score par 3. En utilisant la métaphore de la pose et de la marche sur la route, il est écrit dans l'article Pourquoi les projets informatiques prennent 2-3 fois plus de temps que prévu? ...
Au cours d'un travail sur un produit informatique, les changements suivants: la liste des tâches à effectuer, la profondeur de leur élaboration, l'approche de la conception du système. Cela se produit sous l'influence de l'environnement externe: changements sur le marché, changements dans la stratégie de l'entreprise, changements dans les politiques au sein de l'entreprise, retours des utilisateurs, nouvelles contributions de ceux qui étaient silencieux au stade de l'analyse et ont ensuite décidé de s'exprimer, etc. Notre incapacité à influencer les influences externes est le deuxième facteur qui nous empêche de nous lancer initialement dans l'évaluation.
Le troisième facteur est qu'il n'y a pas de critères pour déterminer l'atteinte de l'exhaustivité lors de la description de la portée des travaux. L'écriture du TK ne peut pas être terminée, elle peut seulement être arrêtée. J'ai écrit à ce sujet en détail dans l'article Quand est-il temps d'arrêter d'écrire les termes de référence .
Je dois faire une réserve que tout cela est vrai si vous travaillez dans un domaine plutôt complexe: selon le cadre Cynefin, ce sont les domaines Complexe et Compliqué. Si votre projet entre dans Evident et qu'il est en même temps plutôt court, vous estimerez probablement la quantité de travail avec beaucoup de précision.
Au total, nous avons que la racine du problème réside dans une estimation inexacte de la portée des travaux et l'impossibilité pratique de rendre cette estimation exacte, donc:
- Les projets à prix fixe sacrifient la qualité interne du système, car il est presque impossible d'entrer dans une estimation avec trois pics fixes. Ou, dans les mêmes projets à prix fixe, ils ré-budgétisent autant de risques pour couvrir toute inexactitude dans l'évaluation, ce qui est inefficace.
- T&M , . Product Owner'.
- FFF , , « » , T&M.
3. ?
S'il est impossible d'estimer la portée des travaux avec une précision suffisante, peut-être pas du tout? Il existe un tel mouvement #NoEstimates. En bref, nous organisons le processus de développement de manière à exécuter les tâches aussi efficacement que possible du stade de l'idée au déploiement en production et en même temps à maintenir une haute qualité interne. Ils proposent d'organiser le processus à l'aide de Kanban avec des métriques de traitement des flux de suivi et une attention particulière à l'amélioration du processus de fourniture de nouvelles fonctionnalités. Les évaluations prématurées sont considérées comme préjudiciables, évaluer et réduire l'arriéré est une perte de temps.
Où en savoir plus sur #NoEstimates:
- David Anderson en parle beaucoup, par exemple, dans son discours The Alternative Path to Enterprise Agility .
- Askhat Urazbayev a pris la parole à AgileDays dans son discours #NoEstimates: Développement non évaluatif .
- Ron Jeffries a écrit à ce sujet dans l'article Quelques réflexions sur l'estimation .
- Denis Stebunov a écrit à ce sujet sur Habré dans l'article On Estimates of Terms in Software Development .
Je suis à la fois pour cette approche. Je l'aime en tant qu'ingénieur et en tant que leader. Mais la vie est tellement arrangée que les propriétaires du budget ont besoin d'une estimation, au moins aux premières étapes des travaux, au moins approximative. Chez Byndyusoft, on passe parfois à #NoEstimates, mais seulement après une relation assez longue avec le client et cela ne se produit pas toujours.
4. FFF - équilibre entre flexibilité et prévisibilité
Bien que les notes gâchent la vie et soient une perte de temps, il est difficile de commencer sans elles. Il est clair cependant qu'aucune estimation ne sera exacte. Il s'avère que la meilleure option est de fixer le délai et le budget afin que l'entreprise puisse vivre avec, et laisser le volume de travail flottant. De plus, le client et l'entrepreneur doivent convenir qu'à chaque instant, l'équipe n'est engagée que dans les tâches les plus importantes et nécessaires, et le client consacre du temps au suivi de la dynamique du choix des priorités.
La première fois que j'ai vu la description de FFF, c'était dans Getting Real by 37signals dans le chapitre Fix Time and Budget, Flex Scope . En ce moment, dans mon entreprise, c'est l'approche de travail la plus populaire, les clients et nous en sommes satisfaits.
5. Qualité interne du système
Comme je l'ai écrit ci-dessus, travailler sur FFF est possible si l'entreprise dispose de développeurs compétents capables d'assurer une haute qualité interne du système. Ceci est généralement accompli en automatisant tout et tout le monde, en créant des listes de contrôle avec les meilleures pratiques, en examinant constamment le code et l'architecture, toutes sortes de tests et, surtout, en recrutant les bonnes personnes dans l'équipe.
Pourquoi ne pas oublier la qualité interne, écrit le blog de Martin Fowler, Is High Quality Software Worth the Cost? ... J'ai écrit à ce sujet dans l'article Déterminer l'échec d'un projet informatique... En bref, FFF implique des changements dans la direction du développement des produits, ce qui implique une flexibilité suffisante du système. Si la qualité du système est faible, alors chaque «tour» ralentira le développement et augmentera son coût, jusqu'à l'arrêt complet du projet.
Si vous souhaitez travailler selon FFF, mettez les critères de qualité dans le contrat afin de les fixer à coup sûr.
6. Motivation du client et de l'entrepreneur
Le travail FFF donne la bonne motivation de la part du client et de l'entrepreneur. Contrairement au prix fixe, où le client et l'entrepreneur communiquent via l'interface du contrat, et contrairement à T&M, où le client peut perdre ses limites et dépenser plus que nécessaire; Chez FFF, chacun doit investir dans la communication et «vivre» dans le projet afin de faire l'essentiel et en même temps de satisfaire les termes du contrat.
7. Choisissez FFF
Le prix fixe et les T&M ont leurs avantages dans certains contextes:
- Si vous participez à un appel d'offres et que vous vous engagez à terminer un travail spécifique dans le temps et l'argent convenus, alors que la communication est principalement établie par le biais d'un contrat, le prix fixe est probablement la meilleure option.
- Si le client sait exactement ce dont il a besoin et sait comment construire efficacement le processus de travail, il lui suffit d'acheter des ressources T&M et de s'en débarrasser à sa discrétion.
Cependant, toutes choses égales par ailleurs, nous essayons de choisir FFF. Cette approche semble la plus équilibrée: elle réduit les risques du client et de l'entrepreneur, crée la motivation nécessaire des deux côtés et veille à la qualité interne du système.
Liens:
- Comment et quels termes de référence écrire lorsque vous travaillez sur Agile .
- Le principe de la gestion de projet dans le bureau d'études d'Artyom Gorbunov.