Je rigole un peu quand je vous lis. Sorry mais un gant c’est rien d’autre qu’un diagramme… Pas une métho… C’est un peu comme de dire qu’UML est une méthode.
Passer à une méthode agile (qui ressemble un peu à un waterfall miniature, hein faut pas non plus croire que ça réinvente tout), ca n’empêche pas de planifier au contraire. Une méthode agile sans une rigueur quotidienne c’est aller dans le mur… Sauf que tu le sais encore plus tard parce que tu espères (du fait du manque de planification) toujours te refaire sur l’itération (sprint) suivant.
Perso je commence a avoir vu passé pas mal de projet dans la boite. Je plussois que le waterfall (dit cycle en V en bon français) est inadapté pour une réactivité sans faille. Maintenant si le client d’appliquer cette métho, pas trop le choix hélas. Un moyen de s’en sortir est de passer sur une logique incrémentale avec livraison progressive des features… A la différence de l’extreme programming, le cahier des charge ne bouge pas trop.
Je comprend pas trop la question. Modéliser un changement de cap ? Y’a pas à modéliser, suffit juste de l’expliquer. Ensuite que tu le fasses par un tableau de bord (ahhh le dashboard avec les ouates milles indicateurs) ou par quelques planches, libres à toi. Le tout est de mettre les infos essentielles. Vu que tu fais un rapport, finalement voit le comme ce que l’on appelle dans ma boite un bilan de fin de lot… En gros tu y fait l’historique de ce qu’y s’est passé, les bonnes méthodes, les erreurs… L’objectif étant de capitaliser l’expérience acquise.
[quote=“Oshimura, post:7, topic: 52039”]
En gros je voulais savoir comment opérer un changement radical dans une planification qui était quasi-certaine d’être respectée d’après un cahier des charges relativement détaillé, et l’Extreme Programming a l’air de coller à la situation.
Questions justifications du passage d’une méthode à une autre, citer les signes de gros retard prévisible peut être suffisant ?
[/quote]
Ahhh je complète puisque j’ai la réponse à ma question (/me apprendra à lire le fil correctement).
Franchement l’XP ne t’assureras rien… Si l’XP était LA solution à tous les problèmes il y aurait longtemps que tout le monde y serait passé. Il n’en est rien. l’XP est une approche qui permet notamment de donner une certaine flexibilité pour s’adapter à des specs changeantes. Visiblement ce n’est pas ton cas. Donc vu de loin, pas d’intérêt.
Perso déjà si tu sors un planning sans marge, laisse tomber c’est mort. Pour qu’une équipe soit motivée à atteindre son objectif il faut qu’elle y croit. Et un planning sans marge c’est s’assurer dès le moindre écart d’une démotivation de l’équipe car les jalons vont à nouveau se perdre dans les couloirs du temps.
A mon avis justifier le changement de méthode par un signe de gros retard n’est pas suffisant. Si le projet est en retard il faut prendre un peu de temps pour analyser les causes du retard (qui n’est qu’une conséquence). Un planning c’est pas fait uniquement pour organiser, c’est aussi pour mesurer et piloter.
Le retard peut être du à plusieurs causes, quelques exemples parmi les grands classiques :
- mise en place tardive des ressources (la personne prévue pour une tâche n’était pas dispo)
- difficultés techniques (==> besoins de formation qui n’étaient pas identifiées)
- entrées critiques en retard (moyens, documents)
- spécifications pas claires ou insuffisantes engendrant des allers retours incessants avec le client, voire l’injection de nouvelles specs non prévues.
Une fois que tu aura compris à quoi est du le retard, il sera plus facile de justifier le changement de cap. Attention, la question piège pourrait être aussi de savoir pourquoi le retard n’a pas été tout simplement annoncé… Car changer de cap a un coût sur un projet… Il faut donc jongler entre la priorité au délais ou aux coûts.
Bienvenue en enfer :devil:
[/center]