Quelques idées en vrac

J’ai assisté à une réunion de présentation des évolutions de « skills », nom de code pour nos pratiques CMMI à SQLI. Comment souvent, ce genre de réunion est une source d’inspiration, même si les idées ne sont pas toujours liées à ce qui est présenté.

Quelques idées en vrac :

  • C’est une erreur de dissocier conception fonctionnelle (spécifications fonctionnelles détaillées) et technique (dossier d’architecture applicative, …). Un projet doit être conçu dans sa globalité. Faire des itérations de synchronisation entre le fonctionnel et le technique ?
  • Distinguer « product breakdown structure » (la décomposition fonctionnelle ou technique de l’application à produire) et « work breakdown structure » (la décomposition du travail à réaliser pour produire)
  • Distinguer reste à faire et valeur restant à acquérir. Je réconcilie les deux en comptant mon reste à faire en heures idéales et en évaluant la vélocité en heures idéales. La valeur acquise devrait sans doute être évaluée en faisant intervenir une quantification de la valeur et pas seulement l’estimation en charge.
  • « Design to cost » et « Time to market « : deux raisons pour simplifier (et réduire) au maximum ce qui est livré. Contrainte de coût ou contrainte de délai. Comme par hasard (coût, délai, qualité)
  • Notion de tracabilité prédictive (vers l’avant). Indiquer a priori quelles exigences devront faire l’objet d’une mention dans le DAT ou dans les specs (et contrôler cette mention une fois le livrable produit)
  • Notion de tracabilité multiple : pour être complètement couverte, telle exigence doit être mentionnée dans le DAT, dans les specs, dans les tests, … (évaluer un niveau de couverture)
  • Y a-t-il une différence de nature entre le paramétrage et le codage spécifique dans le cadre d’un framework avec suffisamment de valeur ajoutée ?
  • Comment trouver une mesure unique de complexité des tâches, alors que l’on fait intervenir des activités très différentes (spécification, conception, implémentation & tu, tests d’intégration, …) Peut-être que la seule mesure réelle est le temps idéal. Un peu l’impression d’additionner des choux et des tire bouchons, mais bon.
Publicités

A propos pierrefauvel

Project Leader and/or Agile Coach. Pragmatic. Hard core Zen inspired.
Cet article a été publié dans Agile. Ajoutez ce permalien à vos favoris.

Un commentaire pour Quelques idées en vrac

  1. Pascal dit :

    J’adore les points que tu relève … On revient au final sur un concept de base : on ne peut mesurer ou réaliser que ce qui est mesurable et réalisable.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s