"le logiciel est terminé quand c'est fait, pas plus tôt, pas plus tard."
Cela est vrai, mais pour chaque tâche sur laquelle vos développeurs commencent à travailler, est-ce que tout le monde dans votre organisation comprend la définition de Fait pour chaque tâche?
L' estimation semble être l'un de vos plus gros problèmes , mais les développeurs ne peuvent fournir une estimation réaliste que lorsqu'ils disposent d'une "définition du fait" sans ambiguïté et clairement spécifiée. (Ce qui inclut les problèmes de processus de l'entreprise - par exemple, la documentation utilisateur, les lots de travaux sur une version officielle, etc.)
Il n’est pas surprenant que la surestimation pose problème, étant donné que la plupart des développeurs voient que l’estimation du temps requis pour effectuer une tâche est la plus difficile qui soit.
Cependant, la plupart des développeurs ont tendance à avoir une idée raisonnable (quoique optimiste ) de la quantité d' effort qu'ils sont capables de déployer, pour une période donnée.
Le problème réside souvent dans le fait que les développeurs ont du mal à créer un lien entre une tâche et le nombre total d'efforts requis pour traiter des informations incomplètes, en particulier s'ils sont contraints de fournir toutes les réponses à une tâche très complexe. .
Cela conduit naturellement à ce que les estimations de temps deviennent déconnectées de la réalité et qu'elles perdent de vue des éléments tels que le processus de construction et la documentation utilisateur.
La déconnexion a tendance à commencer au tout début lorsque la tâche est décrite; et il est généralement composé par une personne non technique qui dresse une liste d'exigences sans avoir la moindre idée de l'ampleur des efforts nécessaires.
Parfois, les membres de la haute direction spécifient des tâches et ignorent complètement les problèmes de processus de l'entreprise; Il n'est pas rare que la haute direction pense que la définition de tests, la création d'une version officiellement publiée ou la mise à jour d'un document utilisateur se déroulent comme par magie, sans effort ni temps. Champs obligatoires.
Parfois, les projets échouent avant même qu'un développeur ait écrit une ligne de code car quelqu'un, quelque part, ne fait pas son travail correctement.
Si l’équipe de développement n’est pas impliquée dans la définition des exigences ni dans la définition des critères d’acceptation, il s’agit alors d’un échec de la direction, car cela signifie que les connaissances insuffisantes du code et des problèmes techniques ont imposé à l’entreprise un ensemble d’exigences incomplet, et laissé le projet ouvert à la fausse interprétation, au fluage de la portée, au placage à l'or, etc.
Si l'équipe de développement est impliquée dans la définition et l'acceptation des exigences, il pourrait s'agir d'un échec de l'équipe, qui est chargée de clarifier les détails (et les critères d'acceptation - par exemple, "à quoi ressemble le produit livrable? Quand est-il effectué ?" ) L’équipe de développement doit également dire NON lorsque d’autres problèmes de blocage se posent ou si une exigence est tout simplement irréaliste.
Donc, si les développeurs sont impliqués dans la capture des exigences:
- L’équipe at-elle l’occasion de s’asseoir avec le chef de produit pour clarifier les exigences / la définition de done?
- L'équipe pose-t-elle suffisamment de questions pour clarifier les exigences implicites / supposées? À quelle fréquence répond-on à ces questions de manière satisfaisante?
- L'équipe demande-t-elle des critères d'acceptation (définition de done) avant de fournir une estimation?
- Dans quelle mesure les critères d'acceptation sont-ils généralement capturés pour chaque tâche? S'agit-il d'un document vague avec peu de détails ou décrit-il une fonctionnalité tangible et une formulation qu'un développeur pourrait traduire sans ambiguïté en un test?
Les chances sont que la productivité de votre équipe n'est pas un problème; votre équipe est probablement en train de déployer tous les efforts possibles pour le développement. Vos vrais problèmes pourraient être un ou plusieurs des éléments suivants:
- Exigences incomplètes et vagues.
- Les exigences / tâches qui sont trop grandes au départ.
- Mauvaise communication entre l'équipe de développement et la direction.
- Un manque de critères d'acceptation clairement définis avant que les tâches ne soient confiées à l'équipe.
- Spécification incomplète ou vague / ambiguë des tests d'acceptation. (c.-à-d. définition de fait)
- Temps insuffisant alloué pour définir / convenir des critères d'acceptation.
- Les développeurs n'ont pas pris le temps de tester le code de base existant ou de corriger les bogues existants
- Les développeurs ont testé le code de base existant mais n'ont pas soulevé les bogues en tant que problèmes de blocage avant de fournir une estimation des exigences.
- La direction a vu les problèmes / bogues et a décidé qu'il n'était pas nécessaire de corriger les bogues avant d'écrire du nouveau code.
- Les développeurs sont sous pression pour consacrer 100% de leur temps, même si probablement 20% (ou un nombre similaire) de leur temps est probablement utilisé par des réunions, des distractions, des courriels, etc.
- Les estimations sont approuvées à la valeur nominale et personne ne règle la marge d'erreur ou les imprévus (par exemple, "nous avons décidé que cela prendrait 5 jours, nous nous attendons donc à ce que ce soit fait dans 8.").
- Les estimations sont traitées par tout le monde (développeurs et direction) comme des nombres uniques au lieu d’être des nombres "extrêmes" réalistes - c’est-à-dire
- Meilleure estimation de cas
- Estimation réaliste
- Pire estimation
... La liste pourrait durer beaucoup plus longtemps que cela.
Vous devez effectuer une "enquête factuelle" et comprendre exactement pourquoi les estimations sont systématiquement déconnectées de la réalité. Le logiciel de base existant est-il mauvais? Est-ce qu'il manque de couverture de test unitaire? Vos développeurs évitent-ils la communication avec la direction? La direction évite-t-elle la communication avec les développeurs? Existe-t-il un décalage entre les attentes de la direction et les attentes des développeurs en ce qui concerne "Definition of Done" ?