Un aperçu de Scrum pour néophyte …

Scrum - MéléeAu cours d’une mission, j’ai été confronté à l’utilisation de Scrum comme méthodologie de projets. Suite à cette première expérience qui m’a parut satisfaisante, j’ai eu l’envie de partager ce que j’ai pu apprendre et comprendre pour en faire profiter d’autres qui n’ont pas eu ce privilège.

L’objectif de ce billet se résume en deux points :

  • Conserver le souvenir de cette expérience, et mettre en avant ma vision de ce que j’ai pu vivre et ressentir au cours de cette période
  • Faire partager et mettre à profit cette connaissance. J’espère donner envie de s’intéresser au sujet, et pourquoi pas, de remettre parfois en cause certaines autres méthodes toujours adoptées sans vraiment pouvoir comparer

Un aperçu de Scrum pour néophyte …



MÉTHODES AGILES

Avec un cycle de développement classique, nous nous retrouvons toujours face à un contrat liant un Client, à la Maîtrise d’Ouvrage (MOA / AMOA) et à la Maîtrise d’Œuvre (MOE). Le client émet son besoin et fixe ses contraintes de temps et d’argent. La MOA joue le rôle de traducteur entre le Client et la MOE, en fournissant des documents tels que l’ « Expression de besoin » ou le « Cahier des Charges Fonctionnelles ». La MOE conçoit, réalise, recette et livre le projet.

Dans le meilleur des mondes, tout le monde sera content à la date fixée par le Client … seulement …

Le Client va faire évoluer son besoin, si ce n’est complètement le changer. Mais les contraintes temporelles, elles, seront toujours là et déjà bien entamées. La MOA, tiraillée de tous côtés, cherchera tant bien que mal à rééquilibrer le projet, en ajoutant, supprimant, modifiant certaines fonctionnalités. La MOE se justifiera par rapport au contrat initial.

Au final, le budget et la date de livraison seront revus à la hausse, le produit final ne sera pas à l’image du contrat initial, mais ne correspondra pas non plus aux attentes du Client. On repartira, alors, sur un nouveau contrat d’évolutions ou de mise à jour, dans un climat très tendu.

Là où le cycle de développement classique manque de souplesse, la méthodologie agile en injecte.

En effet, les méthodes Agiles permettent de concevoir des applications ou sites Web en impliquant au maximum le Client à toutes phases du projet. Ces méthodes cherchent à satisfaire au mieux le réel besoin de celui-ci grâce à une grande réactivité face à ses demandes. De cette idée, il en est sortit 4 grands principes, qui ont donnés naissance au Manifeste Agile, qui sera repris plus tard comme étant la clé de voûte des Méthodes Agiles.

[Haut de page]

Le manifeste Agile

C’est en 2001, aux États-Unis, que 17 figures éminentes du développement logiciel se sont réunies pour débattre du thème unificateur de leurs méthodes respectives, dites méthodes agiles.

Les plus connus d’entre eux étaient Ward Cunningham l’inventeur du Wiki via WikiWikiWeb, Kent Beck, père de l’extreme programming et cofondateur de JUnit, Ken Schwaber et Jeff Sutherland, fondateurs de Scrum, Jim Highsmith, prônant l’ASD, Alistair Cockburn pour la méthode Crystal clear, Martin Fowler, et Dave Thomas ainsi que Arie van Bennekum pour DSDM (Dynamic System Development Method) la version anglaise du RAD (Développement rapide d’applications).

Ces 17 experts venant tous d’horizons différents réussirent à extraire de leurs concepts respectifs des critères pour définir une nouvelle façon des développer des logiciels. De cette réunion devait émerger le Manifeste Agile (ou Agile Manifesto), considéré comme la définition canonique du développement Agile et de ses principes sous-jacents.

Nous découvrons de nouvelles façons de développer les logiciels en pratiquant et en aidant les autres à pratiquer.
De ce fait nous avons déduit des valeurs communes :

  • Les personnes et leurs interactions, plutôt que les processus et les outils
  • Un logiciel opérationnel, plutôt que des documentations exhaustives
  • La collaboration effective avec le Client, plutôt que les négociations de contrats
  • Répondre et accueillir les changements, plutôt que suivre le plan projet.

Autrement dit, alors que nous accordons une certaine valeur aux items de droite, nous en donnons plus à ceux de gauche.

Version originale : http://agilemanifesto.org/

