Les méthodes agiles définissent comme précepte (entre autres) que :
1. C’est une erreur de vouloir définir le plus possible les spécifications d’un projet. Il vaudrait mieux démarrer vite et adapter au fur et à mesure.
2. La documentation du projet est un aspect secondaire. Il vaudrait mieux avoir un logiciel qui fonctionne qu’une documentation (du reste, pourquoi cette opposition (extraite du manifeste agile) antinaturelle au possible).
Le point 1 revient à dire :
- Je pars de Paris et je veux aller à Marseilles
- On me donne une carte pour les 500 premiers kilomètres (et encore, 500 c’est bcp)
- Je demanderai tous les 50 km s’il faut que j’aille à droite, à gauche ou tout droit.
C'est Agile ou c'est guimauve ? Ce principe semble valable uniquement dans des cas bien particuliers, alors qu'Agile en fait une généralité.
Le point 2 (extrait du manifeste agile) signifie que la documentation sera forcément créée de manière partielle.
Dans la vraie vie, plus de 70% du temps de développement est du temps consacré aux évolutions. Par ailleurs, les personnes changent d’entreprise.
Dans ce contexte (pas ou peu de documentation, les personnes ne restent pas forcément), est ce que l’entreprise est agile ? Termine-t-elle ses projets dans les meilleures conditions possibles et peut-elle faire évoluer facilement son système d’information ?
A l'inverse, est-ce que le travail des développeurs reprenant un projet agile (en maintenance) n'est pas forcément de plus en plus difficile ?
Avez-vous des retours d’expériences démontrant le gain en agilité de l’entreprise avec une méthode agile ? (au d'autres commentaires)
Partager