Agile

La méthode Scrum (méthode de développement Agile) est un modèle de gestion de projets qui met l’accent sur le travail d’équipe, la responsabilité et l’avancement progressif vers un objectif bien défini. Les trois piliers de la méthode Scrum sont : la transparence, le contrôle et l’adaptation.

Nous recommandons d’utiliser la méthode Scrum si :

  • Les besoins du projet sont amenés à changer et à évoluer

  • Des retours continus sont nécessaires

  • Vous n’avez pas besoin de vous engager sur une date de release fixe

  • L’équipe Projet souhaite être autonome

La méthode Scrum est particulièrement adaptée pour les projets qui comportent beaucoup de points inconnus ou qui évoluent dans le temps. Elle permet de gérer ces évolutions de manière très efficace, afin que vous puissiez facilement intégrer de nouvelles informations ou fonctionnalités tout au long du processus.

Rôles et responsabilités

Une équipe Scrum doit comprendre trois rôles spécifiques et un rôle optionnel :

  • Un Product Owner (responsable produit)

  • Un Scrum Master

  • Une équipe de développement

  • Un client (optionnel)

Ces trois rôles sont égaux et ont tous des responsabilités.

Rôles et responsabilités

Product_Owner.png

Product Owner

Représente le client et l’entreprise

  • Responsable du suivi des besoins

  • Responsable du succès du produit

  • Transmet la vision du produit

  • Définit toutes les fonctionnalités du produit

  • Maintient le Backlog Produit

  • Garantit la collaboration des membres d’équipe dans le cadre des fonctionnalités de haute valeur

Scrum_Master.png

Scrum Master

S’assure que l’équipe a tout ce dont elle a besoin pour livrer de la valeur. Il/elle agit en tant que responsable de service pour l’équipe de développement

  • Est un facilitateur et non un responsable

  • Écarte les obstacles

  • Protège l’équipe des interférences extérieures

  • Est le garant du processus

  • Facilite les différents événements Scrum

Team_Member.png

Équipe de développement

Se concentre sur la livraison du logiciel

L’équipe de développement est multifonctionnelle, autogérée, auto-organisée et dévouée. Cette autonomie est ce qui rend la méthode Scrum si unique. Elle est au cœur même du processus. Grâce à cette approche, les liens entre les membres d’équipe sont solides et il existe un environnement de travail positif où les personnes se sentent responsabilisées dans leur travail.

  • Gère le Backlog de l’itération

  • Assure les réunions quotidiennes Scrum

  • S’assure qu’à la fin de l’itération, une fonctionnalité potentiellement livrable est délivrée

Customer.png

Client

Optionnel (le client peut être le Product Owner)

Lorsque le projet est développé en interne, le client est souvent le Product Owner.

Lorsque le projet est développé en externe, le client est responsable :

  • Du suivi du Backlog produit en :

    • Priorisant les éléments qui doivent être intégrés dans une itération.

    • Ajoutant des éléments à tout moment si nécessaire.

    • Supprimant des éléments, le cas échéant.

  • Testant les résultats et les validant conformément aux critères d’acceptation.

Cycle de vie Scrum

Scrum_Life_Cycle.png

Dans le cadre de la méthode Agile, le projet est rythmé par les itérations. Pour chacune d’entre elles, le Scrum Master et le Product Owner vont mettre en place une proposition concernant son contenu (aussi appelé Backlog de l’itération) en définissant une liste d’éléments du Backlog qui prend en compte des critères tels que la valeur commerciale, les Epics ou la vélocité passée (c’est-à-dire la capacité à livrer des Story Points). Cette étape constitue ce que l’on appelle une réunion de planification d’une itération.

La proposition est ensuite discutée avec les membres d’équipe. Les estimations des Story Points sont examinées afin que l’équipe puisse éventuellement s’engager sur la livraison du Backlog de l’itération. Il existe différentes manières de diriger cette réunion, comme par exemple la technique du Planning Poker.

