Documentation contractuelle et Scrum

La transition à Scrum dans un contexte de gouvernance et de modèle économique imposant habituellement une production abondante de documents.

J'accompagne une équipe Scrum dans un contexte où de la documentation est exigée lors de jalons contractuels. Au départ, il s'agit d'un appel d'offres dans un domaine industriel. L'appel d'offres est classique -pas agile- et la réponse a proposé un développement avec une méthode agile. Le développement se fait avec Scrum, mais en plein accord avec l'émetteur de l'appel d'offres, ce qui laisse, heureusement, une marge de manœuvre par rapport aux jalons et à la documentation à fournir.

Hier nous avons parcouru la liste des 31 fournitures normalement attendues, pour définir la façon de gérer chacune dans notre approche Scrum. Nous avons identifié, selon le document, différents traitements dans le processus mis en place :

  • Pour certains documents, nous avons proposé qu'ils ne soient pas élaborés du tout, parce que leur rédaction constituerait du gaspillage.
  • Pour des documents de suivi de projet, la demande initiale était de les présenter lors de jalons intermédiaires. L'approche retenue avec Scrum est de les produire à chaque sprint et de les présenter lors de la revue. Leur production sera rapide, à partir d'extraits d'IceScrum.
  • Pour la documentation d'architecture, l'approche retenue est de la mettre à jour à chaque sprint. Ce sera explicite dans la définition de fini, et se concrétisera par une tâche, lors de chaque sprint, portant sur ce travail à faire de façon récurrente.
  • Pour certains documents destinés à l'exploitation, la même approche a été définie; mais pour d'autres, il a été décidé de ne pas la commencer dès les premiers sprints, par manque d'informations. Concrètement, cela implique que le travail à faire est collecté comme élément du backlog de produit. Il sera planifié dans un sprint, au moment où il pourra être élaboré.
  • Pour des documents de tests, la solution proposée est de produire les fournitures attendues sous une forme différente, avec une approche de pilotage par des tests d'acceptation associés aux stories du backlog et l'utilisation d'un outil de test permettant l'automatisation et la production de rapports.

Commentaires

1. Le lundi 01 février 2010, 09:35 par Thierry

bjr Claude,
oui, c'est bien la différence entre "lourd" et agile. Quand on part du "lourd", on enlève des docs, quand on part d'agile on en rajoute parfois.

2. Le jeudi 04 février 2010, 08:54 par Mathieu

Ca me semble l'approche la plus logique: intégrer la création de documentation comme tâches à l'intérieur du sprint, en la considérant comme un item.

Ca me semble être juste du bon sens, ou alors j'ai raté quelque chose ?

Pas sûr que le bon sens suffise. Que la documentation finalement conservée soit du travail à faire, certes, mais est-elle élaborée progressivement au cours de chaque sprint ou faite à un moment précis ? Selon la réponse, cela ira dans la signification de fini ou dans le backlog de produit.

La discussion continue ailleurs

1. Le lundi 01 février 2010, 01:18 par uberVU - social comments

Social comments and analytics for this post

This post was mentioned on Twitter by pointbar: Documentation contractuelle et Scrum : http://bit.ly/cORPiH...