Suite de l’itératif sans concession
Entre les statistiques publiées, une solide base de projets ayant permis de calibrer Evaluateur en son temps http://www.rad.fr/eval2000.htm (à Hydro Québec j’ai supervisé jusqu’à plus de 60 projets simultanément) et mes expériences de consultant méthode de ces dernières années, j’en arrive à la conclusion qu’en termes de besoins :
- seuls 18% des applicatifs auraient été en mesure d’être définis précisément en début de projet;
- environ 22% des applicatifs étaient en mesure d’être abordés sans structuration des exigences en début de projet.
En clair, vouloir fixer un périmètre complet et détaillé pendant une phase d’exploration est une erreur aussi sérieuse que de vouloir se passer de l’indispensable réflexion qui doit précéder l’action. Les échecs de projets itératifs liés à cette faute d’appréciation font courir le risque de voir cantonner les méthodes Agiles actuelles à des petits développements avec un nombre très limité d’utilisateurs. Dans ce cas, il est d’ailleurs intéressant de se demander à quel moment, comment et sur quelles bases, se ferait l’arbitrage budgétaire conduisant à lancer le projet.
Bonjour
L’itératif répond au fait qu’il est impossible de connaître dès le départ le périmètre d’un projet, que le client va aussi ajouter ou retirer des éléments, que les développeurs vont avancer plus ou moins vite. C’est aussi le fait de penser qu’à chaque itération on se concentre pour livrer un incrément analysé, codé, testé et validé.
L’incrément est la quantité de travail livré à chaque itération. C’est bien la valeur de l’incrément qui ensuite demande un travail d’analyse.
Votre raisonnement semble être qu’il faut systématiser ce travail d’analyse, pouvez-vous développer ce qu’est le semi-itératif ?
Est-ce que vous ne pensez pas que l’on peut conserver le terme d’Itératif et simplement expliquer que le travail d’analyse ou de phase exploratoire fait partie d’une itération ?
Mike Cohn en parle très bien dans son livre “User Stories Applied: For Agile Software Development” ISBN 978-0-321-20568-1 au chapitre 15
Il m’est arrivé à plusieurs reprises d’être impliqué dans un projet totalement itératif (le client arrive et l’on commence à coder avec un outil permettant un rendu visuel immédiat) mais c’était toujours de très petits projets dans des contextes de client presque unique. Je ne peux généraliser sur la méthode à partir de ce type d’expérience.
Itératif comme Cascade sont des concepts extrémistes qui permettent à un moment donné de catégoriser un principe. Comme le montre le graphique, ils peuvent être acceptables dans des conditions extrêmes. Il y a des itérations dans la cascade et de la cascade dans un processus itératif.
Le pragmatisme, si on fait abstraction du business promotionnel, c’est d’appeler un chat un chat : le cycle qui couvre la quasi-totalité des projets est semi-itératif.
D’où tenez-vous la certitude suivante : « il est impossible de connaître dès le départ le périmètre d’un projet » ? Dans la plus part des projets le périmètre varie de « totalement connu » 18% à « changeant » 22% en passant par « fréquemment modifié » pour le reste.
suite :
Qu’entendez-vous par « L’incrément est la quantité de travail livré à chaque itération. C’est bien la valeur de l’incrément qui ensuite demande un travail d’analyse. » La valeur des éléments qui constituent un incrément est priorisée avant sa mise en développement pas ensuite.
Vous faites aussi référence à la « vitesse de développement », elle n’a rien avoir avec le cycle de base.
Vous me demandez sur ce blog « pouvez-vous développer ce qu’est le semi-itératif ? » : j’ai écris au moins 5 ou 6 livre sur le sujet depuis 1994 et j’ai un site de plusieurs centaines de pages dédié à cela (RAD.fr)! Vous voulez quoi de plus au juste ? Aller sur wikipédia et chercher “cycle de développement” (pour cet article je ne suis qu’un des contributeurs)
En ce qui concerne la sentence « simplement expliquer que le travail d’analyse ou de phase exploratoire fait partie d’une itération ? » c’est encore une assertion qui ne s’applique qu’à un tout petit projet pouvant tenir dans une seule itération. Observer vos modèles américains : dans le cycle de Scrum comme celui d’XP, l’exploration et la planification sont bien préalable aux itérations.
Accepter le changement mesuré n’implique pas que 100% des choses vont changer. Heureusement.
Pour finir, j’ai lu et continu de lire presque tout ce qui se produit sur le sujet dont le livre de Mike Cohn que vous citez. Tous ont apporté et apportent un petit plus à ma réflexion (d’où PUMA). Je ne sais si vous le savez, mais ma première communication sur l’itératif incrémental adaptatif date de 1990 au Canada et 1994 en France.