Commentaires sur : Comment mieux prioriser en projet agile

Par : PP

PP — Sun, 13 Jul 2008 12:24:27 +0000

Tu as raison de distinguer débit de fonctionnalités du débit de valeur. Mais la valeur est si difficile à mesurer ! C’est pourquoi on discute beaucoup plus de coûts, plus simplement mesurables : combien coûtera d’ajouter un tri par groupe ? combien coûtera de pouvoir gèrer deux devises ? …
Pour maximiser la création de valeur, il faut développer une dialectique. Qu’est-ce qui crée de la valeur dans une entreprise ou l’on introduit de l’informatique ? Trois axes : cela diminue les coûts (63% des factures sont traitées automatiquement ..), cela augmente le chiffres d’affaires (on a sorti le produit corporate+ en 2 mois, il génère 12% de notre CA après 6 mois) ou cela diminue les risques (les rapports financiers sont fiables et auditables). Chaque entrée dans le carnet de commandes doit pouvoir se justifier par cette dialectique : si je ne la fais pas, vais-je perdre une, deux ou trois de ces opportunités ?
Enfin, ne soyons pas manichéen. Cette dialectique fonctionne parfaitement dans un contexte établi. En contexte fortement innovant, elle est possible, mais soumise aux probabilités : écoutez, je pense que cela peut génèrer 2 point de CA dans les 2 ans, mais bon, c’est une intuition ? 50% … Dans ces conditions, il faut simplement définir l’intention, l’objectif et se concentrer sur le plus court chemin qui mène en production : par exemple ‘délivrer un site Web qui permet de sélectionner des entrepreneurs de micro-crédit et faire payer les internautes’. Plus c’est flou, plus il faut livrer vite

Par : Ismaël Héry

Ismaël Héry — Mon, 02 Jun 2008 14:41:33 +0000

Marc,

j'aime bien ton idée d'identifier les goulets d'étranglement dans la démarche de priorisation.

Si je reformule, un product owner ayant peu de disponibilité est un goulet potentiel du processus de priorisation.

Attention toutefois, le processus de priorisation est plus complexe qu'une chaîne de production industrielle. Dans cette dernière la recherche de goulet passe notamment par des mesures du throughput. Or dans le cas de la priorisation le throughput est piégeux : il ne s'agit pas seulement de la vélocité (throughput de delivery) mais aussi et surtout du throughput de VALEUR.
Un des points de mon billet c'est qu'on se contente parfois du throughput de delivery, au risque de ne pas voir émmerger les goulets sur le throughput de valeur.

Par : mac

mac — Sun, 25 May 2008 12:58:20 +0000

Les écueils exprimés au travers des questions sont récurrents pour des organisations qui démarrent
dans l'univers des approches agiles. Ceci m'inspire plusieurs réflexions orientées 'Lean' qui je l'espère, peuvent
apporterons des éléments de réponse.

1) Ne rien lâcher, ne pas se décourager : comme tu l'as dit, une organisation apprenante valorise
l'ensemble des évènements (positif, négatif pour le BUT) par la remise en cause de ses standards
(pratiques, procédés et outils) avec pour objectif d'améliorer son système de production. Ces problèmes
sont donc une richesse et doivent être soulevés de manière à améliorer le système :
'Stop the line', 'Root Cause', 'PDCA', les '5s' sont des outils permettant d'aborder de manière structurée
et efficace ce genre d'évènements.

2) Une vue d'ensemble du système, pour une optimisation d'ensemble : vous connaissez l'adage 'rien ne sert de courir ...'.
En effet, des équipes de développement 'trop rapide' face à un des analystes ou un Product Owner sous pression ou le phénomène
inverse ne sont pas bon pour l'ensemble du système et donc pour l'ogranisation. La théorie des contraintes ou des queues nous enseigne à cet gard qu'il faut que les goulots d'étranglements soit repérés, levés de manière récurrente. Dans ce cas, ou l'équipe
d'analyste est sous-dimensionner ou celle de développement est sur-dimensionner. Dans les deux cas, il faut éviter les stocks et/ou
les gaspillages (de code non testé, les fonctionnalités de second ordre mis en priorité 1...). En somme, régler le problème à la racine
du mal, maintenir le flux continue d'informations entre les différentes activités.

3) Product backlog, Iteration backlog, Code Repository: une propriété collective. Le 'Product Owner' (ou 'Champion') est celui qui donne
la vision produit (et du systeme produit qui en découle). Il tranche lorsqu'il a des options possibles. Le backlog est la propriété de
l'ensemble de l'équipe et les phases ou l'on prépare le contenu d'une itération servent à cela. Durant cette étape, un item du 'Product Backlog'
devient 1 ou N story(ies) dans le backlog d'itération. Les élements qui concourent à la priorisation sont nombreux :
* L'expérience collective des itérations précédentes
* Les expériences individuelles du domaine : marché, client, organisation, stratégie produit....
* L'intérêt du client comme point d'entrée : cf. le modèle Kano en.wikipedia.org/wiki/Kan...
* Une mode de pensée incrémentale (que l'on oublie souvent)

MAC