ScrumDay 2013

Logo-Scrum-Day-20131

Le 11 avril dernier s’est tenu à Paris dans les locaux d’IBM le ScrumDay. Grâce à Guillaume Collic, j’ai pu m’y rendre et découvrir cet évènement pour la première fois.

La keynote d’ouverture

La journée a commencé avec la keynote de Robert RICHMAN “Culture Hacking”, celle-ci était en anglais et je n’ai malheureusement pas pu comprendre tous les messages qu’a voulu nous faire passer Robert Richman. Ce qu’il y a, je pense, à retenir de cette keynote est, l’importance de l’aspect humain dans l’entreprise et de l’importance des rituels (comme fêter un anniversaire). Le message général que Robert a voulu nous faire passer est qu’il est important qu’un employé soit content de venir travailler. Un employé content de sa condition dans l’entreprise est beaucoup plus productif. L’agilité est bien entendu  en accord avec ce message.

Les sessions

La première session, présenté par Sébastien Delest, était un retour d’expérience  sur l’intégration continu. L’intégration continu permet en effet de réduire considérablement l’étape d’intégration d’un projet qui consiste à regrouper le code des différentes parties d’une application. L’intégration continu permet de le faire à chaque commit. Les tests de non-régression assurent toujours la stabilité de l’application.

La deuxième était un retour d’expérience sur la mise en œuvre d’un projet mobile en Scrum. Il était très intéressant de voir que l’agilité à permis de mieux appréhender ce projet surtout par le biais de la communication et de la visibilité entre les équipes.  Merci à Cyrille DERUEL ainsi qu’à Elise PEYRET.

La troisième session était, quant à elle, une session un peu plus détendu.  Christophe HERAL  nous a fait une analogie sur la manière de jouer des joueurs de starcraft  II à l’agilité. Et si ces joueurs faisaient de l’agilité sans le savoir? Un joueur de starcraft doit en effet avoir la capacité de s’adapter au changement (en fonction de ce que joue son adversaire). Pour cela, il a besoin de visibilité, d’indicateur. Il doit pouvoir priorisé ses actions, etc… Identifier, traiter les signaux et les comportements freinant l’adoption de l’Agilité est un sujet primordial pour toute entreprise décidant de se placer sous le parapluie de l’agilité. C’était justement le sujet de la quatrième session. Celle-ci était organisée en un échange entre les occupants de la salle, ayant pour support une fiche faisant état de plusieurs de ces signaux. La session a eu plus de succès que prévu, merci à Eric Siber !

Laurent Morisseau (auteur du livre “Kanban pour l’IT” présenté ici)  ) était le speaker de la session «#OMG, mon équipe fait son haka en Kanban Style », partisan de la méthode Kanban, Laurent nous a démontré comment Kanban pouvait s’inscrire dans un contexte Scrum pour y apporter des problèmes…  ou

La keynote de clôture

Enfin, la journée s’est terminée sur une Keynote de clôture  par Dominique DUPAGNE. Celle-ci avait pour but de nous démontrer que le corps humain était agile et qu’il était impossible de tout prévoir. Il est important pour une entreprise de pouvoir s’adapter face à une situation, comme le fait le corps humain contre une maladie.

Lecture de : Scrum

scrum

Je viens de lire le livre Scrum: Le guide pratique de la méthode agile la plus populaire. Ecrit par Claude Aubry, celui-ci nous explique les rouages de la méthode Scrum. Le livre se découpe en 3 parties : les pratiques de Scrum, les pratiques complémentaires et la mise en place de Scrum.

Introduction

Un peu d’histoire

Jeff Sutherland a créé le processus Scrum en 1993. Il a tiré le terme « Scrum » d’une analogie mise en avant dans une étude réalisée en 1986 par Takeuchi et Nonaka, publiée dans le Harvard Business Review. Dans cette étude, Takeuchi et Nonaka comparaient les équipes à haut rendement et inter-fonctionnelles à la mêlée utilisés par les équipes de rugby. Ken Schwaber formalisa ce processus pour l’industrie du logiciel du monde entier dans le premier document publié sur Scrum au OOPSLA de 1995. Depuis lors, Scrum est devenu l’une des principales méthodes de développement agile, utilisé par les 500 plus grandes entreprises mondiales. source

Une méthode Agile

Scrum s’inscrit dans les méthodes agiles parce qu’elle respecte le manifeste Agile suivant  :

L’importance est donnée:

  • aux individus et aux interactions plus qu’aux processus et aux outils
  • à des logiciels immédiatement disponibles plus qu’à une documentation exhaustive
  • à la collaboration avec le client plus qu’à la négociation contractuelle
  • à la réactivité face au changement plus qu’au respect d’un plan

