Archives par mot-clé : agile

The Agile Inception Deck

Traduction libre de votre serviteur de l’article The Agile Inception Deck par Jonathan Rasmusson

Un domaine dans lequel les méthodes agiles font l’impasse est le lancement de projet. Ci-dessous vous trouverez une méthode simplifiée que vous pouvez utiliser pour combler ce manque et faire pointer vos projets dans la bonne direction longtemps avant que la première ligne de code ne soit écrite.

10 questions à poser au début de votre prochain projet

Ça démarre plein d’espoir, le projet débute, vous et votre équipe êtes sur la même longueur d’onde. Ou c’est ce qu’il semblait. Alors vous commencez à construire et vous réalisez que vous aviez tous quelque chose de différent en tête. Ça vous est déjà arrivé ?

Combien de projets ont commencé comme ça : vous et votre équipe êtes persuadés au début du projet que vous pensez tous à la même chose ?

Et quand vous commencez à construire quelque chose, vous réalisez que vous pensiez à quelque chose de complètement différent.

Cela arrive constamment dans les projets : penser qu’il y a un consensus alors qu’il n’en existe aucun.

Bien que les bonnes équipes puissent surmonter ces divergences et s’adapter au fur et à mesure, c’est une forme de gâchis qui peut ralentir ou tuer les imprudents avant même d’avoir passer la porte.

Pour étouffer ce problème dans l’œuf, quand j’étais à ThoughtWorks nous avons créé un outils léger de lancement de projet appelé « The Agile Inception Deck : 10 questions et exercices que vous seriez fous de ne pas poser et entreprendre avant de commencer votre projet. »

Ces questions ont deux objectifs : alignement et réglages des attentes.

L’alignement c’est être sûr que vous et tous les autres sont sur la même longueur d’onde du pourquoi on est là, qu’est ce qu’on essaye de faire et comment on va y arriver. La base.

D’un autre coté, le réglage des attentes c’est communiquer clairement avec votre équipe et les parties concernées de ce qu’il va falloir pour faire de ce projet un succès. Vous définissez les règles d’engagement.

Oui on peut construire ça pour vous. Non ça ne devrait pas être trop compliqué. Voilà ce que ça va nécessiter …

Vous devez avoir cette conversation tôt et faire en sorte que vos clients sachent ce dont vous avez besoin pour les servir le mieux possible. Ne présumez de rien, soyez explicite et posez des questions.

Comment être sur de ce que veulent vos clients ? Un bon moyen de commencer et de leur demander :

1. Pourquoi est-on là ?

Vous ne pourrez pas construire un super produit si au départ vous ne savez pas pourquoi vous le construisez. Demandez « pourquoi » donnera à vous-même et votre équipe le contexte nécessaire pour prendre toutes les décisions pertinentes pendant l’exécution.

Par exemple, disons que vous avez été embauché par une entreprise de construction pour créer un système de gestion de fermeture de routes, en fonction des dates, sur un chantier de construction.

Une question évidente qui vous aidera vous et l’équipe à construire une solution est « Pourquoi ? ». Pourquoi, en premier lieu, la société va dépenser du capital sur ce projet ?

Est ce pour la sécurité ? Une exigence réglementaire ? Pour réguler efficacement les mouvements de matériels sur le site de construction ?

Connaître et comprendre l’exigence première derrière votre projet vous aidera à trouver le bon équilibre dans les décisions de compromis qui se présenteront inévitablement pendant le développement.
Vous ne pourrez pas le faire sans savoir « pourquoi ? ».

2. Créer le pitch de l’ascenseur

Les projets peuvent représenter beaucoup de choses pour plein de gens. Cet exercice est fait pour s’assurer du contraire.

Un bon pitch d’ascenseur explique aux gens ce que votre produit est, pour qui il est et pourquoi, dans le temps nécessaire à une balade en ascenseur.

En faire un bon peut être plus difficile que vous ne le pensez. Mais une fois que vous l’aurez, vous vous sentirez mieux. Vous pourrez rapidement faire passer un concept bien abstrait (c’est comme ça que tous les projets débutent) en quelque chose de concis, réel et concret.

3. Dessiner la version boite

Bien réfléchir à votre produit du point de vue de votre client est toujours cool. Non seulement construire la version boite de votre produit vous place dans la tête de votre client mais c’est aussi un bon exercice de cohésion d’équipe et ça vous donne la permission de dessiner et colorier à votre boulot !

Vous n’avez pas besoin de produire quelque chose de complexe ou de très élaboré, demandez vous simplement :

  1. Quelles sont les trois raisons les plus importantes qui font que les gens vont acheter ce produit ?
  2. S’il y a un slogan qui va capturer l’esprit du produit, ce serait lequel ?

4. Créer la liste NON

Dire oui c’est facile, c’est dire non qui est difficile. La liste des «NONs» commence à dessiner des limites, à cadrer et à définir ce que l’on ne va pas faire dans le projet.

Dire ce que vous n’allez pas faire est efficace. Cela va éliminer beaucoup de temps perdu en focalisant l’équipe sur ce qui est IN et en ignorant tout ce qui est OUT. C’est de la colonne IN que les scénarios utilisateurs de haut niveau vont découler.

Il n’est pas rare non plus que beaucoup de chose qui pourrait être dans le cadre de la colonne IN n’y soit pas (souvent à cause du temps et du budget). Il vaut mieux résoudre ces questions maintenant que de les laisser pour plus tard.

