Discussion :

[randriano]

Qui peut m'expliquer la 4ème valeur fondamentale de l'Agile: « la réactivité face au changement plutôt que le suivi d’un plan » ??

Par curiosité, fini le Diagramme Gantt et Ms Project avec la méthode Agile??

Merci

[Laurent 1973]

Qui peut m'expliquer la 4ème valeur fondamentale de l'Agile: « la réactivité face au changement plutôt que le suivi d’un plan » ??

Cette valeur se référé au fait qu'un projet, comme en informatique, est soumis à plein d'incertitude.

Par exemple, imagine que tu dois faire un "plan" pour anticiper la température d'une pièce pendant une réunion sans réajuster au cours du temps.
Sachant que tu ne sais pas combien de personne viendront, s'ils aurons des PC ou pas, s'il y aura du soleil ou pas, ....
Planifier à l'avance la position du radiateur reviens à jouer à Mme Irma, voyante extra-lucide.

A la place, on aura un thermomètre dans la pièce est quelqu'un sera charger de monter ou descendre le volume du radiateur au cours de l'évolution de la réunion.

C'est cette idée, dans cette valeur N°4.
On peux avoir une idée initial de notre projet, donc avoir un plan.
Mais on sait que plein d’aléa vont arrivé et que l'on peux pas tout prévoir.
Donc, on prévois la possibilité à réagir face au changement au plan initial.

Les aléas sont multiples dans un projet:
- Point de spécification mal détailler
- Changement d'avis de besoin
- Changement de stratégie du future produit
- Changement technologique (ex: sortie d'un nouvelle OS)
- Problématique technique non prévu
...

Au lieu de jouer à la divination au début d'un projet, en Agile on commence sur un plan simple mais on s'autorise régulièrement à le remettre en cause.
N'oublions pas non plus le principe N°1:

Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

Par curiosité, fini le Diagramme Gantt et Ms Project avec la méthode Agile??

Par curiosité:

• Combien de fois tu as eu un Diagramme de Gantt ou un Ms Project qui est resté inchangé tout au long d'un projet?
• A quoi ça va servir de planifier une tache pour dans 3, 6 ou 9 mois sachant que peut être elle ne sera pas nécessaire pour ton client?
• Est ce que les personnes qui gèrent ces outils ne passent pas tout leur temps à mettre à jours un planning constamment faux?

Mais on va utilisé d'autre outil de suivi, comme le product backlog ou le kanban board.

Merci

You're welcome

[ego]

Mais faut toujours planifier. ..par petits pas. Il ne faut pas non plus sombrer dans l'extrême et la jouer freestyle

[Laurent 1973]

Le texte (version française) des valeurs agiles dit bien:

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.
Ces expériences nous ont amenés à valoriser :

Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

Oui, on a toujours un peu de planification
Ce point agile ne dit pas que l'on ne suit pas de plan, elle met le point que l'on va privilégier la réactivité au plan gravé dans le marbre.

De la même façon, les méthodes agiles ne sont pas anti-processus, anti-doc, anti-contrat et anti-plan.
Mais juste qu'elle privilégie d'autres points à ceux là, sans les exclure bien entendus.

[randriano]

Merci Laurent 1973 c'est on ne peut plus clair

[randriano]

Par curiosité:

• Combien de fois tu as eu un Diagramme de Gantt ou un Ms Project qui est resté inchangé tout au long d'un projet?
• A quoi ça va servir de planifier une tache pour dans 3, 6 ou 9 mois sachant que peut être elle ne sera pas nécessaire pour ton client?
• Est ce que les personnes qui gèrent ces outils ne passent pas tout leur temps à mettre à jours un planning constamment faux?

Oui c'est à 100% vrai!
Donc juste un 1er planning au début. Et puis les sprints!!

[philoo91]

Bonjour, Bonsoir,

Simplement pour répondre à la question en titre qui ouvre ce sujet de discussion : OUI mille fois OUI.

Pour en discuter pleinement débattre des points de vues sur ce sujet, je vous propose le message privé.

@+

[Traroth2]

Certains l'ont déjà deviné dès 2007...

http://dilbert.com/strip/2007-11-26

[Luckyluke34]

Certains l'ont déjà deviné dès 2007...

Certains ont surtout compris que ce qui sort de la bouche du pointy hair boss de Dilbert est en général l'inverse de ce que pense le dessinateur
Caricature, satire, toussa. Ca te parle ?

[pseudocode]

Les méthodes agiles sont-elles une arnaque ?

Non. Les méthodes agiles ne sont pas une arnaque.

L'aspirine n'est pas non plus une arnaque. Mais si je vous vends que l'aspirine est la solution à tous les maux de tête... ca c'est de l'arnaque.
Et si je vous vends que les méthodes agiles sont la solution à tous vos problèmes de développement logiciel... c'est aussi de l'arnaque.

Les méthodes agiles sont la solution aux problèmes les plus communs du développement logiciel: la difficulté d'avoir une spécification complète en début de projet.
Et son corolaire, le retard du projet causé par les clarifications/changements permanents des spécifications.

L'agile c'est préférer l'adaptation des activités, plutôt que le suivi d'un processus pré-établi. Ca n'a pas que des avantages, mais ca en a tout de même de nombreux.