Nous travaillons avec SCRUM – et nos clients en bénéficient

Le cadre de gestion de projet SCRUM est très populaire dans le secteur IT. 

Dans notre agence de développement Drupal, nous avons décidé d'implémenter SCRUM comme un outil de base pour travailler avec nos clients il y a un certain temps. Dans cet article, vous pouvez en savoir plus sur les tenants et aboutissants de cette approche, ainsi que sur la manière dont elle bénéficie aux deux parties.

SCRUM est très facile à comprendre, mais assez difficile à implémenter correctement. Les termes et concepts tels que Daily, Sprint, Retrospective, Sprint Review et Product Owner ne facilitent pas la tâche à une personne qui n'a jamais eu à faire face à eux auparavant. Cependant, en réalité, SCRUM est basé sur des principes très simples.
Imaginez qu'un client vienne chez Droptica et souhaite commander un site web d'entreprise. La première étape après avoir pris connaissance des attentes du client est de constituer une équipe pour s'occuper de cette tâche particulière.

Sprint – la base de SCRUM

Les équipes chez Droptica travaillent en cycles de travail de deux semaines. En raison de leur courte durée, ceux-ci sont appelés Sprints. Pendant le Sprint, l'équipe se concentre sur la réalisation des objectifs fixés comme objectif du Sprint, qui peut être, par exemple, de concevoir ou d'implémenter une fonctionnalité dans le site web. Il est important que l'objectif reste réaliste et puisse être réalisé dans un seul Sprint. Le processus de mise en œuvre de l'objectif consiste en de petites tâches. Nous essayons de nous assurer que les tâches individuelles prennent peu de temps. Si possible, nous divisons les grandes tâches en plus petites, ce qui nous donne un meilleur contrôle sur l'étendue, et le client peut voir les résultats de notre travail plus rapidement. 

Pourquoi travaillons-nous sur de petites tâches ?

Une petite tâche est celle qu'un membre de l'équipe peut effectuer en quelques heures. Grâce au fait que réaliser une telle tâche prend peu de temps, le nombre de tâches réalisées avec succès en un seul sprint augmente rapidement. Cela permet au client de suivre le développement du projet en continu et lui donne un sentiment de contrôle sur le travail. L'objectif du Sprint est fixé par le Product Owner (une personne représentant le client) en coopération avec l'équipe, sur la base des priorités commerciales.

Le principal avantage de SCRUM est le développement progressif et visible du produit. Le Product Owner a une visibilité sur les progrès et reste en contact constant avec l'équipe. Cela permet aux équipes d'éviter les problèmes survenant dans le cas du modèle Waterfall concurrent, où le client ne voit ce sur quoi les développeurs ont travaillé qu'après de nombreux mois, souvent entraînant déception et coûts élevés puisqu'il doit payer pour le travail effectué.

SCRUM est flexible. Par exemple, au début, nous établissons l'ordre des tâches à réaliser avec le Product Owner. Ces tâches peuvent inclure, par exemple, la mise en place de fonctionnalités de connexion et d'inscription sur leur site web. Cependant, si au cours du projet il s'avère que la page produit est plus importante pour le Product Owner (par exemple, parce qu'ils souhaitent présenter leur offre dès que possible), ils peuvent discuter avec les développeurs et l'établir comme objectif pour le prochain Sprint et, par conséquent, changer les priorités de développement. Le Product Owner et l'équipe travaillent de manière réactive, en réagissant aux circonstances changeantes et en résolvant les problèmes actuels.

Le processus SCRUM est axé sur la livraison continue de fonctionnalités qui apportent une valeur ajoutée à l'entreprise. Le plus souvent, après seulement quelques Sprints, le client peut examiner un projet avancé et le comparer aux hypothèses initiales et aux résultats escomptés. Dans une situation où une partie de la stratégie commerciale est redéfinie, le Product Owner peut apporter des changements significatifs au projet, réorganiser la liste des tâches ou ajouter des tâches nouvelles qui n'étaient pas auparavant considérées comme des objectifs commerciaux, puis supprimer des éléments qui n'ont pas encore été terminés ou simplement les annuler complètement. Grâce à cela, l'équipe poursuit les véritables objectifs commerciaux et ne suit pas aveuglément la spécification technique étendue fournie par le client au tout début du projet – c'était le cas avec le modèle en cascade.

