Tobias Mayer a attiré l'attention sur un article classique publié dans la revue développement scrum aujourd'hui. Parnas a rédigé de nombreux documents qui sont aujourd'hui considérés comme des classiques de la littérature sur le développement de logiciels. Celui-ci souligne plusieurs des raisons pour lesquelles le développement de logiciels est un processus empirique qui nécessite une approche d'inspection et d'adaptation par opposition à une conception initiale rigoureuse.
Parnas, David L. et Clements, Paul (1986) Un processus de conception rationnel : Comment et pourquoi faire semblant. IEEE Transactions
Je conserve une copie des documents rassemblés par Parnas pour me rappeler que de nombreux aspects de ce que nous faisons avec le Scrum ont été soulignés par des penseurs de premier plan dans le domaine de l'informatique il y a 20 à 30 ans. La plupart des personnes qui travaillent aujourd'hui dans le secteur des logiciels n'ont jamais lu ces documents, et c'est pourquoi nous continuons à commettre des erreurs stupides. Bien entendu, Scrum a été créé par des personnes qui avaient lu ces documents afin de formaliser ce qui était connu pour fonctionner.
Hoffman, Daniel et Weiss, David (2001) Fondamentaux du logiciel : Recueil d'articles par David L. Parnas. Addison-Wesley Professional.
Certaines entreprises estiment que la chute d'eau fonctionne bien pour elles et que les projets sont livrés dans les délais et le budget (le budget est élevé, le temps est long et la satisfaction du client est faible). Il est important de comprendre qu'elles ont créé l'illusion d'un processus prévisible. Lorsque l'on jette un coup d'œil sous les couvertures et que l'on parle aux personnes qui font réellement le travail, on constate toujours que les principes de Parnas s'appliquent.
POURQUOI UN "PROCESSUS" DE CONCEPTION DE LOGICIEL SERA-T-IL TOUJOURS UNE IDÉALISATION ?
Nous ne verrons jamais un projet de logiciel se dérouler de manière "rationnelle". Certaines des raisons sont énumérées ci-dessous :
(1) Dans la plupart des cas, les personnes qui commandent la construction d'un système logiciel ne savent pas exactement ce qu'elles veulent et sont incapables de nous dire tout ce qu'elles savent.
(2) Même si nous connaissions les exigences, il y a beaucoup d'autres faits que nous devons connaître pour concevoir le logiciel. De nombreux détails ne nous sont révélés qu'au fur et à mesure que nous progressons dans la mise en œuvre. Certaines des choses que nous apprenons invalident notre conception et nous devons revenir en arrière. Parce que nous essayons de minimiser le travail perdu, la conception qui en résulte peut ne pas résulter d'un processus de conception rationnel.
(3) Même si nous connaissions tous les faits pertinents avant de commencer, l'expérience montre que les êtres humains sont incapables de comprendre pleinement la pléthore de détails qui doivent être pris en compte pour concevoir et construire un système correct. Le processus de conception du logiciel est un processus au cours duquel nous essayons de séparer les préoccupations afin de travailler avec une quantité d'informations gérable. Cependant, tant que nous n'avons pas séparé les problèmes, nous sommes condamnés à faire des erreurs.
(4) Même si nous pouvions maîtriser tous les détails nécessaires, tous les projets, sauf les plus triviaux, sont susceptibles d'être modifiés pour des raisons externes. Certains de ces changements peuvent invalider des décisions de conception antérieures. La conception qui en résulte n'est pas celle qui aurait été produite par un processus de conception rationnel.
(5) Les erreurs humaines ne peuvent être évitées que si l'on peut éviter l'utilisation d'êtres humains. Même après la séparation des préoccupations, des erreurs seront commises.
(6) Nous sommes souvent encombrés par des idées de conception préconçues, des idées que nous avons inventées, acquises dans le cadre de projets connexes ou dont nous avons entendu parler en classe. Parfois, nous entreprenons un projet afin d'essayer ou d'utiliser une idée favorite. Ces idées peuvent ne pas être dérivées de nos besoins par un processus rationnel.
(7) Pour des raisons économiques, nous sommes souvent encouragés à utiliser des logiciels qui ont été développés pour un autre projet. Dans d'autres situations, nous pouvons être encouragés à partager notre logiciel avec un autre projet en cours. Le logiciel qui en résulte n'est peut-être pas le logiciel idéal pour l'un ou l'autre projet, c'est-à-dire qu'il ne s'agit pas du logiciel que nous aurions développé sur la base de ses seules exigences, mais il est suffisamment bon et permet d'économiser des efforts.
Pour toutes ces raisons, l'image du concepteur de logiciel qui dérive sa conception de manière rationnelle et sans erreur à partir d'un énoncé d'exigences est tout à fait irréaliste. Aucun système n'a jamais été développé de cette manière et aucun ne le sera probablement jamais.
French 
English 
Spanish