Jeff-Sutherland, continuant l’agilisation de Systematic, présente une évolution du concept de done/done : le ready/ready
Ou plus exactement la Feature ready/ready checklist.
A partir de la notion de done/done, normalement, une équipe construit une liste de typologie de tâche ayant pour objectif l’atteinte du done. Cette checklist se place au niveau Scrum Team, côté développement donc.
La checklist ready/ready reprend ce concept et le remonte d’un cran, côté demandeur (Product Owner, Architecte, et lead developper).
En clair, quelles sont les tâches de préparation nécessaires au passage d'une feature dans l'état "Not Started" de ces user stories dans le task board (repris du Kanban Lean) :
• Preparation de la feature pour l’engagement : préparation à l’acceptation
• Clarification de la feature pour l’équipe : prise en compte des contraintes de l’équipe de développement en amont
• Préparation de la feature pour implémentation : passage de la feature aux stories pour préparation aux sprints.
Tous ces points sont fortement conditionnés par la mise en place du pilotage par les tests d’acceptance (ATDD)
Deux métriques sont utilisées :
• Le Process Efficiency
S’il faut une journée idéale pour produire une user story mais qu’en fait elle est produite en 5 jours, alors l’efficacité est de 20%. Le but étant d’augmenter cette efficacité en préparant au mieux l’implémentation, la checklist ready/ready est construite en ce sens.
• Fix time after failed builds
De la même manière, quelle est l’efficacité du processus concernant la correction d’une erreur de build. Ici, les pratiques ATDD permettent la réduction de temps.
Plus que le nombre de bugs, c’est bien le temps de correction qui importe.
Copyright © 2010 Laurent Carbonnaux : Coaching Agile | Blogger Templates by Splashy Templates
Css Designed by Hot Website Templates
3 commentaires:
Avant d'utiliser la métrique "Process Efficiency", avez-vous suivi ou suivez-vous le temps de cycle des user stories (= Date de mise en production - Date de commande de ladite user story)?
Il me semble que dans Lean le temps de cycle est au dessus de toute autre métrique. Par Exemple on peut avoir un Process Efficiency de 100% et livrer tous les 3 ans! Et il est très facile de déteriorer le temps de cycle en optimisant une autre métrique.
Bonjour Luc,
Il me semble que les deux sont complémentaires et indissociables.
Le process efficicency est une mesure de la production. Le besoin de mise en prod est lui piloté par le marché. On peut avoir un process efficiency à 100% et un client qui n'a pas besoin de plus d'une livraison par an.
Dans le cas contraire, un client souhaitant un temps de cycle court (Lead Time), aura besoin de mesurer le process efficiency. C'est une partie de l'analyse effectuée sur la chaine de valeur ajoutée (VSM).
Bonjour Laurent,
Merci pour ces précisions. Je pense que le process efficiency représente aussi la prédictibilité et la répétabilité des estimations qui est primordiale afin d'obtenir un temps de cycle court.
Cette prédictibilité/répétabilité, chez nous, est observé en constituant un graphique regroupant tous les temps de cycle de nos user stories. Notre process est prédictible si l'on obtient une Gaussienne (voir cours de stat ;o)).
Il fut un temps où nous suivions ce que nous appelions le "planning accuracy". Cette indicateur mesurait la déviation entre l'engagement de l'équipe et ce qu'elle montrait en revue de sprint. Nous avons arrêté cette pratique car elle avait un impact négatif sur la qualité du code produit.
Luc
Enregistrer un commentaire