Je ne suis pas formateur, mais je dirige une agence web et nous avons presque exactement la même configuration. Nous avons mis en place Scrum petit à petit, avec plusieurs aménagement (nous en sommes au 17e sprint de 15 jours), et nous nous félicitons de l'avoir fait : meilleure prévisibilité, meilleure prise en compte des réels besoins clients, travail en équipe, autonomie et partage des connaissances, meilleure communication auprès des clients, etc.
Bravo, des Sprints de 15 jours sont une taille idéale. La révision de Scrum de février 2010, préconise de telles itérations avec un Release de 30 jours. Cette démarche permet de fixer d’éventuels bugs lors du 2nd Sprint et « force » à livrer.
Les particularités sont un peu les mêmes que pour vous :
· Plusieurs projets en simultané à mener de front
· Support / maintenance à effectuer en continu
· Intervenants/fournisseurs externes (web designer, parfois intégrateurs...)
· Besoin de validations ou d'éléments de la part des clients pour avancer sur les stories
Nous avons eu du mal à élaborer la méthode qui nous convient bien, l'outil indispensable et efficace pour s'adapter a été la rétrospective à chaque fin de sprint. Les principaux aménagements ou même entorses aux principes que nous avons fait :
· Notre burdown chart intègre une courbe (ascendante) représentant le temps passé au support / suivi de projet, etc. c'est-à-dire le non planifié. Cela permet de ne pas se laisser bouffer par le non-planifié (téléphone client, réparation d'un bug gênant, coordination d'un projet au téléphone ou par mail). Chaque jour, le scrumMaster fait la somme du temps passé par les uns et les autres dans des tâches de ce type, et c'est affiché sur le burdown chart. On voit tout de suite que si cette courbe monte trop vite, la courbe descendante représentant le temps restant sur les stories ne bouge plus.
J’aime beaucoup la réflexion que j’entraperçois dans vos lignes. Faites attention cependant à ce que l’intégration du temps passé en support ne détériore pas la qualité de vos estimations.
Un peu de confusion tout de même. Je m’explique. La qualité des burndowns charts permet de visualiser le « reste à faire » et les ajouts proviennent principalement d’un redécoupage des stories ou la prise en compte de nouvelles contraintes par rapport à un projet.
Idéalement, il serait peut être plus judicieux de faire un burndown par projet, un burndown pour l’activité de maintenance (même si dans ce cas, Scrum s’orienterait davantage vers une démarche KanBan) et faire un document de synthèse de votre portefeuille.
· Si nécessaire (en cas de débordements) et temporairement nous classifions même le temps passé selon le type de tâche pour identifier la cause d'un dysfonctionnement : bugs, tâches internes, demandes clients dans le cadre du contrat de suivi, aide...
· Nous avons une story (une environ sur 15-20 points) qui reprend diverses tâches de support ou de suivi que nous n'avons pas pu effectuées au fil des jours, et qui justifient de le planifier un peu. Au début, nous n'arrivions jamais à compléter le sprint parce que tout le temps passait là.
Dissociez vos activités de développement de vos activités de support : vous risquez de vous perdre et de détériorer la qualité de vos livrables, tous les livrables.
· Autrement dit, notre backlog product n'intègre pas (ou peu) les tâches de support, nous le gérons à part (par mail pour l'instant). Cela peut paraître bizarre, mais cela permet de se concentrer sur les stories qui apportent une business value importante à nos clients, au lieu de se laisser disperser par les demandes des uns et des autres. On s'aperçoit d'ailleurs que les demandes sont rarement réellement urgentes.
Le Product Backlog ne contient pas de tâches dans Scrum. Seul le Sprint Backlog est composé de tâches.
· Nous comptons 1 point = 1 journée de travail à 100% sur la story. Et nous adaptons la focalisation (20 jours/hommes -> 10 points = 50% de focus), comme dans la méthode / livre Scrum from the trenches d'Enrik Knigsberg : http://www.infoq.com/minibooks/scrum-xp-from-the-trenches. Autrement dit, les points sont liés aux unités de temps, contrairement aux recommandations classiques. Cela nous a permis d'y voir beaucoup plus clair sur le temps passé à faire autre chose que travailler sur les stories. Concrètement, nous sommes autour de 50%. Cela peut paraître peu, mais c'est une dure réalité qu'il a fallu prendre en compte.
L’indexation des points sur l’unité de temps était une idée intéressante lors de la mise en place de Scrum (il y a 5 ans encore). Le problème émergeant de cette indexation était une baisse des Releases et une surcharge de travail : en fait, une défaillance des estimations. Estimer en valeur relative permet avant tout d’identifier la capacité de l’équipe à pouvoir délivrer et surtout, à identifier des tâches encore trop importantes (recherche d’hyper-productivité). La transcription du DONE en fin de Sprint, par le Product Owner, est utilisé à des fins de reporting et permet d’estimer le Time-to-market ou de réadapter la Roadmap en priorisant la Business Value avec le Client et les Utilisateurs.
· Les tâches liées à l'industrialisation, ou à notre organisation interne (serveur d'intégration continue, optimisation des releases, etc.), ou au refactoring de nos logiciels, font l'objet de stories (business value zéro pour le client, mais on considère notre agence un peu comme un client).
Petite erreur. La Business Value est définie par le client ou les utilisateurs. Cependant, l’estimation des tâches ou encore des contraintes liées pour atteindre la Business Value (ou l’item le plus fin) doit être réalisée par l’équipe en terme de faisabilité. La Business Value permet de constituer un Product Backlog et de la prioriser. Le Product Backlog est découpé en Sprint Backlogs reprennant les étapes essentielles pour atteindre l’objectif du Product Backlog
· Notre chef de projet est devenue Product owner, mais elle est aussi membre de l'équipe. Je pense que c'est l'entorse la plus gênante au process scrum, mais pour l'instant nous n'avons pas trouvé d'autre solution. En effet, elle ne peut pas se contenter d'être "planificatrice" et représentante des clients, elle doit contribuer concrètement à l'avancement des projets . Je pense qu'une fois l'équipe étoffée, avec sur un autre gros inconvénient : la spécialisation. Elle ne participerait plus à la production, et les membres de l'équipe (développeurs) ont souvent envie de participer à la gestion des projets, pour être plus proche des clients et utilisateurs.
???? Dans Scrum, le Product Owner fait partie de l’équipe (cf Scrum Guide v.02/2010 par K. Schwaber). Tu mets l’accent sur le Rôle du Product Owner qui a été vu comme le représentant du client lors de la 1e parution du livre de K. Schwaber & Beedle « Agile Software Development with Scrum »). En 2008, Schwaber et la Scrum Alliance ont fait amende honorable en indiquant s’être trompé sur le sujet.
Le Product Owner, dans Scrum, « …est la seule et unique personne responsable de la gestion du Product Backlog et qui assure la valeur du travail délivré par l’équipe. ». Le Product Owner établit la Vision, la feuille de route, le Release Plan, il valide les items/stories en fonction de la Definition of Done (DOD). Sans Product Owner pas de produit, pas de produit pas de projet. Son rôle est avant tout un rôle fonctionnel et il protège l’équipe des interférences provenant du client et des utilisateurs pendant le Sprint. Il anime l’Inspect & Adapt des Utilisateurs/Clients/Management lors de la Sprint Review. Il est le garant de la qualité du livrable et s’engage sur un résultat. Il assure le reporting en matière de Retour sur Investissement et de Time-to-Market. En résumé, c’est un Release Manager ou encore un Product Manager, ou encore un Chef de Projet fonctionnel.
Les projets Scrum fonctionnant mal, càd ne livrant pas, ne disposent pas de Product Owner.
· La direction, c'est-à-dire la commerciale (gérante) et moi-même (directeur technique et gérant) jouons aussi souvent le rôle de Product Owner : nous voulons que les projets soient livrés (cf. facturation ;-)). Je pense que cela est dû au fait que le Product Owner (chef de projet) est membre de l'équipe : elle est à la fois juge et partie : elle produit et valide la production, du coup nous devons intervenir pour booster un peu les choses.
Proposition : vous êtes Manager de votre organisation, donc jouer le rôle du Management ( ?)
· Le client n'est pas présent (même si nous projetons de le faire sur de gros projets. La "review" se passe donc sans lui, la direction validant les stories. Assez gênant aussi, mais cela me parait difficile pour nous parce que nous avons beaucoup de clients concernés par un sprint.
Idée : http://managingagile.blogspot.com/2010/08/declaration-d-traduction-libre-pierre.html
· En revanche, nous nous efforçons d'intégrer les actions du client dans le livrable ("definition of done"). Par exemple, au lieu de mettre une story "Maquette du site envoyée au client", nous avons une story "Maquette du site acceptée par le client". Ou encore, nous avons une story "Intégrer les contenus du client" alors qu'il ne les a pas encore envoyés. Certes, nous dépendons du client, mais en revanche cela permet de nous mettre la pression pour faire bouger les clients inertes. Au départ nous ne faisions pas comme cela, les stories étaient faites, mais les projets n'avançaient pas (autrement dit business value = 0). Le client qui traîne est traité comme un obsacle (impediment) et c'est au scrumMaster de lever ou signaler l'obstacle (il peut par exemple demander à la direction d'appeler directement le client, etc.)
Definition of Done n’est pas égal aux critères d’acceptation du client, il s’agit principalement de la définition faite par l’équipe sur l’acceptation de la réalisation de la tâche/story en fonction du Level of Done préétabli par l’équipe. La DOD permet de communiquer au client le niveau de qualité requis pour le développement de l’item/story.
Level of Done :
1. Développement
2. Tests unitaires
3. Built dans les tests unitaires d’équipe
4. Continuous Built
5. User Acceptance Test
6. UAT Automatisé
7. Intégration continue
8. Déploiement
9. Déploiement continu
· Conséquence du point précédent : nous switchons assez (trop ?) souvent des stories en cours de sprint pour tenir compte du fait qu'une story ne pourra pas être faite à cause du client : parce qu'il traîne à valider (une maquette, une intégration...) ou parce que nous devons attendre ses éléments (textes du site, photos, etc.). C'est l'équipe qui demande le switch, et qui négocie avec la direction (qui joue un peu le rôle de product owner).
Peut être que Scrum n’est pas adapté à votre environnement ?
· Nous considérons nos fournisseurs et sous-traitants comme des membres de l'équipe. Chaque fois que possible, nous leur demandons de nous faire parvenir par mail un daily scrum (ce que j'ai fait, obstacles, ce que nous allons faire) avant celui de l'équipe. De cette manière, nous repérons rapidement les glissements dans le temps.
Excellent.
· Un problème est la gestion des projets répartis sur plusieurs sprints. La notion de release ou de milestone n'est pas très facile à manier. Finalement nous avons fait un tableau blanc (au mur) type kanban avec les étapes types d'un projet : définition du besoin/storyboard -> maquette -> intégration contenus -> version beta -> recette, et nous mettons une croix dans la colonne dès que l'étape est validée par le client.
Cette solution paraît logique. Kniberg a mis en ligne un excellent pdf à ce sujet (dispo sur InfoQ) et une approche ScrumBan peut être envisageable. Le ScrumBan, en quelques lignes, répond aux problématiques des projets de supports où le delivery s’opère de façon continue (intérêt des Review ?) mais où l’on recherche l’amélioration continue grâce à la conservation des cérémonies de Scrum.
Finalement, nous avons bien résolu le problème du support et des projets multiples. Nos deux plus gros problème sont :
- Le rôle de product owner mal identifié, lié à la petite taille de l'équipe (product owner dans l'équipe) et sans doute à l'absence du client dans le process.
La taille idéale d’une équipe est de 5 personnes + 1 ScrumMaster + 1 Product Owner
No comments:
Post a Comment