Business : Sur les professionnels des moutons et des logiciels

Quelque part dans le département d’ingénierie, une fonctionnalité est demandée.

Le chef de produit entre. Le chef de produit fait une demande. Les membres de l’équipe logicielle acquiescent et une autre fonctionnalité est ajoutée au backlog de développement. Le chef de produit s’en va.

Pendant ce temps, dans un univers parallèle. Une fonctionnalité est demandée.

L’équipe du logiciel engage une discussion sur le problème que le chef de produit essaie de résoudre. Parfois, c’est simple, le problème est que la fonctionnalité est manquante. Mais pas cette fois. Cette fonctionnalité n’était que la première solution qui apparaissait dans l’esprit du chef de produit.

C’est un problème intéressant. Le groupe clarifie cela ensemble et discute ensuite de plusieurs manières alternatives de le résoudre. Certaines solutions sont plus chères, d’autres ne sont pas tout à fait correctes. Mais certains sont plus simples, moins chers, moins risqués ou plus puissants que la fonctionnalité demandée. Certains n’impliquent même pas de logiciel! Beaucoup de cerveaux sont engagés, cela prend donc un peu de temps. Ensuite, une solution est trouvée. Pas parfait. Juste bien. Oui très bien.

Les fonctionnalités sont des solutions. Vous feriez mieux de comprendre les problèmes.

Quelque part dans le département d’ingénierie, une itération est sur le point de commencer.

Le chef de produit a priorisé le backlog. Le chef de projet indique clairement à l’équipe l’importance de la fonction la plus prioritaire. Pourtant, l’équipe a du mal à l’adapter à l’itération. C’est une bouchée. Le chef de projet pousse une refactorisation planifiée à la prochaine itération et fait quelques commentaires sur l’estimation élevée. L’équipe se rend. « D’accord, nous allons essayer. » Le chef de projet l’a déjà entendu.

Pendant ce temps, dans un univers parallèle. Une itération est sur le point de commencer.

L’équipe est réunie sur un tableau blanc. Les post-it abondent. Le chef de produit fait le point sur les priorités des problèmes. L’équipe revisite les solutions sélectionnées et les décompose en petits morceaux. Tout libérable. La plupart d’entre eux sont précieux par eux-mêmes, bien que certains impliquent des basculements de fonctionnalités. La conversation est centrée sur la valeur libérée, les opportunités et les contraintes techniques. La résolution est marquée en plaçant plus de post-it sur le tableau. Les verts. Vert signifie aller.

Le chef de produit pointe vers une collection de notes vertes et demande un devis. L’équipe en parle en interne et parvient à un consensus. Beaucoup d’incertitude avec certains de ces travaux, la plage de temps signalée est donc plus large que d’habitude. Le chef de produit sait mieux que de le remettre en question. Cette équipe ne modifie pas les estimations lorsqu’elle est poussée, et elle a un assez bon bilan en matière de précision. La précision s’améliorera rapidement au fur et à mesure du déroulement des livraisons. Le chef de produit peut certainement gérer l’incertitude jusque-là.

Les estimations ne sont pas négociables

Quelque part dans le département d’ingénierie, les travaux de livraison sont sur le point de commencer.

Le chef de produit a noté les exigences de la nouvelle fonctionnalité. Ils sont concis, abstraits, conformes à la norme ISO. Le système doit. Les développeurs s’y plongent. C’est un travail difficile. Ce n’est pas toujours évident ce que les exigences impliquent, une fois que vous en êtes aux détails. Soupir. Il faut vraiment… Mais le chef de produit est un invité rare dans le bureau d’équipe. Et les testeurs sont occupés par le travail de la dernière itération qui a été livré en retard. Ils ne doivent pas être dérangés. J’espère qu’ils ne trouveront pas trop de problèmes. Soupir.

Pendant ce temps, dans un univers parallèle. Les travaux de livraison sont sur le point de commencer.

Le chef de produit rencontre un développeur et un testeur. Il est temps de préciser la première bouchée de la solution. Ensemble, ils écrivent une demi-douzaine d’exemples concrets de la façon dont cela devrait fonctionner. Compte tenu de la situation X, quand y arrive, alors le système ne z.

Il y a une discussion. De toute évidence, le chef de produit connaît parfaitement le domaine. Le développeur apporte une nouvelle connaissance de la solution existante à la table, les détails et les conséquences logiques. Le testeur pointe les cas de bord et les flux alternatifs. Par exemple, que se passe-t-il si l’utilisateur a déjà fait cela, interrompt le flux ici, puis revient? Quelles valeurs par défaut s’appliquent alors?