Lors d’une itération, l’équipe se réunit tous les jours pendant une courte période (réunions quotidiennes Scrum) pour discuter des avancées mais également des problèmes ou des difficultés techniques rencontrés.

À la fin de l’itération, tous les éléments terminés doivent être prêts à être livrés (dans le cadre de la release). Une réunion post-mortem peut être organisée pour discuter des difficultés rencontrées au cours de l’itération, examiner la vélocité et apporter des améliorations pour la prochaine itération.

Backlog du produit

Le Backlog du produit établit la liste de toutes les caractéristiques, fonctionnalités, exigences, améliorations et corrections qui composent les modifications devant être apportées au produit pour les futures mises à jour. Il remplace les exigences en matière de spécifications fonctionnelles de la méthode Waterfall.

Le Backlog du produit présente les caractéristiques suivantes :

  • Chaque élément doit apporter une valeur ajoutée pour le client.

  • Des changements peuvent se produire tout au long du projet.

  • Les activités les moins complexes ne doivent pas être décrites.

  • Chaque élément doit être classé par ordre de priorité afin d’organiser le Backlog du produit.

  • Tous les éléments sont normalement évalués en termes de Story Points.

Le Backlog du produit doit être actualisé de manière continue par le Product Owner.

Éléments du Backlog

Le Backlog du produit est composé d’éléments du Backlog.

Un élément du Backlog est une unité de travail réalisable par l’équipe en une itération. Les éléments du Backlog sont divisés en une ou plusieurs activités.

Lorsqu’ils sont intégrés au Backlog du produit, les éléments du Backlog peuvent être axés sur l’utilisateur. Ils seront alors rédigés sous la forme de user stories.

Une User Story est la définition très détaillée d’une exigence. Elle contient suffisamment d’informations pour que les développeurs puissent donner une estimation réaliste de la charge de travail nécessaire à sa réalisation. Une User Story décrit l’élément de la fonctionnalité du point de vue de l’utilisateur et exprimé de manière concrète et concise. Elle reflète les besoins d’une catégorie particulière d’utilisateurs et leur intérêt. Son format est très simple et facile à utiliser.

« En tant que <catégorie particulière d’utilisateurs>, je veux <être en mesure d’exécuter/de faire quelque chose> de façon à ce que <je puisse en tirer une certaine forme de valeur ou d’avantage> »

Example of a Product Backlog – User Centric

Cependant, la rédaction de User stories n’est pas obligatoire. Vous pouvez également saisir quelques mots clés ou phrases courtes pour les éléments du Backlog, à condition qu’ils puissent être compris par l’équipe Projet et les intervenants.

Key_words.png

Planning de l’itération

Le Product Owner, le Scrum Master et l’ensemble de l’équipe Projet assistent à la réunion de planning des itérations. Des intervenants extérieurs peuvent y assister sur invitation de l’équipe, bien que cela soit rare dans la plupart des entreprises.

Lors de cette réunion, le Product Owner décrit à l’équipe les fonctionnalités jugées prioritaires afin de définir l’objectif de l’itération. Ils déterminent ensuite les éléments du Backlog sur lesquels ils travailleront durant cette itération après les avoir hiérarchisés et estimés.

Itérations

Une itération est la phase donnée d’un cycle de développement continu. Dans le cadre d’une itération, la quantité de travail prévue doit être achevée par l’équipe et soumise à évaluation. Cette notion est principalement utilisée dans la méthode Scrum. Dans une approche Agile, le terme générique utilisé est Itération (c’est également ce terme qui est utilisé dans Sciforma).

La durée moyenne d’une itération se situe généralement entre 2 et 4 semaines.

Estimations du travail

Lorsque la méthode Scrum est utilisée, les estimations de travail ne sont pas faites en heures mais en Story Points.

Les Story Points sont une unité de mesure permettant de donner une estimation de la charge globale nécessaire à la réalisation complète d’un élément du Backlog ou de tout autre élément de travail. Une valeur en points est affectée à chaque élément du Backlog lors d’une estimation en Story Points.

