Les réponses à vos questions
Un article de Agile-Swiss.
Dans cette rubrique vous trouverez les réponses aux diverses questions que vous pouvez vous poser sur XP. Questionnez par mail les membres (remplacer AT par @ et DOT par . dans l'adresse), ces derniers poseront l'intitulé de votre question sur cette page et tenteront d'y répondre. Evidemment, l'effet positif n'est pas garanti sur facture, mais le but est d'essayer de répondre aux interrogations les plus courantes.
Les réponses jugées encore incomplètes par les contributeurs sont notées comme A compléter... afin d'appeler d'autres contributions.
Par exemple:
Quelle est "la taille" d'une user story? par Anonyme
Réponse proposée par les contributeurs (A compléter...): Les user-stories sont nombreuses pour chaque itération. Les demandes résultant de ces stories sont petites. Une U-S décrit en une phrase (de manière à tenir sur une carte de type bristol) une demande du client. Cette carte n'est pas la spécification! La spécification est l'alliance de la U-S ET des tests créés pour valider la mise en oeuvre de ce besoin.
Et maintenant, vos véritables questions:
- XP est-il uniquement applicable à des projets J2EE?
- Estimation de la User-Story et estimations des tâches: [...] Comment s'assurer qu'il n'y ait pas d'écarts entre les deux estimations ?
XP est-il uniquement applicable à des projets J2EE? par D.B., le 9 janvier 2005
Réponse proposée par les contributeurs: Bonne question qui ne nous était jamais venue à l'esprit! Xp est une méthodologie de développement et par conséquent s'applique à toute équipe de développement répondant, certes, à certains critères mais surtout pas celui du langage. Prenons pour preuve le livre de Ron Jeffries, eXtreme Programming Adventures in C# ou le fait que l'équipe ayant développé cette méthodologie l'ait fait pour la première fois sur un projet codé en Smalltalk (le fameux projet Chrysler C3).
Comment estimer le coût d'une User Story ? Les tâches issues d'une User Story sont estimées par le développeur qui en accepte la responsabilité au moment du planning d'itération. La User Story a, quant à elle, été estimée en amont, au moment du planning de la release. Comment s'assurer qu'il n'y ait pas d'écarts entre les deux estimations ? par M.T., le 22 février 2005
Réponse proposée par les contributeurs (A compléter...): Tout d'abord, un petit rappel: une User Story doit être évaluée à l'aide d'une unité virtuelle, nous appelons en général ça un jeton. Ce jeton se différencie du classique "jour de développement" dans sa manière à prendre en compte les imprévus des journées (changements, problèmes...). Une fois la U-S évaluée, les tâches correspondantes sont ensuite elles-aussi évaluées, mais cette fois à l'aide de l'unité réelle "jour". Les estimations restent des estimations et des écarts entre les temps de réalisations des tâches et leurs évaluations se créent forcément. Cela dit, en général, pour une même U-S, ces écarts se compensent. Une tâche aura finalement été plus courte à réaliser que prévu alors qu'une autre avait été sous-sestimée, etc... Evidemment il arrive que le temps total finalement passé dépasse de trop l'estimation initiale de la U-S. C'est pourquoi chaque estimation a valeur d'apprentissage pour l'équipe et doit servir à mieux estimer la prochaine U-S. La responsabilité partagée des divers partenaires de l'équipe de developpement fait qu'en général chacun est à même, jour après jour, de mieux évaluer, connaissant de mieux en mieux les difficultés habituellement rencontrées, les points faibles et les points forts de chacun, les pièges du "trop facile" , etc... En résumé, l'expérience des estimations et la répartition des connaissances dans l'équipe permettent d'éviter ce genre d'écarts entre la réalisation et l'estimation, mais ne cherchez pas forcément à aligner la somme des estimations des tâches avec l'estimation de la U-S. Ce serait plus pour la beauté du geste qu'autre chose et risquerait de "biaiser" vos évaluations initiales qui étaient peut-être bonnes. Les "dérapages" sont toujours sources d'amélioration, un feedback en groupe est donc plus que nécessaire pour les évaluations de chaque U-S. Maintenant tout ceci n'est qu'une première ébauche de réponse et ne demande qu'à être complétée ;)
