Lavoisier Lavoisier Lavoisier Lavoisier

Résumé

Couv_9782100570980


Préface

J'ai rencontré Claude une première fois lors d'une formation ScrumMaster que j'ai donnée à Paris en 2005. J'ai immédiatement remarqué Claude dans le groupe par son enthousiasme et sa volonté de comprendre les valeurs et principes qui sont les fondements de Scrum. Depuis Claude ne cesse de me surprendre par son engagement à défier l'ordre établi et par sa générosité dans son travail.

Je suis personnellement fortement engagé dans la communauté Agile et plus spécifiquement la communauté Scrum depuis 2001 car j'ai la ferme conviction que c'est à travers des gens qui ont intégré les valeurs et principes fondamentaux de Scrum et qui les portent chaque jour dans leur travail que nous arriverons à créer des organisations de développement logiciel où les résultats, la qualité de vie et le plaisir pourront coexister de façon durable.

Je fais particulièrement attention à distinguer les gens de l'approche proprement dite car en ces temps où le rythme d'adoption des approches agiles et en particulier Scrum est ultra-accéléré, et où de plus en plus de gens voient Scrum comme un outil qui va magiquement régler beaucoup de leurs difficultés, il est fondamental de communiquer sur les principes fondamentaux et les enjeux culturels liés à son adoption. Si nous pouvions observer toutes les organisations qui ont du succès avec Scrum nous trouverions invariablement des individus qui osent défier l'ordre établi avec ténacité, qui savent se mettre au service de l'autre, se doter d'une grande capacité d'écoute et qui savent guider un groupe vers sa mission. De vrais ScrumMasters ! Claude est l'un d'entre eux !

Vous aurez deviné que j'ai été ravi lorsque Claude m'a demandé d'écrire la préface de son livre sur Scrum. Pourquoi ? Tout simplement parce que c'est Claude ! Aussi parce que je me suis dit enfin un bouquin sur Scrum en français. Il y a un manque flagrant de titres en français dans le domaine de l'informatique et ça m'a toujours un peu gêné. Pourquoi nous francophones serions-nous moins capables d'écrire ? Pourquoi se contenter de traductions ?

Claude nous offre un ouvrage en français d'une grande qualité. Il nous démontre à travers le texte son talent de vulgarisateur. Dans un style très accessible mais sans compromis, il nous amène à découvrir Scrum et à comprendre comment nous pouvons l'appliquer dans nos organisations.

Merci Claude et bonne lecture.

22 septembre 2009 dans un vol Montréal-Paris
François Beauregard
Fondateur de Pyxis Technologies (www.pyxis-tech.com)
et de Agile Montréal, formateur Scrum certifié depuis 2004.


Avant-propos

Depuis plus d'une douzaine d'années, je conseille des entreprises et je forme des étudiants sur les méthodes itératives et agiles. Depuis sept ans, cet effort porte presque exclusivement sur Scrum ; cela m'a permis de participer à une soixantaine de projets menés avec Scrum et m'a poussé à m'impliquer fortement dans le développement du logiciel libre iceScrum (un outil pour Scrum[1]).

Sur le terrain, j'ai constaté ce qui fonctionnait bien et ce qui fonctionnait moins bien. À travers ce livre, je souhaite vous faire partager mon expérience et les leçons apprises.

Vous y apprendrez à appliquer les pratiques de Scrum en les adaptant aux contraintes de votre environnement.

Même si un livre ne remplace pas une formation et encore moins une application concrète, il présente des conseils, des exemples, des retours d'expérience et des guides qui vous permettront d'optimiser votre mise en œuvre de Scrum.

Ce livre est destiné à tous ceux qui s'intéressent à Scrum. Les novices y trouveront une présentation détaillée des pratiques, ceux qui en ont déjà une connaissance trouveront des conseils utiles.

Il intéressera tous les membres des équipes (pas seulement les ScrumMasters) ayant adopté Scrum ou étant sur le point de le faire, y compris les managers et les clients qui souhaitent se familiariser avec cette méthode et son jargon.

Parcours de lecture : combien de sprints vous faut-il ?

Si vous cherchez une introduction brève aux méthodes agiles et à Scrum, lisez les chapitres 1 et 2.

