Specify, Refine, Plan, Build, Verify, Learn : six étapes pour savoir où en est un projet

Demandez à cinq personnes d’une même équipe où en est une fonctionnalité. Le product owner répond “la spec est validée”. Le développeur répond “il me reste deux tickets”. La QA répond “je n’ai rien reçu à tester”. Le dirigeant répond “c’est prévu pour la prochaine version”. Tout le monde dit vrai, et personne ne parle de la même chose.

Le problème ne vient pas d’un manque d’information. Il vient d’un manque de vocabulaire commun pour situer le travail dans le temps.

Les outils rangent par objet, les équipes pensent par moment

Ouvrez n’importe quel outil de gestion de projet. Le menu liste des types d’objets : tickets, tableaux, versions, documents, tests. C’est un rangement de base de données. Il répond à la question “où est telle chose ?”, jamais à la question “que faut-il faire maintenant ?”.

Une équipe, elle, raisonne par moment. On est en train de cadrer. On est en train de produire. On est en train de vérifier. Ce décalage oblige chacun à reconstruire mentalement l’état du projet à partir de listes qui ne le montrent pas.

Six verbes, toujours dans le même ordre

Sinra organise sa navigation autour de six étapes :

• Specify : décrire ce que le produit doit permettre. On y rédige les capabilities et leurs specs.
• Refine : vérifier que c’est assez clair pour s’engager. L’équipe relit, lève les zones floues, estime.
• Plan : décider ce qui est livré et quand. On remplit les releases et les cycles selon la capacité réelle de l’équipe.
• Build : réaliser. Chacun voit ses issues, le cycle en cours, la release en cours.
• Verify : s’assurer que c’est prêt. Les tests sont exécutés, la revue de phase tranche.
• Learn : tirer les leçons. La rétrospective et le post-mortem nourrissent la spécification suivante.

Ces six mots sont dans la barre latérale, dans cet ordre. Il n’y a rien d’autre à apprendre.

Le V-Model, sans le dire

Lisez la liste de haut en bas : les trois premières étapes précisent, la quatrième produit, les deux dernières contrôlent ce qui a été précisé. C’est la forme d’un V. Rien n’est construit sans spec, rien n’est livré sans vérification.

Mais ce V ne se parcourt pas une fois par projet, sur dix-huit mois. Il se parcourt à chaque release, parfois à chaque cycle. La rigueur vient de l’ordre des étapes. Le rythme vient de leur répétition.

C’est ce que les équipes qui “combinent V-Model et Agile” font déjà sans le formuler. Les six étapes leur donnent un nom.

Ce que ça change au quotidien

Les conversations se raccourcissent. “La capability paiement est en Refine” dit en cinq mots ce qui demandait une réunion : la spec existe, elle n’est pas encore estimée, elle n’est dans aucune release.

Les trous deviennent visibles. Une équipe qui n’ouvre jamais Verify ou Learn le voit dans sa propre navigation. Aucun rapport ne le dit aussi clairement.

Les nouveaux arrivants s’orientent seuls. Un développeur ouvre Build. Une personne de la QA ouvre Verify. Personne n’a besoin d’une formation pour savoir où commence son travail.

Ce que ce n’est pas

Ce n’est pas un processus imposé. Aucune étape n’est bloquante, et une équipe de trois personnes peut passer de Specify à Build sans cérémonie.

Ce n’est pas une méthode à certifier. Il n’y a pas de rôle à nommer, pas de rituel obligatoire, pas de coach à recruter.

Ce n’est pas une cascade. Plusieurs capabilities sont à des étapes différentes au même moment. Les six étapes décrivent le parcours d’une fonctionnalité, pas le calendrier de l’équipe.

Un ordre plutôt qu’une méthode

Les méthodes échouent souvent parce qu’elles demandent à l’équipe de changer avant de produire. Un ordre demande moins : il suffit de savoir ce qui vient avant et ce qui vient après.

Specify, Refine, Plan, Build, Verify, Learn. Six mots pour que cinq personnes donnent enfin la même réponse.

Le détail de chaque étape est dans la documentation du Workflow.