Planification des sprints

La planification de sprint est la première étape du sprint Scrum. Il détermine la portée et les façons de faire le travail pendant le sprint. Toute l'équipe Scrum est impliquée dans la planification.

Un sprint est une période de temps clairement définie pendant laquelle un travail spécifique doit être effectué. Un sprint doit être planifié avant de commencer. Tout d'abord, vous devez déterminer la durée et l'objectif du sprint.

Lors de l'atelier de planification, la liste des tâches et l'objectif du sprint sont convenus. Il est important de donner à l'équipe la bonne motivation pour travailler, afin que chaque membre se concentre sur le succès.

Si le sprint est mal planifié, cela peut conduire l'équipe à l'échec. Les développeurs ne pourront pas faire face aux attentes qui leur sont faites, car les tâches se sont avérées irréalistes.

Questions à prendre en compte lors de la planification d'un sprint :

  • Le client ou le propriétaire du logiciel annonce l'objectif du sprint, tout en expliquant comment l'atteindre. L'équipe Scrum découvre quelles tâches peuvent être accomplies dans un futur sprint pour atteindre cet objectif.
  • Les développeurs se répartissent entre eux un plan de travail, qui est convenu avec le client du logiciel.
  • Le client (propriétaire) du produit participe toujours à l'élaboration du plan de sprint. Il se fixe un objectif, et l'équipe de programmation doit découvrir s'il peut être atteint en un sprint.
  • Le plan doit utiliser un backlog de produit, dont les informations peuvent être ajoutées au plan.
  • Les membres de l'équipe doivent terminer la réunion de planification avec une compréhension claire de ce dont ils ont besoin pour atteindre le résultat. Vous pouvez afficher l'ordre des actions futures dans le backlog de sprint.

La planification ne doit pas dépasser deux heures par semaine. Le Scrum Master doit expliquer à tout le monde qu'il y a des limites de temps. Si tous les problèmes de travail sont résolus rapidement, la réunion peut se terminer plus tôt que d'habitude. Il n'y a pas de durée minimale pour une telle réunion.

Évaluation des tâches

Il n'est pas nécessaire d'en faire trop pour évaluer la complexité du travail. Le processus de planification n'a pas besoin d'une évaluation exacte, mais au moins approximative de la complexité du développement. L'équipe doit non seulement comprendre l'objectif du sprint, mais aussi comparer l'objectif avec les capacités de son équipe.

Pour évaluer la complexité, vous pouvez utiliser les tailles de vêtements habituelles pour tout le monde (L, XL, XXL). Bien sûr, cela ne donne pas une garantie d'exactitude, mais quand même.

Pour que l'évaluation de la complexité soit plus précise, une compréhension mutuelle est nécessaire. Les membres de l'équipe doivent partager ouvertement leurs opinions et ne pas avoir peur de poser des questions au propriétaire du produit.

Les critiques envers l'équipe une fois le travail terminé peuvent conduire au fait que lors de la planification du prochain sprint, les prévisions seront moins optimistes. Cela aidera l'équipe à éviter de répéter l'erreur et à éviter qu'elle ne soit évaluée négativement à l'avenir.

Évaluation de la difficulté en points, points et heures

Généralement, les équipes de développement estiment la complexité de leur travail au fil du temps. Mais certaines équipes Agiles choisissent d'évaluer la difficulté en points ou en points. Il s'agit d'une meilleure indication du coût total requis pour mettre en œuvre un élément du backlog ou une autre tâche assignée.

Les points sont attribués en fonction de la complexité et du volume de travail. De plus, les risques éventuels sont pris en compte. La notation à l'aide de cette méthode permet de décomposer efficacement le travail en petites étapes.

En utilisant régulièrement la méthode de notation (points) lors de la planification, les équipes ont une meilleure et plus précise compréhension du temps dont elles auront besoin pour terminer le travail. De plus, il y a aussi d'autres avantages.

  • L'estimation du temps ne tient pas compte des travaux qui ne sont pas directement liés au projet, même s'ils apparaîtront certainement. Discuter des problèmes de travail via un messager, tenir des réunions - tout cela prend également du temps pour les membres de l'équipe.
  • Les émotions peuvent influencer le choix des dates. La notation lors de l'évaluation du travail élimine ce facteur.
  • L'évaluation de la complexité du travail et, par conséquent, la rapidité d'exécution des tâches peuvent être différentes pour chacune des équipes. Le travail avec des points réalisés ne peut être considéré comme un quelconque indicateur de vitesse. C'est-à-dire qu'il n'y a pas de pression psychologique sur l'équipe.
  • En répartissant correctement les coûts de main-d'œuvre et la complexité, vous pouvez rapidement et sans conflit répartir les points pour le travail effectué entre les participants.
  • Le nombre de points reçus pour l'accomplissement d'une tâche dépend de sa complexité et non du temps passé. Par conséquent, les programmeurs penseront à améliorer leur efficacité, et non au temps que cela prendra.

L'inconvénient de l'estimation de la complexité est qu'elle est souvent mal utilisée. Par exemple, cette méthode ne peut pas être utilisée pour évaluer les employés.

Les équipes doivent utiliser un système de notation pour mieux comprendre la quantité de travail qui leur est assignée et hiérarchiser correctement.

Réunion Scrum quotidienne