Si vous voulez connaître Scrum en détail, lisez les chapitres 1 à 11. Les personnes jouant le rôle de Product Owner liront en particulier le chapitre 3 et le chapitre 5, et les ScrumMasters le chapitre 4. Tous les membres de l'équipe appliquant Scrum seront intéressés par les chapitres 4 à 11.

Scrum2_0_Avant_proposFig1.eps
Les chapitres du livre

À partir du chapitre 12 jusqu'au chapitre 16, l'accent est mis sur les compléments à Scrum pour le développement d'un produit : le chapitre 12 présente une approche pour utiliser Scrum en tenant compte des contraintes des projets, les chapitres 13 et 14 sont plutôt destinés à ceux qui définissent le produit, les chapitres 15 et 16 aux développeurs.

Le chapitre 17 présente l'outillage pour Scrum, le chapitre 18 propose des pistes pour effectuer la transition dans de grandes organisations et le chapitre 20 aborde la diffusion de Scrum en France.

La deuxième édition présente l'état de l'art actualisé en 2011, avec les dernières avancées du domaine. Scrum est toujours la méthode agile la plus populaire et son usage s'est élargi, au-delà des projets. C'est pourquoi le chapitre 19, Scrum à grande échelle a été ajouté. Les chapitres 13 et 17 ont été largement revus pour refléter les nouveautés et mes dernières expériences. Tous les autres chapitres ont été sensiblement modifiés.

Compléments en ligne

Sur le site www.aubryconseil.com, vous trouverez les dernières informations relatives au livre, des articles complémentaires, des précisions, des mises à jour, ainsi que les formations et les conférences de l'auteur.

Remerciements

Tout d'abord, un grand merci à Patrice Courtiade, l'auteur des dessins qui apportent une touche de légèreté à un sujet forcément sérieux.

Mes relecteurs m'ont fourni un feedback précieux, en m'obligeant à repenser certaines parties et en m'aidant à les rendre plus accessibles. Je les remercie chaleureusement pour leur contribution ; il s'agit d'Alexandre Boutin, Thierry Cros, et Antoine Vernois, plus Fabrice Aimetti pour la deuxième édition.

Je remercie également Laure Aubry, Jean-Pierre Odile, Julien Aubry, Vincent Barrier et Gaël Blondelle qui se sont investis dans la révision du manuscrit et m'ont été très précieux par leurs commentaires.

Jean-Claude Grosjean et Philippe Kruchten ont participé chacun à la rédaction d'un chapitre et à sa relecture, je leur en suis très reconnaissant.

Je suis également reconnaissant à François Beauregard d'avoir relu ce livre et d'y avoir contribué en écrivant la préface.

Je remercie mon éditeur Jean-Luc Blanc de m'avoir fait confiance.

Je remercie bien sincèrement toutes les personnes que j'ai rencontrées lors de mes formations et interventions sur les projets, leurs retours et leurs encouragements m'ont été précieux.

Merci enfin à Ruth pour son soutien sans faille au cours des nombreuses journées, soirées et week-ends que j'ai passés à écrire et réécrire ce livre.


Notes

[1]  Voir chapitre 17.


Chapitre 1

Scrum dans le mouvement agile

1.1.   Le mouvement agile

Scrum se range sous la bannière d'un mouvement, l'agilité, qui est né d'un manifeste, possède des valeurs et des principes et se met en œuvre avec des pratiques. De ce mouvement novateur émergent les méthodes agiles dont Scrum est actuellement la plus populaire.

1.1.1.   Méthode agile

Utilisées pour développer des produits, en particulier à base de logiciel, les méthodes agiles visent à apporter plus de valeur aux clients et aux utilisateurs, ainsi qu'une plus grande satisfaction dans leur travail aux membres de l'équipe.

Le développement s'effectuant par itérations successives, il est possible, à la fin de chaque itération, de changer les priorités pour faire en sorte que les éléments apportant le plus de valeur soient réalisés en premier. Cela permet de maximiser la valeur ajoutée.

Un meilleur accomplissement des personnes impliquées dans un développement est rendu possible par la notion d'équipe auto-organisée.

Une tentative de définition, adaptée de Scott Ambler[1], pourrait être :

« Une méthode agile est une approche itérative et incrémentale pour le développement de logiciel, réalisé de manière très collaborative par des équipes responsabilisées, appliquant un cérémonial minimal, qui produisent, dans un délai contraint, un logiciel de grande qualité répondant aux besoins changeants des utilisateurs. »