En d’autres mots, les méthodes Agiles prônent donc les quatre valeurs suivantes :

  • L’équipe (« Les personnes et leurs interactions, plutôt que les processus et les outils ») :

Dans l’optique agile, l’équipe est bien plus importante que les moyens matériels ou les procédures. Il est préférable d’avoir une équipe soudée et qui communique composée de développeurs moyens plutôt qu’une équipe composée d’individualistes, même brillants. La communication est une notion fondamentale.

  • L’application (« Un logiciel opérationnel, plutôt que des documentations exhaustives ») :

Il est vital que l’application fonctionne. Le reste, et notamment la documentation technique, est secondaire, même si une documentation succincte et précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n’est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l’équipe (on en revient à l’importance de la communication).

  • La collaboration (« La collaboration effective avec le Client, plutôt que les négociations de contrats ») :

Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l’équipe et fournir un feed-back continu sur l’adaptation du logiciel à ses attentes.

  • L’acceptation du changement (« Répondre et accueillir les changements, plutôt que suivre le plan projet ») :

La planification initiale et la structure du logiciel doivent être flexibles afin de permettre l’évolution de la demande du client tout au long du projet. Les premières releases du logiciel vont souvent provoquer des demandes d’évolutions.

[Haut de page]

Principes de la méthodologie Agile

Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles :

  • Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.
  • Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.
  • Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.
  • Les gens de l’art et les développeurs doivent collaborer quotidiennement au projet.
  • Bâtissez le projet autour de personnes motivées. Donnez-leur l’environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.
  • La méthode la plus efficace pour transmettre l’information est une conversation en face à face.
  • Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
  • Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
  • Une attention continue à l’excellence technique et à la qualité de la conception améliore l’agilité.
  • La simplicité – l’art de maximiser la quantité de travail à ne pas faire – est essentielle.
  • Les meilleures architectures, spécifications et conceptions sont issues d’équipes qui s’auto-organisent.
  • À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.
Version originale : http://agilemanifesto.org/principles.html

[Haut de page]

SCRUM en 100 mots

SCRUM est une méthodologie AGILE. Elle vise à satisfaire au mieux le besoin du PRODUCT OWNER en l’impliquant aux différentes phases du projet. Celui-ci est responsable du PRODUCT BACKLOG, liste priorisée des USERS STORIES. Lors du SPRINT PLANNING, le PRODUCT OWNER, le SCRUM MASTER et la TEAM définissent le SPRINT BACKLOG que la TEAM s’engage à réaliser au cours du SPRINT. Au quotidien, le SCRUM MASTER se réunit avec la TEAM pour le DAILY SCRUM et la BURN DOWN CHART est mise à jour. La TEAM conclut le SPRINT par une DEMO du travail réalisé, puis une un SPRINT REVIEW.

Cycle Scrum

Cycle Scrum

[Haut de page]

SCRUM

SCRUM est une méthodologie Agile, vous l’aurez compris. Elle se doit alors de respecter les quatre valeurs principales, ainsi que leurs douze principes sous-jacents. Mais ceci n’est que la base sur laquelle Scrum se repose. Cette méthodologie possède trois familles d’éléments utiles au quotidien afin de mieux avancer dans nos projets : les rôles, les réunions et les artefacts. Chacune de ces familles possède 3 éléments.

[Haut de page]

Les rôles

On s’attendrait à voir dans cette partie, les notions de Développeurs, Architectes, Chef de Projet, Responsable, MOA, MOE, Administrateurs de Bases de Données, Testeurs et j’en passe. Vous l’aurez compris, avec Scrum, on met tout cela de côté. Pour faire simple, je citerai le blog de Frédéric Doillon:

Il n’y a que trois rôles dans scrum, chaque rôle portant une responsabilité bien défini, sans chevauchement néfaste à la clarté des missions de chacun : l’équipe, le scrum master, le product owner.

La responsabilité de l’équipe est de produire.

La responsabilité du scrum master est d’assurer le suivi de la méthode.

La responsabilité du product owner est de créer de la valeur.

Chacun des rôles est complémentaire aux deux autres. Sans équipe, le scrum master ne sert strictement à rien, et le meilleur product owner du monde ne créera aucune valeur. Mais sans product owner, le scrum master aura beau être un super héros, animant une équipe de tueurs, le risque est grand de produire au mauvais moment un software qui ne servira à rien. Enfin, un product owner visionnaire ne sera pas d’une grande aide à l’équipe si le scrum master fait défaut : retard, désillusion, mal-être…

