Un guide du programmeur pour déchiffrer le code "deux fois le travail, la moitié du temps"

La gestion théorique est pleine de papys. J'ai lu des œuvres de Deming, Goldratt, Ohno et Drucker. J'ai entendu parler d'Ackoff et de Juran. J'ai apprécié l'attitude humaine et prudente dans chaque livre que j'ai lu. Cela n'a jamais été : « Exploiter les gens jusqu'à leur épuisement ». Peter Drucker, dans son "Management Rev Ed", nous a même guidés, nous managers du 21ème siècle, dans ce que nous devons faire :

La contribution la plus importante, et en fait la plus unique, de la gestion au XXe siècle a été la multiplication par 50 de la productivité de l'ouvrier dans l'industrie manufacturière. La contribution la plus importante que la gestion doit apporter au XXIe siècle est également d'augmenter la productivité du travail intellectuel et du travailleur intellectuel.

Vingt ans après le début du 21e siècle, à quel point sommes-nous proches d'atteindre cet objectif ambitieux dans le monde du développement logiciel ? Je vois qu'on en est loin. Explorons où nous en sommes, quels problèmes nous avons et ce que nous pouvons faire pour les résoudre.

Explorer l'approche généralisée de l'efficacité du développement logiciel

« The Art of Doing Twice the Work in Half the Time » est le sous-titre du livre « Scrum » de Jeff Sutherland, co-auteur de ce framework. J'aime ce sous-titre, car il reflète fortement à quel point nous pouvons devenir plus efficaces dans nos efforts de programmation. Tout n'est pas sans nuages, cependant. Le premier problème que nous rencontrons ici est qu'il est difficile de comprendre ce qu'est l'efficacité dans notre travail. Le problème complexe suivant consiste à comprendre si nous devenons plus efficaces au fil du temps.

Mais pourquoi voulons-nous l'efficacité à la fin ? Eh bien, il s'agit de faire la même chose avec moins d'effort, et dans de nombreuses sphères de notre vie, il est bon d'avoir les mêmes résultats ou de meilleurs résultats plus rapidement ou à un prix inférieur.

Revenons à notre question. Les praticiens Scrum proposent des points d'histoire comme mesure d'une tâche. Il existe une définition sur le site scrum.org :

Un Story Point est une unité de mesure relative, décidée et utilisée par des équipes Scrum individuelles, pour fournir des estimations relatives de l'effort pour répondre aux exigences.

Un story point est une magnitude de complexité liée à la tâche de référence. Vous et moi avons une idée des efforts qu'il nous a fallu pour mettre en œuvre cette tâche pas très difficile. Si je vous dis que le nouveau travail coûtera trois points d'histoire, je dis qu'il sera trois fois plus dur que le précédent. C'est ma conjecture, et qui sait à quel point ce serait difficile.

Concentrons-nous à nouveau sur l'efficacité. Si nous livrons des tâches estimées en 25 story points dans ce sprint, sommes-nous meilleurs que dans le sprint précédent où nous n'en avions que 15 ? Ou peut-être avons-nous été plus prudents et avons-nous donné des estimations plus élevées pour le même effort ? Mais comment pouvons-nous même comparer? Nous ne faisons pas de travail répétitif en génie logiciel à l'échelle d'une usine. Nous concevons et mettons en œuvre des fabriques d'informations qui fournissent des services. Y a-t-il une place pour les discussions sur l'efficacité dans notre industrie ?

Il y a une place pour ces discussions. Au moins, nous pouvons intentionnellement ralentir les choses. Par exemple, nous pouvons tergiverser ou sauter d'une tâche à l'autre. Si nous pouvons faire quelque chose de moins efficace, il y a de l'espoir pour le contraire. Cependant, je ne vois pas les story points comme un instrument de mesure utile ici. Ils peuvent facilement être maltraités, intentionnellement ou non. Nous devons chercher quelque chose de mieux.