Le cérémonial, c'est ce qui définit les règles sociales et conventionnelles régissant la vie d'une équipe ; s'il est vrai que, pour une méthode agile, il est minimal en ce qui concerne la documentation, il est important pour le côté social (on parle de cérémonial Scrum à propos des réunions).

1.1.2.   Manifeste agile

Le terme agile est apparu dans le domaine du logiciel avec le Manifeste agile[2].

Le Manifeste fédère le mouvement agile avec un ensemble de valeurs et de principes :

  • Valeurs – Publié au début des années 2000 et inchangé depuis, le Manifeste agile définit une attitude de réaction par rapport à des processus lourds et bureaucratiques, en vogue à l'époque (et parfois encore aujourd'hui). La position prise par rapport à ces processus ne définit pas les valeurs intrinsèques de l'agilité, mais des valeurs relatives :
    • Les personnes et leurs interactions sont plus importantes que les processus et les outils.
    • Un logiciel qui fonctionne prime sur de la documentation.
    • La collaboration avec les clients est préférable à la négociation contractuelle.
    • La réponse au changement passe avant le suivi d'un plan.
  • Avec ces préceptes, pleins de bon sens, le Manifeste agile représente un coup de balancier, comme on en voit régulièrement dans l'industrie du logiciel, pour promouvoir des processus plus légers.
  • Les principes – Le Manifeste énonce douze principes :
    • Satisfaire le client en livrant tôt et régulièrement des logiciels utiles, qui offrent une véritable valeur ajoutée.
    • Accepter les changements, même tard dans le développement.
    • Livrer fréquemment une application qui fonctionne.
    • Collaborer quotidiennement entre clients et développeurs.
    • Bâtir le projet autour de personnes motivées en leur fournissant environnement et support, et en leur faisant confiance.
    • Communiquer par des conversations en face à face.
    • Mesurer la progression avec le logiciel qui fonctionne.
    • Garder un rythme de travail durable.
    • Rechercher l'excellence technique et la qualité de la conception.
    • Laisser l'équipe s'auto-organiser.
    • Rechercher la simplicité.
    • À intervalles réguliers, réfléchir aux moyens de devenir plus efficace.

Cette liste, pas plus que le Manifeste, ne définit une méthode agile. Il n'y a d'ailleurs pas une seule méthode, ni un emploi qu'on pourrait qualifier d'orthodoxe. Si les valeurs et les principes sont universels, la façon de les mettre en œuvre sur des projets varie. Cette application se fait par l'intermédiaire de ce qu'on appelle les pratiques.

Une pratique est une approche concrète et éprouvée qui permet de résoudre un ou plusieurs problèmes courants ou d'améliorer la façon de travailler lors d'un développement.

Les pratiques agiles, qui ne sont pas évoquées dans le Manifeste, constituent la partie essentielle de ce livre.

1.1.3.   L'agilité

En fédérant les méthodes agiles, le Manifeste agile constitue l'acte de naissance d'un nouveau mouvement, l'agilité. Le mouvement a pris de l'ampleur depuis quelques années, il est maintenant diffusé, au-delà des pionniers, dans de très nombreuses organisations impliquées dans le développement de logiciel. Les idées avancées ont pris progressivement de l'importance au point de devenir incontournables, voire « mainstream » : elles ont désormais vocation à faire partie du bagage que se doivent de posséder les personnes impliquées dans le développement.

Jim Highsmith[3], un des signataires du Manifeste, définit l'agilité par rapport au changement :

« L'agilité est la capacité à favoriser le changement et à y répondre en vue de s'adapter au mieux à un environnement turbulent. »

L'agilité oui, le changement gratuit et permanent non !

Des utilisateurs, brimés depuis longtemps par leur direction des systèmes d'information (DSI), découvrent que l'agilité peut accueillir et même favoriser les changements, ce qui les amène à penser qu'ils peuvent tout changer tout le temps.

Des managers se disent qu'avec l'agilité, il leur sera plus facile de demander à leurs équipes de traiter une urgence par du travail supplémentaire non prévu.

