l’empirisme ou l’acte de prendre des décisions basé sur ce qui est

Empiricism, the act of making decisions based on what is par Ken Schwaber

Scrum est un processus empirique, parfois décrit comme “l’art du possible.” Par cela, je veux dire que nous faisons du mieux nous pouvons avec ce que nous avons.

Un Propriétaire de Produit (« Product Owner ») planifie une version (« release ») en se basant sur toutes les informations actuellement disponibles.

Il ou elle définit les objectifs, puis les fonctionnalités et capacités qui permettront de les atteindre ainsi que le coût probable et la date de livraison. À partir de ce moment-là, le travail du Propriétaire de Produit est d’évaluer ce qui est possible au vu les capacités de l’équipe et de prendre les meilleures décisions possible pour atteindre l’objectif visé. Étant donné la nature de la technologie, des marchés, des besoins et des personnes, des compromis seront faits. Parfois, le but ne peut pas être atteint pour un coût raisonnable. Parfois, le but sera atteint, mais d’une manière un peu différente de celle que le Propriétaire de Produit envisageait initialement. C’est l’empirisme en pleine action.

L’équipe (de développeurs) dans l’équipe Scrum fait de même. Elle rencontre le Propriétaire de Produit et évalue ce que le Propriétaire de Produit voit comme les choses les plus importantes à faire. Si réalisées, ces choses amèneront le produit émergent dans la meilleure direction vers le but désiré. L’équipe choisit autant de choses qu’elle pense pouvoir faire pendant le prochain Sprint. Le coût de l’équipe et la longueur de Sprint sont fixes. Seule la quantité d’items du « Product Backlog » embarquée peut varier. Le Propriétaire de Produit et l’équipe définissent souvent un objectif global pour le Sprint. Il est un sous-ensemble des objectifs de la version (« release »).

Quand l’équipe choisit des items lors d’une réunion de Planification de Sprint, elle s’engage à le faire pendant le Sprint.

Une définition « s’engager » est : « Se lier moralement par une promesse : Il s’est engagé à payer ses dettes dans les huit jours. » selon le Larousse. (ndlt)

Cela correspond à ma compréhension du mot s’engager, qui est une promesse, un engagement sur un plan d’action.

Cependant, beaucoup d’équipes Scrum utilisent le mot « s’engager » comme si c’était « une garantie ». C’est un reste des méthodes traditionnelles dites en cascade, où une estimation valait pour contrat. Cependant, cela reste présent dans l’esprit des propriétaires de produit et des développeurs. J’ai trouvé équipes après équipes qui estiment qu’elles doivent tout faire pour respecter leur engagement: La victime est habituellement la qualité.

Je me demande si nous devrions échanger le mot « s’engager » pour celui de “prédire” ?

Ceci pourrait donner la même perception que la présentatrice météo essayant de nous fournir les meilleures informations possibles. Elle fait avec que l’on connaît et avec ce que peut lui fournir la science de la météorologie. Elle ne fournit pas de garantie mais quelque chose que nous pouvons utiliser pour prendre des décisions. Les prévisions sont également utilisées par les organisations de ventes.

Peut-être cette clarification nous aidera-t-elle à comprendre qu’ « un engagement » dans Scrum est une promesse de faire de notre mieux avec ce que nous avons.

Enregistrer