Ralentir pour stimuler le développement

Du traducteur:
Le début de l'année est le moment idéal pour évaluer soigneusement l'année écoulée. Jetez un coup d'œil sur ce qui se passe et comprenez comment faire de 2019 une année meilleure, plus calme et plus productive. Dans ce cas, nous avons trouvé utile l'article Comment ralentir pour aller plus vite que jamais dans le développement de logiciels écrit par Lemi Orhan Ergin . Et nous publions sa traduction ci-dessous.

Points clés:

• La hâte ne nous rend pas plus rapides ou plus efficaces; cela augmente le stress et rend impossible la concentration. Au lieu de vous précipiter, vous avez besoin d'une approche créative, d'efficacité et de concentration.
• Embauchez les spécialistes les plus talentueux, travaillez ensemble, pratiquez et étudiez ensemble. Cela augmentera le professionnalisme et créera une culture d'excellence dans l'entreprise.
• Renforcez la flexibilité de l'équipe et l'efficacité des processus en élaborant des plans et en les examinant régulièrement. Trouvez, analysez et éliminez toutes les sources de perte de temps.
• Vous ne pouvez pas être flexible sans une base de code de qualité. Éliminez les défauts, publiez les versions plus souvent, écrivez des tests avant d'écrire le code principal, effectuez le refactoring, concentrez-vous sur une conception simple.
• Exécuter un logiciel ne signifie pas bien conçu. Seuls les vrais professionnels peuvent créer des logiciels de haute qualité qui vous permettront de vous développer le plus rapidement possible.

L'exécution la plus rapide possible de tâches peut devenir votre ennemie si vous vous engagez dans un développement incontrôlable. Il y a trois domaines importants à ralentir: les personnes, les processus et les produits. Avant de plonger dans les détails, laissez-moi vous raconter une histoire.

Pour autant que je m'en souvienne, c'était en 2011. J'ai rejoint l'équipe qui a créé la plateforme de marketing en ligne. Ma tâche principale était d'ajouter de nouvelles fonctionnalités aussi rapidement que possible. J'étais développeur senior. Nous appelons les développeurs «seniors» lorsqu'ils se développent plus rapidement que les autres, non? Cependant, lorsque j'ai commencé à travailler, nous avons remarqué qu'il était presque impossible de travailler rapidement en raison de dettes techniques et de défauts dans la conception du système. Nous avons également remarqué qu'à chaque tentative d'accélération, nous augmentons la complexité et détruisons la qualité. J'en suis venu à la conclusion que la seule façon d'accélérer est de réécrire le système à partir de zéro.

Je me souviens que lors d'une conversation téléphonique avec le chef de produit, j'ai dit que nous devions réécrire l'ensemble du système. Après 30 secondes de silence, le manager a demandé: «Vous dites que votre équipe a développé un produit de si mauvaise qualité que cette même équipe devrait désormais réécrire le même produit, mais cette fois, il vaut mieux le faire. Non? Désolé, mais c'est inacceptable. Vous auriez dû mieux l'écrire tout de suite. »

Le logiciel Zombie a besoin d'être réécrit, encore et encore

Selon le rapport Chaos du Standish Group , 94% des projets ont été refaits à zéro plus d'une fois. C'est énorme. En me souvenant des projets sur lesquels j'ai travaillé, je comprends que presque tous ont été réécrits à partir de zéro en utilisant de nouvelles technologies, avec une nouvelle architecture et un nouveau design. La copie à partir de zéro est si typique de notre industrie que les entreprises la considèrent souvent comme le seul moyen de développer et de gérer un projet. D'abord, nous écrivons, puis nous réécrivons et réécrivons, encore et encore.

Nous devons connaître nos principaux ennemis. La vitesse est une qualité vitale dans le développement de logiciels. Il est important non seulement d'entrer en premier sur le marché, mais aussi de répondre rapidement aux avis des clients, d'ajouter des fonctionnalités et de corriger les bugs afin que les utilisateurs soient satisfaits du produit.

