Est-ce fait ou est-ce fait-fait ?

Dans un monde agile, la définition de « Terminé » est intéressante. Parfois, une fonctionnalité est considérée comme terminée, du point de vue du développeur ou du processus de développement, lorsqu’elle est déplacée dans la colonne « Terminé ». Maintenant, elle « ne fait que » nécessiter des tests et une publication. Facile-peasy. Pas si vite. Examinons cette déclaration en petits morceaux et passons-les un par un – seulement alors pourrons-nous comprendre et former une opinion sur pourquoi. Croyez-moi, il y a de nombreux petits concepts cachés ici. Définition de « Terminé » Dans Scrum, l’équipe (dans les meilleurs cas) établit une Définition de « Terminé ». Il s’agit d’un « contrat » entre les membres de l’équipe. Il est important de définir cela car sinon, nous ne savons pas quand nous sommes terminés. Lorsqu’une User Story (ou ticket) est « Terminée » et qu’elle est demandée pour être ajoutée à la branche de publication (une demande d’ajouter le code à la prochaine version), elle peut être considérée comme terminée. C’est juste un exemple. Je vais vous dire le problème avec cette approche. Jeter des choses par-dessus la haie La plupart des développeurs avec lesquels j’ai travaillé détestent être inclus tard dans le processus de réflexion d’une User Story (ou ticket). La plupart préfèrent comprendre le problème et fournir une solution eux-mêmes, plutôt que de simplement mettre en œuvre la solution donnée par un architecte ou le Product Owner (ou le reporter du ticket). Jusqu’ici, c’est bien. Alors pourquoi les développeurs font-ils parfois la même chose ? Cela signifie jeter des choses par-dessus la haie dans le sens où ils veulent être terminés avec leur ticket une fois qu’il est inclus dans la branche de publication. Et qu’en est-il des tests ? Et qu’en est-il d’informer le reporter ? Et qu’en est-il de voir cela en action ? Et qu’en est-il de l’intégration ? Comment désactiver la responsabilité des développeurs La pire chose que nous puissions faire en tant que membres de l’équipe, chefs d’équipe ou managers est d’exclure notre main-d’œuvre qualifiée du processus décisionnel, ainsi que du processus de publication. Ce que je veux dire, c’est ce scénario : Pat travaille sur un ticket et une fois qu’elle est « Terminée », elle est testée par l’équipe QA. Ils trouvent des tonnes de bugs et découvrent des scénarios de rupture du code (avec d’autres choses non liées) que aucun développeur n’aurait jamais envisagé. Ils ajoutent tellement de valeur… ou sont-ils simplement en train de pomper l’énergie de Pat ? En donnant la responsabilité des tests à quelqu’un d’autre, nous retirons la responsabilité des développeurs. Ils ne sont alors qu’une petite partie du processus, une pièce du mécanisme. Ils ne voient jamais le processus entier. D’après mon expérience, ils se sentent moins impliqués et peuvent même écrire un code sous-optimisé parce qu’ils savent que cela sera testé plus tard de toute façon, et ils devront corriger les problèmes. Bien sûr, les développeurs devraient tester leurs propres fonctionnalités. Citation « Ils ne sont alors qu’une petite partie du processus, une pièce du mécanisme. » Autre processus de développement Une alternative à tout cela est de mettre en place un autre processus de développement. Un processus qui permet aux développeurs. C’est simple, et pourtant complexe. Et il maintient le développeur responsable jusqu’au vrai « Terminé ». Exemple d’un processus de développement Kanban : 1. User Story ou ticket arrive et est priorisé par le Product Owner. 2. Les développeurs prennent en charge depuis le haut du Backlog (comme dans tout projet agile). 3. Les développeurs sont 100% responsables de déplacer le ticket vers les autres états du processus (En cours, Testing, Bloqué, Terminé). 4. Une fois que le développeur a travaillé sur son local, il effectue un PR (Pull Request) vers l’environnement de test (révision par les pairs), où le reporter ou le Product Owner vérifie et révise la mise en œuvre visuelle et peut même la montrer à leurs parties prenantes. Le développeur est entièrement responsable de tester complètement sa propre fonctionnalité. Responsable ne signifie pas qu’il doit le faire lui-même. Peut-être que des collègues peuvent l’aider. Peut-être qu’ils construisent des tests. Mais ils sont responsables.

Ce qui est décrit ci-dessus, c'est le processus où le développeur est entièrement responsable de « En cours » à « Terminé » sans zones floues comme « Terminé-Terminé », « Libéré » ou « Terminé-Terminé-Terminé ». Terminé est quand c'est terminé, quand c'est libéré et en production, et cela crée de la valeur. Comme avec tous les flux maigres, tout le temps que nous passons est un gaspillage complet jusqu'à ce qu'il soit livré. Aucune valeur du tout. Juste du déchet. C'est seulement quand il est en production, sur le site web, en pleine fonction que cela crée (potentiellement) de la valeur. Mais c'est un autre post...