Spécification agile : est-ce un canular ? ou une nécessité ?

Quand Alistair Cockburn dit quelque chose comme.. :

Il n'existe pas de "spécifications agiles". Cette expression est un canular".

C'est exactement le genre de discussion que nous avons eue lors de la réunion du Manifeste Agile en 2001. Cela signifie qu'il y a quelque chose de vraiment intéressant à discuter. Premièrement, lire pourquoi Alistair dit qu'il utilise toujours les cas d'utilisation.

Chez PatientKeeper, nous avons des "spécifications agiles" qui sont similaires aux cas d'utilisation d'Alistair pour les nouvelles fonctionnalités. Nous exigeons qu'elles spécifient clairement l'expérience de l'utilisateur avec des captures d'écran détaillées, le flux de travail, la logique d'entreprise et les descriptions de données. Nous voulons juste assez de spécifications et un dialogue avec les développeurs pour déterminer la quantité à documenter. Pour les choses simples, une histoire d'utilisateur peut suffire.

Problème : Vous allez mettre en œuvre plus d'un millier d'histoires d'utilisateurs sur plusieurs années et à des moments aléatoires. Une très grande précision est requise pour les captures d'écran, le flux et la logique d'entreprise, car une erreur pourrait tuer un patient. Ou bien un médecin pourrait qualifier le produit de "merde" et refuser de l'utiliser.

Forces : Les médecins ont besoin d'une adaptation exacte à leur flux de travail, à leurs déductions de données cliniques, en un minimum de temps, alors qu'ils se trouvent devant un patient malade et utilisent leur iPhone pour toutes les données cliniques. Developers n'a aucune idée de l'aspect que cela devrait avoir pour un médecin. Le Product Owner non plus, même s'il s'agit d'un médecin. Un groupe soigneusement sélectionné de médecins leaders d'opinion doit utiliser des prototypes fonctionnels pour déterminer exactement l'aspect et la sensation du produit pour le médecin, tout en parvenant à un consensus, et les développeurs doivent créer très exactement l'approche qu'ils ont choisie, faute de quoi les médecins risquent de refuser d'utiliser le produit. Les médecins n'utiliseront pas de souris. La plupart des choses doivent nécessiter un clic et tout ce qui nécessite plus de trois clics ne sera jamais utilisé car cela interfère avec la conversation avec le patient. Toute corruption de données met la vie du patient en danger. Le manque de facilité d'utilisation met la vie en danger.

Par exemple, une petite partie des données cliniques sont des résultats de laboratoire. Il existe des dizaines de tests de laboratoire, chacun produisant un ensemble de données complexes avec des valeurs multiples et des plages normales. Il existe une interaction entre ces résultats. Des alertes automatiques pour des conditions critiques basées sur une relation complexe entre de multiples résultats de laboratoire sont nécessaires. Ces alertes sont régulièrement mises à jour par des comités cliniques qui déterminent les meilleures pratiques. Tous les tests de laboratoire sont représentés différemment selon les spécifications exactes enseignées dans les écoles de médecine. De nouveaux tests de laboratoire sont souvent nécessaires. Ils sont basés sur des données de recherche développées dans les laboratoires. Le développeur doit être en mesure d'examiner rapidement toutes les implémentations précédentes de tous les résultats de laboratoire afin d'intégrer correctement ce nouveau résultat dans le flux de travail du médecin. La mise en œuvre physique du produit actuel ne suffit pas à cette fin.

La solution : Le Product Owner crée un document juste suffisant et juste à temps appelé Lab Tests. Ce document s'enrichit au fil du temps, au fur et à mesure que les tests de laboratoire se multiplient et que les données de recherche influencent les résultats des tests de laboratoire. Le Product Owner effectue une analyse de haut niveau des captures d'écran, du flux de travail, des structures de données, de la logique commerciale et la présente comme un cas d'utilisation très léger pour soutenir les récits d'utilisateurs mis en œuvre à un moment donné. Le Product Owner a testé un prototype entièrement fonctionnel de cette implémentation sur un groupe de médecins leaders d'opinion avant qu'une histoire ne soit prête à être intégrée dans un Sprint. La Developers refuse de développer toute histoire qui n'atteint pas cet état "prêt". En fait, on leur demande de prendre un jour de congé si le Backlog du Sprint n'est pas "prêt".

Résultat : En huit ans et des milliers d'histoires, la spécification globale a atteint près de trente pages. Un développeur peut saisir dans son esprit, en moins de cinq minutes, tout l'historique de la mise en œuvre de tous les résultats de laboratoire qui sont essentiels à la mise en œuvre d'un nouveau test sanguin pour le traitement des patients diabétiques.

Les Product Owners sont extrêmement disciplinés dans cet environnement. Ils savent que les développeurs prendront un jour de congé si leur "spécification agile" n'est pas prête pour la création d'histoires d'utilisateurs au cours d'un sprint.

L'équipe est également très disciplinée et atteint une vitesse 10 fois supérieure à celle de ses concurrents, ce qui a permis de quadrupler les recettes en 2007.

Nom de cette chose : Up for grabs.
Nécessité de cette chose : Absolument essentielle ou vous risquez de tuer des patients Ou pire encore, les médecins refuseront de l'utiliser en déclarant qu'il s'agit d'un "tas de merde" ou qu'il contient trop d'alertes ou qu'il ne signale pas un état critique sur ce test de laboratoire dans le contexte de certaines données sur de multiples autres tests de laboratoire. Ou bien il ne remplit pas automatiquement les bonnes notes cliniques, ou bien le développeur est tellement ignorant du traitement des patients qu'il devrait être abattu, ou encore .....

La meilleure formation pour les développeurs : Envoyez-les au bloc opératoire où le patient est ouvert sur la table et où le chirurgien commence à crier après lui et le personnel chirurgical en faisant des gestes menaçants pour les frapper avec des instruments chirurgicaux parce qu'ils ont fourni des données erronées, ce qui l'a amené à décider d'annuler l'opération et de la recommencer à une autre date lorsqu'ils lui ont fourni les bonnes données et les bons instruments au bon moment, alors que les résultats de laboratoire du patient sont exactement dans la bonne constellation pour que l'opération puisse avoir lieu.

Jeff Sutherland