La nouvelle "done"

L’article de Clinton Keith, « Beyond Scrum : Lean and Kaban for Game Developpers » explique pourquoi beaucoup d’équipes abandonnent les pratiques Scrum en fin de projet et reviennent à méthodes plus traditionnelles.

Il en explique d’abord les raisons, et propose ensuite une alternative en utilisant Lean Production et Kaban.

Article très intéressant et largement détaillé pour bien comprendre le contexte, le problème et la solution.

Le contexte est le développement de jeux, avec des contraintes de phases que nous n’avons pas dans les autres types de développement logiciel.

La notion de « done »
Un élément primordial de l’agilité (Scrum en l’occurrence) est la notion de « done ».

C’est en quelque sorte la définition de « comment considère-ton le travail fini ».

Elle doit être définie avant de démarrer une activité et être partagée et agrée par tous les intervenants.
C’est une hypothèse et en même temps un indicateur. Hypothèse pour les estimations, indicateur pour le suivi d’avancement.

En Scrum, l’équipe va estimer une tâche en fonction du done défini. De cette façon, et en fonction de la vélocité de l’équipe, on aura la liste des tâches qui sont envisagées à produire le temps d’une itération. Envisagée, donc pas sur d’y arriver.

Même si Scrum est construit sur un enchainement d’itérations « time-boxées », la vélocité et la productivité des équipes peut entrainer une augmentation du nombre d’itérations afin de finir le produit demandé. C’est ce qui pause problème d’ailleurs dans nos modes de fonctionnement au forfait.

Dans le contexte du développement de jeux, la contrainte de deadline semble, aux vues de l’article, incontournable. La date de livraison du produit fini ne changera pas.
Dans ce cas, l’auteur remet en cause non pas la notion de done, mais la façon de la définir.

Le time boxing
Dans le chapitre Time-Boxing, l’auteur précise que ce n’est plus la notion de done qui entraîne l’estimation, mais l’estimation qui conditionne le done.

“We start time-boxing each stage of the value stream. For example, we might give the audio designers 10 days to add audio to a specific zone. This is different from tasks in Scrum where the audio designer would estimate their own work and tell the customers what they are willing to commit to”
…
“The input is the time-box (which is the cost we are willing to pay for the asset). The output is quality that the artist is able to provide within the constraint of time.”

C’est un changement assez radical dans le comportement d’une équipe Agile, mais qui finalement ne semble pas si incohérent et qui pourrait être une piste d’aménagement dans un projet au forfait. Pourquoi,
Parce qu’un forfait c’est un contenu fixe à une date fixe et un prix fixe.
Parce que je constate encore que pas mal de gens n’arrivent pas à faire des estimations. Du fait que cela les engagent, cela les effraie. Bien que je sois fortement favorable à cette façon d’impliquer tous les acteurs, au sens propre, d’un projet.
Parce que la notion de done, n’est jamais clairement définie dans les appels d’offre de nos clients. On le sait bien, ils veulent « tout ».
Enfin parce qu’un projet au forfait empêche la transparence et de ce fait, le client n’a souvent pas la vision détaillée de toutes les tâches nécessaires à accomplir pour atteindre cette notion de done et au final ne comprend pas les estimations que l’on lui donne. (tiens pour une fois j’ai mis 2 n ;-) )

De toute façon, comme toute adaptation, il faut l’évaluer avant de l’adopter ou la rejeter en fonction des contraintes de chaque projet.