Les pratiques de Scrum

Les rôles

Le Product Owner

Le product Owner est responsable du produit.

  • Il donne la vision du produit, c’est à dire l’objectif du produit, la position du produit ainsi que la liste des fonctionnalités essentielles. Il doit s’assurer que tout les membres du projets partagent cette vision.
  • Il définit le contenu du produit :  il est responsable du backlog de produit et définit les priorités de développement. Il s’implique donc dans les tests d’acceptations.
  • Il planifie la vie du produit : il constitue les objectifs d’une release et prend les décisions sur son contenu ainsi que sur la date de mise en production.

L’objectif du Product Owner (PO) est de s’assurer que le produit apporte de la valeur aux utilisateurs.

 

Le ScrumMaster

Le ScrumMaster est responsable du déroulement de la méthode Scrum.

  • Il veille à la mise en application de Scrum(en animant les différents cérémonials par exemple).
  • Il encourage l’équipe à apprendre et à progresser dans les pratiques d’ingénierie.
  • Il aide à éliminer les obstacles freinant l’avancement du sprint.
  • Il incite l’équipe à être autonome et responsable.

L’objectif du ScrumMaster est que l’équipe arrive à un état où elle n’est plus besoin de lui.

 

L’équipe auto-organisée

L’équipe est responsable de la réalisation du produit. Le PO et le ScrumMaster font partis de cette équipe.

  • Elle définit la façon dont elle organise ses travaux sans autorité de la part du ScrumMaster ou du ProductOwner.
  • Chaque membre apporte son expertise, partage sa connaissance afin de créer une équipe multifonctionnelle.
  • Elle veille à posséder toutes les compétences nécessaires.

L’objectif de l’équipe est de réaliser un produit de qualité dans l’environnement de travail qu’elle a défini.

 

Les artefacts

Les artefacts sont les éléments physiques dont l’équipe se sert pour développer le produit.

Backlog de produit  : Il contient la liste des fonctionnalités des produits détaillées en stories. Ces fonctionnalités sont priorisées.

Plan de release : Il présente les sprints à venir ainsi que leurs contenus.Il est orienté vers le client(ils doivent pouvoir le comprendre) et est mise à jour régulièrement.

Plan de sprint : Il présente la liste des tâches à effectuer. Ces tâches sont définis, associé à une story et estimé (en heures ou en “point”, c’est optionnel).

Burndown chart de sprint : C’est un graphique représentant ce qu’il reste à faire dans le sprint. Il sert à montrer l’avancement réel du sprint et permet l’ajustement du plan de sprint.

Burndown char de release : C’est un graphique représentant ce qu’il reste à faire dans la release. Il sert à montrer l’avancement réel et apporte une aide à l’estimation de l’état du produit à la fin de la release. Il permet d’ajuster le plan de release.

Les cérémonials

Scrum est une méthode Agile itérative. Certaines étapes du produit reviennent donc régulièrement :

Release : C’est une version du produit réalisée par une série de 3-4 sprint.

Sprint : C’est une itération d’une durée de 2 à 4 semaines dans laquelle sont réalisées des tâches.

Planification de release : Processus permettant de définir le contenu d’une release (ou version). Elle est composée de plusieurs réunions étalées sur la réalisation de la release. Toute l’équipe y participe. Le PO doit au préalable établir et priorisé les différentes fonctionnalités.

Planification de sprint : Processsus permettant de définir les tâches(liées à des stories) prise dans le backlog qui vont être effectué pendant le sprint. Toute l’équipe y participe.

Scrum quotidien : C’est une réunion quotidienne(appelé scrum), elle appartient à l’équipe et doit lui permettre de s’auto-organiser. Ce n’est pas un compte rendu fait au ScrumMaster ou au ProductOwner. Lors de cette réunion, chaque membre de l’équipe doit répondre à ces trois questions :

  1. Qu’ai je fais depuis le dernier scrum ?
  2. Que vais-je faire jusqu’au prochain scrum?
  3. Quels sont les obstacles qui me freinent dans mon travail?

Ces trois questions ont pour objectif de présenter ce qui a été fait, prévoir ce qui va être fait et identifier les obstacles afin d’actualiser le plan de sprint ainsi que le burndown chart de sprint. Il ne s’agit en aucun cas d’évaluer les membres de l’équipe!

