Précédemment, j'ai abordé la notion de "Exigences agiles"et ce concept est ancré dans la Test Nokia. Il n'existe pas de définition communément admise des exigences agiles, c'est pourquoi j'utilise désormais un concept standard qui correspond mieux à ce qui est nécessaire. Pour de nombreuses applications, en particulier les applications web, une histoire n'a besoin que de notes et de tests d'acceptation sur une carte ou une note autocollante. Pour certaines applications, comme les applications mobiles destinées aux médecins, à moins qu'un prototype entièrement formé ne soit acceptable pour un groupe de médecins testeurs soigneusement sélectionnés, les utilisateurs finaux refuseront d'utiliser l'application lorsqu'elle sera installée dans l'hôpital. C'est pourquoi il est nécessaire de se mettre d'accord sur une spécification d'habilitation complète, avec un prototype qui fonctionne parfaitement, avant de couper une ligne de code.Pourquoi vous ne pouvez pas innover comme Apple." PatientKeeper a utilisé cette stratégie entre 2003 et 2008 et c'est l'une des raisons pour lesquelles les équipes Scrum ont été les plus rapides que j'aie jamais vues dans l'entreprise. Je les ai appelées "L'avenir de Scrum"à Agile 2005. Certaines personnes ont dit que PatientKeeper ressemblait plus à Kanban que Scrum et qu'il s'agissait donc des équipes Kanban les plus rapides jamais vues. J'ai toujours fait fonctionner Kanban à l'intérieur de Scrum depuis 1993, car Scrum correspond à la vision de Takeuchi et Nonaka sur les équipes allégées. Cependant, nous avons essayé de minimiser les Kanban, tout comme Taiichi Ono l'a fait et comme Toyota le fait aujourd'hui.
En 2007, j'ai rendu visite aux conseils en brevets de PatientKeepers, car notre PDG souhaitait obtenir un brevet sur la découverte d'une stratégie de reporting pour l'analyse des paiements d'honoraires des médecins qui augmenterait les revenus des hôpitaux de 30% au cours du premier mois d'utilisation. J'ai demandé à la Product Owner d'apporter la documentation dont elle disposait pour que les avocats puissent l'examiner. Il y avait une spécification Agile de trois pages. Il s'agit d'un document que les Product Owners de PatientKeeper utilisent pour décrire le concept global d'une fonctionnalité. Les histoires d'utilisateurs sont développées à partir de ce document.
Notre objectif était de travailler avec les avocats pour comprendre la quantité de documentation nécessaire pour une demande de brevet. Les avocats ont souligné qu'une demande de brevet est une "spécification habilitante". Il s'agit d'un terme juridique décrivant un document qui permet à une personne moyenne connaissant le domaine de créer la fonctionnalité sans avoir à discuter avec les auteurs de la spécification habilitante.
Les avocats ont déterminé que notre spécification agile de trois pages n'était pas une spécification habilitante. Pour produire un document qui serait approuvé par l'office américain des brevets, nous aurions besoin de cinq pages.
Il s'avère qu'une spécification habilitante est exactement ce qu'il faut pour maximiser l'efficacité du processus d'exécution d'une histoire d'utilisateur. L'efficacité moyenne des processus des équipes qui exécutent des histoires d'utilisateurs est d'environ 20%. Cela signifie qu'une histoire qui nécessite une journée de travail idéale prend cinq jours calendaires pour être livrée. Systematic Software Engineering, une société CMMI de niveau de maturité 5, dispose de nombreuses données montrant que les équipes qui améliorent l'efficacité des processus de rédaction d'histoires à plus de 50% doubleront systématiquement leur vélocité pour chaque équipe. (PatientKeeper fonctionnait à une vitesse 10 fois supérieure à celle de notre partenaire indien en cascade).
La définition d'une "spécification habilitante" fait partie de la législation américaine sur les brevets, qui a fait l'objet d'une vaste jurisprudence. Il ne s'agit donc pas seulement d'un concept communément admis, mais vous pouvez porter vos exigences devant les tribunaux et le juge vous dira s'il s'agit ou non de spécifications habilitantes.
En général, les exigences ne sont PAS des spécifications habilitantes. Lors d'un récent projet dans une grande entreprise internationale, nous avons découvert que des centaines de pages d'exigences n'étaient pas des spécifications habilitantes. En moyenne, 60% du contenu des documents étaient inutiles pour les développeurs. Les estimations ont doublé de volume. Pire encore, 10% de ce dont les développeurs avaient besoin pour mettre en œuvre le logiciel ne figuraient pas dans les exigences.
Les spécifications utilisées chez PatientKeeper fournissent une description globale d'un ensemble de fonctionnalités encadrées par des histoires d'utilisateurs légères avec des captures d'écran, une logique d'entreprise et des structures de données. La spécification habilitante a été utilisée pour générer des histoires d'utilisateurs qui ont ensuite constitué le carnet de commandes du produit. La description globale des fonctionnalités a été régulièrement mise à jour par l'équipe Product Owner et constituait une référence à l'état du système qui permettait aux développeurs de voir d'où venaient les histoires d'utilisateurs dans le carnet de commandes du produit.
Une histoire d'utilisateur doit être une mini-spécification d'habilitation pour que les équipes agiles puissent fonctionner de manière optimale. Si ce n'est pas le cas, il sera nécessaire de poursuivre le dialogue avec le Product Owner au cours du sprint pour comprendre ce que l'histoire signifie. Cela réduira l'efficacité du processus d'élaboration de l'histoire et freinera la vélocité.
Une histoire d'utilisateur contient un modèle, des notes, des tests d'acceptation et implique une conversation avec le Product Owner. La conversation peut donc faire partie de la mini-spécification d'habilitation si la conversation est claire avant le début d'un sprint. Cela peut être sur une carte pour une application simple et sera de l'ordre de 3 à 5 pages maximum, même pour une application compliquée, critique et mettant en danger la vie des utilisateurs, comme la plateforme PatientKeeper.
Comme l'ont souligné les avocats, une spécification d'habilitation pour une fonctionnalité majeure ne doit pas dépasser cinq pages. Ainsi, toute la documentation nécessaire, y compris la transcription de toutes les conversations, devrait être de l'ordre de 3 à 5 pages pour une fonctionnalité modérément importante. C'est ce que j'entends par "spécification agile". Je pense maintenant que "spécifications habilitantes" est une meilleure terminologie.
2-231 Obtention des droits de brevet § 2.07[6]
"Un fascicule de brevet est habilitant s'il permet à une personne ayant des compétences ordinaires dans l'art de mettre en pratique l'invention sans expérimentation excessive.
Voir Jay Dratler. Droit de la propriété intellectuelle : Propriété commerciale, créative et industrielle, Volume 1 pour les citations.
French 
English 
Spanish