Non ! L'agilité favorise le changement, mais ne le rend pas gratuit ni permanent. Si la demande de changement venue d'un utilisateur est la bienvenue, sa prise en compte passe par une gestion des priorités et elle est différée : une équipe qui travaille ne doit pas être perturbée n'importe quand.

L'agilité permet de créer de la valeur tout en s'adaptant à temps aux changements. Pour cela, une nouvelle culture est bien souvent nécessaire.

Une nouvelle culture

Les valeurs et les principes de l'agilité peuvent présenter un caractère indéniablement subversif pour certaines organisations (mais on sait aussi que les valeurs sont assez vite récupérées). Au-delà des idées, l'agilité, en particulier avec Scrum, véhicule un vocabulaire nouveau. En quelque sorte, le vocabulaire contribue à renforcer l'idée du changement de culture.

Il importe de tenir compte des aspects culturels dans la formation et la transition à l'agilité : on ne change pas si facilement de culture.

Scrum2_chap_01Fig1.eps
Fig. 1.1  Il faut s'entraîner pour devenir agile
Place de l'agilité

Pour illustrer la position de l'agilité dans le développement de logiciel, je reprends une phrase de Tom de Marco[4], qu'on ne peut pas suspecter d'être un zélateur de l'agilité :

« La formule du succès : agilité 1, n'importe quoi d'autre 0. »

Ce n'est pas une définition, c'est plutôt un constat, édifiant sur la place actuelle de l'agilité dans l'ingénierie du logiciel.

1.1.4.   Ingénierie du logiciel

Si la culture agile est nouvelle, des pratiques maintenant qualifiées d'agiles existaient avant le Manifeste agile et même, pour certaines, avant les premières méthodes agiles.

Un certain nombre de pratiques dites agiles sont reconnues depuis longtemps dans la communauté du génie logiciel :

  • livrer fréquemment et régulièrement le logiciel,
  • faire des cycles de développement courts et limités dans le temps,
  • constituer une équipe complète,
  • laisser de l'autonomie aux membres de l'équipe,
  • avoir le représentant des utilisateurs situé physiquement avec le reste de l'équipe,
  • produire des plans à plusieurs niveaux : détaillés uniquement pour le court terme, et plus généraux pour le moyen terme,
  • développer en intégrant le code de façon continue,
  • faire des bilans de projet dans le but d'améliorer la façon de travailler.

D'autres sont apparues avec les méthodes agiles et sont devenues indiscutables, après avoir été éprouvées sur de nombreux projets, comme par exemple :

  • avoir un backlog de produit tenant compte des priorités,
  • suivre l'avancement des projets par la tenue d'une réunion quotidienne,
  • écrire les tests avant d'écrire le code,
  • pratiquer, de temps en temps, le travail en binôme, une technique qui consiste à avoir deux personnes derrière un seul écran pour partager les connaissances.

Prises individuellement, ces pratiques sont déjà efficaces. Insérées dans le cadre cohérent d'une approche agile, elles se renforcent mutuellement, et contribuent à la qualité du produit et à son utilité.

1.1.5.   Des méthodes agiles à Scrum

Les méthodes agiles existaient avant le Manifeste : Scrum et Extreme Programming datent des années 1990. Le Lean Software, d'où vient le Kanban, repose sur des bases encore plus anciennes : le système de production dans les usines Toyota dans les années 1950.

Il y a eu de nombreuses autres méthodes qualifiées d'agiles ou de semi-agiles. Le Manifeste en énonçant les valeurs et les principes communs a contribué à les fédérer toutes derrière la même bannière de l'agilité.

Plus récemment, l'engouement pour Scrum (la ScrumMania !) a mis fin à une hypothétique rivalité entre les méthodes agiles. Les études d'opinion et les tendances des recherches sur le Web le montrent : Scrum est de loin la plus populaire dans la famille des méthodes agiles.

Maintenant que Scrum a gagné[5], la difficulté majeure est d'amener ses utilisateurs à en faire un usage correct, mais pas dogmatique, sous la bannière de l'agilité.

1.2.   Survol de Scrum

Le nom vient du rugby

On prononce « screum » pas « scrume », ni « scroum ».

Scrum signifie mêlée au rugby. Scrum utilise les valeurs et l'esprit du rugby et les adapte aux projets de développement. Comme le pack lors d'un ballon porté au rugby, l'équipe chargée du développement travaille de façon collective, soudée vers un objectif précis. Comme un demi de mêlée, le ScrumMaster aiguillonne les membres de l'équipe, les repositionne dans la bonne direction et donne le tempo pour assurer la réussite du projet.

