Comment garder la gestion hors de notre processus de développement

Je suis ingénieur logiciel dans une équipe de développement logiciel. Les 3 dernières années, nous avons travaillé pour un client interne sur un nouveau produit. Maintenant que ce produit est terminé, nous allons travailler sur de nouvelles fonctionnalités majeures pour les produits existants. Pour une fonctionnalité particulière, la gestion des produits a supposé qu'il fallait 150 heures pour se développer. En collaboration avec notre chef de projet, nous avons créé un plan très détaillé et nous arrivons à un effort de 300 heures. Hier, nous en avons discuté et ils pensent que nous avons largement surestimé les choses.

Dans notre planification, nous avons estimé les heures d'écriture des tests unitaires, leur idée est de les vider pour gagner du temps. La décision n'a pas encore été prise et je défendrai ce planning et les tests unitaires si besoin. Mais ce que je n'aime vraiment pas ici, c'est que la direction interfère avec notre processus de développement. Comment les garder hors de notre processus de développement? Et quels arguments pourrais-je utiliser pour maintenir les tests unitaires en place (outre la qualité et le gain de temps à long terme)?

En passant, notre entreprise dispose de 3 équipes d'ingénierie et l'équipe dans laquelle je travaille livre son logiciel à temps (donne ou prend une marge de 10%). Alors que les autres équipes livrent toujours en retard, principalement en raison d'une sous-estimation de la planification. Ils ne planifient que le codage et non la gestion, les tests et la manipulation.

Tout d'abord, permettez-moi de dire que je sympathise totalement avec votre position. Cela peut être frustrant lorsque vous avez un manque de compréhension ou une rupture de communication entre les différentes parties de l'entreprise. Cela dit, je ne pense pas que vous devriez essayer de les garder à l'écart. Au lieu de cela, vous devez leur montrer les chiffres expliquant pourquoi c'est une bonne idée. Quels faits avez-vous qui justifient les tests unitaires qui valent l'effort que vous y consacrez? Si vous n'en avez pas, vous devriez commencer à rassembler ces chiffres ou à montrer des recherches pour étayer vos affirmations.

J'ai moi-même dû faire face à des scénarios similaires et j'ai répondu à cette question sur un sujet similaire . J'ai également blogué sur la façon dont je l'ai traité ici:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

Si vous n'avez pas envie de rechercher des liens, je vais répéter mon résumé de la question connexe:

Pour résumer, j'ai comparé nos heures estimées aux heures réelles du projet, puis j'ai comparé notre taux de défauts au taux de défauts des autres équipes. Dans notre cas, ces chiffres se comparaient favorablement et il n'y avait plus de préoccupations.

Ma conclusion basée sur cette expérience est:

... la meilleure façon de convaincre quiconque que votre approche pour faire quelque chose est pratique et pragmatique est de le faire et de la mesurer par rapport à d'autres approches. Les gens ne se soucient pas du dogme, ni de la raison pour laquelle vous pensez que quelque chose devrait être le meilleur moyen. Ce n'est qu'en montrant aux gens les chiffres et en mesurant l'efficacité de votre approche que vous pouvez vraiment montrer que vos pratiques sont efficaces.

Si votre équipe de gestion n'accepte pas d'investir ce qu'elle considère comme 150 heures supplémentaires sur les tests unitaires, vous pouvez peut-être les convaincre d'investir dans une petite zone du produit (ou même accepter de vous aspirer les heures pour fournir des données ). Effectuez des tests unitaires dans cette zone du produit, puis collectez des données sur les taux de défauts dans cette zone du produit et le coût pour trouver et corriger ces défauts par rapport aux taux de défauts dans d'autres zones du produit. J'espère que vous rassemblerez des données pour sauvegarder votre cas et ce ne sera pas un problème pour votre prochain projet.

La règle numéro un à suivre, quelle que soit la méthode que vous utilisez, est que

1. Les développeurs devraient avoir le droit d'estimer leur propre travail.
2. Les parties prenantes devraient avoir le droit d'établir des priorités entre ces travaux.

L'estimation et la priorisation sont deux forces qui fonctionnent très bien ensemble une fois que les deux parties acceptent leurs propres responsabilités. Donc, au lieu de perdre du temps à discuter, convenez de cela et respectez que les deux parties feront leur travail au mieux de leurs capacités.

Vous pourriez souligner que les tests unitaires font gagner du temps, donc si vous les laissez tomber, l'estimation passe à 500 heures.

Parlez-leur de la dette technique et de la valeur des tests unitaires

Regardez ce post de quelques bonnes idées sur la dette technique. En suivant ce post, vous pouvez accéder au pdf suivant

