Série - Cycle de développement

Fil des billets - Fil des commentaires

Le cycle de vie en V n'existe pas

J'entends parfois : les méthodes agiles c'est bien mais chez nous on utilise encore le cycle de vie en V alors...

Ok, vous arrivez sur cette page. Sachez qu'elle date de 2007. Je ne renie pas ce qui est écrit, mais je vous invite à lire mes écrits plus récents sur Scrum. Claude Aubry

Un cycle de vie est un ensemble ordonné de phases décrivant la vie d’un projet, la phase n ne pouvant commencer que si la phase n-1 est terminée. Dans la représentation graphique du V, les boites s'appellent Spécification, Conception, Codage, Test et Validation pour prendre la variante la plus simple[1]. La signification du nom de ces différentes boites est à peu prés claire : Spécification on décrit le quoi, Conception le comment etc... Il s'agit des disciplines classiques du développement de logiciel.

cycle en V

Les travaux ne sont jamais séquentiels

Considérer que les boites du V correspondent aussi à des phases d'un cycle de vie revient à dire qu'elles se déroulent en séquence stricte : d'abord toute la Spécification puis toute la Conception puis tout le Codage puis tout le Test... Evidemment aucun logiciel n'a jamais été développé de cette façon strictement séquentielle. Jamais. La preuve la plus évidente concerne les travaux de Test. Quand on trouve un bug (et on en trouve) dans la "phase" de test, le minimum est de refaire des travaux de codage. Dans quelle phase ? Les 2 possibilités débouchent sur une impasse :

  • revenir en arrière dans une phase précédente, ce serait remonter dans le temps !
  • considérer que pendant la "phase" de test on fait du codage, de la conception, de la spécification en plus du test alors que c'est le nom d'autres "phases" du V, ce serait utiliser le même terme avec 2 significations différentes[2].

Le V n'est pas un cycle de vie

Plutôt que de parler du cycle de vie en V, on devrait parler de modèle en V en considérant les boites non pas comme des phases mais uniquement comme des disciplines.

J'ai dû voir la représentation du V pour la première fois en 1989[3]. Autant qu'il me souvienne, l'idée de départ du V est de montrer que le résultat d'un travail de la branche de gauche sert en entrée d'un travail le la branche de droite du V. Exemple : le document de spécification est en entrée du travail de validation, en plus de servir pour le travail de conception.

De mon point de vue, c'est une erreur d'interpréter la représentation en V comme un cycle de vie, alors qu'elle montre simplement des dépendances [4]entre des disciplines.

Le RUP

On sait depuis longtemps qu'un développement de logiciel n'est pas une suite de travaux définis à l'avance et exécutés en séquence. C'est pour cela que sont apparus le cycle en spirale, puis le RUP, ça fait déjà plus de 10 ans.

Rational Unified Process

Le RUP fait explicitement la distinction entre :

  • le cycle de vie, avec des phases et des itérations
  • les disciplines, comportant la description des rôles, produits et tâches

Pour éviter de mélanger 2 notions différentes (comme expliqué ci-dessus), les auteurs du RUP ont volontairement choisi des noms particuliers pour les phases : Inception, Elaboration, Construction et Transition, alors que les disciplines portent des noms plus classiques comme Conception, Test... Le schéma de la page d'accueil du RUP montre l'importance de la discipline pour la phase[5].

Représentation des processus

Cette séparation entre les concepts de phases et de disciplines est maintenant largement adoptée. On la retrouve, notamment, dans le méta-modèle SPEM élaboré par l'OMG pour représenter les processus.

Cette distinction apparaît très explicitement dans l'outil de représentation des processus EPF/Composer, basé aussi sur le SPEM, et dans les processus documentés avec EPF comme OpenUP.

Agilité et cycle de vie

Chaque projet a son cycle de vie. Les managers ont besoin de savoir à tout moment où on en est dans ce cycle. Pour les processus Agiles, un cycle de vie est composé des itérations (ou sprints) successives.

Même ceux qui se croient éloignés des processus Agiles (et pensent suivre le cycle en V) utilisent probablement la notion de phase avec un jalon permettant de passer à la phase suivante.



