Scrum est le plus connu des frameworks agiles. Il est à l'origine d'une grande partie de la réflexion sur les valeurs et les principes du Manifeste Agile, qui constituent une base commune à toutes ces approches. Les valeurs du Manifeste Agile s'appliquent directement à Scrum :
Les individus et les interactions plutôt que les processus et les outils.
Scrum, comme tous les frameworks et méthodes agiles, repose directement sur la confiance dans les équipes, les individus qui les composent et la manière dont ils interagissent. Les équipes déterminent ce qui doit être fait, les équipes déterminent comment le faire et les équipes le font. Les équipes identifient les obstacles qui se dressent sur leur chemin et prennent la responsabilité de résoudre toutes les difficultés qui se trouvent dans leur champ d'action. Les équipes travaillent avec d'autres parties de l'organisation pour résoudre les problèmes qui échappent à leur contrôle. Ce point est essentiel. Si vous essayez de mettre en œuvre Scrum tout en mettant de côté l'accent mis sur la responsabilité de l'équipe, vous aurez généralement des problèmes.
Un logiciel fonctionnel plutôt qu'une documentation complète.
Scrum exige un incrément fonctionnel et fini du produit comme résultat principal de chaque sprint. Il y aura certainement des travaux d'analyse, de conception et de test, qui devront tous être documentés. Mais c'est le logiciel fonctionnel qui permet à l'organisation de guider le projet vers le succès. Ce point est essentiel. Les équipes Scrum doivent produire un incrément de produit à chaque Sprint.
La collaboration avec le client prime sur la négociation du contrat.
Le Product Owner de Scrum est le principal point de contact de l'équipe Scrum avec les utilisateurs finaux éventuels du produit et avec les parties de l'organisation qui ont besoin du produit. Le Product Owner est un membre de l'équipe et travaille en collaboration avec l'équipe pour déterminer ce qui doit être fait. Dans cette collaboration, le Product Owner sélectionne les prochaines choses à faire qui ont le plus de valeur, en s'assurant que le produit a la plus grande valeur possible à chaque moment. C'est essentiel. Le Product Owner doit construire une collaboration riche avec son équipe.
Réagir au changement plutôt que de suivre un plan.
Tout ce qui concerne Scrum est conçu pour s'assurer que chacun dispose des informations dont il a besoin pour prendre de bonnes décisions concernant le projet. L'avancement du projet est représenté par un incrément de produit réel, en cours d'exécution. Le backlog des choses à faire est disponible pour tous. L'avancement, tant global que sprint par sprint, est clairement visible. Les problèmes et les préoccupations sont discutés ouvertement et traités immédiatement. Ce point est essentiel. Scrum fonctionne bien pour les équipes qui "inspectent" ouvertement ce qui se passe et "adaptent" leurs actions à la réalité. Il fonctionne mal pour celles qui ne le font pas.
Tout travail effectué dans Scrum nécessite une base solide de valeurs pour servir de fondement au processus et aux principes de l'équipe. Grâce au travail d'équipe et à l'amélioration continue, Scrum crée ces valeurs et s'appuie sur elles. Les valeurs sont les suivantes : Concentration, Courage, Ouverture, Engagement et Respect.
- Concentration. Parce que nous nous concentrons sur quelques éléments à la fois, nous travaillons bien ensemble et produisons un excellent travail. Nous livrons les articles de valeur plus rapidement.
- Courage. Parce que nous ne sommes pas seuls, nous nous sentons soutenus et disposons de plus de ressources. Cela nous donne le courage de relever de plus grands défis.
- Ouverture. En travaillant ensemble, nous nous exerçons à exprimer ce que nous faisons et ce qui nous gêne. Nous apprenons qu'il est bon d'exprimer ses préoccupations, afin qu'elles soient prises en compte.
- L'engagement. Parce que nous avons un grand contrôle sur notre propre destin, nous nous engageons davantage à réussir.
- Le respect. En travaillant ensemble, en partageant nos succès et nos échecs, nous en venons à nous respecter mutuellement et à nous aider à devenir dignes de respect. Si une organisation laisse Scrum faire son travail, elle découvrira les avantages de Scrum et commencera à comprendre pourquoi ces valeurs sont à la fois nécessaires à Scrum et engendrées par Scrum.
Scrum est un framework pour la construction d'un produit. Scrum commence lorsque certaines parties prenantes ont besoin d'un produit.
Scrum est un processus d'équipe. L'équipe Scrum comprend trois rôles, le propriétaire du produit, le ScrumMaster et les membres de l'équipe de développement. Le propriétaire du produit a la responsabilité de décider du travail à effectuer. Le ScrumMaster agit en tant que leader servant, aidant l'équipe et l'organisation à faire le meilleur usage de Scrum. L'équipe de développement construit le produit de manière incrémentielle, en une série de courtes périodes de temps appelées Sprints. Un Sprint est une période de temps fixe, de une à quatre semaines, avec une préférence pour les intervalles plus courts. Dans chaque sprint, l'équipe Scrum construit et livre un incrément de produit. Chaque incrément est un sous-ensemble reconnaissable, visiblement amélioré et opérationnel du produit, répondant aux critères d'acceptation compris et construit à un niveau de qualité appelé la définition de l'achèvement.
Scrum comprend trois artefacts essentiels, le Backlog de produit, le Backlog de sprint et l'incrément de produit. Le Backlog de produit est la liste ordonnée des idées pour le produit, conservée dans l'ordre où nous prévoyons de les construire. Le Sprint Backlog est le plan détaillé du développement du prochain Sprint. L'incrément de produit est un résultat obligatoire de chaque sprint. Il s'agit d'une version intégrée du produit, maintenue à un niveau de qualité suffisamment élevé pour pouvoir être expédiée si le propriétaire du produit choisit de le faire. En plus de ces artefacts, Scrum exige la transparence au sein de l'équipe et avec les parties prenantes. À ce titre, l'équipe Scrum produit des affichages visibles des plans et des progrès.
Scrum comprend cinq activités ou réunions. Il s'agit de l'affinement du carnet de produit, de la planification du sprint, de la mêlée quotidienne, de la revue du sprint et de la rétrospective du sprint.
Nous décrirons ci-dessous les rôles, les artefacts et les activités, ainsi que le déroulement du cycle Scrum.
Le Product Owner est l'unique personne responsable de l'élaboration du produit le plus valable possible à la date souhaitée. Pour ce faire, il gère le flux de travail dans l'équipe, sélectionne et affine les éléments du carnet de produit. Le Product Owner tient à jour le Product Backlog et veille à ce que chacun sache ce qu'il contient et quelles sont les priorités. Le Product Owner peut être assisté par d'autres personnes mais doit être une seule personne.
Il est certain que le Product Owner n'est pas le seul responsable de tout. L'ensemble de l'équipe Scrum est responsable d'être aussi productive que possible, d'améliorer ses pratiques, de poser les bonnes questions, d'aider le Product Owner, etc. L'équipe de développement est responsable de la détermination de la quantité de travail à effectuer dans un sprint et de la production d'un incrément de produit utilisable dans chaque sprint.
Néanmoins, le Product Owner, dans Scrum, est dans une position unique. Le Product Owner est généralement la personne la plus proche du "business" du projet. Le Product Owner est généralement chargé par l'organisation de "sortir ce produit", et est généralement la personne qui est censée faire le meilleur travail possible pour satisfaire toutes les parties prenantes. Le propriétaire du produit s'acquitte de cette tâche en gérant le backlog de produit et en veillant à ce que le backlog de produit et les progrès réalisés par rapport à celui-ci soient visibles.
En choisissant ce que l'équipe de développement doit faire ensuite et ce qui doit être reporté, le propriétaire du produit prend les décisions relatives à la portée et au calendrier qui mèneront au meilleur produit possible.
L'équipe de développement est composée de professionnels qui effectuent le travail de livraison de l'incrément de produit. Ils s'organisent eux-mêmes pour accomplir leur travail. Les membres de l'équipe de développement doivent être disponibles à temps plein pour le projet.
Scrum exige que l'équipe de développement soit un groupe interfonctionnel de personnes qui, parmi elles, possèdent toutes les compétences nécessaires pour livrer chaque incrément du produit.
Les membres de l'équipe de développement ont la responsabilité de s'auto-organiser pour atteindre l'objectif du sprint, en produisant chaque nouvel incrément de produit conformément à chaque plan de sprint.
Le Product Owner établit une liste ordonnée de ce qui doit être fait. Les membres de l'équipe de développement prévoient ce qu'ils peuvent faire en un seul sprint et décident de la manière dont ils vont le faire.
Le ScrumMaster est un "servant leader", qui aide le reste de l'équipe Scrum à suivre son processus. Le ScrumMaster doit avoir une bonne compréhension du cadre Scrum et la capacité de former les autres à ses subtilités.
Le ScrumMaster travaille avec le Product Owner pour l'aider à comprendre comment créer et maintenir le Backlog de produit. Il travaille avec l'équipe de développement pour trouver et mettre en œuvre les pratiques techniques qui leur permettront d'arriver à leurs fins à la fin de chaque sprint. Il travaille avec l'ensemble de l'équipe Scrum pour faire évoluer la définition de "Done".
Une autre responsabilité du ScrumMaster est de veiller à ce que les obstacles à la progression de l'équipe soient supprimés. Ces obstacles peuvent être externes à l'équipe, comme un manque de soutien de la part d'une autre équipe, ou internes, comme le Product Owner qui ne sait pas comment préparer correctement le Product Backlog.
Le ScrumMaster favorise l'auto-organisation. Les problèmes doivent être éliminés par l'équipe dans la mesure du possible.
Le ScrumMaster agit comme un coach pour l'équipe Scrum, en les aidant à exécuter le processus Scrum. Il les aide à travailler ensemble et à apprendre le Scrum Framework, et les protège des distractions internes et externes. Il peut animer des réunions et contribuer à maintenir l'équipe Scrum sur la bonne voie, à la rendre productive et à la faire progresser.
Le ScrumMaster est chargé de veiller à ce que Scrum soit compris et mis en place, au sein de l'équipe et à l'extérieur. Il aide les personnes extérieures à l'équipe à comprendre le processus, et à comprendre quelles interactions avec l'équipe sont utiles et lesquelles ne le sont pas. Le ScrumMaster aide tout le monde à s'améliorer pour rendre l'équipe Scrum plus productive et plus utile.
Le carnet de produit est un artefact essentiel de Scrum. Le Backlog de produit est une liste ordonnée d'idées pour le produit, conservées dans l'ordre où nous prévoyons de les réaliser. C'est la source unique d'où découlent toutes les exigences. Cela signifie que tout le travail effectué par l'équipe de développement provient du Backlog de produit. Chaque idée de fonctionnalité, d'amélioration, de correction de bogue, d'exigence de documentation - chaque partie du travail qu'ils font - est dérivée d'un élément du Backlog de produit. Chaque élément du carnet de produit comprend une description et une estimation.
Le Product Backlog peut commencer par une liste longue ou courte. Il peut être vague ou plutôt détaillé. En général, il commence court et vague et devient plus long et plus concret au fil du temps. Les éléments du Product Backlog devant être mis en œuvre prochainement seront "affinés" : clarifiés, mieux définis, divisés en plus petits morceaux, dans le Framework de l'activité Product Backlog Refinement.
Le Product Owner est responsable et comptable de la mise à jour du Product Backlog, même s'il peut - et doit - se faire aider pour le produire et le tenir à jour. Les éléments du carnet de produit peuvent provenir du propriétaire du produit, des membres de l'équipe ou d'autres parties prenantes.
Étant donné que les éléments du carnet de produit sont souvent vastes et de nature générale, que les idées vont et viennent et que les priorités changent, l'affinement du carnet de produit est une activité permanente tout au long d'un projet Scrum. Cette activité comprend, sans s'y limiter, les éléments suivants
- maintenir l'ordre dans le Backlog de produit ;
- supprimer ou rétrograder les éléments qui ne semblent plus importants ;
- l'ajout ou la promotion d'éléments qui apparaissent ou deviennent plus importants ; - la division d'éléments en éléments plus petits ;
- la fusion d'éléments en éléments plus importants ;
- l'estimation des éléments.
L'un des principaux avantages de l'activité d'affinement du carnet de produits est de préparer les prochains sprints. À cette fin, l'activité d'affinement accorde une attention particulière à la préparation des éléments à mettre en œuvre. Il y a beaucoup de choses à prendre en compte, y compris mais sans s'y limiter :
- Chaque élément entrant dans le Sprint devrait idéalement représenter un incrément de "valeur commerciale".
- L'équipe de développement doit être capable de construire chaque élément au cours d'un seul sprint.
- Tout le monde doit être clair sur ce qui est prévu.
Selon la nature du produit, d'autres compétences et contributions peuvent être nécessaires. Dans tous les cas, il est préférable de considérer l'affinement du Backlog de produit comme une activité pour tous les membres de l'équipe, et pas seulement pour le Product Owner.
Chaque sprint commence par une réunion limitée dans le temps appelée planification du sprint. Au cours de cette réunion, l'équipe Scrum collabore pour sélectionner et comprendre le travail à effectuer dans le sprint à venir.
Toute l'équipe assiste à la réunion de planification du sprint. En travaillant à partir du Backlog de produit ordonné, le Product Owner et les membres de l'équipe de développement discutent de chaque élément et parviennent à une compréhension commune de cet élément et de ce qui est nécessaire pour l'achever conformément à la définition actuelle de "Done". Toutes les réunions Scrum sont limitées dans le temps. Le temps recommandé pour la réunion de planification du sprint est de deux heures ou moins par semaine de la durée du sprint. Comme la réunion est limitée dans le temps, le succès de la réunion de planification du sprint dépend fortement de la qualité du backlog de produit. C'est pourquoi l'affinement du Backlog de produit est une activité importante de Scrum.
Dans Scrum, la réunion de planification du sprint est décrite comme ayant deux parties :
1. Déterminer le travail qui sera réalisé au cours du sprint ;
2. Déterminer comment le travail sera accompli.
Dans la première partie de la réunion, le Product Owner présente les éléments du Product Backlog commandés à l'équipe de développement, et toute l'équipe Scrum collabore pour comprendre le travail.
Le nombre d'éléments du Backlog de produit à réaliser au cours du Sprint dépend uniquement de l'équipe de développement. Pour décider du nombre d'éléments à entreprendre, l'équipe de développement prend en compte l'état actuel de l'incrément de produit, les performances passées de l'équipe, la capacité actuelle de l'équipe et le Backlog de produit commandé. L'équipe de développement décide seule de la quantité de travail à entreprendre. Ni le Product Owner, ni aucun autre organisme, ne peut imposer plus de travail à l'équipe de développement.
Souvent, mais pas toujours, un objectif est fixé pour le sprint, appelé objectif du sprint. Il s'agit d'une pratique très forte qui aide tout le monde à se concentrer davantage sur l'essence de ce qui doit être fait, et moins sur les petits détails qui peuvent ne pas être importants pour ce que nous devons vraiment accomplir.
Dans la deuxième partie de la réunion, l'équipe de développement collabore pour décider comment produire le prochain incrément de produit en accord avec la définition actuelle de ce qui est fait. Ils font suffisamment de conception et de planification pour être sûrs de terminer le travail pendant le Sprint. Le travail à effectuer dans les premiers jours est divisé en petites unités d'un jour ou moins. Le travail à faire plus tard peut être laissé dans des unités plus grandes qui seront décomposées plus tard.
Il incombe à l'équipe de développement de décider de la manière de réaliser le travail, tout comme il incombe au propriétaire du produit de décider de ce qu'il faut faire.
Le Product Owner peut rester pendant cette partie de la réunion, pour répondre aux questions et résoudre les malentendus. Dans tous les cas, il doit être facilement disponible.
La planification du sprint se termine lorsque l'équipe de développement arrive à une compréhension commune de la quantité et de la complexité de ce qui doit être accompli pendant le sprint, et dans un éventail rationnel de circonstances, s'attend à le terminer. L'équipe de développement prévoit la quantité de travail qu'elle va accomplir et s'engage les uns envers les autres à l'accomplir.
En résumé, lors de la réunion de planification du sprint, l'équipe de développement
- considère et discute des éléments du Backlog de produit avec le Product Owner, - s'assure qu'elle les comprend,
- sélectionne un certain nombre d'éléments qu'elle pense pouvoir réaliser, - et crée un plan suffisamment détaillé pour être sûre de pouvoir réaliser ces éléments.
La liste des choses à faire qui en résulte est le "Sprint Backlog".
Le Sprint Backlog est la liste des éléments raffinés du Product Backlog choisis pour être développés dans le Sprint en cours, ainsi que le plan de l'équipe pour accomplir le travail. Il reflète les prévisions de l'équipe quant au travail qui peut être accompli.
Une fois le Sprint Backlog en place, le Sprint commence et l'équipe de développement développe le nouvel incrément de produit défini par le Sprint Backlog.
Pendant le sprint, l'équipe de développement s'organise pour produire un incrément de produit en accord avec le backlog du sprint, tel que déterminé pendant la planification du sprint. L'auto-organisation signifie que l'équipe produit de manière responsable l'incrément de produit en accord avec toutes les normes de l'organisation, selon la définition de "Done", et que l'équipe de développement détermine comment s'y prendre.
L'artefact Scrum le plus important est l'incrément de produit. Chaque sprint produit un incrément de produit. L'incrément de produit doit être d'une qualité suffisante pour être remis aux utilisateurs. L'incrément de produit doit répondre à la définition actuelle de "fait" de l'équipe Scrum, et chaque composant doit être acceptable pour le propriétaire du produit.
Scrum exige la transparence au sein de l'équipe et en dehors de l'équipe. Bien que l'incrément de produit soit le moyen le plus important de créer la transparence, l'équipe Scrum créera tout autre artefact nécessaire pour s'assurer que le statut du projet est compris. Les artefacts supplémentaires les plus courants sont les tableaux de brûlure et les tableaux de tâches.
Lorsque l'incrément de produit est livré, il doit être "terminé" selon une compréhension commune de ce que signifie "terminé". Cette définition est différente pour chaque équipe Scrum, et à mesure que l'équipe mûrit, la définition de ce qui est fait s'élargira et deviendra plus stricte.
La définition de "terminé" doit toujours inclure la notion que l'incrément de produit est d'une qualité suffisante pour être expédiable : le propriétaire du produit pourrait choisir de le publier immédiatement. L'incrément de produit comprend la fonctionnalité de tous les incréments de produit précédents et est entièrement testé afin que tous les éléments du Backlog de produit terminés continuent de fonctionner ensemble.
L'équipe de développement est auto-organisée. L'équipe de développement utilise la réunion quotidienne de Scrum pour s'assurer qu'elle est sur la bonne voie pour atteindre l'objectif du sprint. La réunion a lieu tous les jours à la même heure et au même endroit. Chaque membre de l'équipe de développement donne trois éléments d'information :
- ce que j'ai accompli depuis notre dernière mêlée quotidienne ;
- ce que je prévois d'accomplir d'ici la prochaine mêlée quotidienne ; - ce qui entrave ma progression.
Il peut y avoir de brèves questions et réponses de clarification, mais il n'y a pas de discussion sur aucun de ces sujets pendant la Mêlée quotidienne. Cependant, de nombreuses équipes se réunissent juste après la mêlée quotidienne pour travailler sur les problèmes qui sont apparus.
La mêlée quotidienne n'est pas un rapport à la direction, ni au propriétaire du produit, ni au ScrumMaster. C'est une réunion de communication au sein de l'équipe de développement, pour s'assurer qu'ils sont tous sur la même longueur d'onde. Seuls les membres de l'équipe de développement, y compris le ScrumMaster et le Product Owner, prennent la parole lors de cette réunion. Les autres parties intéressées peuvent venir et écouter. En fonction de ce qui est dit lors de la réunion, l'équipe de développement réorganise le travail si nécessaire pour atteindre l'objectif du sprint.
La mêlée quotidienne est un élément clé de Scrum, qui conduit à la transparence, à la confiance et à de meilleures performances. Elle permet de reconnaître rapidement les problèmes et favorise l'auto-organisation et l'autonomie de l'équipe. Toutes les réunions Scrum sont limitées dans le temps. La durée recommandée pour la réunion quotidienne est de quinze minutes maximum.
À la fin du Sprint, l'équipe de Scrum et les parties prenantes examinent les résultats du Sprint. Toutes les réunions de Scrum sont limitées dans le temps. La durée recommandée pour la revue du sprint est d'une heure par semaine de la durée du sprint.
Le point central de la discussion est l'incrément de produit réalisé pendant le sprint. Comme les parties prenantes sont celles qui ont un "intérêt" dans les résultats, il est généralement sage et utile qu'elles assistent à cette réunion. Il s'agit d'une réunion informelle qui permet de faire le point sur la situation et de collaborer sur la manière d'aller de l'avant. Tout le monde a son mot à dire lors de la revue de sprint. Naturellement, le Product Owner prend les décisions finales concernant l'avenir, en mettant à jour le Product Backlog comme il convient.
Les équipes trouveront leur propre façon de procéder à la revue de sprint. Une démonstration de l'incrément de produit est courante. Le groupe discute souvent de ce qu'il a observé pendant le sprint, des idées de produits qui lui sont venues à l'esprit. Ils discutent de l'état du Backlog de produit et parlent des dates d'achèvement possibles et de ce qui pourrait être fait à ces dates.
La revue du sprint donne à toutes les personnes présentes un aperçu de l'incrément de produit en cours. Dans cette optique, il est courant de mettre à jour le carnet de produit dans le cadre de la revue du sprint.
À la fin de chaque sprint, l'équipe Scrum se réunit pour la rétrospective du sprint. L'objectif est d'examiner comment les choses se sont déroulées en ce qui concerne le processus, les relations entre les personnes et les outils. L'équipe identifie ce qui s'est bien passé et ce qui ne s'est pas bien passé, et identifie les améliorations potentielles. Elle élabore un plan pour améliorer les choses à l'avenir. Toutes les réunions Scrum sont limitées dans le temps. La plage horaire recommandée pour la rétrospective du sprint est d'une heure par semaine de la durée du sprint.
L'équipe Scrum améliore son propre processus, en restant toujours dans le Scrum Framework.
Le cycle Scrum se répète à partir d'ici, pour chaque Sprint.
En résumé, les membres de l'équipe Scrum (le propriétaire du produit, l'équipe de développement et le ScrumMaster) collaborent pour créer une série d'incréments de produit, pendant de courts intervalles de temps appelés Sprints. Chaque incrément répond aux critères d'acceptation du propriétaire du produit et à la "définition de l'achèvement" partagée par l'équipe. Ils travaillent à partir d'un Backlog de produit. Dans chaque Sprint, ils commencent par la planification du Sprint pour produire le Sprint Backlog, un plan pour le Sprint. Ils s'organisent pour effectuer le développement, en utilisant les réunions Scrum quotidiennes pour coordonner et s'assurer qu'ils produisent le meilleur incrément de produit possible. Ils affinent le Backlog de produit pour préparer la réunion de planification du Sprint suivant. Ils terminent le sprint par la revue et la rétrospective du sprint, en examinant le produit et leur processus.
| 28 rue du Chemin Vert 75011 Paris |
|
| contact@50a.fr | |
| 01 40 33 00 65 |