Revue de sprint : C’est une démonstration du produit en cours de développement faite à toutes les personnes concernées ou intéressées par le produit. Elle a lieu le dernier jour du sprint. La démonstration ne contient que les fonctionnalités finis du produit. Son objectif est de collecter un feedback sur le produit, d’actualiser le backlog de produit(par des évolutions ou des corrections) et d’ajuster le plan de release.

Rétrospective : C’est la réunion qui clôture le sprint. C’est un moment de réflexion collective qui a pour but :

  • de capitaliser sur les pratiques qui ont marché.
  • d’éviter de refaire les mêmes erreurs.
  • partager différents points de vue.
  • permettre au processus de s’adapter aux nouvelles avancées dans la technologie utilisée pour développer.

Le résultat de cette rétrospective est un regroupement d’actions divisé en 4 catégories :

  1. celles dirigées vers les personnes.
  2. celles sur leur façon d’appliquer les pratiques Scrum.
  3. celles orientées outils à installer ou à adapter.
  4. celles axées sur l’amélioration de la qualité.

Signification de fini : La définition de fini doit être définis au départ du projet (et actualisé si besoin). Elle permet de motiver l’équipe, diminuer les ambiguïtés et obtenir plus de performance et de transparence. Il y a trois définitions de fini : Une pour une story, une autre pour un sprint et une dernière pour une release.

 

Schéma globale de Scrum :

VueGlobaleScrum

Les pratiques complémentaires

Claude Aubry nous explique dans cette partie des pratiques complémentaires à Scrum permettant de faciliter son utilisation comme par exemple la création du backlog ou bien la mise en place d’indicateurs. Ces pratiques concerne le PO, le ScrumMaster et l’équipe.

De la vision aux stories

Avant de devenir une série de stories, le produit est avant tout une vision. Celle-ci possède un but, c’est à dire l’objectif du produit. Elle prend en compte les besoins des utilisateurs et développe une présentation de la solution à ces besoins tout en prenant compte des contraintes imposées au développement. Il est bien sûr possible d’avoir plusieurs visions selon la dimension du projet. On peut avoir une vision globale du produit puis des visions par release(ou version).

On découpe cette vision en une liste de fonctionnalités (ou features). Ces fonctionnalités sont des services fourni par le produit, observable de l’extérieur, qui répondent à un besoin et dont la description se situe à un niveau tel que toutes les parties prenantes du projet comprennent facilement ce dont il s’agit.

Une fois cette liste de fonctionnalités obtenu, elle est décomposée en “stories”. Ces stories possèdent un nom, une description, un identifiant(la fonctionnalité à laquelle elle appartienne). Il existe 3 type de stories :

  • User story : Elle définit un comportement visible pour les utilisateurs et leur apporte de la valeur ou de l’utilité.
  • Story technique : Elle définit un comportement invisible pour les utilisateurs mais visible par l’équipe de développement. Elle est nécessaire au développement de certaines user stories.
  • Défaut : Elle définit un comportement  qui enlève de la valeur au produit. Elles sont souvent créées lors des feedbacks.

De la story aux tests d’acceptation

Une fois une story définis, il est important de lui définir des tests d’acceptations. Ces tests permettent de savoir précisément lorsque la story est finis et d’être sûr de n’avoir rien oublié. Le Product Owner participe donc grandement à la création de ces tests. Le nombre de ces tests doit être inférieur à 8. Dans le cas contraire, la story est sans doute trop grosse et le Product Owner doit avoir la possibilité de la décomposer.

Lorsque plusieurs stories sont liées, on met alors un scénario en place qui permet d’effectuer les tests dans un certains ordre.

L’équipe doit être capable de refuser une story lors de la plannification de sprint lorsque celle-ci ne possède pas les conditions requises pour déterminer son état de finition.

Estimations, mesures et indicateurs

L’indicateur principal de la méthode Scrum est le burndown Chart. Celui-ci est représenté grâce à la récupération de mesure et permet de faire des estimations. Dans cette partie, Claude Aubry nous liste des mesures qu’ils séparent en 4 catégories :

  1. Les mesures quotidiennes
    • Le nombre d’heures restant pour finir les  tâches du sprint
    • Le nombre de tâches restant à finir
    • etc…
  2. Les mesures à chaque sprint
    • La capacité estimé au début du sprint
    • La vélocité réelle du sprint
    • L’utilité ajoutée pendant le sprint
    • etc…
  3. Les mesures à chaque release
    • identique à celle du sprint mais à l’échelle d’une release
  4. Autres
    • Nombre d’obstacles rencontrés et non éliminés
    • Ressource consommé
    • etc…

Ces mesures  permettent de créer des indicateurs(sous forme graphique par exemple) et ainsi pouvoir estimer la suite du projet. Ces estimations ne sont pas des engagements et peuvent être actualisées!