Étant donné le contexte ci-dessus, le client contrôle les coûts et les dépenses, et il a la possibilité de planifier ce sur quoi son argent est dépensé en priorité. En travaillant étroitement avec le client, l'équipe apprend à mieux connaître ses attentes. Les développeurs sont constamment disponibles pour le Product Owner, et grâce à cette relation, le projet est mieux adapté à ces attentes.

D'où viennent les tâches pour l'équipe ?

Les tâches pour l'équipe sont assignées par le Product Owner sur la base des objectifs commerciaux. Une liste générale de toutes les tâches, appelée Backlog, est élaborée conjointement avec les développeurs. Les tâches en attente peuvent être assignées à un Sprint donné, ou elles peuvent attendre leur tour pour être mises en œuvre. Les tâches peuvent également être supprimées du Backlog, ce qui signifie qu'elles sont effectivement abandonnées.

SCRUM et réunions

Dans le cas de SCRUM, l'équipe se réunit lors de réunions, qui se tiennent régulièrement. Pendant ces réunions, les tâches sont assignées individuellement aux membres de l'équipe. Après la planification, les tâches sont exécutées au cours des quatorze jours suivants. L'équipe se réunit chaque matin pour une courte réunion appelée Daily, qui dure au maximum 15 minutes. Pendant le Daily, chaque personne répond à des questions spécifiques : qu'ont-ils fait depuis le dernier Daily ? Que prévoient-ils de faire jusqu'au prochain Daily ? Y a-t-il des obstacles ? Ont-ils besoin d'un soutien de la part des autres membres de l'équipe ? Les réunions rendent la communication et la coopération au sein de l'équipe plus efficaces, permettant à chacun de rester informé et de s'entraider pour atteindre l'objectif du Sprint.
À la fin du Sprint, les résultats sont résumés et les résultats du travail sont présentés. Le Sprint Review est une réunion visant à présenter les progrès réalisés et à recevoir des retours sur les résultats du travail de l'équipe.

Une Rétrospective est une réunion au cours de laquelle l'équipe partage ses retours et commentaires sur le Sprint terminé. Les membres de l'équipe peuvent partager leurs retours concernant le processus et proposer des améliorations pour les futurs Sprints. L'objectif de la Rétrospective est de résumer les meilleures pratiques et d'améliorer les processus qui doivent être affinés dans les prochains Sprints. Chez Droptica, nous voulons que chaque Sprint soit meilleur que le précédent et que l'équipe se développe et s'améliore avec le temps.
Il n'y a pas d'équipes permanentes chez Droptica, car chaque équipe est formée séparément pour travailler sur un projet donné. Parfois elles sont plus petites, parfois elles sont plus grandes. En fin de compte, la nature de l'équipe et sa composition sont déterminées par les attentes du client et leur projet.

Chaque réunion peut être suivie par un Product Owner ; cependant, ils ne doivent pas nécessairement être présents à chaque réunion. Par exemple, durant le Daily, la présence du Product Owner n'est pas nécessaire (mais souhaitable). Le PO peut écouter ce sur quoi l'équipe travaille actuellement. 

Le Product Owner est nécessaire pour la planification (détermination de l'objectif du Sprint) et pendant le Sprint Review (présentation des résultats du Sprint) ; ils ne sont pas nécessairement tenus de prendre part à la Rétrospective (résumé du Sprint), mais ils peuvent y participer s'ils le souhaitent.

SCRUM est un outil idéal pour la construction de projets complexes impliquant de nombreux intervenants. Grâce à sa transparence, il permet à nos clients de voir le processus et ses résultats tout en leur donnant plus de contrôle sur la mise en œuvre de leurs besoins et attentes. C'est aussi un outil important pour économiser et contrôler les budgets, car le client n'a pas à dépenser d'argent sur des fonctionnalités inutiles qui ne sont pas nécessaires pour le moment. En bref, le client paie pour ce dont il a réellement besoin. Cette approche est idéale pour la relation entre nos clients et Droptica, ce qui se traduit par des clients satisfaits, ainsi que par des projets qui sont constamment développés par nos équipes.