Mais nous avons tous des problèmes avec le concept de «vitesse». Nous pensons que des actions rapides et raisonnables et efficaces sont en quelque sorte liées à la fixation de délais. Nous pensons que le résultat sera atteint plus rapidement si vous travaillez plus dur ou attirez plus de personnes. En conséquence, nous ajoutons de nouvelles personnes au projet ou faisons des heures supplémentaires pour accélérer le travail. La hâte ne nous rend ni plus rapides ni plus productifs. La hâte crée une atmosphère stressante, nous prive de la possibilité de nous concentrer sur le travail et détruit la productivité. Ce qu'il faut, c'est de la créativité, de l'efficacité et de la concentration.

Le développement de logiciels est sacrément compliqué. Nous ne pouvons pas nous débarrasser de cette complexité. Par conséquent, nous devons vivre avec elle. L'obligation de travailler rapidement crée une atmosphère instable et turbulente, nous plonge dans le stress et rend impossible un travail productif et intensif. Cette approche ne fonctionne tout simplement pas.

Productivité (capacité) de l'équipe, plan directeur, estimations des coûts de main-d'œuvre, heures de travail fixes, délais et vitesse de l'équipe (vitesse de l'équipe) - tout cela est illusoire. L'incompétence est réelle. La rapidité de livraison dépend directement du professionnalisme des personnes, de l'efficacité des processus et de la qualité du travail effectué. Le plus souvent, les développeurs fixent eux-mêmes des délais internes, même si cela n'est pas nécessaire.

En conséquence, nous obtenons un système hérité. La pression des délais combinée à l'incompétence conduit à un code hérité - une impasse pour la poursuite du développement du système. J'avais l'habitude d'utiliser un autre nom pour les systèmes hérités - logiciel zombie. Cette définition fonctionne mieux, car l'héritage est un logiciel littéralement mort, mais qui semble fonctionner en production. Cela fonctionne et rapporte même de l'argent, mais cela nécessite le sang, la vie et l'énergie des développeurs pour pouvoir travailler. Les développeurs ont peur de toucher au code qui fonctionne, personne ne veut le développer.

Robert C. Martin a beaucoup parlé des systèmes hérités sur son twitter : "Si votre logiciel devient de plus en plus difficile à développer, vous faites quelque chose de mal." Travaillant à la hâte, nous réduisons tellement la qualité qu'à chaque étape, le travail ralentit de plus en plus. Je suis sûr que la seule façon de se développer plus rapidement est de ralentir le processus jusqu'à ce que nous atteignions la stabilité.

La ruée vers le développement logiciel est mauvaise

Dans une série CleanCoders, Robert C. Martin a déclaré : «La principale valeur du logiciel est la capacité du système à s'adapter aux changements futurs et à simplifier leur mise en œuvre.» Dépêchez-vous est mauvais dans le développement de logiciels. Toute tentative de se dépêcher entraînera une baisse sérieuse de la productivité, de la concentration, de l’efficacité des personnes, de l’adaptabilité aux changements et de la flexibilité des logiciels.

Par exemple, nous avons toujours le temps de corriger les bogues, mais nous n'avons pas le temps d'écrire des tests. Nous ne refactorisons pas ou n'écrivons pas de tests parce que nous avons peu de temps. Mais nous avons toujours le temps de déboguer, de conduire avec des béquilles et de corriger les bugs.

Nous sommes tellement concentrés sur le processus que nous oublions souvent le plus précieux pour le développement logiciel - les gens. Les processus aident les gens à fabriquer de meilleurs produits, à accroître leur motivation et à cultiver un environnement de travail sain. En fin de compte, l'efficacité des processus est importante, mais il n'y a rien de plus précieux que les gens.

Vous devez comprendre que personne et rien n'est parfait. Les clients, les cadres, les gestionnaires, les membres de l'équipe, les représentants commerciaux, même vous, ne sont pas tous parfaits. Les exigences, la documentation, les outils, le code, un système développé et sa conception ne seront également jamais idéaux. Nous devons donc nous arrêter à la hâte et accélérer sans réfléchir le développement. La seule façon d'aller plus vite à un rythme soutenu est de ralentir dans trois directions importantes:

• Personnel - accroître le professionnalisme et les compétences,
• Le processus améliore la flexibilité et l'efficacité,
• Produit - amélioration de la qualité et automatisation.

Où ralentir en ce qui concerne les gens

Les processus et les outils ne créent pas de produit. Les gens le font. Il convient de reconnaître que «l'embauche de talents» est la tâche la plus importante de l'entreprise, qui a un impact direct sur l'avenir de l'entreprise dans son ensemble et le produit en cours de création en particulier.

