Planification

[Rémi Guitreau]

Salut,

Je répond dans un nouveau thread pour que le précédent reste concentré sur la question initiale de Sylvain ;)

Disons que nous sommes encore dans un fonctionnement de projet où un client nous commande un lot de fonctionnalités, ou disons qu'une commande implique un certains nombres de fonctionnalités, et ces fonctionnalités sont déployées sur des serveurs de ce client. Or avant que ces fonctionnalités ne passent en production, il faut qu'elles aient été testées sur un environnement de qualification chez eux. Ce mode de fonctionnement leur est imposé par ailleurs, au niveau législatif par exemple. Donc difficile de passer outre... par contre nous pouvons essayer de l'améliorer avec le client peut-être.

Du coup je ne sais pas si l'annonce d'une probabilité de réalisation soit bienvenue par le client. Par contre je la comprend bien pour une application "cloud" qui est déployée automatiquement.

Après en y réfléchissant, il faut peut-être intégré le temps jusqu'à la mise en production réelle, donc ayant passé les tests de qualif chez le client ?

En effet pour l'instant nous mesurons un temps de cycle "interne" à l'équipe de dev et qui se termine par "Bon à livrer" et pas par "en prod". Une idée pourrait être de continuer à garder notre tableau de flux "interne" équipe de dév avec nos mesures avant bon à livrer, et en monter un parallèlement pour le projet global, avec les fonctionnalités et qui intègre le temps de développement, de qualification et de déploiement en production.

Du coup la communication par rapport au client se ferait plutôt sur les chiffres de ce tableau-ci, et donc sur le temps avant mise en production, plutôt que sur le temps avant passage sur la qualification ?

En tout cas merci pour les retours enrichissants ! :)

Rémi.

Le 6 mai 2013 18:40, alexis8nicolas <alexis8...@gmail.com> a écrit :

Pour ta question sur la planification, je te recommande le slide 13 " Lead Time Distribution as an enabler of a Probabilistic Approach to Management "    http://dl.dropboxusercontent.com/u/33524813/LKNA13_AndersonKeating_BeyondKanban.pptx

La plannification et l'estimation ne sont pas particulièrement utiles à partir du moment où on a collecté suffisamment de données sur les probabilités du système. Cependant la transition doit se faire avec le client, c'est-à-dire on commence par appliquer Kanban sans rien changer aux processus, on collecte des données, on apprend de nos lead time et autres données, puis on cherche à faire mieux, par exemple en passant à de la priorisation à la demande, ou à de la livraison à la demande (en attendant la livraison continue), ou à l'arrêt des estimations (mais uniquement du management probabiliste : cher client, si cette demande est importante pour vous donnez nous votre GO et vous avez 85% de chances que votre demande soit traitée dans 8 jours à partir du GO). Est-ce que ça répond à ta question ?

Le lundi 6 mai 2013 15:25:14 UTC+2, Rémi Guitreau a écrit :

Du coup si j'ai bien suivi cette façon de voir les choses (se baser sur le vécu plutôt que sur des estimations), n'empêche pas de faire de la planification, mais cette planification se fait sur les temps de réalisation mesurés et pas sur les temps estimés comme on a pris l'habitude de le faire ?

Par contre on ne peut commencer à faire de la planification sur le vécu qu'à partir du moment où on dispose d'un nombre de données suffisamment grand.

Comment ce point (la planification) est abordé avec des équipes qui commencent Kanban, mais qui sont face à un client et où la planification est un élément indispensable de la communication entre le client et l'équipe.

Faut-il faire deux planifications (en interne) ? Une en utilisant des estimations et une autre se basant sur le petit vécu de l'équipe ?

Après peut-être que c'est la planification qu'il faut essayer de supprimer, mais ça me semble délicat ?

Rémi Guitreau.

[laurent morisseau]

Salut Rémi,

La question de la planification et de l'engagement sur un périmètre est toujours délicat.

l'annonce d'une probabilité de réalisation est dur à entendre pour ton client, et il y a des contextes ou cela peut vraiment se comprendre, après cela reflète la réalité du projet avec laquelle on doit avancer ensemble.

Cela n'aide pas, mais il faut voir cela comme une base de discussion factuelle avec le client pour voir comment faire au mieux pour la suite. Et, tu as raison, pour réussir à embarquer ton client dans cette discussion, je t'invite à suivre ce temps jusqu'à la mise en production. Je n'utiliserais qu'un seul et même tableau qui visualise l'ensemble du flux. La vision d'ensemble est intéressante également pour l'équipe pour comprendre certains choix, certaines priorités.

Pour commencer, je suivrais le temps de cycle (interne pour l'équipe) et le lead time (bout en bout pour les discussions client). A terme, seul le lead time devrait rester.

--Laurent Morisseau

Mobile: 06 08 34 63 55

Skype: laurentmorisseau

Twitter Viadeo LinkedIn DoYouBuzz SlideShare   YouTube

2013/5/7 Rémi Guitreau <rgui...@netceler.com>

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes KanbanDevFr.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse kanbandevfr...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
 
 

[Youen Chene]

Bonjour tt le monde, 

Un petit retour d'expérience que j'ai poussé auprès des chefs de projets (des expérimentés ceux qui ont 10-15 ans de bouteilles).

J'ai mis en avant des chose de type : une story standard met x jours pour 85% des cas pour arriver en production ou en QA.

Au pire ils s'en foutent, au mieux cela les fait rire. Avec du recul la question n'est d'être sur à 100%, 110%, ou 70%. Ils veulent un engagement humain sur le fait que l'on va tenir la date qu'on leur demande de tenir.

Cela fait plus chasse au coupable quand ça merde, car le chef de projet va mettre la pression sur la personne qui n'a pas tenu ses engagements.

Quid de vos retours d'expérience sur ce sujet?

Youen

2013/5/8 laurent morisseau <laurent....@gmail.com>