Il est fréquent d’utiliser des échelles comme celles qui suivent pour permettre une estimation des Story Points :

  • Les nombres de la suite de Fibonacci (0, 5, 1, 2, 3, 5, 8, 13, 21…)

  • Les nombres de la séquence linéaire (1, 2, 3, 4, 5, 6, 7, 8…). Il s’agit de celle utilisée par Sciforma.

Cet exercice doit être réalisé collectivement ; certaines entreprises utilisent donc des méthodes telles que la technique du Planning Poker.

  1. Le Product Owner présente les éléments du Backlog qui doivent être estimés. Les membres d’équipe posent des questions et le Product Owner leur donne plus de précisions.

  2. Chaque membre d’équipe recevant un jeu de cartes choisit de manière confidentielle la carte représentant l’estimation.

  3. Lorsque tous les membres d’équipe ont fait leurs estimations, ils révèlent simultanément leurs cartes. Si toutes les estimations sont identiques, un nouvel élément du Backlog est sélectionné et le même processus est appliqué. Si les estimations diffèrent, les membres d’équipe en débattent pour trouver un compromis.

Vélocité de l’équipe

Une fois que les éléments du Backlog ont été estimés, les Story Points doivent être comparés à la vélocité de l’équipe.

La vélocité de l’équipe est basée sur les Story Points effectivement terminés et qui correspondent généralement à la moyenne de toutes les itérations précédentes. Elle est utilisée pour planifier le nombre d’éléments du Backlog que l’équipe peut planifier et réaliser lors de la prochaine itération.

Cependant, pour savoir quels éléments du Backlog peuvent être pris en compte lors de la prochaine itération, il est nécessaire de prendre en compte la capacité de l’équipe Projet. La capacité correspond à la disponibilité de l’équipe pour l’itération. Elle peut donc varier si des membres d’équipe sont en vacances, malades, etc.

Résultat du planning des itérations

Le résultat du planning des itérations correspond au Backlog des itérations.

Backlog de l’itération

Le Backlog de l’itération un sous-ensemble du Backlog produit. Le Backlog de l’itération est issu du Backlog du produit et comprend les éléments du Backlog qui peuvent être terminés au cours de l’itération.

Contrairement au Backlog du produit, le Backlog de l’itération ne change pas pendant toute la durée de l’itération. En effet, les éléments du Backlog et les étapes nécessaires à leur réalisation sont figés à la fin de la planification pour toute la durée de l’itération. Si certains éléments du Backlog ne sont pas terminés à la fin de l’itération, ils seront ajoutés au Backlog du produit et traités lors de la prochaine itération.

Au plus haut niveau, un projet peut débuter par des Épics, des thèmes ou des fonctionnalités qui sont ensuite divisés en éléments du Backlog.

Les activités sont utilisées pour diviser encore plus les éléments du Backlog, lorsque cela est nécessaire. Elles constituent la plus petite unité utilisée dans le suivi du travail. Une activité doit être réalisée par une seule personne au sein de l’équipe. En général, plusieurs activités sont associées à un élément du Backlog. L’équipe étant interfonctionnelle, le fait de définir des activités pour un même élément du Backlog permet aux membres d’équipe de travailler simultanément en fonction de leur domaine de spécialisation afin de terminer l’élément collectivement.

Ainsi, diviser les éléments du Backlog en activités aide l’équipe à déterminer la manière dont elle va aborder le travail à réaliser. Les éventuelles incertitudes seront révélées grâce à ce niveau de détail.

Réunion quotidienne Scrum

L’objectif des réunions quotidiennes Scrum (aussi appelées Daily Stand-up Meetings) est de rapidement informer tout le monde de ce qui se passe au sein de l’équipe. La réunion, dont le temps est limité à 15 minutes, est menée par le Scrum Master qui pose 3 questions à chaque membre d’équipe.

Qu’avez-vous fait hier ?