Embauchez les personnes les plus talentueuses de votre organisation. Dire "le plus", je ne veux pas dire le plus intelligent et le plus expérimenté. Je recherche au moins enthousiaste, discipliné et motivé. Si une personne a ces trois qualités, elle développera facilement ses talents.

L'embauche devrait être avantageuse pour les deux parties. Par conséquent, ralentissez le processus d'embauche et prenez le temps de l'améliorer. Les gens rejoignent des entreprises auxquelles ils croient. Simulez le type de personnes que vous attendez de voir dans votre équipe. Et faites croire en vous des gens talentueux, en regardant votre culture, votre idée de l'avenir et vos employés.

L'ego est le poison qui tue lentement votre organisation. Ne le laissez jamais infiltrer votre organisation. En partant des imbéciles qui sont agréables en communication et en terminant par des idiots brillants - ne laissez pas les extrêmes faire partie de votre équipe. N'embauchez pas de personnes avec un ego gonflé. Avec eux, vous ne créerez jamais une culture d'entreprise qui ravira les autres.

Arrêtez de travailler seul, travaillez ensemble. Ne permettez pas la fragmentation dans l'équipe. Les solitaires et les développeurs de héros sont le signe d'une organisation dysfonctionnelle. Asseyez-vous à côté. Fixez des normes avec toute l'équipe. Travailler en binôme ou en groupe; examiner ensemble. Permettez à tous les participants au processus d'être responsables du résultat.

Pratiquer ensemble est le moyen le plus efficace d'améliorer vos compétences. En interagissant, nous inspirons non seulement les autres, mais nous apprenons également les uns des autres. Exécutez régulièrement une retraite de code , un dojo de codage et un randori avec toute votre équipe. Passez 30 minutes chaque jour à vous entraîner.

Laissez la connaissance se répandre parmi les gens. Apprenez ensemble. J'ai organisé des sessions Brown Bag / Lunch & Learn avec toutes les équipes dans lesquelles je travaillais depuis 2010. Deux fois, j'ai entendu mes collègues: "Participer aux séances le mercredi me permet de pomper, et cela me motive beaucoup." Cela reflète clairement les avantages de la tenue régulière de mitaps internes.

Recueillir des commentaires et les transmettre aux autres. Pour recueillir des commentaires collectifs, organisez une grande rétrospective. Je fais cela depuis plus d'un an. Soit dit en passant, c'est un excellent moyen de vous immerger dans la résolution de problèmes avec un groupe de 20 personnes ou plus.

Enseigner aux autres et partager les connaissances est le meilleur moyen d'atteindre la maîtrise. Parlez publiquement et contribuez à la communauté.

Il est généralement admis que les développeurs détestent écrire de la documentation. Mais la réalité dit le contraire. Tout résultat lu par d'autres personnes est de la documentation. En partant du code système et en terminant par le code de test, des messages aux validations au graphique de validation dans le référentiel, des messages de journalisation aux messages d'erreur, les développeurs créent beaucoup de documentation sans s'en rendre compte. Et, peu importe ce que vous documentez, si les gens le lisent - documentez le mieux possible.

Vous n'êtes pas des enfants. L'organisation n'est pas vos parents. Chacun devrait gérer de façon indépendante sa carrière et investir en lui-même. Si votre contribution implique une perte de temps ou d'argent, faites-le par vous-même.

Comment ralentir et améliorer le processus

Chaque jour, nous sommes confrontés à de nouveaux défis. Ce ne sont pas seulement les besoins du marché et les exigences des nouveaux produits. Les défis techniques affectent également nos progrès.

Les plans ne sont rien, mais la planification est tout. Faites un plan et revoyez-le constamment. Surtout aux premiers stades d'un projet lorsqu'une flexibilité maximale est nécessaire. La réconciliation quotidienne avec un plan tel qu'une mêlée quotidienne ou un standup quotidien ne suffit pas. Il est nécessaire d'interagir plus étroitement au sein de l'équipe, de travailler en binôme et de consulter le plan encore plus souvent. Gardez la durée d'itération minimale jusqu'à une semaine. Organisez plusieurs canaux de rétroaction avec des sessions de révision et de démonstration régulières.

