Certaines organisations y poussent... parce que cela permet de ne pas faire de doc!
L'agile ne dispense pas de faire de la doc. Ni d'écrire des specs d'ailleurs, c'est juste qu'il y en a qui se planquent derrière l'agile pour ne rien documenter. Ce qui est vrai c'est que les specs peuvent changer en cours du projet pour s'adapter aux besoins réels de l'utilisateur.
L'agile est adapté à certains projets mais pas du tout à d'autres (et également pas du tout adapté à certaines organisations) :
le besoin est susceptible d'évoluer
on a une date de livraison (non décalable) : en gros théoriquement en agile on peut livrer ce qui est prêt
Le truc c'est qu'il y a très peu de boîte qui l'applique correctement (comme tu le dis c'est une excuse pour ne produire aucun écrit). Mais quand c'est bien fait ça marche.
Par contre ça plait pas forcément aux commerciaux/managers/comptable car le coût en ressource est important : ça nécessite de voir l'utilisateur régulièrement (1 fois par semaine) pour avoir son feedback.
Ce n'est pas un mode de développement économique (du moins quand c'est bien fait),le gros avantage : si l'utilisateur lorsqu'il voit le produit évoluer voit un truc qui n'a rien à faire dans le produit final ou un oubli : comme c'est en dev la correction est rapide (contrairement à un cycle en v ou il faudrait refaire tout le cycle)
[^] # Re: Agile... comment casser le charme!
Posté par Marco . En réponse à la dépêche Formation « Développeur d’applications full stack » à l’INP de Toulouse, épisode 2. Évalué à 2.
L'agile ne dispense pas de faire de la doc. Ni d'écrire des specs d'ailleurs, c'est juste qu'il y en a qui se planquent derrière l'agile pour ne rien documenter. Ce qui est vrai c'est que les specs peuvent changer en cours du projet pour s'adapter aux besoins réels de l'utilisateur.
L'agile est adapté à certains projets mais pas du tout à d'autres (et également pas du tout adapté à certaines organisations) :
Le truc c'est qu'il y a très peu de boîte qui l'applique correctement (comme tu le dis c'est une excuse pour ne produire aucun écrit). Mais quand c'est bien fait ça marche.
Par contre ça plait pas forcément aux commerciaux/managers/comptable car le coût en ressource est important : ça nécessite de voir l'utilisateur régulièrement (1 fois par semaine) pour avoir son feedback.
Ce n'est pas un mode de développement économique (du moins quand c'est bien fait),le gros avantage : si l'utilisateur lorsqu'il voit le produit évoluer voit un truc qui n'a rien à faire dans le produit final ou un oubli : comme c'est en dev la correction est rapide (contrairement à un cycle en v ou il faudrait refaire tout le cycle)