Je veux même bien croire que ça a de supers avantages mais j'ai bien peur que ça puisse amener à négliger la pérennité.
Non, justement, les méthodes agiles ont pour but de faire des produits pérenne et bien conçus qui collent aux besoins mais (revert de la médaille) sans engagement sur quand le résultat sera obtenu. On vise l'objectif à long terme en étant conscient que les méthodes permettent d'avoir un outil fonctionnel (mais avec peu de fonctionnalité) rapidement et des mises à jours stables très fréquentes (env 2 semaines).
On arrive à une certaines pérenité grâce aux test unitaires qui permettent de ne pas hésiter à faire de la refactorisation de code. Le développement dirigé par les tests, le pair programming ainsi que la revue de code permet aussi d'avoir un premier jet de code de meilleure qualité ce qui permet de passer moins de temps sur la correction de bug (ce qui est assez chronophage).
Pour ce qui concerne les "specifications" mouvantes, il existe sur chaque projet agile ce qu'on appelle un "product owner" qui est charg" d'avoir la vision de que doit être le produit. C'est à lui de "proteger" les developpeur et de trancher les choix afin qu'il n'y ai pas de changement majeur au cours d'une itération. Les choix doivent être statués avant le début de développement d'une fonctionnalité.
Ce que te permettent les méthodes agiles c'est d'être au plus près du focntionnel et donc de mieux comprendre la problématique et de faire les ajustements presque en temps réel.
Dans le cas de M6, je pense plutot pour de l'incompétence technique ou du je-m'en-foutisme, méthode agile pour mener le projet ou pas.
[^] # Re: DRM inside
Posté par cosmocat . En réponse au journal M6 replay : le site qui n'aime pas linux.. Évalué à 2.
Non, justement, les méthodes agiles ont pour but de faire des produits pérenne et bien conçus qui collent aux besoins mais (revert de la médaille) sans engagement sur quand le résultat sera obtenu. On vise l'objectif à long terme en étant conscient que les méthodes permettent d'avoir un outil fonctionnel (mais avec peu de fonctionnalité) rapidement et des mises à jours stables très fréquentes (env 2 semaines).
On arrive à une certaines pérenité grâce aux test unitaires qui permettent de ne pas hésiter à faire de la refactorisation de code. Le développement dirigé par les tests, le pair programming ainsi que la revue de code permet aussi d'avoir un premier jet de code de meilleure qualité ce qui permet de passer moins de temps sur la correction de bug (ce qui est assez chronophage).
Pour ce qui concerne les "specifications" mouvantes, il existe sur chaque projet agile ce qu'on appelle un "product owner" qui est charg" d'avoir la vision de que doit être le produit. C'est à lui de "proteger" les developpeur et de trancher les choix afin qu'il n'y ai pas de changement majeur au cours d'une itération. Les choix doivent être statués avant le début de développement d'une fonctionnalité.
Ce que te permettent les méthodes agiles c'est d'être au plus près du focntionnel et donc de mieux comprendre la problématique et de faire les ajustements presque en temps réel.
Dans le cas de M6, je pense plutot pour de l'incompétence technique ou du je-m'en-foutisme, méthode agile pour mener le projet ou pas.
Un petit lien sur des méthodes agiles : http://fr.wikipedia.org/wiki/Scrum