Définissez des objectifs à court et à long terme. Les objectifs à court terme définissent l'objectif de l'équipe, les objectifs à long terme empêchent sa perte.

Si vous voulez comprendre pourquoi quelque chose ne va pas, visualisez le flux de travail, à la fois d'un point de vue technique et organisationnel. Visualisez les erreurs et les échecs pour maximiser l'apprentissage de première main.

Ne prenez jamais de décisions basées sur des sentiments. Collectez toujours des données, analysez et prenez des décisions en fonction de celles-ci. Il est également important de donner à chaque développeur l'accès aux produits et aux métriques techniques. Cela augmente l'implication et la compréhension du produit en cours de développement.

Les déchets sont tout ce que vous passez du temps, mais cela n'a pas de valeur pour l'entreprise. Trouvez et éliminez les déchets au bureau, dans le code et dans les processus métier.

Les boy-scouts quittent le parking plus propres qu'à leur arrivée. La même philosophie s'applique au développement de logiciels. Suivez la règle de reconnaissance et gardez le code plus propre après chaque modification. Si vous allez ajouter de nouvelles fonctionnalités et voir des failles dans le fichier qui peuvent être corrigées, faites-le sans demander la permission. N'oubliez pas d'écrire les tests en premier. Cela vous donnera confiance pour effectuer des changements.

Vous pouvez découvrir les déchets à tout moment du cycle de développement du système. Suivez des critères de préparation clairement définis (définition du fait) et éliminez les tâches dans l'esprit de «90% terminé, 90% restant».

Ne laissez pas l'émergence de branches à longue durée de vie - elles sont considérées comme mauvaises. Ne vérifiez pas votre code manuellement. Avec les tests manuels, vous êtes susceptible de vérifier un script d'exécution réussi. Tous les autres scripts ne peuvent être vérifiés qu'en utilisant du code. Par conséquent, prenez ce problème au sérieux.

Comment le ralentissement peut améliorer la qualité des produits

Une chose est sûre: sans base de code de haute qualité, vous ne pouvez pas être flexible, désolé. La première chose à faire est d'éliminer la dette technique et de corriger les erreurs. Si nécessaire, suspendez le développement de nouvelles fonctionnalités et concentrez-vous sur la correction des bogues.

L'approche «Je vais le réparer rapidement, puis je vais le réparer» ne fonctionne pas dans les réalités actuelles, car elle est trop risquée. Lors de l'élimination des erreurs, une approche plus disciplinée est nécessaire. Tout d'abord, écrivez un test qui reproduit le problème. Après cela, corrigez le bogue et assurez-vous que le test réussit maintenant. Vous pouvez maintenant envoyer le patch en production en toute sécurité.

J'ai travaillé en équipes qui ont passé presque tout leur temps à corriger des bugs et à maintenir le projet. La raison de leur souffrance est un travail instable dans la production. Pour continuer à développer de nouvelles fonctionnalités, tout en corrigeant les erreurs, vous devrez diviser l'équipe en équipes virtuelles. Par exemple, à chaque itération, nous sélectionnons deux gars impliqués dans le support et la correction des bugs. Nous les appelons Batman et Robin. Peu importe les fonctionnalités que vous êtes pressé de terminer, les bugs sont corrigés sans interruption depuis le développement principal.

Les développeurs utilisent souvent l'une des pratiques de décélération pour accélérer davantage les demandes d'extraction. Ils arrêtent le développement en cours, effectuent des vérifications et effectuent des révisions de code pour améliorer la qualité du code. Le code non vérifié ne sera jamais mis en production.

Notre objectif ultime devrait être la transition vers la livraison continue et les versions fréquentes. Commencer par utiliser des branches git et finir par des stratégies de déploiement, des moyens de fournir des commentaires aux pratiques de test automatisées - tout cela nécessite une approche spéciale.

Les pratiques que vous utilisez à différentes étapes du cycle de développement logiciel montrent à quelle vitesse vous vous développez. Lorsque vous travaillez avec des succursales, utilisez l'approche «s'engager tôt, engager souvent, perfectionner plus tard, publier une fois». Si vous travaillez sans branches, utilisez les bascules de fonction. Cela éliminera la perte de temps.

