Beaucoup prétendent utiliser des méthodes agiles pour masquer le dépouillement de leurs projets. C'est plus facile : pas d'analyse, pas de tests business structurés, pas de documentation... et aucun planning, par la même occasion.

La méthode agile la plus en vogue depuis quelques années, Scrum, est fortement axée sur la description de quelques "techniques" de travail (ou ranger les fonctionnalités, comment organiser le suivi du projet, etc.) et sur 3 rôles pour les acteurs du projet : Team, Product Owner et Scrum Master. En dehors de ça... la liberté est presque totale (tant qu'on respecte la philosophie Agile, bien entendu).

Chacun son rôleDès lors, pourquoi se priver d'une analyse fonctionnelle digne de ce nom quand c'est nécessaire ?

Un article dans Agile Journal, écrit par Ellen Gottesdiener et Mary Gorman, fait avancer le débat en proposant quelques pistes intéressantes sur la place de l'analyste fonctionnel au sein d'un projet Scrum.

Et si vous êtes encore réticents et que pour vous, marier scrum et analyse fonctionnelle est une hérésie, dites-vous que (comme le dit fort justement le titre ce cet article) le plus important, c'est de ne pas se tromper sur l'objectif du projet.

It's the Goal, Not the Role: The Value of Business Analysis in Scrum