Scrum2_chap_01Fig2.eps
Fig. 1.2  La mêlée

Au-delà de cet accent mis sur la puissance du collectif, Scrum attaque la complexité par une approche empirique.

1.2.1.   Scrum, un truc qui marche

On est naturellement tenté de parler de méthode agile ou de processus agile pour Scrum. En fait, la définition officielle, celle donnée par la Scrum Alliance[6] et son fondateur Ken Schwaber (qu'il a maintenant quittée) est légèrement différente. Scrum n'est présenté ni comme un processus ni comme une méthode.

Le plus souvent, Ken Schwaber décrit Scrum comme un cadre (framework) ; à d'autres occasions il dit que c'est une voie à suivre (path) ou un outil. Mais parfois il revient à processus… Cela montre que ce n'est pas si évident.

Un spécialiste des processus parlerait, pour Scrum, de pattern de processus qui doit incorporer différentes méthodes ou pratiques d'ingénierie quand il s'applique sur un projet.

Qu'on le désigne comme un cadre, un pattern de processus, une méthode, voire un truc, Scrum définit des éléments qui feront partie du processus appliqué pour développer un produit. Ces éléments sont en petit nombre, le cadre imposé par Scrum étant très léger : guère plus que des itérations, des réunions au début et à la fin de chacune, une mêlée quotidienne, un backlog de produit et trois rôles.

Les succès sur le terrain donnent à croire que Scrum est un truc qui marche.

1.2.2.   Scrum en bref

Si la vraie nature de Scrum est difficile à définir, il est bien plus simple d'en expliquer la mécanique de mise en œuvre :

  • Scrum sert à développer des produits, en quelques mois tout au plus. Les fonctionnalités souhaitées sont collectées dans le backlog de produit et classées par priorité. C'est le Product Owner qui est responsable de la bonne tenue de ce backlog.
  • Une version (release) est produite par une série d'itérations d'un mois[7] appelées des sprints. Le contenu d'un sprint est défini par l'équipe, avec le Product Owner, en tenant compte des priorités et de la capacité de l'équipe. À partir de ce contenu, l'équipe identifie les tâches nécessaires et s'engage pour réaliser les fonctionnalités sélectionnées pour le sprint.
  • Pendant un sprint, des points de contrôle sur le déroulement des tâches sont effectués lors des mêlées quotidiennes (scrums). Cela permet au ScrumMaster, l'animateur chargé de faire appliquer Scrum, de déterminer l'avancement par rapport aux engagements et d'appliquer, avec l'équipe, des ajustements pour assurer le succès du sprint.
  • À la fin de chaque sprint, l'équipe obtient un produit partiel (qui s'enrichit d'un nouveau incrément à chaque sprint) qui fonctionne : il est potentiellement livrable. Son évaluation et le feedback récolté permettent d'ajuster le backlog pour le sprint suivant.

1.2.3.   Théorie

Les premières expérimentations de Scrum datent de 1993 et le premier article[8] est paru en 1995, pour la conférence OOPSLA[9] ; signé de Ken Schwaber, il présente Scrum comme un processus empirique adapté aux développements de produits complexes.

Scrum a donc son origine dans la théorie de contrôle empirique des processus. Les trois piliers de la théorie sont la transparence, l'inspection et l'adaptation :

  • Transparence – La transparence garantit que tous les indicateurs relatifs à l'état du développement sont visibles par ceux qui sont intéressés par le résultat du produit. Non seulement la transparence pousse à la visibilité mais ce qui est rendu visible doit être bien compris ; cela signifie que ce qui est vu est bien le reflet de la réalité. Par exemple, si une mesure considère que quelque chose est fini (le produit ou une partie seulement du produit), cela doit être strictement conforme à la signification de fini définie par l'équipe.
  • Inspection – L'inspection des indicateurs permet de détecter des variations par rapport aux attentes. Les différentes facettes du développement doivent être inspectées suffisamment souvent pour que des variations excessives dans les indicateurs puissent être détectées à temps.
  • Adaptation – Si l'inspection met en évidence que certains indicateurs sont en dehors des limites acceptables, il est probable que le produit résultant sera également inacceptable si on ne réagit pas ; le processus doit donc être ajusté rapidement pour minimiser les futures déviations. Il y a trois points d'inspection et d'adaptation dans Scrum :
    • Le scrum quotidien permet d'inspecter la progression par rapport au but du sprint et de faire des adaptations qui optimisent la valeur du travail du jour suivant.
    • La planification et la revue de sprint sont utilisées pour inspecter l'avancement du développement par rapport au but de la release et faire des adaptations sur le contenu du produit pour le prochain sprint.
    • La rétrospective incite l'équipe à revenir sur sa façon de travailler dans le sprint afin de déterminer les améliorations du processus pour le prochain sprint.

1.2.4.   Éléments

Le cadre Scrum consiste en une équipe avec des rôles bien définis, un cérémonial favorisant la collaboration et quelques artefacts (figure 1.3) :

Scrum2_chap_01Fig3.eps
Fig. 1.3  Éléments de Scrum
  • Équipe et rôles  L'équipe a un rôle capital dans Scrum : elle est constituée dans le but d'optimiser la valeur produite ; pour cela, elle doit avoir toutes les compétences nécessaires au développement du produit. Elle est investie avec le pouvoir et l'autorité pour faire ce qu'elle a à faire.
  • Cérémonial Scrum utilise des blocs de temps pour créer de la régularité. Le cœur du rythme de Scrum est le sprint, une itération d'un mois ou moins. Dans chaque sprint, le cadre est donné par un cérémonial léger mais précis basé sur des ateliers de travail collectif.
  • Artefacts – Scrum impose peu d'artefacts lors du développement : le plus remarquable est le backlog de produit, pivot des différentes activités.

Le cadre est complété avec quelques règles liant ces éléments.

Scrum2_chap_01Fig4.eps
Fig. 1.4  Le déroulement d'un sprint qui permet de transformer une partie du backlog
en produit
En résumé

Sous la bannière de l'agilité et de son Manifeste, Scrum fournit un cadre simple pour développer des produits. Toutefois, derrière l'apparente simplicité de Scrum se cache une grande puissance pour mettre en évidence le degré d'efficacité des pratiques de développement utilisées, et comme nous allons le voir, si le cadre est simple, la mise en œuvre demande de nombreux efforts.


Notes

[1] http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm

[2] http://www.agilemanifesto.org et http://www.agilemanifesto.org/iso/fr/ pour la version française (traduction « officielle » de 2010).

[3]  http://www.jimhighsmith.com/

[4]  De Marco, cité par Highsmith, est un expert du génie logiciel connu depuis plus de 25 ans : http://en.wikipedia.org/wiki/Tom_DeMarco.

[5]  À l'heure où j'écris ces lignes (mai 2011 pour la seconde édition), mais ça peut changer.

[6] http://www.scrumalliance.org

[7]  On peut remarquer que l'usage de Scrum évolue : par exemple, le plus courant aujourd'hui est d'avoir des sprints de deux semaines alors que la durée initiale était 30 jours calendaires.

[8]  http://jeffsutherland.org/oopsla/schwapub.pdf

[9] Object-Oriented Programming, Systems, Languages & Applications.


Chapitre 2

Des sprints pour une release

J'ai pris part à des dizaines de projets, soit en tant que développeur, soit en tant que consultant et il n'y en a pas deux qui se soient déroulés de la même façon, bien que certains aient suivi le même processus. Il y a une grande variation dans le déroulement temporel d'un projet, appelé cycle de développement (ou cycle de vie).

Un cycle est défini par des phases et des jalons. Les phases se succèdent et un jalon permet de contrôler le passage à la phase suivante : une phase a des objectifs et le jalon est là pour vérifier qu'il n'y a pas de déviation par rapport à ces objectifs.

Scrum2_chap_02Fig1.eps
Fig. 2.1  Dans un cycle traditionnel, chaque phase est différente

Évidemment le cycle est influencé par le modèle de cycle (ou de processus) qu'on utilise. Un modèle ancien, encore répandu en France, est le cycle en V[1], mais les entreprises, surtout les grandes, ont souvent défini leur propre modèle de cycle.

Dans certaines entreprises, l'application du modèle est fortement recommandée et dans d'autres l'équipe a plus de latitude. Bien souvent, et quel que soit le degré de recommandation, j'ai constaté qu'il y avait un grand écart entre le modèle et sa mise en œuvre sur les projets.

Plusieurs raisons l'expliquent :

  • Le modèle est bien souvent trop théorique, élaboré par des méthodologistes éloignés des réalités, et s'avère inapplicable sur le terrain.
  • Les contrôles sont difficiles à faire lors des jalons, parce qu'ils portent souvent sur une multitude de documents.
  • Les jalons étant franchis sans difficulté, l'équipe accumule les travaux non faits des phases précédentes.

Scrum fait partie des approches itératives et incrémentales dont le modèle de cycle de développement est basé sur une phase qui se répète plusieurs fois successivement. C'est la notion d'itération, appelée sprint avec Scrum. Tous les sprints se déroulent selon le même schéma et on y fait à chaque fois les mêmes types de travaux.

Scrum2_chap_02Fig2.eps
Fig. 2.2  Avec Scrum, le processus se répète à chaque sprint

C'est une différence majeure avec les méthodes traditionnelles pour lesquelles chaque phase impose des travaux de nature différente. Cela a un effet sur les activités de chaque sprint : elles ne sont pas définies par le cadre Scrum, c'est l'équipe qui en a la responsabilité.

C'est de ce cycle de développement et de ses implications dont il est question dans ce chapitre.

Définitions

Sprint est le terme utilisé dans Scrum pour itération. Dans le langage Scrum, un sprint est un bloc de temps fixé aboutissant à créer un incrément du produit potentiellement livrable.

Release peut avoir plusieurs sens :
Release comme version – Le dictionnaire du jargon informatique français définit une release comme suit : « version d'un logiciel effectivement diffusée, donc lâchée dans la nature. Synonyme de « Mise sur le marché ». Exemple : Unix system V release 4 ». Cette définition énonce clairement qu'il y a des versions qui ne constituent pas des releases.
Release comme période de temps – Par extension, on appelle également release la période de temps qui permet de la produire. On devrait dire le cycle de production d'une release, mais l'usage en anglais, et maintenant en français, est d'utiliser release comme période de temps, notamment dans l'expression plan de release. C'est ce sens, période de temps composée de sprints, qui est utilisé pour release dans ce livre.

2.1.   L'approche itérative et incrémentale

2.1.1.   Incrément et itération

Scrum se base sur une approche itérative et incrémentale pour le développement d'un produit.

Incrémental

Incrémental est utilisé pour mettre en évidence l'accroissement du produit obtenu à la fin de chaque sprint. Un processus incrémental permet de construire un produit morceau par morceau, chaque nouvelle partie venant s'ajouter à l'existant.

Pour l'écriture de ce livre, j'ai utilisé une approche incrémentale : j'ai fait un plan initial et j'ai rédigé chapitre par chapitre, sans respecter l'ordre du plan, d'ailleurs.

La pratique d'un cycle incrémental est répandue dans les développements de logiciel ; on parle souvent de lots pour les incréments qui font l'objet d'un contrat.

Itératif

Itérer est l'action de répéter. Dans le calcul scientifique, l'itération est un procédé de calcul répétitif qui permet, par exemple, de trouver la racine d'un nombre ou d'une équation, par approximations successives.

Dans le développement de logiciel, le terme itération est utilisé pour désigner une période de temps dans laquelle sont effectuées des activités, qui seront répétées dans les prochaines itérations. Le terme est souvent associé à processus.

Exemple : un article du Nouvel Observateur (grand public, donc) de juillet 2008 met en exergue les itérations du processus d'Amazon, qui expliquent, selon l'auteur, les succès de l'entreprise.

Un processus itératif permet de revenir sur ce qui a été fait, dans le but de l'améliorer ou de le compléter. Cela part de l'idée qu'il est difficile, voire impossible, de bien faire la première fois. Le feedback collecté sur le résultat d'une itération permet de faire des améliorations dans la suivante. On cesse d'itérer quand la qualité obtenue est jugée satisfaisante.

Pour l'écriture de ce livre, j'ai utilisé une approche itérative : j'ai diffusé le premier jet à des lecteurs et grâce à leur feedback, j'ai produit une nouvelle version.

Itératif et incrémental

Scrum combine les deux approches avec la notion de sprint :

  • à l'issue du sprint, il y a un incrément de produit qui est réalisé,
  • le feedback sollicité sur cet incrément permet de le perfectionner dans un prochain sprint.

En résumé, un sprint est une itération qui produit un nouvel incrément (incrémental) et peut aussi enrichir un incrément obtenu dans un sprint précédent (itératif).

Pour l'écriture de ce livre, j'ai utilisé une approche itérative et incrémentale : en fait, je n'ai pas diffusé le premier jet de tout le livre à mes lecteurs, mais celui d'un chapitre. Comme j'ai suivi Scrum pour ce projet de rédaction, dans un sprint je travaillais sur la première version d'un nouveau chapitre et aussi sur la révision d'un chapitre suite au retour d'un ou plusieurs lecteurs.

Les organisations qui développent du logiciel en passant par la production d'une maquette, celles qui procèdent par lots, celles qui produisent une ou plusieurs versions intermédiaires disent volontiers qu'elles appliquent un processus itératif et incrémental. Elles ne sont pas agiles pour autant.

Cycle agile

Quelles sont les caractéristiques de Scrum, en plus d'être itératif et incrémental, qui justifient le qualificatif d'agile à propos de son cycle de vie ?

  • Des itérations plus courtes : les sprints durent au maximum un mois.
  • Une séquence plus stricte : les sprints ne se chevauchent pas.
  • Un rythme régulier : les sprints ont toujours la même durée.
  • Scrum2_chap_02Fig3.eps
    Fig. 2.3  Différences entre incrémental par lots et agile

2.1.2.   Bloc de temps

Les sprints ont tous la même durée : Scrum s'appuie sur la notion de bloc de temps limité (timebox).

Il n'y a pas que les sprints qui sont timeboxés avec Scrum : de nombreuses activités d'un développement sont basées sur cette notion. Cela se manifeste en particulier dans les réunions qui constituent le cérémonial.

Pas de sprint extensible

Pour le sprint, la notion de timebox s'applique de la façon suivante : on ne change pas la date de fin une fois que le sprint a commencé. Même si on n'a pas fini tout ce qu'on voulait faire, on conserve comme date de fin celle prévue.

Pourquoi ? Cela permet d'éviter le syndrome du presque fini (ou fini à 90 %) où, finalement, la date de fin est repoussée plusieurs fois.

J'ai accompagné de nombreux projets, agiles ou pas. J'ai eu très souvent des demandes d'équipes venant négocier la date d'un jalon. Ces équipes me disent qu'elles ont un tout petit peu de retard et demandent à repousser la date d'une revue de deux ou trois jours. Juré, avec ce délai, ce serait mieux et on aurait tout ce qui était prévu. Évidemment la plupart du temps, après ce laps de temps supplémentaire, il en aurait fallu encore un peu... Les développeurs ont tendance à être optimistes.

La notion de bloc de temps évite les dérives : à la date prévue, on fait une inspection objective de l'avancement et on ajuste en conséquence la planification des prochains sprints.

Rythme régulier

La durée des sprints est toujours la même, dans la mesure du possible. L'intérêt de cette pratique est de donner un rythme à l'équipe, qui va s'habituer à produire régulièrement.

Cela permet d'éviter des situations de sur-régime que l'équipe ne pourra pas tenir bien longtemps. Pousser une équipe à travailler au-delà de son régime de croisière a des effets de bord négatifs sur la qualité de son travail : le nombre de défauts augmente, la motivation diminue, les pratiques d'ingénierie sont négligées…

Au contraire, un rythme régulier peut être conservé longtemps. Cela présente un autre avantage : comme on connaît les dates de début et de fin de à l'avance, les revues sont plus faciles à organiser et les intervenants peuvent planifier leur participation longtemps à l'avance.


Notes

[1]  En fait c'est un modèle théorique plus qu'un cycle de vie : http://www.aubryconseil.com/post/2007/01/23/162-le-cycle-de-vie-en-v-n-existe-pas.

Caractéristiques

Editeur : Dunod

Auteur(s) : Claude Aubry

Edition : 1ère édition

Intérieur : Noir & blanc

Support(s) : eBook [PDF]

Langue(s) : Français

Code(s) CLIL : 3193

EAN13 (papier) : 9782100563203

Ouvrages du même auteur