La spécification finale n’est peut-être pas parfaite. Mais l’écrire ensemble constitue une base assez solide pour les tests et le codage.

Des exemples concrets constituent une base fiable pour le travail logiciel. Peu d’autres choses font.

Quelque part dans le département d’ingénierie, le temps presse.

Il est tard dans l’après-midi et le bureau de l’équipe grouille d’activités. Il y aura des pizzas ce soir. Encore. Les rapports de bogues du travail de la dernière itération arrivent à un rythme régulier, et la fonctionnalité importante de cette itération n’est pas encore terminée. Cela est fait à 90% cependant, et l’équipe a promis au chef de projet une version au plus tard lundi matin. Les tests seront rares, mais l’équipe se rattrapera au cours de la semaine.

Les conditions et les boucles implémentant le cœur de la nouvelle fonctionnalité sont écrites, cassées et corrigées à la hâte. Il y en a beaucoup, et il semble y avoir un motif caché quelque part, bien que ce ne soit pas évident. Les bons développeurs ne se répètent pas, mais la répétition ici n’est ni purement syntaxique ni paramétrique, elle est… à un niveau différent.

Une autre tâche de refactoring entre dans l’arriéré. Qui sait quand l’équipe sera autorisée à la prioriser? En ce moment, il y a une sortie à livrer, et de préférence avant le week-end.

Pendant ce temps, dans un univers parallèle. Le temps presse.

Le bureau est vide. Les membres de l’équipe sont avec leurs familles et amis, faisant ce que les gens font après le travail. Temps est mais cela ne préoccupe pas l’équipe en ce moment. La suite de tests d’acceptation automatisée a été occupée à vérifier X, quand y, alors en effet le système ne z. Il est constamment vert depuis trois jours. La majeure partie de cette semaine a été consacrée à des tests exploratoires et à la simplification du code.

Les modèles communs de conditionnels et de boucles ont été réifiés en une structure simple d’objets de valeur composables. Le code client est désormais déclaratif et si simple qu’il ressemble à de la triche. Les développeurs sont enthousiasmés par la perspective de mettre en œuvre de nouvelles fonctionnalités à moindre coût en utilisant la même structure. Les testeurs sont plus enthousiastes à propos d’un bug vraiment génial qu’ils ont trouvé ce matin. «Si cela fonctionne la première fois, essayez à nouveau. Ha! » De tels défauts de réinitialisation sont amusants à trouver lorsque le système est par ailleurs solide comme le roc.

Le chef de produit n’est pas très conscient de ces activités. La dernière estimation, de la semaine dernière, indique qu’il y aura une sortie d’ici la fin des affaires demain, bien dans l’estimation initiale. Le chef de produit attend la sortie. Cette qualité sera à la hauteur de ses normes habituelles. Que les futures versions mettent plus de valeur entre les mains des utilisateurs, à plusieurs reprises et à un rythme constant. Tant que cela reste vrai, on peut faire confiance à l’équipe pour gérer ses propres affaires.

Les pratiques d’ingénierie de base peuvent bien être contextuelles, mais elles ne sont ni des éléments de l’arriéré ni des négociations

Quelque part dans le département d’ingénierie, le logiciel est sorti.

La sortie a été retardée d’une semaine et maintenant elle est enfin sortie. Les membres de l’équipe sont épuisés. Trop de nuits tardives, trop de tests précipités, trop de corrections de bugs de dernière minute. Et il y aura des pompiers dans les jours à venir.

Pendant ce temps, dans un univers parallèle. Le logiciel est sorti.

C’est vraiment un non-événement. Puisant dans le pipeline de livraison continue, l’équipe a publié de nouvelles versions du logiciel des dizaines de fois au cours des dernières semaines. Ce qui rend cette version un peu différente, c’est qu’elle inclut le basculement d’une fonction bascule. Les utilisateurs peuvent désormais accéder à la solution initiale de l’équipe pour leur problème prioritaire. Il résout élégamment la plupart de ces problèmes, pour la plupart des utilisateurs. L’équipe passe à des préoccupations plus pressantes sur la liste du chef de produit.

Mettez de la valeur entre les mains des utilisateurs. De façon répétée, cohérente et durable.

Quelque part dans le département d’ingénierie, la vie continue.

Des rapports de bogues affluent. L’équipe n’est pas surprise. Une autre once de fierté professionnelle s’évapore, inaperçue. Personne ne mentionne le travail de refactoring qui devait commencer cette semaine. Le chef de produit entre. Personne ne lève les yeux.