Book Review: The Agile Extension to the BABoK 1.0

IIBA et Agile Alliance ont co-publié l’Extension Agile au BABoK en Juillet 2013 après avoir publié publiquement une version préliminaire pour commenter. Une pratique très efficace pour obtenir du feed-back d’un lectorat plus large. Cette approche est aussi envisagée pour le BABoK version 3.0

The Agile Extension to the BABoK - CoverStructure et contenu

Après une introduction dans l’agilité en développant le manifeste agile, le livre développe brièvement les principes de quelques approches agiles: Scrum, XP et Kanban

Une nouvelle structure

Par rapport au BABoK qui inventorie les techniques dans des domaines de compétence sans fil conducteur temporel mais uniquement selon les domaines de compétence, l’extension agile distingue bien deux phases dans le travail au sein d’un projet: le cadre de la découverte et le cadre de la livraison.

Naturellement, comme nous sommes dans une réflexion agile, ce concept s’applique du plus large au plus fin d’une manière itérative. Souvent ces deux cadres se superposent: pendant la réalisation d’une itération, le business analyst découvre ce qui est le plus pertinent à faire dans l’itération suivante.

Les 7 lignes directrices

C’est probablement le chapitre le plus important. Les 7 lignes directrices concrétisent les valeurs du manifeste agile en principes de business analyse. C’est l’équivalent des Principes sous-jacents au manifeste qui s’adressent plutôt aux développeurs.

  • La vraie valeur de la business analyse se manifeste dans le soutien de l’organisation pour maximiser la valeur livrée et de produire des solutions d’une grande valeur
  • L’analyse se porte particulièrement sur la compréhension des valeurs et attentes des clients
  • Pour confirmer ce qui apporte de la valeur, on fait des exemples concrets pour  soulever et  valider les besoins
  • Une bonne analyse des besoins permet à l’IT de mieux déterminer leur capacité de livrer, de saisir des options dans les exigences et de donner des recommandations sur les solutions aux parties prenantes
  • La facilitation permet une collaboration efficace et permet à l’équipe d’accélérer pour concevoir et livrer les produits
  • La confiance est fondamentale dans le travail en équipe pour qu’elle puisse identifier les opportunités d’amélioration. L’amélioration continue du produit et du processus sont impératifs – les équipes agiles tentent toujours de s’améliorer
  • Evitez les déchets (Lean: les déchets dans le développement logiciel)

En renforcement du principe lean « évitez les déchets », le livre souligne à de nombreuses reprises de produire des documents « low fidelity ». Produire des documents qui véhiculent l’information d’une manière simple, qui permettent d’ouvrir la discussion et où l’on ne se perd pas dans les détails. Ces documents peuvent être des dessins à main levée, des photos d’un travail sur un tableau blanc ou un document photocopié et annoté. Le côté éphémère des documents du projet – ils n’ont pas de valeur au delà du projet – ne justifient pas d’investissement, c’est une dépense nécessaire pour pouvoir réaliser la solution.

Le Business Analyst dans les différentes approches agiles

Le livre présente 3 approches agiles

  • Scrum
  • XP – Extreme Programming
  • Kanban

et mentionne d’autres approches un peu moins populaires: Crystal Clear, DSDM, AUP, FDD, et Adaptive Software Developement.

Le choix de Scrum et Kanban est pertinent: Scrum avec 80% du « marché » agile et Kanban comme approche sans itération.

DSDM et DAD aurait être plus intéressants à développer, puisque le rôle du business analyst en fait partie explicitement.

Le cycle de planification dans l’agilité

Les auteurs dédient un chapitre entier à la planification pour sensibiliser le business analyst à l’approche itérative et avec de plus en plus de détails. La planification se fait donc aux niveaux suivants

  • stratégie
  • release
  • itération
  • quotidien
  • planificaiton continuelle

Bien que les frameworks du chapitre précédent ne contiennent pas de processus ou phases au delà du cycle de développement, une réflexion stratégique et l’intégration de grandes releases sont essentielles dans les grandes organisations.

Mappage des techniques agiles au BABoK

Afin de souligner le coté « extension » du présent livre, il fallait bien référencer le BABoK. Toutes les techniques agiles sont associées aux différents chapitres du BABoK.

Ainsi par exemple, le chapitre BABOK 4.1 « Manage Solution Scope and Requirements » est complété par les techniques Story Decomposition et Story Mapping de l’extension Agile.

C’est un exercice intéressant, mais dans le concret cela ne représente pas une grande valeur puisque le chapitre détaillant toutes les activités décrit déjà bien le cadre d’utilisation des techniques

Les 21 techniques agiles

Les techniques agiles de la business analyse sont classées selon 2 grands domaines:

  • Le cadre le la découverte
  • Le cadre de la livraison

Le cadre de la découverte traite du « Quoi » et du « Pourquoi » du produit. Dans ce cadre, les principes suivants s’appliquent

  • gardez la vue de l’ensemble
  • pensez « Client »
  • analysez pour déterminer ce qui a de la valeur

Le cadre de la livraison traite du « Comment » et « Quoi » du produit. Les 4 principes qui supportent une livraison efficace sont

  • soyez concret en utilisant des exemples
  • comprenez ce qui est réaliste à réaliser
  • stimulez la collaboration et l’amélioration continue
  • évitez les déchets

La liste des 21 techniques

  • Business Capability AnalysisPersonas
  • Personas
  • Value Stream Mapping
  • Story Decomposition
  • Story Elaboration
  • Story Mapping
  • User Story
  • Storyboarding
  • Backlog Managment
  • Business Value Definition
  • Kano Analysis
  • MoSCoW Prioritisation
  • Purpose Alignment Model
  • Get Real Using Examples
  • Behaviour Driven Development (BDD)
  • Relative Estimaiton
  • Planning Workshop
  • Real Options
  • Collaborative Games
  • Avoid Waste
  • Lightweight Documentation

Malheureusement dans cette extension, il n’y a pas de séquence logique utilisable dans le travail. On ne décompose les stories certainement pas avant de les avoir créées. Une priorisation avant l’estimation ne fait pas beaucoup de sens etc.

Bien qu’un des principes stipule « soyez concret », IIBA s’obstine toujours à ne surtout pas organiser les techniques dans une séquence « normalement » observée dans la pratique. Pour un business analyst novice, l’approche est inutilement compliquée, c’est pourquoi notre workshop Business Analyst Agile restructure les techniques autour d’un processus projet, tels que AUP, DAD, DSDM etc. nous le proposent.

Conclusion

The Agile Extension to the BABoK 1.0 est un excellent résumé de quelques techniques agiles mises dans le contexte des approches agiles les plus populaires.

La plus grande valeur vient des 7 principes de la business analyse agile qui nous guident dans la démarche quel que soit le processus.

Pour les BA qui n’ont pas encore eu l’occasion de travailler dans un projet agile, nous recommandons de participer au workshop Business Analyst Agile. Pour ceux qui veulent s’investir directement dans un projet Scrum, nous recommandons le cours Scrum Product Owner qui donne une introduction dans le framework Scrum sous l’angle du Product Owner et présente des techniques pour Product Owner et Business Analyst.

Les commentaires sont désactivés.