Définition de l'objet de la mesure

Avant de définir la manière d'augmenter la vitesse de notre effort de programmation, nous devons déterminer quel est cet effort que nous voulons mesurer. Je ne vois rien que nous puissions utiliser à l'échelle de l'industrie, mais le côté positif est que nous n'avons pas besoin d'une telle étendue pour améliorer l'efficacité. Le besoin est pour quelque chose qui décrit une étape de travail significative dans le développement de votre produit de programmation. Nous pouvons utiliser des épopées, des tâches, des fonctionnalités ou tout autre élément représentant l'ajustement positif du système en cours de développement.

Dans ma place actuelle, nous utilisons trois niveaux différents :

 User-valuable feature: ⎿ Its slice for the engineering team's convenience: ⎿ The specific task inside a slice (eg, back-end task).

Nous avons besoin que l'ajustement ait les caractéristiques suivantes :

1. A l'heure de début et l'heure d'achèvement ;
2. Se produit régulièrement.

Donc, ce que nous définissons ici est "ce gros travail". Appelons-la l' action dans la suite de l'article. Toutes les actions ne sont pas identiques. J'ai démontré trois types dans l'exemple ci-dessus.

Nous avons besoin d'actions régulières.

Cette exigence vient du fait que vous ne pouvez pas être efficace dès le départ, mais que vous pouvez devenir plus efficace avec le temps. Ce n'est pas l'inconvénient de l'approche décrite. Scrum fonctionne ainsi, Toyota Production System fonctionne ainsi et la science fonctionne ainsi. Nous avons besoin de répétabilité pour découvrir l'état actuel et l'améliorer constamment.

Vous ne pouvez faire quelque chose de nouveau avec une efficacité finalement optimisée que par hasard. Et plus l'action est complexe, moins elle est possible. Une préparation préalable peut aider. Cependant, la capacité de se préparer à l'avance signifie que l'action ou ses sous-actions se sont produites dans le passé et qu'il existe des connaissances à leur sujet. Il n'y a rien à préparer pour quelque chose de complètement nouveau. D'un autre côté, nous ne rencontrons guère de nouveauté complète dans notre vie. Une fraction de l'expérience précédente est toujours pertinente pour les situations jamais vécues.

En résumé, nous avons une action d'un genre comme une essence à mesurer.

Comment mesurer une action d'un genre ?

A première vue, la section précédente n'apporte rien. Nous faisons des actions en quelque sorte. En quoi est-ce mieux que des tâches mesurées avec des points d'histoire, des tailles de t-shirts ou des animaux ? Un nom n'est pas un gain unique. L'action d'un genre a deux horodatages, et nous pouvons mesurer sa durée en soustrayant le début de l'achèvement. La durée est ici un excellent gain car elle est notre clé du langage de la réalité quotidienne.

• Combien de temps a-t-il fallu pour terminer une épopée ?
• Il nous a fallu 39 jours du début à la fin.

Formidable.

Y a-t-il autre chose que nous gagnons ?

La deuxième exigence de notre action, la régularité, nous donne tellement qu'il est difficile d'y croire. Tout d'abord, nous gagnons un flux d'actions d'un certain type. Voici une définition du flux issue du livre "Actionable Agile Metrics for Predictability " de Daniel Vacanti :

En termes simples, le flux est le mouvement et la livraison de la valeur client à travers un processus.

Notre exigence de deux horodatages, le début et la fin d'une action, nous donne un bon ensemble de nouvelles métriques. Les voici tirés du même livre :