En résumé, un « bon » projet scrum, c’est une équipe de tueurs, animés par un super héros, travaillant pour un visionnaire !

[Haut de page]

Le directeur de produit

Le directeur de produit, aussi appelé « product owner », représente le client et les utilisateurs. C’est lui qui prend toutes les décisions importantes à propos de l’orientation du projet et notamment, c’est lui qui doit prioriser les fonctionnalités métiers qui seront développées et maintenir à jour cette liste. Il est important qu’il reste très disponible pour répondre aux questions de l’équipe et pour valider / rejeter les résultats attendus.

[Haut de page]

Le scrum master

Le Scrum master n’est pas un chef de projet. On pourrait plutôt le voir comme un « Coach ». Son but est d’assurer le suivi de la méthode comme indiqué plus haut, mais il a bien sur d’autres rôles. Il protège l’équipe des éléments perturbateurs extérieurs et l’aide à résoudre ses problèmes non techniques. C’est lui aussi qui va s’assurer de l’efficacité fonctionnelle de l’équipe, de sa productivité et donc émettre les différentes résolutions possible en cas de problèmes.

[Haut de page]

L’équipe SCRUM

L’équipe Scrum, ou la « Team », s’occupe de la partie technique. Elle est composée de 5 à 9 membres maximum. Elle doit s’autogérer … en fait, mieux que ça, au sein de l’équipe personne n’a rôle désigné. Bien entendu, l’expérience technique passée d’un membre de l’équipe va aider et influencer la répartition des tâches au quotidien, mais personne ne doit être confiné dans son coin à développer sa partie. En Scrum, toute l’équipe avance ensemble et au même rythme sur le même front.

[Haut de page]

Les réunions et les artefacts

Il me parait difficile de séparer les réunions des artefacts tant les uns impliquent les autres.

Nous savons maintenant que trois grands rôles vont prendre part à la vie du projet. Scrum offre à chacun des outils ou documents qui vont contribuer orienter et faire avancer le projet en plusieurs phases itératives appelées Sprint. Un Sprint ? C’est une période de 2 à 4 semaines durant laquelle l’équipe va développer une partie du projet et au bout de laquelle il y aura un livrable. Ce livrable sera présenté lors d’une démo en fin de sprint. Mais revenons tout d’abord au lancement du projet.

[Haut de page]

Artefact #1 : Le Backlog de produit

Nous avons vu que le directeur de produit est en charge de lister et prioriser les fonctionnalités métiers à développer. Cette liste de tâches est appelé « Product Backlog » (ou backlog de produit). Chaque élément de la liste est appelé « User Stories ». C’est une unité fonctionnelle qui peut être directement livrée au client.

Le Product Backlog définit avec une multitude de User Stories les exigences fonctionnelles du produit à livrer.

Cette liste peut être réalisée lors d’une réunion de lancement de projet avec les principaux intéressés. Ceci permet en général d’ouvrir les discussions autour du projet et de mieux définir le besoin. Les priorités sont définies initialement par le directeur de projet et elles sont revues à chaque début de sprint.

Priorité # N° User Stories
1.0 0001 En tant qu’utilisateur, j’ai accès à un site via une URL donnée.
2.0 0002 En tant qu’utilisateur connecté, je peux modifier mon mot de passe.
3.0 0003 En tant qu’administrateur, je peux créer un nouvel utilisateur.
1.1 0004 En tant qu’utilisateur, je peux m’identifier sur le site et obtenir un profil spécifique.

Dans la pratique, les user stories sont notées sur des Post-It et ils sont positionnés sur un mur ou sur un tableau. L’idée étant d’avoir une vision globale, et en même temps ponctuelle, de ce qui fait, ce qui est en cours et ce qui reste à faire, et de pouvoir facilement manipuler ces user stories tout au long du projet.

Il y a également plusieurs offres logicielles permettant de gérer tout cela numériquement.

[Haut de page]

Réunion #1 : La planification du Sprint

La planification du sprint a pour but de spécifier quel va être l’aboutissement de celui-ci. L’équipe, son scrum master et le directeur de projet vont alors sélectionner des user stories du backlog de produits. L’équipe va s’engager à livrer pour la fin du sprint toutes les user stories sélectionnées. Cette réunion ne doit pas durer plus de deux heures.

Nous arrivons au moment le plus divertissant de la planification, le Planning Poker !

