Introduction à Scrum: les itérations

Iterations 2

Image by jremsikjr via Flickr

Je débute ici une courte série d’introduction à la méthodologie Scrum. Wikipedia possède un article très complet sur les tenants et aboutissants de la méthode Scrum. Mon but n’est pas de répéter tout cela ici, mais simplement de rédiger quelques billets sur les aspects les plus intéressants de cette méthode, selon mon expérience personnelle. Je couvrirai dans ce billet les itérations. Puis dans les prochains billets je vous parlerai des histoires, du backlog, du calcul de la vélocité, puis finalement je ferai un petit tour d’horizon des autres caractéristiques que je juge plus ou moins pertinentes.

Scrum est une méthodologie agile orientée vers la gestion de projet. Alors que d’autres méthodologies agiles définissent un ensemble de pratiques de programmation, Scrum ne couvre aucune technique proprement dite du développement de logiciel. Elle peut ainsi être utilisée par un plus vaste ensemble d’équipes de gestion et s’appliquer à la gestion de projet dans des domaines très variés: planification d’événements (mariages, conférences, festivals), soutien à la clientèle, éducation, etc.

Le fondement de Scrum réside sur plusieurs éléments importants.  Pour ce premier billet, j’aimerais apporter mon opinion sur les itérations.

Itérations

La base même du concept du Scrum mets l’emphase sur les itérations. L’idée est de raccourcir considérablement la période de livraison d’une phase du projet. Ce concept permet de faire des mises à jour du produit très rapidement, en gardant en tête que chacune de ces mises à jour procure une réelle valeur ajoutée à l’utilisateur (le client). Typiquement, l’équipe peut déterminer qu’une itération (aussi appelée Sprint dans le jargon Scrum) équivaut à 2 semaines (10 jours de travail), 3 semaines (15 jours de travail) ou même une seule semaine de travail. L’équipe travaille alors conjointement pour livrer une version du produit dans le délai adopté. Bien qu’en début de projet il soit possible de varier le nombre de jours de travail contenu dans un Sprint afin de tester la valeur la plus efficace, une fois la taille optimale du Sprint adoptée par l’équipe, elle ne doit plus changer. Cet aspect sera crucial plus tard pour le calcul de la vélocité de l’équipe.

L’utilisation d’itérations permet de briser le cycle lourd et long de la méthode Waterfall dans laquelle des semaines et des mois peuvent passer entre la livraison de deux mises à jour du produit. Ici, chaque Sprint donne de la valeur au produit. L’on peut voir évoluer le produit à chaque Sprint, avec , certes, moins de changements à la fois, mais des changements axés sur une réelle valeur à l’utilisateur. C’est à mon avis l’une des qualités les plus satisfaisante de cette méthodologie.

Déroulement d’une itération

En début de Sprint, l’équipe évalue avec le client la complexité des fonctionnalités demandées par celui-ci. En évaluant chacune des histoires (ce sont des demandes de fonctionnalités dont je parlerai dans le prochain billet), l’équipe peut conjointement avec le client en arriver à déterminer le nombre de fonctionnalités qui feront parti du cycle de production qui débute, donc de cette itération. En classant les histoires par ordre de préférence (les fonctionnalités les plus importantes aux yeux du client sont prioritaires), l’équipe peut être en mesure de dire au client combien de ces fonctionnalités peuvent effectivement être complétées et livrée dans la durée du Sprint. Une fois un consensus arrêté sur le développement qui sera fait pendant cette période, l’équipe se met au travail.

Durant cette itération, toute l’énergie, la motivation et la concentration de l’équipe est orientée dans un seul et même but: compléter les tâches définies pour qu’à la fin du Sprint ces nouvelles fonctionnalités soient livrées dans le produit. Mais également, pendant toute la durée de ce Sprint, aucune nouvelle fonctionnalité n’est ajoutée ou même discutée sur la table de travail. Si d’autres fonctionnalités importantes sont demandées, celles-ci feront l’objet de discussions et d’analyses lors de la rencontre de planification de la prochaine itération.

Avantages du système par itérations

L’avantage que j’ai le plus apprécié dans mon cas est la prévisibilité que cela m’offrait. Lorsque je me suis lancé dans l’utilisation de Scrum, mon équipe de développement n’était composé que d’une seule personne, c’est à dire moi-même. Le fait de m’imposer des périodes prédéfinies pour livrer des fonctionnalités m’a permis :

  • D’apprendre à (ré-)évaluer la priorité des demandes qui m’avaient été faites.
  • De trouver les moyens de me concentrer spécifiquement sur une partie du développement à la fois. Du coup cela m’a emmené à m’intéresser à la technique Pomodoro de micro-management du temps.
  • De comprendre le pourquoi des demandes en me mettant dans la peau du demandeur, pour réaliser quelle était la réelle valeur ajoutée dans cette perspective.
  • De donner des estimés réalistes aux demandeurs sur les dates de livraisons de leurs demandes
  • De réaliser que j’étais plus productif que je ne le croyais, car je pouvais voir concrètement l’avancement du produit.

Bien que le concept de Scrum se veule un concept d’équipe, je ne vois pas pourquoi une équipe de un ne pourrait pas mettre à contribution les nombreux avantages que nous offre cette méthodologie pour améliorer sa productivité. Maintenant nous sommes trois dans notre équipe de développement, et j’essaie tranquillement de convertir mes collègues. Ce n’est pas facile, car il y a toujours de la résistance aux changements. Bien que nous ayons pris l’habitude de définir ensemble de courts Sprints, nous avons encore parfois de la difficultés à demeurer centrés uniquement sur ces demandes pour le reste du Sprint. Nous y travaillons cependant afin d’améliorer cela.

Lors de mon prochain billet dans cette série, je vous parlerai des histoires, cette façon plutôt ingénieuse de décrire les demandes de fonctionnalités.

Et vous, utilisateurs de la méthode Scrum, quels avantages y avez-vous trouvé?

Publicités
Tagué , , , , ,

4 réflexions sur “Introduction à Scrum: les itérations

  1. […] majorité des ressources pointent vers des explications sur les différentes méthodes agiles: Scrum, Extreme Porgramming, Kanban, Lean, […]

  2. […] a vu dans les billets précédents que le travail se fait par itérations. Au début  de chaque Sprint, l’équipe de développement fait une rencontre de […]

  3. […] Jusqu’à présent dans cette série, nous avons vu le premier principe de base de Scrum, les itérations, et dans le second billet, l‘importance de rédiger les demandes du produit sous forme […]

  4. […] billet est le second d’une courte série dédiée à l’introduction à la méthodologie Scrum. Dans le premier billet, nous avons vu ce que sont les itérations et l’importance […]

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :