Waterfall une erreur historique? Ne voulait-il pas dire Agile?
La méthode « Waterfall » serait-elle une erreur historique en réalité? Voilà trois incompréhensions flagrantes de la pratique basé sur la publication initiale, de M. Royce le fondateur des méthodes en cascade. Ne serait-il pas l’initiateur des méthodes Agile finalement?
Le modèle « Waterfall » ou en cascade, est attribué à Winston W. Royce qui publia un article en 1970 en présentant pour la première fois le modèle « Waterfall » et en y proposant à la deuxième page de son article le fameux modèle en cascade que nous connaissons tous aujourd’hui : Analyse, Architecture, Code, Tests.
Incompréhension 1 :
Les ambassadeurs de cette méthode auraient-ils arrêté leur grande lecture à la deuxième page seulement?! Puisque M. Royce à la page deux, présente ce modèle comme étant « risqué et fortement voué à l’échec » avec la mention suivante en-dessous :
« I believe in this concept, but the implementation described above is risky and invites failure [...] The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable »
[Managing the development of large software systems]
Dont voilà l’extrait original de la publication de 1970.
Au-delà des risques et imprévisibilité de cette méthode proposée, M. Royce propose quelques pages plus loin un modèle itératif qui relie l’étape de test à l’étape d’architecture et même à l’étape des définitions des besoins. Voilà l’extrait original du processus final proposé par M. Royce.
Incompréhension 2 :
De plus lors de la description du processus (Step. 3), M. Royce recommande la réalisation d’une première simulation (un prototype jetable) qui permettra d’améliorer la conception et la réalisation suite à cette phase (itération, pourquoi pas!).
« They must quickly sense the trouble spots in the design, [..] forget the straightforward aspects of the design which aren’t worth studying at this early point, and finally arrive at an error-free program. [...] Without this simulation the project manager is at the mercy of human judgment. »
[Managing the development of large software systems]
M. Royce identifie donc déjà l’imprévisibilité et la dépendance d’un projet logiciel à l’équipe (les gens) de l’équipe de projet. Encore une fois, les membres d’une équipe de développement logiciel ne sont pas interchangeables. De plus M. Royce, parle de la pertinence de la prise de décision « Just in time » puisqu’il recommande de passer outre les détails triviaux de design trop tôt dans le projet.
Incompréhension 3 :
La dernière recommandation (Step 5), de la publication a trait à l’implication du client qui est décrite comme étant essentielle afin d’éviter la libre interprétation.
« For some reason what a software design is going to do is subject to wide interpretation even after previous agreement. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble. »
[Managing the development of large software systems]
M. Royce, identifie donc les dangers et les risques de l’interprétation et la conception basé sur la documentation et architecture initiale. L’implication du client, est même requise le plus tôt possible et ce de manière formelle!
Conclusion
Les pratiquant et défenseurs des méthodes « Waterfall » sont-ils conformes aux recommandations et pratiques initialement proposées de celui-là même qui proposant la façon de faire?! J’en doute très fortement!
Les fondements même de la publication de M. Royce préconisent un premier principe d’itération, de prototypage et d’implication du client dès le tout début du processus de développement logiciel. La pratique « Waterfall » communément rencontrée aujourd’hui, n’est-elle donc que le reflet d’une TOTALE incompréhension de la publication initiale de ces méthodes? Est-elle le fruit d’une monstrueuse erreur historique datant de 1970?! Pourquoi les pratiquant des méthodes en cascades, ne pratique-t-ils pas au moins le modèle final proposé par M. Royce, plutôt que celui de la page 2 mentionné comme étant un modèle voué à l’échec!?
Alors que la réalité logicielle n’est plus du tout la même que celle de 1970, encore aujourd’hui certains pratiquent et défendent une initiative des années 70 qui en plus, a été, de toute évidence, mal interprétée! M. Royce serait-il plutôt un disciple des approches Agile? L’initiateur des approches itératives?
En effet, le Waterfall tel qu’il est pratiqué depuis plus de 30 ans est bien éloigné de la publication originelle de W. Royce.
Pour la petite histoire, nous devons cela au “DOD-STD-2167″, un standard militaire du département de la défense américain pour le “développement logiciel de systèmes de défense”. Ce document promouvait un processus séquentiel en cascade à passe unique, partant du principe que tout peut être défini à l’avance et dénaturant ainsi les travaux de Royce sur lesquels il s’appuyait. Ensuite, c’est l’effet boule de neige et la catastrophe que nous connaissons : le standard 2167 influence d’autres ministères américains, d’autres pays, ce qui finit par aboutir à la généralisation de ce Waterfall dénaturé au niveau mondial.
Interviewé par la suite par Craig Larman, l’auteur principal du standard 2167 concéda qu’il regrettait la création de cette approche Waterfall à passe unique. Il déclara qu’il n’était à l’époque pas familier avec les approches itératives et incrémentales et que s’il devait réécrire ce standard aujourd’hui, il recommanderait fortement une approche itérative et incrémentale.
Ceci dit, je ne sais pas si j’irais jusqu’à dire que Royce était initiateur des méthodes agiles; mais du développement itératif et incrémental et d’une approche évolutionniste des besoins, certainement.
Merci pour cet article que j’ai pris beaucoup de plaisir à lire.