Chacune des user stories vont être estimées en « User Story Points ». C’est une notation abstraite qui sera propre à chaque projet. Chaque personne dispose d’un jeu de carte un peu spécial composé de 9 cartes avec les valeurs de la suite de Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, 55), ou plus simplement les valeurs 1, 2, 3, 5, 8, 13, 20, 50, 100. Certains rajoutent des cartes 0 et 0.5. D’autres, des cartes à usage unique « Pause Café », ou « Joker ».

Le directeur de produit va expliquer une user story sortie du backlog de produit selon la priorité qu’il aura défini. Tout le monde va pouvoir demander des explications et réagir sur la fonction qu’elle doit remplir. Une fois qu’elle sera claire et comprise de tous, chaque participant va évaluer individuellement cette user story et retourner devant lui la carte correspondant au nombre de user story points qu’il souhaite affecter à cette tâche.

Evidement, il sera rare que tout le monde donne la même estimation, et donc les extrémités vont expliquer aux autres leurs choix. Dès lors, tous les participants vont estimer de nouveau la tâche, et l’opération se répètera tant que l’unanimité ne sera pas votée.

L’avantage est simple à comprendre … le dialogue est facilité. Tout le monde va pouvoir s’exprimer clairement et simplement sur sa propre vision.

Certaines user stories vont être sélectionnées pour le sprint, d’autres vont être laissées de côté pour un sprint suivant. Les user stories sélectionnées devront être réalisées pour la fin de ce sprint. On appelle « vélocité » le nombre de user story points qu’une équipe est capable de réaliser par sprints.

# N° User Stories U.S.Pts
0001 En tant qu’utilisateur, j’ai accès à un site via une URL donnée. 1
0004 En tant qu’utilisateur, je peux m’identifier sur le site et obtenir un profil spécifique. 3
0002 En tant qu’utilisateur connecté, je peux modifier mon mot de passe. 2

Les user story points sont reportés sur les différents post-it définissant les user stories afin de toujours avoir à l’esprit leurs poids les unes par rapports aux autres.

[Haut de page]

Artefact #2 : Le Backlog de sprint

Le « Sprint Backlog » (ou backlog de sprint) est constitué des user stories qui ont été sélectionnées et estimées lors du « Sprint Planning ». Mais pour le backlog de sprint, nous allons plus loin. Ces user stories aussi sont découpées en petites tâches indivisibles (métier ou non) et elles sont estimés en heures.

Ces tâches ne sont pas tout de suite réparties au sein de l’équipe, chaque membre, selon son envie, son humeur va décider avec les autres de ce qu’il souhaite faire au fur et à mesure. Tous les jours, le backlog de sprint est remis à jour par le scrum master au cours des « Daily Scrum ».

#0001 – En tant qu’utilisateur, j’ai accès à un site via une URL donnée. – 1 USP
# N° Tâches Durée (h)
0001-01 Demander à Roland (l’administrateur réseau) de créer le DNS, et le faire pointer sur le bon répertoire … 0.5
0001-02 Créer une ébauche de page d’accueil pour notre site 0.5
0001-03 Publier la page dans le site d’exploitation 0.5
0001-04 Tester le bon fonctionnement 0.5
#0004 – En tant qu’utilisateur, je peux m’identifier sur le site et obtenir un profil spécifique. – 3 USP
# N° Tâches Durée (h)
0004-01 Définir la structure de la base de données 2
0004-02 Créer la base de données 1
0004-01 Créer le formulaire 1.5
0004-04 Implémenter les requêtes liant le formulaire à la base de données 0.5
0004-05 Tester le bon fonctionnement 1
#0002 – En tant qu’utilisateur connecté, je peux modifier mon mot de passe. – 2 USP
# N° Tâches Durée (h)
0002-01 Créer le formulaire 2
0002-02 Implémenter les requêtes liant le formulaire à la base de données 0.5
0002-03 Tester le bon fonctionnement 1.5

Ces tâches et leurs estimations en heure sont reportées sur des post-it d’une autre couleur. Elles sont placées sous la user story auxquelles elles appartiennent.

[Haut de page]

Réunion #2 : Les scrums au quotidien

Le daily scrum se fait à chaque début de journée. Il doit durer au maximum 15 minutes. Cette réunion se déroule face au mur portant les user stories, ce qui permet d’avoir un œil sur le sprint en cours. Tous les participants directs (directeur de produit, équipe et scrum master), debout afin que la réunion ne s’éternise pas, vont répondre tour à tour aux questions suivantes :

  • Qu’est-ce que j’ai fait hier ?
  • Quels sont les problèmes que je rencontre ou que j’ai résolus ?
  • Qu’est-ce que je vais faire aujourd’hui ?