J'utilise TDD depuis des années. Souvent, les gens se plaignent que TDD affecte négativement la vitesse de développement. Joe Rainsberger a partagé ses réflexions sur TDD sur Twitter : « Craignez-vous que TDD ralentisse vos programmeurs? Pas besoin. Ils ont probablement besoin de ralentir. »

TDD est plus refactoring que test; plus de réflexion que de codage; plus de simplicité que d'élégance. C'est pourquoi TDD conduit à une qualité supérieure. Lorsque vous utilisez TDD, vous n'aurez que le nombre minimum suffisant de tests et une conception simple.

Avez-vous déjà atteint une couverture à 100% du code avec des tests? Je l'ai atteint dans un projet de trois mois, couvert chaque ligne de code de production avec des tests. À ce moment, je me sentais comme un héros doté de super pouvoirs. Mais lorsque nous avons déployé le système en pré-production pour les tests d'acceptation, nous avons remarqué que les quatre fonctions ne fonctionnaient pas. J'ai écrit des tests d'intégration et fonctionnels pour trouver et corriger les erreurs. À ce moment, j'ai réalisé que les tests unitaires ne garantissaient pas une bonne conception et une fonctionnalité fonctionnelle. Arrêtez de compter le pourcentage de couverture du code comme des tests. Cette métrique ne montre rien.

Corrigez immédiatement les erreurs si cela prend 30 minutes ou moins. De plus, utilisez 20% du temps pour éliminer la dette technique.

En règle générale, nous écrivons du code sans l'intention de le modifier à l'avenir. Lors de la conception d'un système, nous choisissons également les technologies et les outils, en prévoyant de ne pas les modifier à l'avenir. Mais nous nous trompons. La refactorisation devrait être possible à n'importe quelle étape du projet. Comme le dit Kent Beck, nous devons apporter des changements faciles afin que d'autres changements soient faciles. Pour rendre cela possible, nous stockons le code de tous nos microservices dans un mono-référentiel. Cela rend le refactoring facile et vraiment nécessaire.

Toute décision dans la conception est erronée si elle est prise plus tôt que nécessaire. Vous devez attendre le dernier moment acceptable pour prendre une décision. Nous utilisons l'architecture «Ports et adaptateurs» pour obtenir un faible couplage et une cohésion élevée au niveau de la conception de l'ensemble du système. Pour cette raison, nous obtenons des monolithes parfaitement conçus.

Un monolithe n'est pas mal, le mal est une mauvaise conception. Nous commençons toujours par le développement d'un monolithe, et grâce à l'architecture «ports et adaptateurs», nous extrayons des parties de la fonctionnalité en microservices. Comme Martin Fowler l'a dit dans son article Monolith First : «Commencer immédiatement avec une architecture de microservices est risqué, il vaut mieux commencer avec un monolithe. Divisez en microservices uniquement lorsque et si nécessaire. "

Ralentir pour accélérer comme approche de la vie

Andreas Möller a partagé ses sentiments sur le développement de logiciels sur un tweet : «Je ne veux pas écrire du code qui fonctionne. Je veux écrire du code propre, maintenable, facile à comprendre et bien testé. »

Pour y parvenir, nous devons nous concentrer sur trois domaines: les personnes, les processus et les produits. En ralentissant le travail des gens, nous nous efforçons d'augmenter le professionnalisme et les compétences. En ralentissant le processus, nous nous efforçons d'augmenter la flexibilité et l'efficacité. Et en ralentissant le travail sur le produit, nous nous efforçons d'augmenter le niveau d'automatisation et le niveau de qualité. Lorsque nous nous concentrons sur ces trois domaines, nous commençons à cultiver une culture qui rend possible un développement rapide.

Nous devons nous rappeler ce qui suit:

• Un système qui fonctionne n'est pas nécessairement bien écrit
• Seuls les vrais professionnels peuvent créer un système bien conçu
• Seul un système bien conçu vous permettra de libérer de nouvelles fonctionnalités le plus rapidement possible

À propos de l'auteur

Lemi Orhan Ergin est un assistant de développement logiciel qui cherche à élever le niveau d'excellence dans son industrie et à partager son expérience avec la communauté. Co-fondateur de Craftbase et fondateur de la communauté turque de l'artisanat logiciel . Participe au développement de logiciels depuis 2001. Il pratique et encadre activement dans des domaines tels que Scrum, la programmation extrême, les méthodologies de développement et les technologies Web.