Le Scrum Master cherche à savoir quelles activités sont « terminées » et si les activités en cours seront terminées à temps. Si les estimations sont allongées ou si de nouvelles activités sont identifiées, le burndown chart sera modifié.

Qu’allez-vous faire aujourd’hui ?

Cette question remplace les diagrammes de GANTT. Les dépendances changent constamment. Répondre à cette question permet de revoir quotidiennement la stratégie du projet en réorientant l’équipe en fonction des évolutions des dépendances révélées par la question précédente.

Existe-t-il des éléments bloquants ou des obstacles qui vous empêchent de faire votre travail ?

La conséquence la plus importante de cette question est de dresser une liste des obstacles affectés à l’équipe ou remontés. Le Scrum Master a pour responsabilité majeure de gérer, hiérarchiser et s’assurer que cette liste d’obstacles soit supprimée.

Tableau des activités

Le tableau des activités est un support permettant de visualiser l’avancement de l’équipe Projet au cours d’une itération. Il présente une capture du Backlog de l’itération en cours et permet à chacun de savoir quelles activités et quels éléments du Backlog doivent encore être commencés, ceux qui sont en cours et ceux qui sont terminés.

Le tableau des activités est mis à jour tous les jours lors de la réunion quotidienne Scrum.

Task_board.png

Burndown Chart

Un Burndown chart est la représentation graphique du travail restant à effectuer par rapport au délai.

Burndown_Chart.png

L’axe X du graphique représente toujours le délai (généralement en jours).

L'axe Y représente le travail restant à faire au cours de l’itération. Ce travail peut être représenté par les activités restantes (en nombre d’activités) ou la charge restante (en Story Points/heures).

La ligne d’avancement montre comment votre équipe progresse par rapport à l’itération. Elle est mise à jour chaque jour grâce aux nouvelles estimations restantes. Au fur et à mesure que l’itération progresse, cette ligne indique si votre équipe est dans les temps et si des actions correctives sont nécessaires.

Le repère est une ligne diagonale orientée vers le bas et allant de gauche à droite sur le graphique. La ligne d’avancement de votre itération doit être aussi proche que possible du repère. Si votre équipe est capable de terminer toutes les stories à un rythme régulier tout au long de l’itération, votre ligne d’avancement suivra parfaitement le repère.

Si la ligne d’avancement de l’itération est située au-dessus du repère, cela signifie que l’équipe Projet est en retard sur le planning et que le travail effectué à ce stade aurait dû être plus important.

Si la ligne d’avancement de l’itération et le repère sont proches, cela signifie que l’équipe projet terminera tout le travail si sa vélocité est maintenue.

Si la ligne d’avancement de l’itération est située au-dessous du repère, cela signifie que l’équipe Projet est en avance sur le planning et devrait terminer tout le travail avant la fin de l’itération. Dans ce cas, de nouveaux éléments du Backlog peuvent être ajoutés à l’itération afin de s’assurer que l’équipe Projet sera occupée jusqu’à la fin de l’itération.

Bonus

Un bonus est un élément du Backlog ne faisant pas partie des engagements de l’équipe dans le cadre d’une itération. Cependant, il s’agit d’un élément marqué comme pouvant être effectué par les membres d’équipe s’ils terminent leur travail plus tôt que prévu.

Réunion d’examen de l’itération

Au terme de l’itération, le Product Owner invite l’équipe Projet et les principaux intervenants à la réunion d’examen de l’itération. Lors de cette réunion, le résultat est examiné au moyen d’une démonstration afin que chacun puisse donner son avis sur le travail effectué.

Le but de la réunion n’est pas de faire un point sur la situation ou une présentation aux intervenants, mais de rassembler et traiter les commentaires sur le résultat de l’incrément.