Ceci a pour but de tenir informé tous les participants afin que personne ne s’isole dans son coin. En Scrum, on avance, oui, mais on avance en groupe.

Pour terminer le daily scrum, le backlog de sprint est mis à jour : les tâches terminées sont retirées ou déplacées, les durées mises à jour.

Il est courant de retrouver sur notre mur portant les user stories trois colonnes dans lesquelles nos post-it sont triés : A faire, En cours, Terminés.

Le graphe de charge de travail restant est également mis à jour.

[Haut de page]

Artefact #3 : Le graphe de charge de travail restant

Le graphe de charge de travail restant, ou plutôt la « Sprint Burndown Chart », est une visualisation graphique du temps de travail restant sur le sprint en cours. Il représente le nombre d’heures totales restant à faire au cours du sprint, au jour le jour, et permet ainsi de suivre son bon avancement.

Il existe également la « Release Burndown Chart » qui permet de suivre sprint par sprint le nombre de user story points restant avant la fin du projet. Elle est mise à jour lors de chaque sprint planning. Cependant, ce graphique n’est possible que si toutes les user stories du backlog de produit ont été estimées en user story points.

Ces graphes sont également positionnés sur le mur auprès des post-it.

[Haut de page]

Réunion #3 : Le compte-rendu de sprint

La fin du sprint arrive, c’est l’heure pour l’équipe de faire une démo des user stories réalisées. Tout le monde peut-être invité à cette réunion qui ne doit pas dépasser deux heures … et dont la préparation ne doit pas durer plus de trente minutes. Cette démo a pour but de ne pas s’isoler et de montrer à un maximum de personnes l’avancement du projet. Le directeur de produits va pouvoir valider les user stories terminées. C’est à ce moment là aussi qu’il va pouvoir commencer à remettre en question la priorisation des user stories du backlog de produits. Lors de cette démo, tout le monde peut prendre la parole et ainsi débuter des échanges d’idées et de points de vue. Le dialogue est encore une fois facilité.

Suite à la démo, et à la fin du sprint, l’équipe de développement et son scrum master vont pouvoir débriefer lors de la rétrospective de sprint. Celle-ci vise à tirer des leçons de ce qui s’est passé tout au long du sprint. Chacun tour à tour va répondre aux questions :

  • Quels sont les points positifs me concernant lors de ce sprint ?
  • Quels sont les points négatifs me concernant lors de ce sprint ?
  • Quels sont les points à améliorer qu’ils soient individuels ou collectifs ?

[Haut de page]

En aparté

Scrum implique au cœur du projet le directeur de produit. Ceci permet d’accueillir au mieux les changements pendant la phase de réalisation. Cependant, ceci induit une disponibilité accrue du directeur de produit ce qui n’est pas toujours la chose la plus simple.

Scrum propose, par itérations, ou au jour le jour, plusieurs outils permettant de suivre l’état d’avancement des tâches et plus généralement du projet avec des versions partiellement utilisables. C’est un point positif pour lutter contre le fameux et redouté de plus d’un chef de projet : l’effet tunnel. Pour des projets plus volumineux, il est possible également de gérer des « Release ». Ce sont des successions de Sprint, qui permettent de fournir à leurs termes un produit potentiellement livrable. Ces release sont contrôlées par le directeur de produit et permettent d’avoir un meilleur contrôle sur les dates prévisionnelles.

« Une application opérationnelle, plutôt que de la documentation exhaustive » … c’est l’un des principes de base de Scrum qui malheureusement est souvent mal compris. Scrum ne remet pas en cause la documentation mais plutôt sa manière prédictive de création. En ce sens, il vaut mieux avoir une application qui marche plutôt qu’une documentation complète sans application … Scrum ne donne pas d’indications quant à la réalisation de cette documentation mais le plus souvent, la documentation est rédigée au fur et à mesure de l’avancement du projet de manière incrémentale. Il n’est pas rare de voir des tâches du Sprint spécifiques à la création ou à la modification des documents fonctionnels et techniques, ou même des plans de recette et cas de tests.