Scrum dans l’ingénierie du logiciel : Pratiques d’eXtreme Programming

Scrum est une méthode Agile pouvant s’adapter à différents domaines. Dans le cas de l’ingénierie du logiciel, Claude Aubry se tourne vers des pratiques de la méthode agile eXtreme Programming. Je vous invite à lire ce billet pour plus d’information : lien

Mise en place de Scrum

Dans cette dernière partie, Claude Aubry sort de l’aspect pratique de Scrum et s’attarde sur sa mise en place.

Adapter Scrum au contexte

Scrum n’est pas une méthode qu’il faut appliquer bêtement. Il faut la voir comme un cadre. A ce cadre vient s’appliquer des pratiques liées à l’ingénierie(pratiques d’eXtreme Programming pour l’ingénierie lié au développement du logiciel par exemple).

Claude Aubry nous explique également qu’il faut savoir adapter Scrum et revenir dessus à chaque rétrospective. Afin de bien cerner ce contexte, Il faut répondre à ces questions :

  • A quel niveau d’innovation se situe l’entreprise
  • Dans quel culture? N’oubliez pas le côté humain d’un projet!
  • Quel est le domaine métier?
  • Quel niveau de maturité? A-t-on beaucoup d’expérience dans le domaine?

Le contexte peut être partager en 4 catégories :

  1. La nature du produit
  2. L’état du logiciel
  3. L’équipe
  4. L’organisation de développement

Pour résumé, Scrum possède deux axes sur lesquelles repose son application : la sélection des pratiques liées au domaine métier et le contexte.

La transition à Scrum

La transition à Scrum ne doit pas être brutale, elle doit être réfléchis. Cette transition constitue en lui même un projet dans lequel sera exécuté un projet pilote. L’équipe du projet pilote peut être différente de l’équipe du projet de transition. L’équipe du projet de transition doit être un support pour l’équipe du projet pilote.

Claude Aubry définit un cycle de 5 étapes :

  1. Evaluer le contexte : Il s’agit d’avoir d’avoir un vision claire de la raison du changement.
  2. Préparer l’application de Scrum : Choisir le projet pilote, adapter les pratiques. Créer l’équipe pilote et la former à Scrum (il existe plusieurs méthodes).
  3. Exécuter Scrum sur un projet pilote : Le projet de transition et le projet pilote se déroule simultanément. Les phases de rétrospective sont nombreuses et importantes.
  4. Diffuser dans l’organisation : L’objectif du projet de transition et de faire passer toute l’organisation de l’entreprise à Scrum.
  5. Evaluer le niveau atteint : A chaque fin de projet, on évalue le niveau atteint et on ajuste.

Scrum avec un outil

Dans cette partie, Claude Aubry nous présente différents outils utilisés pour Scrum. Il nous présente également iceScrum dont il est Product Owner.

Scrum à grande échelle

Scrum s’applique à des équipes constituées de 5 à 10 personnes. Dans le cas de la création d’une très grosse application, il est possible d’avoir plusieurs équipes. Il est important alors de bien constituer le backlog. Pour cela, il est possible de constituer des scrums de scrum. C’est à dire que chaque équipe scrum possèdera son backlog. Un représentant de chaque équipe est choisi pour créer une autre équipe Scrum. Cette équipe a pour but d’avoir une vision globale du projet. Elle possède son propre backlog. En décomposant celui-ci, les features obtenues alimentent les backlogs des équipes “normales”.

Il faut cependant bien garder à l’esprit que la communication est la clé de la réussite d’un projet. Par conséquent, plus l’équipe sera grosse et éparpillé géographiquement, plus il sera difficile de maintenir le projet dans un environnement stable. Il est alors possible d’utiliser la méthode Kanban pour améliorer sa chaîne de processus.

Scrum en France

Dans cette dernière partie, Claude Aubry fais un état de lieu de la méthode Scrum en France.

 

Conclusion 

Ce qu’il faut retenir est que la méthode Scrum est un cadre qui repose sur un contexte et un domaine métier. Ce cadre possède des pratiques à respecter qu’il faut enrichir par des pratiques lié au domaine métier. Ce billet n’est qu’un résumé de ces pratiques. Pour plus d’information je vous conseille vivement la lecture de ce livre qui vous expliquera ces pratiques en détails ainsi que toute la dimension humaine lié à un projet Scrum. Cette dimension est malheureusement difficile à exprimé en un simple article de blog :  Scrum n’est en aucun cas une méthode permettant d’évaluer les membres d’une organisation.