Comment arrêter le placage à l'or et se contenter de publier des développements fonctionnels [fermé]

L'équipe de développement dont je fais partie s'est récemment adaptée pour travailler selon les pratiques Agile. Cela a personnellement mis en évidence le fait que je ne peux pas m'arrêter sur le code de placage à l'or (et la documentation) et que je dépasse donc les estimations originales, alors que j'aurais pu fournir des solutions qui répondent aux exigences beaucoup plus tôt.

Je pense que mon éthique frise l'obsession en ce que je m'attache trop à mon code et je me contente rarement de le publier avant de l'avoir refactorisé et perfectionné au nième degré. Je suis heureux d'avoir réalisé cela, mais comment puis-je changer mon attitude / mentalité pour me contenter de mes progrès et sortir à temps à la place?

Le meilleur est l'ennemi du bien.

Vous pouvez toujours faire plus de tests, écrire une meilleure documentation, dénicher ces cas d'angle, remplir ce que vous pensez qu'il manque des fonctionnalités, rendre l'architecture plus propre. Ça ne finit jamais. Mais cela doit cesser. Il y a des dates d'échéance qui doivent être respectées, des contraintes externes qui dépendent de votre partie du produit en cours de finition. La recherche de la perfection dans une petite partie d'un produit nuit au produit dans son ensemble.

Tout d'abord, je souhaite que plus de développeurs aient ce problème, non pas parce que le logiciel finirait par être publié plus tard que prévu, mais parce que ce serait probablement une version de meilleure qualité.

Si vous dépassez vos propres estimations initiales, vous devrez peut-être inclure vos étapes de «plaquage or» dans vos estimations. S'il ne s'agit pas de vos propres estimations, vous devriez peut-être participer à leur formulation.