Les différences entre un processus Agile et un autre qui ne l'est pas peuvent être définies selon cette notion de phase :

  • processus pas Agile
  1. une phase[6] est définie par un objectif généralement exprimé en termes d'états de produits (documents). Cela amène à un avoir un déroulement des disciplines globalement séquentiel, mais qui essaie de prendre en compte la réalité non séquentielle des développements. Par exemple pendant la phase de Définition des besoins on fait essentiellement de la Spécification mais on peut faire du codage, par exemple pour réaliser une maquette[7]. Autre exemple pendant la phase de Test en Vraie Grandeur, on fera de la Conception et du Codage en plus du Test.
  2. une phase dure assez longtemps (quelques mois) et la durée est variable (on s'arrête normalement quand les objectifs sont atteints)
  3. il y a peu de phases (à l'extrême une seule)
  4. les phases produisent uniquement de la documentation au début et jusque assez tard dans le développement. Le logiciel testé n'est produit qu'à la fin.
  • processus Agile comme Scrum
  1. une phase (itération ou sprint) a un objectif qui porte sur des fonctionnalités et contient du travail dans toutes les disciplines[8].
  2. elle dure de 1 à 4 semaines. La durée est fixée à l'avance (notion de bloc de temps et de rythme régulier).
  3. le nombre d'itérations n'est pas fixé et peut être important
  4. chacune produit un logiciel fonctionnel (testé).

En allant au-delà de la vue réductrice et à une seule dimension montrée par le V, la distinction entre phases et disciplines peut aider à mieux appréhender les motivations qui amènent à un processus Agile.

Notes

[1] celle de Wikipedia divise la conception en 2 travaux et ajoute bizarrement Analyse des besoins et faisabilité

[2] par exemple codage devrait être compris d'un côté comme une phase et de l'autre comme un travail inclus dans la phase de test

[3] Je travaillais pour la société Verilog dont le logo était un ... V

[4] dépendance signifiant qu'une sortie d'une discipline est une entrée pour une autre

[5] Malgré cette présentation il arrive que la phase d'Elaboration du RUP soit (mal) comprise comme étant le moment où l'on ne fait que de la spécification, et celle de Construction l'unique phase où on code

[6] La plupart des entreprises ne commettent pas l'erreur de nommer ces phases comme les disciplines, on parle de phase de Définition, d'Etude...

[7] entendu en buvant une Guinness lors d'un pot avec mes collègues

[8] il arrive même qu'une personne les déroule toutes dans une seule journée

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

A la recherche du cycle en V

J'ai écrit il y a presque 2 ans que le cycle en V n'existait pas. Pourtant il y a en a qui le cherchent encore.

Je le sais, parce que les statistiques de mon blog montrent que des visiteurs arrivent sur mon blog en tapant cycle en V sur Google. Plus de 400 depuis le début de l'année !
Mais qui sont ces chercheurs du mythique cycle en V ?
J'avais tendance à penser que c'étaient des étudiants révisant leurs cours de génie logiciel. Mais je vois qu'il y en a encore 11 rien qu'hier dans mes stats, alors que les étudiants sont en vacances ou en stage.

Visiteur qui arrive ici en googlant cycle en V, dis-moi qui tu es !

Même dans les présentations du cycle en V comme celle-ci, il est dit clairement qu'il n'est pas applicable. Alors on évoque un intérêt pédagogique. Elle a bon dos la pédagogie, quand on voit les dégâts provoqués : une confusion entre les activités d'ingénierie (analyse, conception, codage, tests) et le déroulement dans le temps du projet. Le V ne sert qu'à montrer des dépendances entre les activités, alors que le nom cycle fait croire, à tort, qu'il s'agit d'un cycle de vie. Présenter le "cycle en V" comme un cycle de vie est une aberration pédagogique.

Cycle de vie avec Scrum

La vie d'un produit développé en appliquant Scrum est faite d'une séquence de releases. En général, une release dure quelques mois (entre 2 et 8 mois). Quand on a fini une release, on passe à la suivante, jusqu'à la fin de vie du produit. Normalement, les releases se suivent, mais ne chevauchent pas.

Une release est constituée d'une séquence de sprints. Un sprint dure entre une semaine et 4 semaines. Quand un sprint est fini, le suivant commence. En principe, il n'y a pas de trou entre 2 sprints et les sprints ne se chevauchent pas.

Après le début de la release et avant le début du premier sprint de cette release, il y a une période de temps de durée variable, parfois appelée improprement sprint zéro.

Un exemple de cycle de vie, avec une représentation temporelle de type "timeline" :

Roadmap avec 2 releases

Cette timeline a été faite en mars, pendant le sprint 2 de la release de printemps. Le sprint 1 était fini, et les sprints 3 et 4 prévus dans cette release dont la fin était prévue au 30 avril. La release d'été commençait alors et devait se finir le 30 juin.

Une timeline montre toute la vie du produit. Avant la date du jour, c'est l'historique. Après, cela constitue, en ajoutant le contenu prévu pour les futures releases, la roadmap du produit.

Des sprints pour une release

Chapitre 2

Mon éditeur (Dunod) m'a demandé de commencer à réfléchir à une deuxième édition de Scrum, le guide pratique de la méthode agile la plus populaire. Oh, on a le temps, c'est pour une publication au printemps en automne 2011.

Une 2ème édition peut inclure un éventuel nouveau chapitre, mais le plus usuel est d'améliorer et d'ajouter des paragraphes à ceux existant.

Je commence par le chapitre 2 : Des sprints pour une release. Je viens de le relire, c'est d'ailleurs la première fois que je me relis depuis octobre de l'année dernière, pour le bon à tirer. Parmi les retours que j'ai reçus de mes lecteurs, je ne crois pas en avoir qui portent en particulier sur ce chapitre.

Voici le plan de ce chapitre :

L’APPROCHE ITÉRATIVE ET INCRÉMENTALE

  • Incrément et itération
  • Bloc de temps
  • Durée du sprint

CYCLE DE DÉVELOPPEMENT SCRUM

  • L’aspect temporel
  • Activités et cycle de développement
  • Le résultat d’un sprint
  • Le résultat d'une release

GUIDES POUR LES SPRINTS ET RELEASES

  • Démarrer le premier sprint au bon moment
  • Produire des micro-incréments
  • Enchaîner les sprints
  • Utiliser le produit partiel
  • Savoir finir la release

Ce chapitre parle donc de cycle de vie pour développer un produit. Voici les quelques idées que j'ai pour l'améliorer dans la seconde édition.

Je pourrais montrer un niveau supplémentaire dans la vie du produit. Je dis qu'une release est constituée de sprints; je pourrais aborder l'enchaînement de releases, ce qu'on voit généralement dans une roadmap de produit.

Dans l'autre sens, montrer davantage l'intérieur d'un sprint, éventuellement aborder le pomodoro.

Ce chapitre, orienté processus, montre la différence entre un processus basé sur des activités de développement séquentielles et une approche agile. Je pourrais montrer comment les 2 se combinent, mais à la réflexion, cela serait prématuré au début du livre, je réserve cela pour le chapitre 18, Transition à Scrum.

Comme le Kanban est une pratique qui prend de l'importance, je pourrais l'évoquer dans ce chapitre. Cela permettrait de mettre en évidence la possibilité d'avoir des rythmes différents pour la planification, la livraison (et le déploiement) et l'amélioration de processus. Bien que Scrum soit orienté développement de produit, je pourrais aborder son usage pour des services, à travers la notion de flux continu.

La notion de timebox pourrait être approfondie avec des guides pour donner des pistes dans des situations rencontrées sur le terrain : équipes à effectif non stable, période de vacances...

Je parle souvent de la période de temps au début de la release avant de commencer le premier sprint. Je me refuse à l'appeler sprint zéro, mais il serait tout de même plus clair de lui donner un nom.

Évidemment j'en profiterai pour remettre à jour le paragraphe sur la durée des sprints avec mon sondage 2010.

Si vous avez d'autres idées, votre feedback est le bienvenu.

Billets en rapport :

Le rythme dans Scrum, au service de la collaboration

Le rythme régulier des sprints est la base de Scrum. A quoi sert-il ?

Plus largement, le rythme fonctionne selon 3 cycles dans Scrum :

  • celui du scrum quotidien, tous les jours donc,
  • celui du sprint, selon sa durée,
  • celui de la release, si elle est aussi cadencée avec une durée constante.

La réunion quotidienne sert à définir les points de synchronisation nécessaires dans la journée entre les membres de l'équipe.

La revue de fin de sprint sert à montrer le résultat pour obtenir du feedback des parties-prenantes.

Les événements de fin de release permettent, en particulier à grande échelle, de faire communiquer les différentes équipes de l'organisation.

Dans les 3 cas, le rythme sert à déclencher des activités de collaboration, à différents niveaux (au sein de l'équpe, avec les parties-prenantes, dans l'organisation). Les événements associés facilitent cette collaboration, surtout pour les équipes qui démarrent et n'ont pas la maturité suffisante pour le faire naturellement, quand le besoin s'en fait sentir.

Sur le modèle de Schneider, qui avait été remis dans l'actualité en 2012 par Michael Sahota[1] et son guide pour l'adoption et la transformation agile, la collaboration est à l'opposé de la compétence.

Ce n'est donc pas étonnant que les managers qui défendent, avec la compétence, la spécialisation et l'expertise, soient réticents à la notion de sprint. Ce sont les mêmes qui ont du mal à comprendre la notion d'équipes feature et même celle d'équipe pluridisciplinaire qui est une notion fondamentale de Scrum. Les impliquer dans une transformation agile demandera de les convaincre des bienfaits de la collaboration. Un changement de culture, pour certains.

Note

[1] qui sera présent au ScrumDay cette année