Cependant, il arrive que des sociétés de conseil et même des entreprises de produits se trouvent dans l'obligation de facturer des heures ou de collecter des heures en raison d'une gestion peu éclairée. Dans ce cas, les données Scrum peuvent être collectées de manière à fournir une estimation horaire et une réalisation plus précises que la planification traditionnelle. Dans les premières années de PatientKeeper, nous avons expérimenté le Scrum hyperproductif et nous voulions une estimation horaire détaillée. Pendant plusieurs années, nous avons recueilli des dizaines de milliers de points de données jusqu'à ce que nous apprenions que nous pouvions aller plus vite avec la seule estimation des points (à ce moment-là, nous avons abandonné tout suivi horaire).
Lorsque nous avons mis en œuvre un type C Scrum automatisé en 2002 chez PatientKeeper, nous avons effectué une analyse utilisateur sur ce qu'il fallait demander aux développeurs pour minimiser leur temps administratif (gaspillage) et alléger l'organisation. Je n'ai pas connaissance d'autres études d'utilisateurs de ce type sur l'élimination du gaspillage administratif pour les développeurs.
Nous avons trouvé une réponse contre-intuitive. Alors que tout ce que nous voulions savoir était comment mettre à jour le tableau d'avancement, nos développeurs nous ont dit de ne pas demander le temps restant sur une tâche pour les raisons suivantes :
1. Il a fallu plus de 60 secondes pour répondre à la question pour cinq tâches et 60 secondes était le critère de conception du système de compte rendu de projet.
2. Cela les obligeait à trop réfléchir et ils ne voulaient pas être dérangés lorsqu'ils pensaient que l'estimation obtenue n'était pas nécessairement exacte.
3. Ils ont estimé que l'estimation du temps restant présentait une grande variabilité et donc un risque élevé. Si l'estimation actuelle explosait, ils savaient combien de temps ils avaient investi et quel était le pourcentage d'avancement. Tout le reste n'était que pure supposition.
Il s'agissait d'ingénieurs professionnels de haut niveau. L'équipe comptait plusieurs doctorants du MIT et d'ailleurs. Les fondateurs de l'entreprise étaient tous diplômés du MIT. Par conséquent, je pense qu'ils ont donné les "bonnes" réponses aux questions en se basant sur les meilleures pratiques et non sur les réponses que donneraient des ingénieurs inexpérimentés, peut-être peu motivés, qui ne connaissent pas grand-chose au Scrum.
En prenant le temps investi et le pourcentage d'achèvement de chaque tâche touchée chaque jour, le système calcule automatiquement le temps restant pour mettre à jour le tableau d'épuisement des stocks Scrum. Si une tâche est 50% terminée et qu'un jour a été investi, le temps restant est supposé être d'un jour. La nouvelle estimation totale de la tâche est de deux jours. L'estimation initiale de la tâche est archivée dans le système à des fins d'analyse historique. Le tableau d'avancement recalcule automatiquement chaque estimation pour chaque élément touché au cours d'une journée.
Le temps restant jusqu'à l'achèvement du sprint est tout ce qui est rapporté publiquement et l'équipe reste concentrée sur ce qu'il faut faire pour obtenir "Done" à la fin du sprint et n'a même pas l'impression que les questions posées sont liées au rapport de temps d'une manière ou d'une autre. Il s'agit simplement de la manière la plus "légère" d'obtenir les données nécessaires à la mise à jour du tableau d'avancement.
Un effet secondaire de cette approche est que les sociétés de conseil qui facturent leurs clients sur une base horaire peuvent générer des factures à partir de notre système automatisé sans avoir à remplir de feuilles de temps.
Lors d'un cours de formation Scrum organisé hier à Copenhague avec des chefs de projet expérimentés opérant au niveau 5 de CMMI chez IBM et ailleurs, il a été généralement admis que le fait de demander aux développeurs de remplir des feuilles de temps réduisait la productivité de l'équipe d'au moins 10%. Ils détestent le faire, c'est du travail en double, c'est manifestement du "gaspillage" et ce n'est fait que par des entreprises qui n'ont pas la moindre idée de ce qu'est le développement de produits allégés. J'ai été consultant dans certaines entreprises où les rapports de temps sont si complexes que les développeurs inventent des feuilles de temps, que l'entreprise ment à ses clients et que les cadres supérieurs prennent de mauvaises décisions sur la base de données erronées, ce qui compromet le succès de l'entreprise sur le marché. Le rapport final que j'ai remis à la direction générale indiquait que 50% de la productivité totale du développement avait été perdue à cause de la mise en œuvre de la feuille de temps.
Tout chef de projet sensé ne "gaspillera" pas 10% ou plus de la productivité de l'équipe de développement. Il remuera ciel et terre pour l'éviter et obtenir plus de fonctionnalités plus rapidement et avec une meilleure qualité.
La recommandation aux organisations de développement de logiciels qui doivent facturer des heures est la suivante :
1. Supprimer tous les rapports sur le temps de travail.
2. Instituer la partie de la déclaration de type C Scrum décrite ci-dessus. Il n'est pas nécessaire de mettre en œuvre un Scrum de type C pour ce faire. La manière de procéder est décrite en détail dans la version actuelle du livre "The Scrum Papers". Les personnes désireuses d'apporter des commentaires éditoriaux peuvent m'envoyer un courrier électronique et une copie de la dernière version sera mise à leur disposition.
3. Générer automatiquement des rapports de temps pour le client à partir de l'approche de type C Scrum. Ne jamais l'utiliser pour rendre compte de l'avancement du développement.
4. Cette approche fournit des informations plus précises que n'importe quel système de relevé de temps jamais créé :
- Developers n'invente jamais les données figurant sur les feuilles de temps.
- Le temps exact est disponible pour chaque tâche.
- Il fournit une analyse "micro-cosée" des travaux en cours.
- Vous ne mentez jamais aux clients. Ils ne sont facturés que sur le travail réel.
Pour les organisations qui ne facturent pas en heures, nous recommandons d'abandonner complètement le suivi du temps et de se contenter d'une estimation relative.
Les équipes qui procèdent ainsi ont des estimations plus précises et une plus grande vélocité. Découvrez pourquoi les points d'histoire valent mieux que les heures.
French 
English 
Spanish