J'aime ce post sur la valeur des tests unitaires (il y en a probablement plus à trouver)

L'espoir n'est pas de les sortir de votre processus de développement mais de les impliquer et de les engager de la bonne manière.

À mon humble avis, vous devez écrire votre planification originale, ajouter les chapitres 1 et 2 (pas dans une annexe) dans lesquels vous expliquez la dette technique et la valeur des tests unitaires. Donnez-leur des alternatives:

• moins d'heures (pas les 150 au total, cela semble ridicule) où chaque changement (pendant la phase de développement et pendant la maintenance) prendra en moyenne:
  • petit 4 heures
  • moyen 16 heures
  • grand 40 heures
• vos heures estimées où chaque changement (phase de développement et pendant la maintenance) prendra en moyenne:
  • petit 2 heures
  • moyen 8 heures
  • grand 20 heures

(Les heures ne sont qu'indicatives. Vous êtes bien mieux équipé pour donner des estimations appropriées.)

N'oubliez pas d'inclure vos antécédents pour les livraisons dans les délais et le budget.

Écrivez-le et discutez-en avec eux. Ils pourraient avoir des points précieux dans les fonctionnalités dont ils n'ont pas vraiment besoin actuellement ou une dette technique qu'ils sont prêts à prendre pour livrer à temps. Assurez-vous simplement que ce sont des choix conscients.

J'espère que ça t'aide et bonne chance.

Tout d'abord, ne divisez pas les «tests unitaires en écriture» en une tâche distincte à estimer, à planifier et potentiellement à couper. Vos estimations doivent être au niveau de la fonctionnalité "Implémenter le XYZ - 18 heures". Ces 18 heures devraient inclure tout ce qu'il faut dans votre processus pour obtenir cette fonctionnalité à "FAIT", y compris "écrire des tests unitaires".

C'est une bonne façon de sortir le développement non technique "de votre processus de développement". N'incluez pas votre processus de développement dans la liste des tâches ou le calendrier du projet que vous leur donnez!

Deuxièmement, il semble que votre équipe leur livre déjà de bons produits et à temps, mais que les autres équipes ne le sont pas. Peut-être que ce groupe de gestion est habitué à devoir microgérer ces équipes. Jouez sur vos points forts - offrez-leur de leur montrer des mises à jour hebdomadaires ou bihebdomadaires avec des fonctionnalités fonctionnelles, et ils vous tiendrons au courant du "processus de développement".

J'étais une fois dans une situation où je travaillais avec une base de code en très bon état; une nouvelle fonctionnalité exigeante était nécessaire dans un délai très court, et j'ai réussi à livrer la fonctionnalité dans un délai très court. À ce stade, la base de code était dans un état bien pire. Donc, la fonctionnalité a été livrée, mais mon travail n'a pas été fait: j'ai dû tout remettre dans un état tout aussi bon.

J'ai expliqué au manager deux niveaux comme celui-ci: C'est comme faire un travail de peinture chez vous. Si tous les outils sont là où ils appartiennent et en bon état, toutes les brosses nettoyées et ainsi de suite, vous pouvez faire un travail de peinture très rapidement. Mais alors vous devez passer du temps à remettre tous vos outils en ordre. Si vous ne le faites pas, votre prochain travail de peinture prendra beaucoup plus de temps. En fait, vous ne vous souviendrez plus où se trouvent vos outils, vos pinceaux ne peuvent plus être récupérés et cela vous coûte beaucoup plus de temps et d'argent comme si vous aviez fait le nettoyage immédiatement.

Et la même chose dans mon travail de programmation: En nettoyant, je remets la base de code dans un état où je peux livrer quelque chose très rapidement à nouveau la prochaine fois que cela est nécessaire. Sinon, la prochaine fois, cela prendra beaucoup plus de temps.

Vous ne pouvez pas les garder complètement hors de votre processus, après tout, ils paient votre salaire et ils utiliseront votre produit (sinon directement, probablement quelqu'un de votre entreprise est l'utilisateur final).

Les managers accusant les développeurs de surestimer le temps sont un scénario très courant dans mon expérience, et s'ils ne sont pas traités, cela peut conduire à une course aux armements assez stupide où vos prochaines estimations sont doublées parce que vous savez que les patrons les divisent par deux, ils le savent ils les séparent, donc vous les quadruple, etc. etc. Vous devez éviter ce cercle vicieux si possible.

En supposant qu'il n'y a pas de raison de "drop dead" pour la date limite, je suggérerais 2 choses.

1. Fournissez un plan détaillé de ce que vous pensez pouvoir faire en 150 heures, en respectant votre approche actuelle du travail de haute qualité. Énumérer exactement ce qui peut être livré dans ce laps de temps. La réponse de KeesDijk a de très bons liens sur la planification à un niveau fin.
2. Continuez dans le même style de planification détaillée pour couvrir toutes les fonctionnalités et montrer comment cela prendra 300 heures (ou quel que soit le chiffre).

Ensuite, mettez-vous au travail et faites régulièrement rapport sur les progrès accomplis et, si possible, ayez des livrables à intervalles réguliers. Cela devrait donner confiance à la direction dans vos compétences d'estimation et votre capacité à livrer.

Demandez-leur la base de leurs estimations. Il est juste de discuter des écarts. Le dumping des tests unitaires est une fausse économie, ce que vous ne dépensez pas pour écrire des tests unitaires, vous le dépenserez plus tard (et plus longtemps) dans un débogueur. Essentiellement, vous avez documenté le fait que vous prévoyez de tester le travail que vous effectuez. Ils vous disent de ne pas tester du tout . Que vous testiez à l'aide de tests unitaires ou de tests ad hoc pendant que vous développez le projet, vous devez toujours tenir compte de cette période. La suppression du temps alloué pour les tests unitaires supprime également le temps alloué pour les tests ad hoc.

Conclusion: respectez vos armes avec votre estimation. Votre historique montre que vous savez de quoi vous parlez et que vous pouvez donner une réponse raisonnable quant à la base de votre estimation (hypothèses, attentes, performances passées, etc.). Il semble que votre direction n'a pas la visibilité nécessaire pour créer une estimation raisonnable. Supposent-ils des journées de 8 heures sans interruption pour les réunions? Prévoient-ils un budget pour les tests du système dans leurs estimations? Comment ont-ils trouvé le nombre qui est la moitié du vôtre, compte tenu de votre bilan?

J'estimerais que cela prendra 300 heures et si le budget de 150 leur donne la possibilité, ce sera soit un buggy rush soit tard pour être livré. Lorsque le projet est terminé et que vous le prédisez, vous pouvez simplement leur dire que c'est ce que vous avez demandé.

Que ferait Wally?

Il y a plusieurs façons d'interpréter ce que la direction vous demande, l'une est qu'elle ne veut pas que vous livriez à temps.

Semble absurde? Oui, mais comment peuvent-ils savoir autrement que vous ne surestimez pas? Ne respectez pas vos délais (relâchez si nécessaire), si vous glissez et livrez accidentellement quelque chose à temps, assurez-vous d'avoir l'air vraiment fatigué pour ne pas donner l'impression que c'était une promenade dans le parc.

Vous êtes dans un cornichon. Si vous vous en tenez à vos armes et que vous voulez vous en tenir aux tests unitaires et que vous voulez réclamer les 300 heures, vous vous ferez des ennemis.

Si vous réduisez à 150 heures et effectuez des tests unitaires de mandrin, vous pouvez livrer un produit plus bogué plus rapidement, mais cela causera des problèmes en cours de route, avec un coût de maintenance plus élevé.

De toute façon, vous perdez.

C'est du moins ce qu'il semble.

Vous voyez, vous ne dirigez pas un laboratoire scientifique dans une université. Vous fournissez un service commercial à une unité commerciale d'une entreprise qui fournit des services aux clients dans un écosystème d'entreprises. Votre entreprise peut avoir besoin de votre produit pour commencer à fournir des services plus rapides et meilleurs à ses clients, et ainsi augmenter les revenus nécessaires.

Vous voyez, ce dont vous avez besoin est une analyse du retour sur investissement, et vous n'avez pas toutes les données pour effectuer cette analyse. Vous n'avez qu'une partie des coûts (vous ne connaissez pas les numéros de paie de tout le monde) et vous n'avez certainement pas les parties des revenus, surtout pas les prévisions de revenus.

Votre direction, croyez-le ou non, est capable de faire les projections de ROI (c'est ce qu'elles enseignent dans les écoles de commerce) et peut avoir exécuté plusieurs projections de ROI et proposer le "si nous agissons maintenant, nous gagnerons encore plus d'argent en payant le triple pour la maintenance du logiciel dont se plaignent les bozos en informatique. "

Donc, si vous voulez gérer le joint, lancez votre propre entreprise. Vous verrez, ce n'est pas si simple.

En d'autres termes: faites ce qu'on vous dit. Si la direction sait ce qu'elle fait, vous passerez devant. Sinon, vous êtes sans emploi, tests unitaires ou non.

Quel ROI vous demandez? Retour sur investissement. C'est un mauvais nom cependant. Il doit s'agir d'un retour sur investissement opportun (ROTI), car le timing est tout dans l'investissement.