XP, l’essentiel : Carte, Conversation, Confirmation

((/dotclear/public/photos/ron_jeffries.gif|Ron Jeffries|L|Ron Jeffries))Un récent billet de Jean Claude Grosjean sur son blog QualityStreet, ++[« Des User Stories … de qualité »|http://www.qualitystreet.fr/2008/08/25/des-user-stories-de-qualite/|fr]++, m’a fait rebondir sur les __3Cs__ et donc sur le très intéressant article de Ron Jeffries ++[« Essential XP: Card, Conversation, Confirmation »|http://xprogramming.com/xpmag/expCardConversationConfirmation|en]++ du 30 août 2001.%%% %%% Ça m’a intéressé de le traduire pour deux raisons :%%% – je me suis rappelé la remarque de mon collègue Jean-François M. qui s’étonnait du caractère très (très) light des spécifications sous forme de post-its…%%% – je souhaitais constater par moi-même le caractère ++précurseur++ de XP,  »tel le prophète annonçant l’arrivée de Scrum »… mais je m’égare, et si je continue je m’expose à des critiques au vitriol de la part de certains membres de la communauté: ça tombe bien, il y en a un qui s’appelle  »Jean-Baptiste » :-)%%% >  »Le Cycle de Vie XP permet de garder en vie des projets. Un élément clé de ce cycle est le Test d’Acceptation. Les Tests d’Acceptation sont essentiels pour maintenir la communication entre les membres de l’équipe, en particulier entre le client et le développeur. »%%% > %%% > Dans le livre  »Extreme Programming Installed », nous décrivons les quatre éléments du Cycle de Vie XP : le client sur site, travaillant avec les développeurs, utilise le planning game pour sélectionner des user stories afin d’élaborer des versions de petites tailles présentant le maximum de valeur ajoutée. Les user stories constituent le point critique de ce cycle.%%% > %%% > Les user stories présentent trois caractéristiques essentielles, que nous pouvons appeler Carte, Conversation et Confirmation.%%% > %%% > __Carte__%%% > %%% > Les user stories sont écrites sur des cartes. La carte ne contient pas toutes les informations qui constituent l’exigence. Par contre, la carte a tout juste assez de texte pour identifier le besoin, et pour rappeler à tous ce que la story raconte. La carte est un signe représentatif de cette exigence. Elle est utilisée dans la planification. Des notes sont écrites sur la carte pour retranscrire la priorité et le coût. La carte est souvent remise aux développeurs une fois la mise en œuvre de la story planifiée, et redonnée au client une fois qu’elle est terminée.%%% > %%% > __Conversation__%%% > %%% > L’exigence elle-même est communiquée du client vers les développeurs à travers une conversation : un  »échange » de pensées, d’opinions et de sentiments. Cette conversation a lieu au fil du temps, essentiellement lorsque la story est estimée (généralement pendant la planification de la version), et de nouveau lors de la réunion de planification de l’itération lorsque la story est planifiée pour être implémentée. La conversation est essentiellement orale, mais est souvent complétée par des documents. Vous verrez souvent des feuilles de calcul, des dessins d’écran et même des documents ressemblant aux classiques spécifications. Encouragez la discussion quand cela fonctionne, mais notez tous les détails sur format papier ou numérique.%%% > %%% > __Confirmation__%%% > %%% > Peu importe combien de discussions nous avons ou combien de documents nous produisons, nous ne pouvons jamais être suffisamment sûr de ce qui doit être fait. Le troisième C des caractéristiques essentielles de la user story apporte la confirmation dont nous avons cruellement besoin. Il s’agit du test d’acceptation.%%% > %%% > Au début de l’itération, le client communique aux développeurs ce qu’il souhaite, en leur racontant comment il va confirmer qu’ils ont fait ce qui est nécessaire. Il définit les tests d’acceptation qui seront utilisés pour montrer que la story a été mise en œuvre correctement.%%% > %%% > Les développeurs implémentent la user story, et mettent également en œuvre les tests d’acceptation. Certaines équipes construisent des outils qui permettent au client de saisir leurs tests par eux-mêmes, et d’autres équipes ont des personnes de la recette ou des testeurs qui les aident dans ce travail. Mais d’une manière ou d’une autre, les tests d’acceptation sont faits.%%% > %%% > À la fin de l’itération, les développeurs démontrent au client que la story est bien terminée, confirmant le succès en montrant que les tests d’acceptation s’exécutent correctement.%%% > %%% > La confirmation fournie par le test d’acceptation est ce qui rend possible l’approche simple de la carte et la conversation. Lorsque la conversation sur une carte descend jusqu’au niveau du test d’acceptation, le client et le développeur règlent ensemble les derniers détails de ce qui doit être fait. Lorsque l’itération est terminée et que les développeurs démontrent la bonne exécution des tests d’acceptation, le client constate que l’équipe peut, et va, livrer ce qu’il faut. La confirmation, en termes de tests d’acceptation, c’est ce qui permet au Cycle de Vie de fonctionner. Et le Cycle de Vie … c’est ce qui maintient votre projet en vie.%%%

Une réflexion au sujet de « XP, l’essentiel : Carte, Conversation, Confirmation »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *