Les cycles de vie Scrum et OpenUp

Une release, c'est toujours une série d'itérations, avec, avant, une phase pour les préparer et, éventuellement, une phase pour les mettre en production après.

Le cycle de vie d'OpenUp se présente comme celui du RUP, avec 4 phases successives : Inception, Elaboration, Construction et Transition. Dans chacune de ces phases, il y a une ou plusieurs itérations qui se déroulent toujours en séquence.

Avec Scrum, la notion de cycle de vie est moins mise en évidence. Un article ancien(1996) de Ken Schwaber évoque 3 phases : la première s'appelle Planning & Architecture, la deuxième est la phase des sprints et la dernière est Closure.

La vie dont il est question dans les 2 cas est celle d'une release, considérée comme une période de temps, en général de quelques mois. Ce cycle de vie d'une release se répète plusieurs fois dans la vie du produit : la release 1 est suivie de la release 2, etc...

Le développement d'une release nécessite toujours du travail particulier à faire avant de commencer les itérations successives, comme constituer l'équipe, définir la vision, produire un backlog initial et une première planification de la release. Si la release en question est la première dans la vie du produit, il conviendra également de faire des travaux d'architecture. La phase d'Inception d'OpenUp et la phase préliminaire de Scrum[1] sont donc tout à fait équivalentes.

Le développement d'une release se termine dans OpenUP par la phase de transition, qui est équivalente à la Closure. Pour savoir si on a vraiment besoin de faire des travaux spécifiques à la fin de la release, je renvoie à ce billet ou à celui-ci.

Les itérations des phases d'Elaboration et de Construction dans OpenUP ne diffèrent que par une activité qui est présente dans celles d'Elaboration et pas dans celles de Construction : cette activité s'appelle Develop the Architecture.

wkflwElab.jpg

La stabilité de l'architecture est un critère essentiel pour franchir le jalon de fin de phase d'Elaboration. C'est particulièrement important pour la première release d'un produit (ce qu'on appelle un nouveau développement, avec de nouvelles technos). Mais pour les releases suivantes du même produit, il est fréquent que l'architecture ne bouge pas : elle sera déjà considérée comme stable au début du projet. Dans ce cas, les travaux spécifiques d'Elaboration ne sont pas faits et les 2 phases se confondent. Je serais d'ailleurs partisan de fusionner ces 2 phases en une seule dans OpenUp : cela éviterait l'erreur fréquente qui consiste à considérer, à tort, la phase d'Elaboration comme de la spécification et de la conception[2] et celle de Construction comme du codage.

Les cycles de vie Scrum et OpenUp ne sont pas incompatibles. Au delà, le cycle de vie d'un produit constitué de releases successives, au cours desquelles l'architecture n'est pas remise en question, peut se généraliser de la façon suivante, en reprenant les noms des phases OpenUp :

  • Release 1 : I E C (T)
  • Release 2 et suivantes : I C (T)

Notes

[1] je l'ai appelée Phase de préparation dans le plugin Scrum pour EPF

[2] les fameux Big Up Front Requirements, Big Up Front Design et Big Up Front Modelling