C’est vraiment de l’estimation des « essentiels ». Ce que vous représentez là c’est « si on implémente ces parties dans le projet, ce sera bon ».

5. Rencontrer vos voisins

Une fois, j’ai presque failli perdre un projet car je n’avais pas apprécier que la communauté d’un projet est toujours plus large qu’on ne le pense. Il est facile d’imaginer que tout tourne autour de vous et du noyau de l’équipe mais la réalité est que la plupart des projets nécessite plus que l’équipe de base pour être un succès (surtout dans les grandes entreprises).

Cet exercice consiste à vous projeter, vous et l’équipe, bien en avant dans le temps et pour rencontrer et établir des relations bien avant que le projet en ait besoin réellement. Non seulement c’est de la courtoisie mais cela leur laisse le temps de se préparer à votre arrivée et d’être là quand vous aurez besoin d’eux.

6. Montrer la solution

Vous choisissez votre architecture quand vous choisissez votre équipe donc il vaut mieux être sur que tout le monde est à la page avec votre solution avant de commencer.

Cet exercice consiste à faire passer les grandes lignes. Si vous comptez utiliser certains outils ou certaines architectures pour faire ce projet, il vaut mieux le faire savoir maintenant. C’est très énervant de se rendre compte plus tard qu’on est plus dans les limites d’un standard de l’entreprise par exemple.

C’est aussi une opportunité pour mettre les choses au clair si vous n’avez pas toutes les réponses (et c’est OK aussi !). Faites le leur savoir.

7. Demander ce qui pourrait nous empêcher de dormir

Il y a des milliers de choses qui peuvent mal tourner sur nos projets. Certaines sont gérables, d’autres non. Cet exercice aide à identifier les risques qui méritent qu’on s’en préoccupe et ceux dont on n’a pas besoin de se soucier.

Par exemple, on ne peut pas faire grand chose pour prévenir un crac de l’économie ou que votre contact client soit promu vice directeur informatique. Donc pas la peine de s’en soucier.

Avoir une équipe avec des membres permanents à temps plein, ça par contre vous pouvez travailler dessus et ça vaut le coup de se battre pour.

C’est votre chance de limiter l’emballement avant le début du projet et de vous battre pour ce qui va être nécessaire pour transformer ce projet en succès. Vous n’obtiendrez peut être pas tout mais ça fait jamais de mal de le demander.

8. Évaluer la taille

Cet exercice doit répondre à la question de la taille. On ne pourra pas dire exactement combien de jours cela va prendre pour mener à bien ce projet mais on peut dire si c’est un projet de 3, 6 ou 9 mois.

Cet exercice consiste à estimer et planifier des scénarios clients de haut niveau. La liste des «NONs» vous aidera bien ici. Vous devrez arriver à quelques grosses estimations pour que votre donneur d’ordres se fasse une idée de la taille du projet et ce que ça représente.

Le but de l’exercice n’est pas la précision des estimations mais de déterminer si ce projet est tout simplement faisable avec les ressources qu’on vous donne.

9. Soyez clair sur ce qui va compter

Tous les projets ont des leviers comme la durée, le budget, le cadre ou la qualité. Il vaut mieux savoir lequel est le plus important et sur lesquels ont peut jouer.

Pour certains projets, tout ce qui compte c’est le budget, pour d’autres, c’est la date de livraison.

Il faut mener cette conversation pour savoir quand la pression va monter si vous serez flexible sur la couverture fonctionnelle (de préférences) ou si vous avez une marge de manœuvre sur la date.

L’autre sujet à discuter est : qu’est ce qui fait que ce projet sera LE projet ? La facilité d’utilisation, la simplicité, la rapidité, la flexibilité, la sécurité, etc. ? Mettez ça sur papier pour être certain que tout le monde le garde à l’esprit avant de commencer. Ces aspirations de haut niveau peuvent vous servir de lanterne quand le ciel s’assombrit.

10. Montrer ce que ça va prendre

Cet exercice est à propos des deux questions qui occupent l’esprit de tous les clients : combien de temps ça va prendre et combien ça va couter ?

Si le projet est en pré-vente, votre budget est peut être déjà fixé. Dans ce cas, le calcul va être simple pour voir si le projet est faisable avec les ressources qui vous ont été attribuées.

C’est encore une opportunité pour expliquer quel type d’équipe vous devez monter pour sortir ce projet. Vous pouvez appuyer vos attentes sur la taille de l’équipe et l’éventail des compétences nécessaires à la réalisation.

Mettre tout le monde dans le même bus

Travailler sur un Agile Inception Deck pour votre projet n’est pas magique. C’est simplement une façon de mettre les bonnes personnes dans une pièce, leur poser les vraies questions et partager les résultats avec vos clients et toute l’équipe.

Ça peut prendre un jour ou deux, jusqu’à deux semaines pour le compléter et ça assure normalement trois à six mois de planning. C’est un outil inestimable pour poser les attentes du projet et rappeler aux gens en quoi consiste votre équipe et ce projet.

Donc avant de commencer votre prochain projet agile, soyez sûr d’avoir poser les vraies questions et que tout le monde est sur la même ligne. Vous ressemblerez à un pro et vous aurez préparé votre succès longtemps avant qu’une ligne de code ne soit écrite.

[Voir le post original pour un lien vers une présentation de support vide et le lien vers le livre sur Amazon]

Le traducteur remercie Mizu no kokoro pour sa lecture attentive et ses suggestions.