Utilisation de ScrumPré requis
 Vision du projet et product backlogAvant toute chose, il est primordial de partager avec le client la vision du projet (objectifs, jalons, attentes des utilisateurs finaux, bénéfices attendus,...). Vous devez ensuite établir la liste des principales fonctionnalités attendues par le client. Sans essayer d'être forcément exhaustif et sans rentrer dans le détail de chaque fonctionnalité. Si un cahier des charges existe déjà, il peut vous servir de base mais rien ne vaut une bonne réunion interactive (surtout si vous travaillez pour la première fois avec ce client. Après tout il faut bien faire connaissance).
Une fois que cette liste est constituée, il faut la prioriser en fonction de la valeur métier (ou importance métier du point de vue client) et du coût de chaque élément. L'approche la plus simple consiste à pondérer chaque fonctionnalité avec un niveau d'importance. "haute", "moyenne" ou "faible" par exemple ou encore avec des points selon la suite de Fibonacci. Par la suite, les fonctionnalités les plus importantes pour le client (en tête de liste) seront implémentées en premier. La liste pourra être modifiée/complétée tout au long du projet, elle constitue le "Product Backlog".
Par ailleurs, vous devez identifier dans l'équipe client (ou MOA/AMOA) le "Product Owner" ou "responsable du produit". Cette personne devra s'approprier et maintenir à jour le product backlog tout au long du projet, être l'interlocuteur privilégié de votre équipe,...
Estimations L'ensemble des fonctionnalités de la liste doivent être estimées par l'équipe après avoir été transcrites en histoires d'utilisateur
(voir § Rédaction d'une exigence fonctionnelle en "Histoire d'utilisateur" en annexe). Le planning poker est un excellent outil en la matière. Il permet d'estimer relativement rapidement, avec
précision en impliquant plusieurs membres de l'équipe. Avant ou pendant les
estimations, le Product Owner sera peut être sollicité pour répondre aux
questions de l'équipe. A ce stade vous approfondirez un peu plus le besoin, mais sans aller trop loin (il s'agit simplement d'estimer le coût de chaque exigence). Au bout de quelques séances de planning poker, vous disposerez ainsi de l'ensemble des estimations en points et d'un montant total convertible en jours hommes. Vous obtenez ainsi une bonne estimation de la charge totale du projet.
DémarrageVous pouvez commencer par déterminer en accord avec le client la durée d'une itération ou Sprint (en général de 2 à 4 semaines). Vous devrez vous tenir à cette durée.Un projet démarre généralement (mais pas forcément) par ce qu'on appelle souvent le "Sprint 0" dédié aux travaux préparatoires du projet (ex : préparation des environnements, mise en place de l'intégration continue, définition de l'architecture générale du projet au besoin, formalisation des exigences fonctionnelles et non fonctionnelles,...). Exceptionnellement, la durée de ce "Sprint 0" ne respecte pas forcément la durée fixée précédemment. Réunion de planification de l'itération (environ 2h)
Ou "Sprint Planning Meeting". |
| Tâche | Propriétaire | Jour 1 |
Jour 2 | Jour 3 | Jour 4 | Jour 5 | Jour 6 |
Jour 7 |
... |
| Configurer la base de données |
David | 4 | 4 | 3 | 1 | 0 | |||
| Implémenter le détail d'un article |
Mohamed | 3 | 3 | 5 | 2 | 0 | |||
| Ajouter le HTTPS sur les transactions |
Marc | 2 | 2 | 2 | 2 | 2 | |||
| ... | ... | ... |
... |
... |
... |
||||
| TOTAL | 50 | 48 | 44 | 43 | 34 |
Les chiffres correspondent au nombre d'heures (ou jours) de travail restant sur chaque jour de l'itération.
La courbe peut parfois augmenter ponctuellement pour différentes raisons :
- Mauvaise estimation de la charge
- Ajout de fonctionnalités par le Product Owner
- Ajout d'anomalies costauds à corriger
- ...
Voici un exemple :
De cette façon, vous disposez d'indicateurs simples à calculer qui devraient satisfaire votre client et votre responsable.
Réunion de démonstration (environ 2h)
Fréquence : A la fin de chaque itération
L'objectif de la démonstration n'est pas de trouver des bug mais de détecter en amont les éventuelles mauvaises interprétations du besoin. Pour le client, c'est l'occasion de prendre conscience de votre avancement, de se rassurer ou d'être plus précis dans l'expression de son besoin voir plus impliqué (parfois le client tarde à prendre certaines décisions importantes pour vous). Les feedbacks sont les bienvenus.
Il ne s'agit pas d'une présentation, pas de power point, seules 30 minutes de préparation au maximum sont nécessaires. Un simple PC de développement peut faire l'affaire. Idéalement, le Product Owner peut orienter la démonstration selon ses souhaits voir prendre la souris. Les autres intervenants du projet peuvent également être conviés. Les aspects aussi bien métiers que techniques peuvent être abordés.
Le Product Owner détermine quelles fonctionnalités on été terminées durant l'itération et échange avec l'équipe et autres intervenants afin d'éventuellement re-prioriser au mieux le « product backlog ». A l'issue de cet échange, l'objectif du prochain Sprint peut être définit.
La démonstration n'implique pas forcément une livraison, il est cependant recommandé de réaliser des livraisons régulièrement (toutes les 1, 2 ou 3 Sprints selon les contraintes du projet). Cela permet au client et ses utilisateurs finaux de pousser un peu plus loin leurs tests, d'anticiper d'éventuels problèmes de fond, voir de mettre en production plus tôt que prévu l'application partielle dégageant ainsi un premier retour sur investissement. Sur un plan technique, ces livraisons permettent aussi de valider l'architecture technique cible, d'essuyer les plâtres sur le processus de livraison, d'exploitation de l'application, de gestion des environnements,...
Réunion de rétrospective (environ 2h)
Fréquence : A la fin de chaque itération
Cette seconde partie est animée par le « ScrumMaster » qui s'adresse
à son équipe. Elle a pour but d'améliorer continuellement la productivité de l'équipe en mettant les idées de chacun à contribution.
On se concentre essentiellement sur :
- La façon dont l'équipe a travaillé de concert
- Encouragement des aspects positifs de ce travail collaboratif pour la suite
- Identification de ce qui peut être amélioré, élaboration de stratégies d'amélioration en accord avec l'ensemble de l'équipe
Un bon exercice consiste à utiliser le paper board et séparer
l'espace en deux colonnes à remplir : une colonne « Qu'est ce qui a bien fonctionné ? » et « Qu'est ce qui ne va pas ou peut être amélioré
? ». Chacun à tour de rôle remplit les colonnes et lorsqu'un élément
est déjà identifié on ajoute un « bâton » en face. Ensuite il ne reste
plus qu'à réfléchir ensemble aux solutions d'amélioration de la
productivité de l'équipe. Ces solutions concrètes d'amélioration constituent le plan d'actions (fruit de la réunion).
Projet Scrum et vieilles habitudes MOA/MOE
Il est donc primordial de décloisonner au maximum MOA et MOE, ces deux entités doivent collaborer étroitement tout au long du projet. Etant donné que l'on touche ici à des habitudes bien ancrées, je vais m'efforcer d'expliquer quel rôle peut jouer la MOA dans un projet Agile.
Le rôle du consultant métier
- Modélisation des processus métier
- Participation aux ateliers de conception
- Rédaction des tests d'acceptation (en amont des développements)
- Vérification de la conformité des fonctionnalités (en aval des développements)
- ...
Rôle du responsable du produit (product owner)
- Produire ou fortement contribuer à la rédaction de la liste initiale des exigences du projet (ou histoires d'utilisateur)
- Prioriser ces dernières en fonction de leur importance métier
- Répondre aux attentes de l’équipe de réalisation
- Valider une fonctionnalité "terminée"
- Prendre des décisions importantes en temps voulu
A la fin de chaque itération, le responsable du produit peut :
- Ajouter une exigence manquante
- Retirer une exigence finalement inutile
- Redéfinir la priorité des exigences
Renfort du responsable du produit (product owner)
L’équipe de réalisation aide le « Responsable du produit » à prioriser ses exigences en lui apportant une évaluation de leur coût.
Une équipe de consultants métier peut l’aider à différents niveaux :
- Réponse aux questions de l’équipe de réalisation tout au long du projet, prises de décisions
- Rédaction des tests d'acceptation
- Remaniement des exigences à la fin de chaque itération
- Formalisation des feedbacks à la fin de chaque itération
- Autres sujets : logistique, conduite du changement, déploiement,…
Annexes
Rédaction d'une exigence fonctionnelle en "Histoire d'utilisateur"
Une "Histoire d'utilisateur" doit être :
- Courte : une ou trois phrases environ
- Négociable : elle peut être discutée avec l’équipe chargée de la réalisation du produit, notamment lors de l’estimation
- Source de valeur : elle doit être porteuse d’une valeur pour le client ou l’utilisateur
- Indépendante des autres histoires d’utilisateur (dans la mesure du possible)
- Estimable : elle peut être estimée par l’équipe de réalisation avec un risque d’erreur faible
- D’une taille appropriée : sa taille doit être relativement petite afin de faciliter son estimation. Elle doit pouvoir être conçue, développée et testée au sein d’une itération.
Voici un exemple d'histoire d'utilisateur dans le cadre de la réalisation d'un site de vente en ligne de DVD :
Quid des spécifications ?
La conception fonctionnelle voir technique d'une fonctionnalité se fait au fil de l'eau dans chaque itération. Ce n'est qu'au moment où on s'apprête à l'implémenter qu'on rentre dans les détails du besoin (pour rappel, le besoin lié à cette fonctionnalité à été abordé dans les grandes lignes lors de la phase amont d'estimation). Cette approche a le mérite de permettre au client d'ajuster ou approfondir son besoin sur les fonctionnalités implémentées plus tard. Elle lui permet aussi (ainsi qu'à l'équipe) de retarder certaines décisions sans risque pour le projet (c'est souvent plus sage quand on manque de visibilité).XP considère que les "histoires d'utilisateur", les tests associé et le code source constituent les spécifications fonctionnelles du projet. D'autres méthodes vont plutôt préconiser la rédaction de cas d'utilisation avec un niveau de détail variable selon le contexte du projet, les exigences du client et la complexité de la fonctionnalité à spécifier.
Il faut bien comprendre que rédiger des spécifications ultra détaillées n'a de sens que dans une approche traditionnelle. Car dans ce cas de figure, le client ne verra son produit qu'à la fin des développements. Il doit donc avoir une vision précise de ce qu'il aura en fin de projet grâce aux spécifications détaillées. Or l'approche Agile apporte au client une visibilité sur le produit dès le début du projet ainsi qu'une possibilité d'ajustement du besoin. On privilégie donc le développement de l'application à une documentation exhaustive et pléthorique (d'ailleurs souvent indigeste pour le client qui tarde à valider et retarde ainsi son propre projet).
Pour la partie technique on peut souvent se limiter à un dossier d'architecture, un modèle conceptuel de données (voir physique), aux commentaires du code (Javadoc) et à une spécification détaillant les modules éventuellement complexes pour faciliter la maintenance du produit par la suite.
En appliquant ce principe, on assiste généralement à un gain de productivité par rapport à une approche traditionnelle, puisqu'on ne perd pas un temps considérable en rédaction, validation puis mises à jour de spécifications détaillées. Il est sans doute bon de préciser également que l'on ne néglige pas la conception du produit pour autant. La conception fait partie des tâches sous-jacentes à la réalisation d'une fonctionnalité.