Vous devez choisir le logiciel dont vous avez besoin: écrit à temps ou de haute qualité

J'espère que j'ai pu attirer votre attention avec un titre aussi provocateur (et, certes, exagéré). Bon. Maintenant, laissez-moi le reformuler d'une manière un peu plus élégante et moins attrayante :

En principe, les logiciels peuvent être écrits à temps ou bien, mais pas les deux en même temps *

* sauf dans quelques cas dans les équipes performantes existantes

Depuis plusieurs mois, je réfléchis aux raisons pour lesquelles la création de logiciels de haute qualité ne cadre pas bien avec les dates estimées et la planification en général. Au cours de ma carrière, j'ai vu des projets construits sur une variété de modèles (en cascade, véritablement flexibles, en cascade de manière flexible), et ils avaient tous une chose en commun: quel que soit le projet sur lequel nous travaillons s'il était réalisé « par la science» ( c'est-à-dire que nous ne nous sommes pas permis de sales tours, à cause desquels nous aurions plus tard des cauchemars), alors nous avons toujours dépassé les délais.

D'un autre côté, chaque fois que le projet était livré «à temps», cela signifiait qu'en cours de route, il devait inévitablement réduire son volume, ou couper tellement de coins que pendant la mise en œuvre, des montagnes de dettes techniques s'accumulaient, garantissant pratiquement que le projet devrait être réécrit peu de temps après lancement. Par conséquent, j'ai commencé à me demander: pouvons-nous vraiment supposer que le projet a été livré «à temps» si, par conséquent, nous avons une laid, gênant à supporter, bourré de bugs et, franchement, une version plus laide du code par rapport à ce que nous avions à l'origine essayé de faire?

Traduit en Alconost

J'ai eu l'occasion de travailler sur des projets sans délais. Oui, formellement des «délais» étaient là, mais loin du béton armé. Tout le monde a compris que nos délais sont flexibles et que la qualité est plus importante que la livraison rapide du produit. C'est sur ces projets que nous avons obtenu le meilleur logiciel, il y avait les développeurs les plus satisfaits et, en général, ces projets étaient parmi les plus réussis de tous sur lesquels j'ai dû travailler. Mais nous savons tous que de tels projets sont très rares, sinon je n'aurais pas écrit tout ça.

Alors, pourquoi est-il si difficile de planifier le travail et de distribuer de bons logiciels, avec des délais fixes? Je pense que cela est largement dû à la créativité , aux compétences et à l' imprévisibilité .

Côté créatif de la programmation

Je suis d'avis que le développement de logiciels est, par définition, une activité créative . Bien sûr, il y a des développeurs qui effectuent les mêmes tâches triviales, mais ils n'ont de travail que jusqu'à ce que quelqu'un ait compris comment automatiser leur travail. Vous ne les envierez pas et le sujet de cet article est complètement différent.

Pour moi, il y a quelque chose de spécial dans l'acte de créer quelque chose de nouveau et dans la recherche de solutions originales en réponse aux défis; c'est pourquoi je me sens appelé au développement de logiciels, et je ne pense pas que je suis le seul. En fait, je pense que la créativité est la principale raison pour laquelle les développeurs apprécient leur travail. Mon expérience suggère que chaque fois que je travaillais dans des conditions où un «ensemble de pratiques» strictes et immuables (qu'il s'agisse d'une pile technologique, de processus, de réglementations, etc.) était observé, alors il y avait moins d'espace pour la créativité J'étais - moins j'étais fasciné par un tel travail. "En fin de compte, s'ils ont déjà tout décidé pour eux-mêmes, alors pourquoi ont-ils besoin de moi?" - J'ai pensé. D'un autre côté, j'étais beaucoup plus remplie, inspirée par un tel travail (dans lequel j'étais aussi le plus productif), où il y avait relativement peu de directives d'en haut, il y avait de la place pour la créativité et on me faisait confiance pour prendre des décisions techniques moi-même.

Il est important de noter qu'une liberté de création supplémentaire conduit au fait que sur le chemin de la recherche d'une solution, il y aura inévitablement plus d'essais et d'erreurs - et c'est normal. Il semble à certains que vous pouvez simplement connaître la solution parfaite a priori (à l'avance) sans écrire une seule ligne de code. Au contraire, j'insiste sur le fait que dans le processus de création, le chemin vers la découverte d'une solution à une tâche (cela ne s'applique pas seulement au logiciel) nécessite un bricolage : il est impossible de tout savoir à l'avance avec certitude; au contraire, vous apprenez en pratique, en triant progressivement les nouvelles options et en vous en tenant à celles qui fonctionnent, en affinant votre décision (et éventuellement en la remettant progressivement aux clients si vous travaillez selon une méthodologie «flexible») jusqu'à ce que vous en soyez satisfait.



Pensez simplement au nombre de fois qu'il a fallu pour concevoir minutieusement un composant sur papier - alors seulement, pour refaire complètement la conception, cela ne valait que commencer la mise en œuvre. Il y aura toujours des inconnues inconnues dans cette entreprise , et vous pouvez les identifier et y faire face a posteriori (en fait), programmer votre décision, et ne pas passer beaucoup de temps à théoriser et à ne pas prétendre que nous pouvons posséder à l'avance des informations parfaites. Une telle improvisation ne correspond pas bien aux dates estimées.

En outre, comme c'est le cas pour d'autres activités créatives, il est utile de pratiquer la procrastination stratégique lors de la programmation - c'est le premier terme proposé par Adam Grant, affirmant que souvent il n'est pas possible de créer à la demande, mais, au contraire, la créativité vient comme une «notification push » de un processus qui se déroule en arrière-plan dans votre tête:

«Les employés qui procrastinent régulièrement consacrent généralement plus de temps à la pensée divergente, et les conservateurs les considèrent plus souvent comme plus créatifs que leurs collègues. La procrastination n'alimente pas toujours la créativité: si un employé n'a pas une motivation sûre pour résoudre un problème majeur, alors en raison du glissement, il est tout simplement à la traîne. Cependant, si une personne est suffisamment passionnée par l'entreprise et donne de nouvelles idées, puis reporter la tâche, il arrive à des solutions plus créatives . "
- Grant, Adam. «Originaux: comment les non-conformistes font bouger le monde»

Encore une fois, cela ne plaira pas aux partisans de la planification centrale qui cherchent à prévoir et à mesurer chaque minute dans les projets de développement logiciel.


Voie lactée , Mars et météore

Compétence de programmation

Les meilleurs développeurs que je connaisse sont des artisans qualifiés. La maîtrise est une caractéristique d'un bon logiciel: vous créez quelque chose qui fonctionne et vous le créez de la meilleure façon possible - il est relativement facile de créer quelque chose qui fonctionne, mais il est très difficile de faire quelque chose qui non seulement fonctionnera, mais résistera également à l'épreuve du temps.

Puisque vous êtes un maître, la qualité de votre travail parle de vous . Pour vous, la qualité est plus importante que la quantité, parce que vous ne voulez pas être reconnu comme l'auteur de govnokod, même si vous pourriez satisfaire le chef de produit, donner à votre programme un brillant externe, et à l'intérieur le bourrer d'un tas de mauvaises surprises - j'appelle cette approche Kindersurprise Development . Vous savez que consacrer suffisamment de temps à un cas et écrire un bon programme est juste, alors résistez à la pression «faites-le plus vite», car vous savez que plus vous installerez de béquilles maintenant, plus votre code sera court et plus il y aura de problèmes avec lui entreprise.


Les yeux saignent

L'artisanat est soucieux des soins : nous nous soucions de faire un excellent travail, de ceux qui devront maintenir notre code après nous, de nos clients qui devraient avoir un accès facile à notre programme, des coéquipiers, etc. Vous faites cela parce que vous n'êtes pas un connard et parce que vous savez que c'est ce que vous devez faire si vous vous souciez de la réussite du projet.

Bref, un bon ingénieur a une tâche difficile: veiller à la qualité - qui se fera sentir sur le long terme - dans un monde où tout est décidé pour se faire rapidement.

En pratique, cela s'exprime de manière similaire:

• Trouvez la bonne combinaison entre l'encapsulation, l'extensibilité, l'évolutivité, etc. - encore une fois, une approche itérative par essais et erreurs sera nécessaire, car personne ne réussit à construire la meilleure solution du premier coup.
  
• Prenez le temps de refactoriser si vous rencontrez un morceau de code honteusement mauvais.
  
• Écrivez de bons tests complets - faites peut-être même TDD
  
• Programme en tandem avec un collègue
  

Inutile de dire qu'il est impossible de planifier tout cela à l'avance, donc une approche similaire ne vous aidera toujours pas à respecter les délais.

Vos prédictions sont fausses

«Même s'il existe des exigences claires - et il semble que cela ne se produise jamais, il est presque impossible de calculer le temps qu'il faudra pour un travail particulier, car nous n'avons jamais résolu ce problème auparavant. Si vous décidez, alors donnez-vous simplement le résultat. "
- Ron Jeffries, Mouvement NoEstimates

Les projets logiciels sont des Systèmes Complexes : ils sont créés par des personnes, et portent donc l'empreinte des relations interpersonnelles, de la motivation, des problèmes de communication et de la psychologie humaine en général - tout cela est très difficile à modéliser et à quantifier dans le tableau si vous êtes intéressé par mon avis. Les projets logiciels sont donc très difficiles à modéliser (et donc à prévoir). Ceci est mieux expliqué par Nassim Taleb dans son livre " Anti-Fragility" :

«Les systèmes complexes sont fortement interdépendants (ce qui est difficile à reconnaître) et les réactions non linéaires. «Non linéaire» signifie que lorsque vous doublez, par exemple, la dose de médicament ou le nombre de travailleurs dans l'usine, le retour ne sera pas deux fois plus, mais soit beaucoup plus ou beaucoup moins. Cela ne veut pas dire que deux week-ends à Philadelphie sont deux fois plus agréables qu'un - je peux le dire d'après ma propre expérience ... »
- Nassim Nicholas Taleb, Anti-Fragilité

Pire, étant donné que le temps ne peut pas être une valeur négative, toute «surprise» imprévue risque de retarder l'achèvement du projet, plutôt que de le rapprocher, car il existe une asymétrie de résultats:

«Le temps n'est pas une valeur négative, ce qui signifie qu'un projet de trois mois ne peut pas être mis en œuvre sur une période nulle ou négative. Par conséquent, sur l'axe du temps, qui se déplace de gauche à droite, les erreurs s'accumulent à droite et non à gauche. Si l'incertitude est linéaire, nous verrions que certains projets sont achevés beaucoup plus tôt que prévu (car nous arrivons parfois à un endroit beaucoup plus tôt, et parfois beaucoup plus tard). Mais en réalité, ce n'est pas le cas. "
- Nassim Nicholas Taleb, Anti-Fragilité

C'est une mauvaise nouvelle, car l' incertitude est garantie , et même de petites erreurs dans l'évaluation des tâches individuelles s'accumuleront exponentiellement à l'échelle du projet. De plus, nous considérons ici le meilleur cas lorsque les délais sont fixés par les développeurs eux-mêmes après une évaluation minutieuse du timing. Cependant, la réalité est beaucoup plus absurde: dans la plupart des cas, «l'entreprise» fixe les délais à sa guise, et ce n'est qu'à ce moment-là que les ingénieurs qui prévoient comment satisfaire à toutes les exigences pour cette période arbitrairement spécifiée se saisissent de la question; le cas est aussi flagrant que de démarrer une maison par le toit, pas par la fondation, ou de mettre une charrette devant un cheval.


Bonne question

Voici quelques exemples qui démontrent la non-linéarité du développement logiciel et les boucles de rétroaction qui en résultent:

• Vous avez suggéré une fois que l'API à laquelle vous souhaitez vous lier accepte accountId , mais en fait, elle n'accepte que memberId . Ajoutez à la période estimée de 4 jours dont vous avez besoin pour refactoriser le code API - après quoi, à votre tour, vous aurez besoin d'un examen séparé, pour lequel nous ajouterons encore 2 jours.
  
• La tâche que nous espérions résoudre en 2 jours dure une semaine, car dans le processus d'examen, l'un de nos collègues vous oblige (et le fait correctement) à refactoriser et à optimiser le morceau de code dégoûtant qui attend depuis longtemps dans les coulisses.
  
• N'oubliez pas cette tâche ponctuelle lorsque vous ne deviez mettre en œuvre qu'une seule nouvelle opportunité. Mais il s'est avéré que pour cela, vous devez mettre à jour la dépendance, ce qui a pris 4 jours, et cette opération a provoqué une réaction en chaîne avec la mise à jour d'autres dépendances et tout un tas de dépendances lors de l'assemblage.
  

Sommes-nous foutus?

Par simple inertie, nous continuons à jouer à ce jeu avec évaluations et planification, juste pour nous assurer: nous sommes censés contrôler la situation. Mais en réalité, nous ne contrôlons rien; l'expérience montre que les projets logiciels sont imprévisibles. Je pense donc qu'il vaut mieux se concentrer sur les affaires plutôt que sur la planification - #NoEstimates , qui est avec moi? Cependant, bien sûr, cela ne fonctionnera pas dans de nombreuses organisations: «Vous ne pouvez pas simplement le prendre et laisser les ingénieurs diriger la balle afin que personne ne les contrôle. Il doit y avoir une responsabilité! » Je comprends.


Tu ne dis pas ça?

Que faire alors? Je pense que cela se résume à réduire l'écart entre le monde des tables et le monde de l'IDE afin de donner aux ingénieurs un maximum de créativité, de flexibilité et de liberté pour faire preuve de maîtrise, mais en même temps, respecter de manière responsable la promesse et répondre aux attentes des parties prenantes du projet. Technical Manager (Engineering Manager) - le meilleur spécialiste de la construction de tels ponts, qui peut également absorber l'écart entre les deux mondes. Ce travail n'est pas facile, mais nécessaire. Voici à quel point Aaron Longwell parle d'elle dans son article:

«Puisque les responsables techniques vivent à la frontière entre les entreprises et les techniciens, ce sont eux qui doivent résoudre les contradictions entre les attentes et la réalité. Ils sont comme une suspension à levier, qui est tirée dans différentes directions: elle peut se casser des deux côtés. Si l'entreprise gagne, les développeurs sont mis à mort. Si les considérations d'ingénierie l'emportent sur celles des entreprises, alors adieu au budget et aux délais. En tout cas, un échec. Un chef de projet logiciel performant trouve des moyens d'agir avec souplesse; pour céder, ne pas casser, et résoudre progressivement la friction. Le leadership comme approche de service peut vous aider à devenir plus flexible. »
- Aaron Longwell, Pourquoi le développement logiciel nécessite des leaders de serveurs

Il est également très important d'établir une relation de confiance solide entre la production et les ingénieurs. S'il y a confiance, vous pouvez négocier honnêtement et consciencieusement les délais. Si vous avez déjà prouvé que votre équipe fait de bons logiciels, alors vous devriez avoir une assez bonne réputation, et les parties prenantes devraient vous faire confiance, sachant que si vous êtes en retard, alors pour de bonnes raisons et pour le bien commun.

Un autre «truc» que j'ai personnellement utilisé en tant que manager était de ne pas nommer de dates spécifiques, car elles se transforment inévitablement en échéances strictes. Il est préférable de donner des dates floues, par exemple, "trois à cinq semaines". Dans ce cas, à l'approche d'une échéance aussi chancelante, vous ajoutez: «en avril ou mai», ce qui peut facilement être interprété comme «entre le 15 avril et le 3 mai» début avril, vers le 10 avril, il peut devenir «d'ici 20 Avril ", etc. Dans ce cas, vous ne dissimulez pas, ne communiquez pas avec vos collègues et l'équipe offre la flexibilité des termes qui seront nécessaires pour résoudre les problèmes inévitables imprévus qui surviennent.

Enfin, n'oubliez pas que c'est le développeur qui devrait être responsable de la qualité technique du produit délivré, et non les autres parties intéressées. Il est tout à fait naturel qu'il y ait des frictions entre les organisations qui, à première vue, sont guidées par différentes incitations. Dans ce cas, il est très important de noter que vous êtes tous (vraisemblablement) unis par un objectif commun: fournir au client un logiciel de haute qualité dans les plus brefs délais. Apparemment, seuls les bons développeurs sont capables de penser dans cet esprit et de comprendre qu'il est important d'éviter l'approche trompeuse «un, deux - et c'est fait!», Qui à long terme est la plus lente.

En conclusion, je dirai qu'il s'agit d'un problème résoluble, bien que complexe (et courant). Je dirais que si, à votre avis, votre manager ou votre organisation n'est pas enclin à écrire un bon logiciel, alors vous devez en parler et essayer de le changer; si cela échoue, trouvez un autre emploi.

À propos du traducteur

L'article a été traduit par Alconost.

Alconost localise des jeux , des applications et des sites dans 70 langues. Traducteurs en langue maternelle, tests linguistiques, plateforme cloud avec API, localisation continue, chefs de projet 24/7, tout format de ressources de chaîne.

Nous réalisons également des vidéos de publicité et de formation - pour les sites qui vendent, présentent des images, de la publicité, des formations, des teasers, des explicateurs, des bandes-annonces pour Google Play et l'App Store.

Plus de détails