Avant de commencer je vais faire un petit focus sur le CARA (Club Agile Rhône Alpes). Le CARA était jusqu’à l’année dernière une association englobant plusieurs antennes : Grenoble, Lyon et Valence. Depuis cette année chaque antenne est devenue une association à part entière. Le but de chacune de ces associations est toujours de promouvoir l’agilité et ses différentes pratiques à un maximum de personnes. Que vous soyez débutant ou confirmé vous pouvez assister chaque mois à un rassemblement sur Lyon autour d’un thème particulier. Vous pouvez vous faire une idée en consultant les différentes activités rescencées sur leur site web.
Thierry Cros est un coach agile aidant différentes entreprises à s’organiser pour faciliter leur développement logiciel. Il est également l’auteur d’un livre “Spécifiez Agile” dans lequel il indique plusieurs pistes pour améliorer le processus de l’expression des besoins. Thierry est venu au CARA pour donner quelques clés de ce processus
Je n’ai pas lu son livre mais vous pouvez trouver une critique d’Alexis Monville sur le site ayeba.
La spécification d’un besoin informatique est toujours un exercice délicat car elle est le résultat de la rencontre entre deux groupes de personnes de culture différentes : d’un côté des informaticien et de l’autre les utilisateurs ou leurs représentants. C’est un peu comme un voyage où l’on part à la rencontre de personnes qui ne parlent pas le même langage que nous.
La première étape pour arriver à construire quelque chose en commun est de se comprendre et pour cela il faut s’entendre sur un vocabulaire commun. Pour que tous les acteurs sachent de quoi on parle, cette première étape est essentielle. Il est important de formaliser ce glossaire car il aidera à intégrer de nouvelles personnes au projet. Combien de fois, êtes vous arrivé dans une société, sur un projet où les gens autour de vous employait un vocabulaire que vous ne compreniez pas ?
Il existe de nombreuses méthodes agiles qui présentent toutes des intérêts et des inconvénients XP, Scrum, Lean Kankan... C’est en fonction du contexte de l’entreprise et des personnes impliquées sur le projet que vous allez pouvoir appliquer tel ou tel principe. Il n’existe pas de recette pré établie.
Revenons à la spécification du besoin. Il n’y a pas très longtemps j’ai entendu deux chefs de service de ma société discuter sur les spécifications : “ aujourd’hui on est agile on n’a plus de spécfications… on peut aller plus vite...”. En tant qu’agiliste je n’ai pas pu m’empêcher d’intervenir pour leur faire une piqûre de rappel. Ce n’est pas parce que vous faites de l’agilité que vous ne devez pas spécifier le besoin.
Certes exprimer un besoin utilisateur sous forme de diagramme UML est peut être un délire d’informaticien mais il est important d’avoir une spécification écrite. Même si vous avez des post its au tableau ces posts its ne contiennent qu’une partie de l’histoire…
Comme le dit Thierry, les users stories sont apparues avec XP et au lieu de formaliser un besoin sous forme d’UML on a demandé aux utilisateurs de raconter des histoires courtes de comment ils travaillaient, des actions qu’ils voulaient effectuer dans le futur logiciel. Ces différentes histoires sont écrites et mises à plat sur une table. Elles sont ensuite réorganisées pour constituer un backlog du produit.
C’est à partir d’une vision produit que nous allons déterminé un ensemble de fonctionnalités puis décrire les users stories.
Vision >>> Features >>> User Stories
Si le besoin final est flou les fonctionnalités et la vision peuvent découler des stories. On peut demander aux utilisateurs de nous raconter différentes histoires et c’est à partir de ces histoires que nous allons déterminer les fonctionnalités puis la vision du produit. Cette démarche colle particulièrement bien avec le Lean Startup
User Stories >>> Fetaures >>> Vision
Un projet au niveau de la valeur métier peut être vu comme un budget financier mais aussi temporel. La question est de savoir ce que l’on va pouvoir faire dans la période. L’agilité permet de construire un logiciel via une démarche empirique au cours des différentes itérations.
La spécification agile revient à un cycle dans lequel on demande aux utilisateurs de raconter des histoires. En tant qu'informaticien on discute de ces histoires avec eux pour les affiner et les ranscrire dans un langage commun. Puis on les planifie et les développe. A la fin du cycle on capitalise sur le feedbacks et on recommence...
Merci pour cet article. Effectivement il faut en finir avec la dictature de la démarche analytique et rappeler qu'il existe aussi la démarche ascendante à partir des stories.
RépondreSupprimer