Ces notes sur la mise en place de Scrum et de XP dans un projet "réel" sont disponibles en ligne sur le site de la société Crisp. Il s'agit d'une approche très pragmatique de Scrum avec de nombreux conseils sur des pratiques très concrètes sur les différents composants de Scrum: file d'attente produit, sprint, mêlée quotidienne...
File produit
Ou Product backlog
- Définition des narrations:
- quantification relative de l'importance de chaque narration
- estimation initiale en nombre de jours
- critère de démonstration (tests d'acceptation)
- en terme métiers (pas technique): utilisation de la technique des 5 pourquoi pour extraire la motivation initiale
À définir avant la planification du sprint, différencier le degré d'importance de chaque élément pour ordonner (!!) facilement lors de la réunion.
Chaque narration est écrite sur une carte (pas d'interface informatique), pour pouvoir être affichée et manipulée sur un tableau visible de tous.
Division d'une narration en tâches: permet d'anticiper une sous-estimation, lever des problèmes flagrants...
Éléments techniques (architecture, infrastructure, tâches de maintenance des outils,....) difficiles à intégrer dans la file produit. Utiliser le coefficient d'effort pour les "masquer", ou les intégrer en tant que tâches.
Anomalies: différentes stratégies, soit les intégrer dans la file produit, soit en tenir compte pour le coefficient d'effort
Planification du sprint
Notion de Vélocité : total de l'estimation de charge pour un ensemble de narrations. Comparer le planifié avec le réalisé, sans tenir compte des narrations non achevées (ie. non démontrées). Attention: on ne prend pas en compte le temps ed travail effectif, mais l'estimation attachée à une narration. Le temps de travail effectivement accompli n'est jamais pris en compte dans Scrum et XP en tant qu'objectif.
Estimation de la vélocité: calcul du nombre de jours de travail disponibles (réel, aprés application congés, temps partiel) puis application d'un coefficient d'effort ou de concentration (focus factor).
La vélocité estimée représente une limite sur l'engagement de l'équipe pour le sprint (en terme de narrations). À comparer avec le réel des sprints précédents !
Définir le but du sprint (Sprint goal): motivation, justification du sprint.
Positionner la mêlée quotidienne: horaire, lieu, règles.
Le sprint
Information du démarrage du sprint: lieu et date de la démo, de la mêlée, membres de l'équipe. Communication à toute l'entreprise (wiki central).
File de sprint: classification des tâches et narrations par importance et état, mise en place tableau de bord (papier):
- colonne en cours
- colonne fait
- graphe du RAF
- tâches et narrations supplémentaires (en cas de sur-estimation de l'effort pour le sprint)
Seat the team together !! mais ne pas avoir le gestionnaire produit trop près.
La mêlée
Mise à jour du tableau de bord des tâches, reévaluation du temps, mise à jour du graphique RAF
Mise à l'amende des retardataires.
La démo
Matérialisation de l'atteinte de l'objectif du sprint. Effet positif sur l'équipe, communication envers le reste de l'entreprise, obligation de terminer le travail.
Le debriefing du sprint
Résumé du déroulement du sprint, tour de table, analyse des écarts avec les prévisions.
SI plusieurs équipes: faire circuler l'information entre les équipes.
Planification des livraisons
Planification de plusieurs sprints à l'avance pour identifier les narratinos à inclure dans une livraison (contrats au forfait).
Estimation des différentes narrations dans la file produits, puis séparation en plusieurs sprints en fonction de la vélocité estimée.
Pratiques XP
Programmation par paires
Effets positifs sur:
- la qualité du code
- la concentration sur l'objectif
- la diffusion rapide des compétences
Toutefois:
- fatigant, ne peut pas être pratiqué toute la journée
- certaines personnes sont mal à l'aise (en fonction de leur degré d'acceptation d'intrusion dans leur espace personnel)
- la revue de code est une alternative possible
Développement dirigé par les tests
Pratique la plus rentable en termes de qualité du code et de la conception, ROI rapide, nécessite du temps pour apprendre à le pratiquer et pour mettre en place l'environnement adéquat.
Nécessite outillage: xUnit framework, DB mémoire, containers légers...
Remarque concernant le code patrimonial: plutôt que d'essayer d'automatiser totalement les tests, étudier le travail des testeurs et automatiser les tâches administratives et répétitives
Effet de bord: réusinage et conception incrémentale
Intégration continue
Maven + CruiseControl
Recette
Problèmes:
- la phase de recette est indispensable
- c'est un processus non-agile qui vient par conséquent interrompre le flux du processus agile (??)
Il faut donc minimiser cette phase en :
- maximisant la qualité du code produit lors du sprint
- maximisant l'efficacité du code manuel
Plusieurs solutions:
- intégration d'un testeur dans l'équipe (approche plus XP, intégrité de l'équipe, autonomie, complétude), rôle central dans la délivrance d'un permis de déployer
- diminuer le volume réalisé durant un sprint
Gestion des anomalies de production (ou de recette): intégrer la résolution des anomalies dans le sprint (en jouant sur le facteur d'effort, en ajoutant une narration pour les anomalies à corriger, ...)