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.