Travail en cours (le nombre d'éléments sur lesquels nous travaillons à un moment donné), le temps de cycle (combien de temps il faut à chacun de ces éléments pour passer à travers notre processus) et le débit (combien de ces éléments sont terminés par unité de temps ).

Je peux vous intriguer si vous pensez que c'est tout ce que nous avons ici. Nous sommes au tout début. Un autre trésor que le flux nous offre est la trace qu'il laisse au fil du temps. Cette trace nous permet de mieux comprendre le système. Nous pouvons le capturer à l'aide de plusieurs schémas. L'un d'eux est le diagramme de dispersion du temps de cycle.

Son plaisir vient du fait qu'il capte "comment on fait les choses ici". Cela ne nécessite rien de votre processus, aucune méthodologie particulière. Voulez-vous capturer le flux de brossage des dents à l'aide du diagramme de dispersion du temps de cycle ? Fais-le c'est tout. Souhaitez-vous la même chose pour les maisons construites dans votre région ? Absolument bien. Souhaitez-vous suivre le cycle de vie du développement, y compris les expériences A/B effectuées après le développement de nouvelles fonctionnalités ? S'il vous plaît commencer et faire.

Sur l'image, vous pouvez également voir les lignes de centiles signées avec 50 %, 70 %, 85 % et 95 % à droite. Que signifient-ils? Sur le côté gauche, il y a des jours. Vous pouvez lire les 85 % et 16 jours de la manière suivante :

Pour 85 % des articles qui sont entrés dans notre système au cours de la période considérée, il a fallu 16 jours ou moins pour en sortir.

C'est la deuxième fois que j'utilise le mot "système" dans cette section. Qu'est-ce que ça veut dire? Définissons-le de la manière suivante pour cette histoire :

Le système est quelque chose qui fait des actions d'une sorte.

Une action du genre dans l'exemple de système de construction de maisons ci-dessus est de construire une maison. Faire un kilomètre de route ne compte pas comme une action ici. C'est un autre type d'action et un autre système. Cependant, il n'y a pas de division concrète, mais nous voulons que nos maisons se ressemblent, ainsi que le brossage des dents et le développement de logiciels avec des tests A/B. Pour quelque chose d'assez différent, nous pouvons proposer un autre système.

Un autre gain important

Il est temps de discuter d'un autre effet qui nous aiderait à garantir l'exactitude de nos efforts d'amélioration. Imaginez que vous ayez une équipe et que vous ayez besoin de créer un nouveau logiciel. Vous prenez les user stories comme une mesure de progrès, comme une action. Après avoir terminé votre première histoire, il est temps de faire la rétrospective pour voir où nous pourrions être meilleurs la prochaine fois.

Y a-t-il quelque chose dans cette logique qui nous mène à un piège ? Regardons de plus près.

Lors de la mise en œuvre de la première user story, le principal obstacle était de se mettre d'accord sur les bibliothèques nécessaires et d'installer les logiciels requis. Cela a pris du temps, et c'était une vraie douleur. Au cours de la rétrospective, l'équipe a discuté à quel point c'était douloureux et comment pouvons-nous être meilleurs la prochaine fois. Le manque assez évident est que la prochaine fois à peine, vous devrez vous mettre d'accord sur les bibliothèques et installer le logiciel. Les bibliothèques restent généralement longtemps. L'installation de logiciels ferait partie de l'intégration de nouveaux membres, mais cela ne dérangera pas l'équipe déjà établie sur leur deuxième histoire d'utilisateur. C'est assez différent et peut maintenant faire partie du système d'intégration.

Jetons un coup d'œil à la sagesse de programmation suivante de Donald Knuth ( ou Tony Hoare ) :

L'optimisation prématurée est la racine de tout Mal.

Je suppose que vous avez rencontré celui-ci, qui vous dit de ne pas penser à la performance dans les premières étapes du développement logiciel. Vous avez peut-être vu cette sagesse sous la forme suivante :

Faites-le fonctionner, faites-le bien, faites-le vite.

L'exemple sur l'installation des bibliothèques montre que l'adage est pertinent pour le code et aussi pour l'équipe de codage ! Quel mystère nous rencontrons ici ! Ce n'est pas un mystère mais l'attribut d'un système. Il y a au moins deux raisons pour lesquelles nous devrions éviter de sauter directement dans les améliorations après le premier essai.

Raison statistique de ne pas sauter tout de suite dans l'amélioration

Chaque action complète d'un genre a sa durée. La durée se compose de deux parties : une causée par des raisons communes et une autre causée par des raisons spéciales.

Revenons une fois de plus à l'exemple du brossage des dents. Généralement, enduire la brosse à dents de dentifrice prend quelques secondes. Dans des cas particuliers, vous devez sortir le dentifrice du placard, l'ouvrir et l'utiliser. Ici, toute l'action prend plusieurs minutes. Si, pour une raison quelconque, nous devons penser à l'efficacité de la sous-action du revêtement de la brosse à dents lors du brossage des dents, le faire après la première serait trompeur. L'action initiale contient une partie supplémentaire et diffère de l'action typique que nous voulons accélérer.

La nature d'être spécial conduit à l'apparition incohérente des raisons de durée spéciale. Ce qui transparaît toujours est le cœur de notre action, la cible féconde de nos améliorations.

Théorie des contraintes Raison de ne pas sauter tout de suite dans l'amélioration

Que nous dit la théorie des contraintes ? Il nous dit que le tout produisant quelque chose sera aussi productif que sa partie la moins productive. Imaginez que nous ayons une entreprise qui construit de minuscules maisons à un étage. Nos capacités annuelles sont les suivantes :

• 6 sous-sols,
• 24 ensembles de murs,
• 52 toits.

Combien de maisons peut-on construire par an ? Vous pourriez répondre six, mais je suggère de ne pas en dire plus de six. Notre processus de construction est conséquent : sous-sol → murs → toit. Finir la dernière, sixième maison peut prendre du retard sur la fin de l'année.

Si nous augmentons le nombre de murs que nous élevons ou de toits que nous construisons, cela changera-t-il la capacité de toute notre entreprise ? Produirons-nous plus que le "pas plus de six" mentionné ? Non, le sous-sol nous limite toujours.

Les chiffres de capacité ci-dessus proviennent de l'expérience de cette entreprise superficielle. Nous n'avons pas cette expérience après la mise en œuvre de la première user story. Nous devons encore déterminer la contrainte de notre système de construction de user stories car nous ne savons pas combien de temps dure chaque sous-action. Considérez que nous avons une assurance qualité dans le cadre de notre processus de développement de user stories. Le test d'une user story dure quatre heures. Le développement d'une user story dure cinq jours ouvrés en général. Disons qu'il y a 250 jours ouvrables dans une année. Vous attendez-vous à avoir 50 user stories complètes à la fin ou 730 ? Comme pour les maisons et les sous-sols, au maximum 50 par an. Nous avons besoin de rassembler des statistiques pour comprendre la forme de notre action et sa partie la moins productive.

Combien d'actions complètes suffisent-elles pour commencer les améliorations ?

Pour être tout à fait sûr, je suggère d'avoir le nombre ∞ d'actions complètes à ce stade. Après avoir obtenu ce nombre exact, vous pouvez être sûr à 100 % de ce qu'il faut améliorer en premier.🥁

Pour ceux qui ne sont pas dans le monde des mathématiques pures, considérons les réflexions suivantes. Voici une référence du livre «Actionable Agile Metrics for Predictability » faisant référence au livre « How to Measure Anything » :

Par exemple, Douglas Hubbard (dont le livre "How to Measure Anything" est listé dans la Bibliographie) conseille ses clients sur sa " Règle de Cinq " : Règle de Cinq - Il y a 93,75% de chance que la médiane d'une population se situe entre la les valeurs les plus petites et les plus grandes dans tout échantillon aléatoire de cinq de cette population.

S'il vous plaît, ne voyez pas cela comme un tabou pour changer quelque chose pour les cinq premières actions. Considérez également d'autres aspects : la sécurité sanitaire, la cohésion d'équipe et plus encore.

Par où commencer l'amélioration ?

Si nous prenons l'action élémentaire, par exemple, allumer le téléviseur en appuyant sur un bouton dessus, nous pouvons le penser comme un tout. Pour réduire le nombre de mouvements et le temps total, achetez-vous un clicker et gardez-le à un endroit près de votre canapé. Dans cet exemple, la première action peut prendre environ 20 secondes et la seconde... une seconde. Mes félicitations! Vous avez réduit les 95 % du temps précédemment requis et recevez toujours la même valeur. Quelle fantastique élimination des déchets !

Toutes les actions ne sont pas aussi simples. Le développement des user stories déjà mentionné est complexe. Il est difficile de gérer l'amélioration là-bas en un seul saut. Nous devons décomposer les choses en sous-actions, comme dans l'exemple de la construction de maisons. Nous pouvons commencer par le cycle de vie suivant :

1. Une analyse,
2. Développement,
3. Essai,
4. Fait.

Où commencer?

Dans le Lean Manufacturing, le processus de création, ou action tel que nommé dans cet article, se compose de sous-actions de trois types :

• Activités à valeur ajoutée ;
• Activités nécessaires sans valeur ajoutée ;
• Déchets.

La formulation de la user story, la conception d'une solution et son codage sont toutes des activités à valeur ajoutée. L'utilisation de la branche git pendant le développement peut être considérée comme une activité nécessaire sans valeur ajoutée. Il n'ajoute rien à ce changement mais organise tout le processus. Le gaspillage empêche l'accumulation de valeur pendant un certain temps sans raison valable. Attendre la base de données qui ne fonctionne pas est un gaspillage.

Dans le Lean manufacturing, les gaspillages (ou muda ) sont connus et définis par le créateur du Toyota Production System, Taiichi Ohno. Au moins, ils sont définis pour la société Toyota, le constructeur automobile. D'autres industries ont leurs variantes. Voici le nôtre, créé par Mary et Tom Poppendiecks dans le livre " Lean Software Development " :

1. Travaux en partie terminés,
2. Processus supplémentaires,
3. Fonctionnalités supplémentaires,
4. Le changement de tâche,
5. En attendant,
6. Mouvement,
7. Défauts.

Ou ceux-ci ? Extrait du livre " Implementing Lean Software Development " des mêmes auteurs :

1. Travaux en partie terminés,
2. Fonctionnalités supplémentaires,
3. Réapprentissage,
4. Transferts inutiles,
5. Le changement de tâche,
6. Retards,
7. Défauts.

Au moins, les ingénieurs logiciels peuvent bouger maintenant ! 😅

Comment ces piliers ont-ils pu autant changer en seulement quelques années dans notre industrie ? Je vois la réponse dans l'impossibilité d'avoir une liste suffisante de déchets pour tous les temps à venir. Même Toyota, à un moment donné, a inventé le huitième gaspillage.

C'est formidable que la liste de notre industrie ait changé si radicalement. Ce changement ouvre nos esprits à reconsidérer nos pensées sur ce qui est un déchet en permanence. Voici un autre point de vue sur ce qui peut être une partie inutile du développement logiciel :

L'un des plus grands malentendus dans le monde du logiciel est la valeur du code. Mais le code est un handicap, comme nous le répéterons à maintes reprises dans ce livre. Plus nous écrivons de code, plus nous générons de complexité et de risques pour nous-mêmes.

C'est une citation de " The Value Flywheel Effect " de David Anderson avec Mark McCann & Michael O'Reilly. Ouf, quelle balade !

Alors, comment commençons-nous ? En regardant la sous-action la moins productive. Que cherchons-nous ? Sous-actions qui n'ajoutent pas de valeur.

Reconsidérer le workflow de développement des user stories

Permettez-moi de vous rappeler le flux de travail que nous avions :

1. Une analyse,
2. Développement,
3. Essai,
4. Fait.

Habituellement, ce sont les parties faites par différentes personnes, et il y a toujours un peu de temps pour attendre le transfert. Documentons-le :

1. Analyse active,
2. Analyse effectuée,
3. Développement Actif,
4. Développement terminé,
5. Essai,
6. Fait.

Je n'ai pas inventé ces étapes. Je les ai tirées de la démo du produit ActionableAgile Analytics . Peut-on leur faire confiance ? Je dirai oui, car j'ai vu différents exemples de données réelles, et celui-ci semble proche. Examinons les statistiques des étapes suivantes. Il montre les moyennes.

Le temps de cycle du système est de 9,37 jours. Cette déclaration signifie qu'une tâche arrive à l'étape Analysis Active , passe par toutes les suivantes et quitte Testing pour Done , et, en moyenne, ce chemin prend 9,37 jours. Les étapes avec "Active" dans leur nom semblent apporter une utilité au résultat ainsi que Testing . Les étapes se terminant par "Terminé" sont des files d'attente, de l'attente et rien d'utile. Si nous les marquons en conséquence à l'aide du diagramme Flow Efficiency, nous verrons qu'en moyenne, seulement 40 % du temps passé sur une seule user story est précieux.

Dans ce diagramme, nous incluons également le temps bloqué suivi et les tâches étranges, qui ont passé tout leur temps dans les étapes "Terminé". Si nous les excluons, l'efficacité du flux pour cet exemple de démonstration serait d'environ 50 %.

Aborder la perte de temps découverte

Comme nous avons trop peu d'informations sur l'ensemble de données de démonstration, il n'y aura pas de recommandations spécifiques telles que : "Donnez à l'équipe E de meilleurs ordinateurs". Cependant, il y aurait suffisamment de réflexions pour inspirer les vôtres dans votre cas. La partie la moins productive de notre processus est l'étape Analyse terminée . Nous ne pouvons même pas l'appeler ainsi car il décrit l'attente. Cependant, cela prend près de 29% de chaque tâche. Quelle pourrait être la raison ici?

La phase de développement actif ne semble pas lente, nécessitant moins de temps que la partie d'analyse active. En regardant le WIP moyen, nous mettrons en évidence le problème : le service d'analyse peut gérer plus de user stories simultanément.

Équilibrer cela, par exemple en amenant plus de développeurs dans l'équipe, pourrait être une solution possible. Cependant, ne soyez pas trop pressé ici. La raison peut être très différente. L'étape Analyse terminée peut contenir le travail d'infiltration. Il se peut que les développeurs ne soient pas satisfaits de la qualité des exigences mais ne parviennent pas à résoudre systématiquement ce problème et passent du temps lors de cette étape à les améliorer. Découvrir les conditions aux limites, proposer l'interface utilisateur de traitement des requêtes asynchrones et plus encore.

Avant de proposer la solution, appliquez l'analyse des causes profondes : utilisez cinq pourquoi , une arête de poisson ou autre chose.

Vérification du succès de la modification appliquée

Disons que nous avons abordé le problème de la section précédente. Comment pouvons-nous être sûrs que le changement proposé a fonctionné ? Nous devons à nouveau accumuler des données. Vous souvenez-vous de la règle de cinq de ce qui précède ? Nous pouvons également l'utiliser ici. Notre système est maintenant ajusté. Mesurons-le à nouveau.

Dans mon travail, j'utilise deux outils pour mesurer les résultats de l'expérience :

1. Diagramme de flux cumulatif,
2. La ligne de tendance sur le diagramme de dispersion du temps de cycle.

Voyez-vous la zone cyan de l' Analyse terminée ? Attendez-vous au moins à ce qu'il s'amincit avec le temps et qu'il disparaisse tout au plus.

Regardez la ligne pointillée verte apparaissant sur ce diagramme déjà familier. Il montre la tendance du temps de cycle à 85 % pour les N derniers jours. J'utilise 30 au lieu de N, car il est suffisamment stable pour démontrer les changements. Si la solution découverte gère la cause profonde suffisamment profonde, attendez-vous à ce que cette ligne glisse de ≈30 % jusqu'à 11 jours.

S'il n'y a pas de modifications importantes des données, il est temps de rechercher d'autres solutions.

Les prochaines étapes

Le prochain point évident à améliorer est l'étape Développement terminé . Imaginons que nous y soyons également parvenus. Nous avons réduit de 50 % le temps nécessaire initialement pour terminer la user story. Cependant, le titre de l'histoire promet une productivité quadruplée. Dans ce cas, nous pouvons commencer à penser à l'étape d' analyse active . Essayez ensuite de paralléliser celui de Testing avec celui-ci et Development Active .

Néanmoins, je ne suis pas sûr que ce soit nécessaire ici. Imaginez que vous utilisiez un logiciel qui intègre de nouvelles fonctionnalités tous les deux jours. Le marché n'est peut-être pas prêt pour cela. Le marché devient une contrainte pour notre système. Cette découverte ne signifie pas que nous sommes toujours limités dans nos améliorations. Habituellement, nous avons plusieurs systèmes de développement créateurs de valeur, et nos fonctionnalités prennent plus de neuf jours. D'après mon expérience, la vue d'ensemble sur les articles d'une durée de six mois a découvert seulement 30% du temps à valeur ajoutée. L'image plus détaillée des tâches à l'intérieur des 30 % a de nouveau démontré les 30 % exacts du temps à valeur ajoutée. Il s'est avéré que pour l'ensemble des 180 jours, il n'y avait que 16 jours d'activité à valeur ajoutée. Un potentiel d'amélioration de 11 fois est visible.

L'approche en résumé

Questions valides

Je pense que l'approche décrite a un fort potentiel en faisant la contribution de la gestion du XXe siècle qui nous a dépassé. Lorsque je parle de la méthode à quelqu'un, je suis généralement confronté à plusieurs questions :

1. Cela ne va-t-il pas détruire le plaisir de programmer ?

2. Le développement de logiciels est tellement imprévisible et tellement créatif. Comment parler de travailler son efficacité ?!

   
   

La proposition ne détruira pas la joie de la programmation. Vous avez peut-être remarqué que nous avons travaillé à éliminer les trous dans le processus où rien ne s'est passé. Être capable de prendre la tâche qui vient d'être créée est aussi joyeux que de la prendre deux jours après. Une autre joie vient de regarder votre code comme le système en cours de changement et votre équipe comme la même chose. Vous avez un nouveau pays d'outils de programmation et d'approches ouvertes.

Pourquoi auriez-vous auparavant besoin d'outils de programmation de foule en ligne ? Devenir plus rapide ? Mais qu'est-ce qui était plus rapide à l'époque ? Pourquoi auriez-vous besoin de l'étape de conception logicielle explicite ? Ah ! Notre équipe de développement est accablée de bugs, c'est pourquoi les user stories attendent jusqu'à 30 % de leur cycle de vie pour que les développeurs corrigent les bugs. Pourquoi ne pas les empêcher ?

Ce qui tue la joie de programmer, c'est le besoin régulier de se couper la chair pour accomplir les tâches. Être doté de meilleures méthodes, outils et connaissances ne tue pas la joie.

Oui, la création de développement logiciel est en effet imprévisible et non routinière. Cependant, est-ce infiniment imprévisible ? Un an serait-il suffisant pour accomplir l'une des tâches qui vous regarde depuis votre carnet de commandes ? Qu'en est-il de dix ans ? La nature de leur variation est-elle si insaisissable que nous ne pouvons rien y faire ? L'existence du diagramme Cycle Time Scatterplot nous montre qu'il y a une limite à la variation du développement logiciel. Vous pouvez souligner que certaines tâches nécessitent une correction constante textuelle rapide, tandis que d'autres nécessitent plusieurs jours d'enquête. Je serais d'accord avec cela, mais je vous demanderais aussi : "L'existence de ces tâches est-elle le résultat d'une nature logicielle inévitable, ou est-ce le résultat de l'architecture logicielle que vous utilisez ? La grosse boule de boue dans les processus n'est-elle pas la raison d'un tel gâchis ?"

Le besoin d'un flux de développement plus fluide n'est-il pas enfin une raison à toute épreuve pour régler vos dettes techniques, architecturales et processuelles ?

Oui, même dans l'architecture la plus favorable au changement, il semblerait que des questions difficiles nécessitent plus de temps que nous ne le souhaiterions. Et nous avons déjà la place sur le diagramme de dispersion du temps de cycle au-dessus de la ligne du 95e centile pour les gérer. Mais ce sont des exceptions, et nous ne voulons pas que tout devienne des exceptions.

Nous, les managers, ne devrions pas faire la lutte contre les incendies mais devrions travailler sur la conception de nos systèmes et leur variation.

Éviter les étapes évidentes et erronées

Je ne suis pas la première personne à rechercher l'efficacité dans notre industrie. Certains chercheurs pensent qu'ils connaissent déjà le sujet. Leur approche consiste à installer le logiciel de suivi sur les ordinateurs de leurs employeurs et à punir ceux qui font du travail considéré comme non. Cette méthode montre l'ignorance totale des sources d'efficacité du développement logiciel. L'idée d'un grand succès résultant d'une grande tension n'est pas seulement mauvaise. C'est mortel. Cela limite notre regard sur nos systèmes dans une seule dimension : travailler assez dur ou pas assez. Votre expérience personnelle fournit suffisamment d'exemples de personnes épuisées. L'histoire nous montre que des pays sont tombés dans ce piège avec de nombreuses victimes. Non, travailler dur n'est pas la voie vers l'amélioration continue. Mais qu'est-ce que c'est?

Découvrir le lieu de départ

Il y a plus d'un siècle, Frederick Taylor a commencé ses travaux sur ce que nous appelons aujourd'hui la gestion scientifique. Il regarda ses collègues et chercha les méthodes les plus efficaces pour qu'ils fassent leur travail :

Taylor déterminé à découvrir, par des méthodes scientifiques, combien de temps il faudrait aux hommes pour effectuer chaque travail donné; et c'est à l'automne 1882 qu'il commença à mettre en œuvre les premiers éléments de la gestion scientifique.

Je ne connais pas la structure de l'entreprise sur laquelle Taylor travaillait à l'époque. Il se peut que son étape de production soit parmi d'autres, ce qui pourrait également signifier que Taylor a été pris dans le piège de la sous-optimisation locale. Il s'agit d'augmenter le nombre de toits que notre entreprise de construction de maisons imaginaire peut gérer. L'influence de la découverte de Taylor ne diminue pas, même si c'était le cas. Maintenant, nous connaissons le danger de ce piège et pouvons agir plus intelligemment.

Vous souvenez-vous de mon exemple avec des articles d'une durée de six mois ou de 180 jours ? Si j'élimine avec succès la perte de temps dans les éléments intérieurs où travaillent les ingénieurs, j'économiserai 38 jours et il me restera 142 jours pour un gros élément. Si je fais la même chose pour l'extérieur où toute l'équipe travaille, j'économiserai 126 jours et j'aurai 54 jours pour le même gros article. Torturer les développeurs avec des heures supplémentaires et des lits au bureau n'a aucun sens si vous voulez gagner gros. Regardez le processus de création de valeur du point de vue d'un oiseau et n'approfondissez-le qu'une fois que vous n'êtes plus dans la marge d'amélioration à ce niveau.