Bruno Orsier Exigences Exécutables Efficaces Doing the Right Software Agile4Techos Rémy Sanlaville

Contrat de la session Ce que vous verrez Ce que vous ne verrez pas La méthode (au-delà des outils) pour des exigences exécutables efficaces La mise en place d’exigences exécutables via 3 scènes concrètes de la vie d’un projet Une introduction aux exigences exécutables Une comparaison des outils Une solution magique à tous vos problèmes

Les slides sont là plus en tant que support. La session est construite sur un jeu théâtral 1. Nous jouons une scène pour illustrer un problème particulier dans la vie d’un projet 2. Résumé du problème et interaction avec le public pour valider le vécu du problème chez vous 3. Nous rejouons la scène avec des solutions concrètes basées sur la mise en place d’exigences exécutables. Note aux participants

Acte 1 : L'incompréhension Afin d'améliorer la satisfaction des utilisateurs et de livrer plus rapidement En tant que Client Je souhaite définir des exigences à forte valeur et qu'elles soient comprises par les autres acteurs du projet

Acte 1 : L'incompréhension Symptômes Ne pas arriver à finaliser la spec même après un an de rédaction… Sur-spécification Le client veut tout et ne priorise pas Je ne comprends pas le besoin Constat Etude Standish Group : 64% des fonctionnalités rarement ou jamais utilisées Le développement est fait en parallèle pour aller plus vite

Acte 1 : L'incompréhension Solutions Spécifier au fur et à mesure (par incrément) avec priorisation (on tire vers le haut ce qui est utile et vers le bas ce qui est incertain) Spécification piloté par la valeur client/utilisateur Améliorer la communication basée sur des exemples Collaboration vs contractualisation

Acte 2 : Dans l'arène du code Afin d'implanter les exigences du client et que mon code soit maintenable/évolutif En tant que développeur Je souhaite que mon développement soit piloté par les exigences et que mon code soit compréhensible par un autre développeur et que je ne crée pas de régression fonctionnelle

Acte 2 : Dans l'arène du code Symptômes A quoi sert ce bout de code ? Est-ce que mon code couvre bien mon exigence ? J'ai du mal à faire la différence entre TDD et BDD Constat Code mort, code dupliqué... Les exigences décrivent l'implémentation plutôt que le besoin Les exigences sont difficilement maintenables

Acte 2 : Dans l'arène du code Solutions Développement piloté par les exigences Utiliser les concepts métiers dans le code (DDD) Disposer d'un DSL métier vs concepts techniques

Acte 3 : L'effet tunnel Afin d'éviter l'effet tunnel (mauvaises surprises à la livraison) En tant qu'acteur du projet Je souhaite connaitre l'avancement tout au long du projet et que l'implantation soit conforme aux besoins et qu'il n'y a pas de régression fonctionnelle

Acte 3 : L'effet tunnel Symptômes Je n'ai pas ce que j'ai demandé Je ne sais pas où on en est (pas de visibilité) Nous sommes en retard Constat

Acte 3 : L'effet tunnel Solutions Augmenter la fréquence du feedback : démo à la fin de l’itération + ajuster/rectifier au plus tôt Visibilité de l'avancement : rapport de couverture des exigences + intégration continue

Questions ?

5 doigts : Excellente Super c'est exactement ce qu'il me fallait ! 4 doigts : Bonne Très intéressant, j’ai gagné plus que le temps que j’y ai passé. 3 doigts : Juste Moyenne Intéressant, sans plus. Je n’ai pas perdu mon temps. 2 doigts : Utile Bof ! J'ai perdu du temps. 1 doigt : Inutile Je n'ai rien appris. J’ai vraiment perdu mon temps ROTI (Return On Time Invested)