Les ateliers sont importants : lors d'eux, les membres de l'équipe partagent leurs opinions, communiquent et s'accordent sur d'autres actions. Des réunions scrum quotidiennes sont également nécessaires pour renforcer l'esprit d'équipe et annoncer les actualités.

Le stand-up est une brève réunion des principaux participants au projet : le propriétaire du logiciel, les programmeurs et le scrum master. La structure du stand-up se compose de trois questions.

  • Qu'avons-nous pu faire hier ?
  • Sur quoi travaille-t-on aujourd'hui ?
  • Qu'est-ce qui nous empêche d'obtenir des résultats?

Poser ces questions stimule le développement et aide à identifier les problèmes au sein de l'équipe. Lorsque chaque participant communique comment il contribue à atteindre un objectif commun, cela améliore la compréhension mutuelle au sein de l'équipe.

Il est important de se rappeler qu'il n'y a pas de modèle unique sur la façon de mener des stand-ups. Chaque équipe tient des réunions selon son propre modèle, basé sur les caractéristiques de l'équipe.

Et maintenant, discutons de ce qui est nécessaire pour un stand-up parfait et familiarisons-nous avec des exemples de stand-up efficaces.

Vous devez d'abord choisir un moment qui convient à tout le monde. Habituellement, les stand-ups pour les équipes du même bureau ont lieu au début de la journée de travail - entre 9 et 10 heures du matin. Cela vous donne le temps de mieux planifier votre emploi du temps pour la journée. Si les membres de l'équipe travaillent dans différentes régions, un moment est choisi qui convient à tout le monde. Par exemple, si certains membres de l'équipe vivent en Californie et à Sydney, le stand-up commence à 15h30, heure de Californie. Bien sûr, se lever après le dîner n'est pas pratique pour tout le monde, mais cela permet de garder le contact avec des collègues de l'autre côté de l'océan.

Gardez une trace de la productivité debout. Ne tenez pas la réunion trop longtemps - la concentration de l'attention doit rester optimale. Si possible, ne tenez pas debout plus de 15 minutes.

Utilisez le ballon. Il peut être jeté l'un à l'autre à tour de rôle. Ainsi, tout le monde participera à la discussion. Ce jeu aide à garder l'attention dans le groupe. Utilisez la rétrospective d'équipe. Les stand-ups sont utilisés dans de nombreuses méthodologies Agiles, cela ne nous empêche pas de discuter de l'efficacité des stand-ups lors des rétrospectives. Quelqu'un se rencontre tous les jours, d'autres équipes - quelques fois par semaine. S'il est difficile pour l'équipe de tirer profit du stand-up, trouvez-en les raisons et changez quelque chose.

Revue de sprint

La revue de printemps est effectuée à l'étape finale du sprint. Il est nécessaire de vérifier l'incrément du produit et d'adapter le backlog. Toute l'équipe Scrum et toutes les parties prenantes participent à l'examen des résultats du sprint. La réunion se tient dans un format détendu pour améliorer l'interaction des participants au projet.

L'examen des résultats de sprint comprend les éléments suivants :

  • Le propriétaire du logiciel montre ce qui a été achevé dans le backlog et ce qui ne l'a pas été.
  • Les programmeurs discutent de ce qui s'est bien passé, où les difficultés sont apparues et comment elles ont été éliminées.
  • L'équipe de développement montre les résultats de son travail pendant le sprint et l'incrément de produit qu'elle a reçu.
  • Le Product Owner partage ses réflexions sur le backlog actuel. Il donne également une prévision pour le prochain objectif et la date limite pour sa mise en œuvre.
  • Tout le monde discute de ce qu'il vaut mieux faire ensuite en fonction de l'évaluation du marché et des intérêts des utilisateurs.
  • Il y a un échange de vues sur le calendrier, le budget et les perspectives d'augmentation de l'arriéré.

Le résultat est un backlog mis à jour avec de nouveaux objectifs pour les sprints suivants. L'arriéré peut être modifié si la situation l'exige.

Rétrospective Sprint

La rétrospective Sprint est un atelier qui explique comment améliorer votre flux de travail. Il crée également un plan d'amélioration pour le prochain sprint. La réunion a généralement lieu après la revue de sprint et ne dure pas plus de trois heures. Diriger la réunion est le Scrum Master.

Les principaux objectifs de la rétrospective Sprint incluent :

  • Analyse de sprint (travail des participants, résultats et problèmes).
  • Discutez des solutions possibles pour améliorer le flux de travail lors des sprints suivants.
  • Création d'un plan de mise en œuvre des améliorations par les membres de l'équipe lors de la mise en œuvre du projet.

Le Scrum Master invite les membres de l'équipe à faire des suggestions sur la façon d'améliorer l'efficacité du développement. L'équipe discute des propositions et suggère certaines voies et techniques pour leur mise en œuvre.

À la fin de la rétrospective de sprint, l'équipe doit mettre en évidence quelques suggestions d'amélioration à mettre en œuvre dans le prochain sprint. Les suggestions peuvent être mises en œuvre à tout moment, mais Sprint Retrospective offre l'opportunité d'approfondir leur possible adaptation du point de vue de l'équipe.

C'est là que nous terminons notre discussion sur la méthodologie Scrum. Vous pouvez en apprendre plus à ce sujet dans la documentation thématique ou sur votre premier lieu de travail.