Dans tous les cas, si vous avez une date limite de sortie, vous devez vous y tenir. Toute "dorure" devrait être laissée comme une étape finale qui ne devrait pas retarder une libération. Si vous pensez absolument qu'il doit être inclus dans le cadre d'une version, pensez à ajouter le "placage à l'or" sur votre temps (c'est-à-dire en dehors des heures de travail).

Ce que vous devez faire, c'est présenter vos étapes de «plaquage or» à votre équipe et / ou à votre direction et discuter des raisons pour lesquelles vous pensez qu'elles sont importantes. Si vous pouvez les convaincre que ces étapes sont bénéfiques, elles devraient faire partie des futures versions.

Logiciel plaqué or

La première fois que j'ai vu le placage à l'or utilisé comme description d'un logiciel, c'était dans un article de Barry Boehm où il a donné la cause fondamentale suivante:

Placage d'or. Les spécifications des exigences fixes avant la conception tendaient à encourager le dorage logiciel. Les utilisateurs interrogés sur leurs besoins pouvaient souvent dire: «Je ne sais pas si j'aurai besoin de cette fonctionnalité ou non, mais je pourrais aussi bien le spécifier au cas où.»

Dans sa description, il recommande d'utiliser les méthodes décrites dans ses recherches, y compris le modèle de cycle de vie du logiciel en spirale dans lequel les projets ont été définis pour produire une série de prototypes un par cycle, et à mesure que les spirales grossissaient, un produit complet. Spiral avait une large influence parmi les chercheurs en logiciels et était un pont important entre la cascade et Agile. Une limitation critique de la spirale est qu'à chaque tour de spirale, les cycles sont devenus plus longs et plus chers.

Comme avec Agile, Spiral essaie d'éviter le placage à l'or en cadrant plus étroitement et en planifiant le livrable du projet assez longtemps pour que les équipes puissent terminer les exigences, tout en étant suffisamment court pour permettre de se concentrer sur l'objectif du premier jour au jour de la livraison. Une façon dont les méthodes Agiles comme Scrum sont supérieures est que Scrum sprinte pour un laps de temps qui ne s'allonge pas avec les itérations. D'après le document, la gestion de projet semble avoir plus d'influence sur le placage à l'or que les développeurs individuels.

Talent pour le Time Boxing

Pouvoir chronométrer est très important, mais ce n'est pas une compétence binaire. Vous ne l'avez pas ou vous en manquez. Vous êtes meilleur ou moins bon avec ça. Que cela vienne de votre patron ou de vous, je préférerais que personne ne dise que vous ne pouvez pas arrêter le placage à l'or. Cela semble personnel, omniprésent et permanent.

Une analyse des causes profondes pourrait aider à identifier plusieurs problèmes. Je suis certain qu'ils ne vous pointeront pas tous vers vous, et qu'à moins que vous ne travailliez avec des psychopathes, les autres membres de votre équipe verront des besoins similaires pour améliorer leur ensemble de compétences Agile. Si vous connaissez quelqu'un sans problème, vous ne le connaissez pas très bien. Si vous connaissez quelqu'un qui pense qu'il n'a pas besoin de s'améliorer, il ne se connaît pas très bien.

J'espère que les améliorations que vous identifierez seront des choses que vous pourrez résoudre avec votre propre conscience et l'aide de l'équipe. Cependant, je pense que ce n'est pas là que cela se termine. Je m'attends à ce que le superviseur ou le gestionnaire qui rédige vos commentaires soit qu'ils peuvent également coacher leurs subordonnés pour réussir. Ceci est particulièrement critique lorsque l'organisation subit un changement révolutionnaire comme le passage de planifié à Agile (ou ad-hoc à Agile).

Prototype rapide et sale ou géré par le risque?

J'avais un responsable qui demandait que les tâches soient exécutées d'une certaine manière.

Rapide et sale, mais une chose de beauté.

Il savait la bêtise de cela, et cela faisait partie de son sens de l'humour ironique. Beaucoup de gens disent des choses comme ça et ils sont très sérieux. Quelque part, il existe un compromis ou une opportunité pour atténuer le problème avec une technologie ou une approche améliorée.

Que pouvons-nous sacrifier pour s'adapter à notre boîte de temps?

Dans le premier chapitre d' Extreme Programming Explained , deuxième édition, Kent Beck parle de ce qu'il faut pour aller vite. Sa réponse est que "vous ne faites que ce que vous devez faire pour créer de la valeur pour le client".

Risque

Dans la première édition du même livre, Beck identifie un peu plus étroitement les vues de Boehm sur le contrôle des risques comme étant essentielles à sa méthodologie en disant:

"Le risque est le problème fondamental du développement logiciel"

Dans les deux éditions, Beck répertorie et décrit huit risques courants, suivis d'une affirmation selon laquelle XP (ou peut-être par extension, Agile) aborde chacun d'une manière particulière. Pour moi, la plupart de ses explications se résument à l'utilisation d'incréments plus petits et d'itérations plus rapides nous permettant de remettre les choses sur la bonne voie avant que les risques ne deviennent trop grands pour être gérés.

Mentalité de suffisance

Beck discute des ressources dans le contexte d'une histoire sur les montagnards et les forestiers et présente un concept appelé «mentalité de suffisance». Dans le contexte de votre situation, il demande "Comment feriez-vous si vous aviez assez de temps?" Juste ce premier chapitre, disponible sous forme d'aperçu de livre, peut fournir beaucoup de matière à réflexion sur la façon dont XP (et d'autres méthodes Agiles) pensent aux contraintes comme le temps.

La contrainte pourrait être le symptôme, pas la maladie

Il y a des années, j'ai regardé un livre sur la procrastination qui disait que beaucoup de procrastination provient de la peur. Si vous ne commencez pas, vous ne vous trompez pas et vous ne serez peut-être pas critiqué. La contrainte et le perfectionnisme donnent quelque chose que notre sens moral nous dit est meilleur que la procrastination, mais a probablement le même résultat. Considérez que vous avez peut-être un problème avec la procrastination sous une autre forme?

Critique et concurrence

Dans les méthodologies agiles comme Scrum, les chances d'être critiqué ou puni pour la procrastination n'ont jamais été aussi élevées. C'est un cercle vicieux. Je tergiverse parce que je suis critiqué, je suis critiqué parce que je tergiverse. Avec les réunions de mêlée quotidiennes, nous sommes toujours en alerte parce que nous sommes toujours un jour ou moins de rapporter à l'équipe ce que nous avons accompli.

Dans une équipe idéale, Scrum donne une opportunité quotidienne de corriger la procrastination. Les erreurs ne devraient pas avoir le temps de grossir avant l'arrivée des secours. Les équipes ne sont pas toujours là où elles devraient être fondées sur la confiance, de sorte que les dirigeants au sein de l'équipe peuvent avoir à répondre de manière proactive à la critique ou à la peur de la critique pour permettre aux choses d'avancer.

Dans notre monde du travail, chaque membre d'une équipe doit également rivaliser avec les autres. Il est un peu schizophrène de croire en une équipe qui partage le travail et la gloire des réalisations, mais utilise ensuite un processus annuel de gestion des performances qui récompense 20% de ses membres, punit ou expulse 10% ou plus des membres, et prétend que la majorité de 70% contribue de son mieux sans incitations. Je pense que c'est un gros éléphant dans la salle WRT qui promeut le travail d'équipe, et pour faire référence à l'histoire de Kent Beck, cela montre des liens culturels profonds avec le fait d'être Mountain People.

La voie à suivre

En tant que membre d'une équipe Agile, il serait bon d'étudier et de dialoguer avec d'autres sur ce qui fonctionne. Si votre équipe utilise TDD pour automatiser ses tests unitaires avec un outil, demandez à la personne qui fait le mieux de vous coacher. Si votre superviseur ou gestionnaire a un problème avec votre approche de la documentation, découvrez ce qu'il aime ou qui le fait à sa guise et suivez leur approche. Si cela se résume à une vitesse de codage brute, examinez ce qu'il faut pour coder plus rapidement.

Les leaders peuvent prendre des mesures dans la bonne direction en modélisant les comportements souhaités, comme parler franchement de leurs propres problèmes (pas de ceux de quelqu'un d'autre), proposer et suivre avec aide, dialoguer sur la façon dont l'équipe peut passer au style Agile Marine (c'est-à-dire sans homme laissé derrière). Tout le monde dans l'équipe n'a pas les mêmes capacités. Il peut être approprié d'explorer le jumelage des membres de l'équipe ou d'attribuer des tâches et des rôles qui peuvent mettre l'accent sur les forces complémentaires des personnes impliquées. La planification de la croissance ou de la correction des compétences devrait être une partie enrichissante du travail à la fois pour le superviseur et le subordonné, mais elle doit se produire tôt et souvent pour être efficace.

Vous programmez aussi pour le plaisir? J'ai également été ennuyé par les restrictions au travail qui prennent le plaisir de la programmation, et pour compenser, je lance parfois un nouveau projet à la maison et "fais le bien". La scission me permet de satisfaire à la fois: mes besoins et l'entreprise.

Ou, vous pourriez développer une nouvelle compétence autre que la programmation à faire pendant votre temps libre qui (éventuellement) satisfait ce que le travail ne peut pas fournir. ;)