Le déroulement typique d’une réunion d’examen de l’itération est le suivant :

  • Le Product Owner indique quels éléments du Backlog ont été « terminés » et ceux qui ne le sont pas.

  • L’équipe Projet parle des réussites de l’itération, des problèmes rencontrés et de la manière dont ces problèmes ont été résolus.

  • L’équipe Projet présente le travail qui a été « terminé » et répond aux questions sur l’incrément.

  • Le Product Owner discute du Backlog du produit actuel et, le cas échéant, propose des dates cibles et des dates de livraison en fonction des progrès réalisés à ce stade.

  • L’ensemble du groupe décide de ce qui doit se passer ensuite. Ainsi, l’examen de l’itération fournit des informations utiles pour les Backlogs de l’itération suivante.

Analyse rétrospective de l’itération

L’analyse rétrospective de l’itération a lieu après l’examen de l’itération et avant la planification de la prochaine itération. L’équipe Projet, le Scrum Master et le Product Owner y participent ; cette réunion est l’occasion de discuter de l’itération qui vient d’être livrée.

Son objectif est de permettre aux membres d’équipe de discuter entre eux de la façon dont le travail s’est déroulé au cours de la dernière itération, dans le but de trouver de meilleures façons d’atteindre les objectifs du projet et d’améliorer leur productivité. Tous les membres discutent des échecs, des améliorations futures et conservent une trace des retours d’expérience.

L’analyse rétrospective de l’itération peut être comparée à la réunion post-mortem de la méthodologie Waterfall. Cependant, elle a lieu à la fin de chaque itération et non à la fin du projet, ce qui permet d’ajuster le processus plus fréquemment et de réaliser de petites améliorations de manière régulière.

Quelle est la meilleure organisation lorsqu’on utilise la méthode Agile ?

Une organisation Agile est une organisation qui réagit rapidement aux évolutions du marché ou de l’environnement. Une organisation très agile réagit avec succès à l’émergence de nouveaux concurrents, aux progrès rapides de la technologie et aux changements soudains des conditions générales du marché.

Qu’est-ce qui n’est pas une équipe Agile ?

Une équipe Agile n’est pas uniquement une équipe Projet composée de différentes personnes provenant de différents secteurs de l’entreprise, comme un groupe de travail.

Une équipe Agile n’est pas uniquement composée de développeurs. Elle n’est pas non plus une équipe de type matrice.

Qu’est-ce qu’une équipe Agile ?

Une équipe Agile est un groupe interfonctionnel de personnes et est autonome, à tel point que les membres du groupe peuvent livrer le produit (ou l’itération suivante) sans avoir besoin de faire appel à des compétences extérieures au groupe.

Agile_Team.png

Une équipe Agile est un groupe de personnes dévouées qui ne changent pas de produit ou d’équipe simplement parce qu’un autre projet est plus prioritaire.

Une équipe Agile est auto-organisée. Elle a donc la responsabilité et la compétence pour créer une structure d’équipe interne et fonctionnelle en remplaçant, reformant ou réorganisant les membres de l’équipe selon les besoins.

Une équipe Agile est autogérée. Les membres d’équipe sont responsables de la planification, de l’exécution, du suivi et de la gestion de leurs activités avec une supervision réduite ou inexistante.

Il est important de rappeler que la méthode Agile correspond à une approche et un état d’esprit qui s’adaptent. C’est à chaque entreprise d’adapter son organisation de manière à ce qu’elle fonctionne pour ses projets.

Modèle de données Sciforma

Le modèle de données Sciforma a été mis en œuvre pour répondre aux besoins et aux exigences des clients.

Sciforma_Data_Model.png

Les Stories, Anomalies, Activités et Problèmes sont tous gérés comme des éléments du Backlog.

L’avancement du projet s’en trouvera facilité, notamment lorsque vous utiliserez le tableau des activités, car tous les éléments du Backlog sont gérés au même niveau.

De plus, les éléments du Backlog peuvent avoir une liste des éléments de la check-list qui leur est attachée. Ces éléments peuvent être convertis en activités. Si tel est le cas, une connexion sera créée entre l’élément du Backlog et la nouvelle activité.