Pour conclure, disons que Scrum offre certains avantages, s’emploie sur un large panel de projet mais ne doit pas être employé “à moitié”. Il appartient maintenant à chacun de se faire son propre avis, et de décider si pour tel ou tel projet dans telle et telle circonstance la méthodologie Scrum est adaptée ou non.

[Haut de page]

Références

Pour aller plus loin, vous trouverez une mine d’informations énorme en parcourant les blogs ou sites spécialisés, français ou étrangers, sur le sujet.

Certains prônent cette méthodologie, d’autres la dénigrent. Faites vous votre propre avis, l’important est toujours de comparer de son propre chef.

Je vous laisse quelques sites dont j’ai pu m’inspirer pour écrire cette présentation.

[Haut de page]

Illustration extraite de “Les Rugbymen” de Poupard et Beka

Nombre de vue : 1418

COMMENTAIRES 8 commentaires

  1. […] courte réflexion, vous verrez que l’on les retrouve dans quasiment toutes les cérémonies Scrum (Démo, Chiffrage, Planning poker, Découpage, Rétro, […]

  2. nabeth dit :

    bonjour,

    très bien votre blog, Je débute en scrum et j’ai une question assez simple je pense mais qui demande un éclairage.

    Lors de la construction du backlog j’estime en point la compléxité de la US est dans ce cas il faut passer l’ensemble de tous les fonctionnalité du backlog car comment je peux donner à ma direction une date de fin ??

    de plus pour donner une date de fin il faut une vélocité, lorsque je monte une équipe la vélocité est calculée comment ???

    merci de votre retour

    cordialement

  3. Anthony LHOMME dit :

    Désolé pour mon manque de réactivité en cette jolie fin de Mai 😉

    Ce n’est pas très simple de répondre à cette question.

    A chaud, j’aurai dit impossible.
    En me remettant en question, j’aurai répondu, que c’est lors du Sprint 0, de la planification du projet, ou de la réunion de lancement du projet (appelons là comme on veut) qu’une date prévisionnelle sera définie en tenant compte des expériences de chacun.

    Finalement, ma plus belle réponse sera :
    La date de fin sera celle que le directeur de produit souhaitera.

    Il faudra lister, sélectionner, écarter certaines choses qu’on pourra mettre en place ou non, arbitrer, négocier pour faire rentrer dans période fixe ce qui serait envisageable.

    Ce qui est sûr, c’est qu’à la date visée, il y aura un livrable qui sera apprécié par le directeur de produit.

    Et toc 😉

    En ce qui concerne la vélocité d’une équipe, effectivement, on ne peut la calculer qu’à la fin d’un premier Sprint, et au fil du temps elle sera de plus en plus précise, comme la date à laquelle le projet pourrait prendre fin.
    Ce sera au ScrumMaster d’ajuster son équipe au besoin (si vélocité trop forte ou faible) par rapport au projet. Il pourra par exemple si son budget lui permet acquérir de nouvelles ressources afin d’augmenter la vélocité de l’équipe.

  4. Vanessa dit :

    Merci pour ce travail de synthèse extrêmement bien fait: simple, limpide, efficace! Un très bon overview pour qui ne connaît que la méthode Waterfall!

  5. […] méthode Scrum définit trois rôles distincts : Product Owner, Scrum Master et équipe opérationnelle. Chacun des acteurs s’occupe uniquement […]

  6. DEGBEDJI dit :

    Bonjour,
    Existe t-il une phase de recette fonctionnelle dans la méthodologie SCRUM.
    Il y a t-il besoin d’une AMOA dans la méthodologie SCRUM?
    Les User-Story, est-ce des spécifications?
    Je vous remezrcie par avance pour votre retour.

    Cordialement,

  7. Anthony LHOMME dit :

    Bonjour,

    Scrum ne définit pas d’archétype prédéfini concernant le déroulement du cycle d’un projet.
    si c’était le cas, selon moi, on n’aurait plus cette notion d’agilité.

    Donc pour répondre aux questions :
    1. non, cette une phase à prévoir lors de la création et à planifier dans un Sprint.
    2. Sans rentrer dans les grands débats sur les MOA/AMOA, l’utilité d’une AMOA se fait ressentir, elle ne sera qu’intervenant externe (ne fera pas partie de la Team, mais devra être disponible pour celle ci).
    3. Les users stories ne sont pas des specs, ce sont des tâches à réaliser, qui sont insécables et ne nécessitent pas de specs (mais peuvent être documentés).

AJOUTER UN COMMENTAIRE