Théorie et pratique

A partir de nos réflexions sur le sujet du design, réaliser un projet complexe de développement avec succès et durablement ne devrait pas être un problème: Sur la base des prototypes nous clarifions toutes les questions ouvertes, et après nous créons une conception modulaire. Des conceptions douteuses sont évitées dès le départ, en plus elles ne sont pas nécessaires, parce que nous dévéloppons avec la "méthode agile", donc dans chaque décision toutes les options sont ouvertes.

Mais le plus souvent, dans la pratique quotidienne, on doit atteindre les buts importants du projet plus tôt et particulièrement à coûts plus faibles que dans le mode décrit. De ce désir compréhensible et risqué au même temps de raccourcir le procès de dévéloppement les questions suivantes se poseront:

• Où peut-on commencer tout de suite avec une conception modulaire, et par contre, dans quelles parties un prototype est commandable pour gagner des connaissances importantes?
• Dans quels secteurs peut-on créer directement une conception monolithique sans s'exposer au danger de devoir tout recommencer plus tard?

• Comment peut-on tourner les exigences qui ne sont pas encore suffisamment clarifiées parce que, au début du projet, pas toutes les informations importantes étaient disponibles?

À cette occasion, il faut se rappeler que même la "méthode agile" n'aide pas dans de telles situations, parce qu'à la place d'une action sérieuse on cherche un raccourci. Mais on provoque assez souvent des coûts considérables à un lieu non prévu avec un mal essai d'épargner effort dans une autre partie. Ce dilemme semble bien connu dans l'histoire culturelle humaine - ce proverbe de la philosophie Zen est transmis: "Si vous êtes pressé, prenez un détour." Quand même dans la pratique un dévéloppeur est souvent confronté aux situations suivantes:

• Les faits pour les décisions importantes de conception sont parfois assez minces.
• En raison d'un calendrier serré pour le projet, des décisions de conception, qui sont plus tard reconnues comme mauvaises, ne peuvent plus être corrigées.

• Dans des projets précédents, nous avions peut-être fait l'expérience que, malgré un calendrier serré, il aurait été préférable de changer une mauvaise conception le plus tôt possible. Dans la pratique, cependant, personne ne veut prendre la responsabilité pour une refonte radicale, parce que dans le cas d'un échec la décision vraiment correcte serait immédiatement attaquable. Par conséquence, la déclaration précédente est généralement valable: Une décision mauvaise faite au début ne peut plus être corrigée postérieurement.

À la recherche de l'eau

Le défi est d'atteindre les objectifs du projet, même si le temps disponible et les informations existantes n'offrent pas une base solide pour les décisions de conception à long terme. Les compétences techniques ne suffiront pas dans ces conditions. Au lieu de cela, la question est de se décider pour une des méthodes différentes de solution. Dans les sections suivantes, nous avons illustré le problème abstrait de cette recherche par trois scénarios exemplaires d'une "recherche fictive de l'eau", avec laquelle nous voulons montrer au moyen d'analogies ce qui doit être considéré à notre avis.

Essayé tout ce que possible

La présente illustration est destinée à exprimer ce qui suit:

• Pour économiser de l'effort dans la recherche, on a appliqué une méthode standardisée, qui peut facilement être reproduite n'importe où.
• Bien qu'on a effectué des forages exploratoires dans des endroits significatifs, on n'a jamais trouvé l'eau.

• Finalement, on a abandonné l'emplacement, parce qu'il semblait prouvé qu'il n'y a pas d'eau dans cet endroit – après tout, on a "tout essayé".

D'une perspective avec les informations complètes l'échec peut être évalué comme suit:

• On a sous-estimer l'étroitesse de la méthode choisie (profondeur bas du percement).
• Les échecs continuels devraient soulever des doutes de la méthode.

• Surtout si on avait du succès avec certaines technologies et procédures déjà dans le passé, le désir de prendre les méthodes éprouvées sans nouvelles investigations augmente.

Travaillé profondément

Avec cette illustration nous voulons montrer le suivant:

• L'arbre présent a été considéré comme un signe certain qu'il doit y avoir de l'eau ici. En conséquence, on ne s'est pas attardé aux forages exploratoires, mais immédiatement mis en place une plate-forme définitive et foré dans les profondeurs.

• Après que toutes les ressources disponibles auraient été épuisées, on devrait remettre l'emplacement, parce qu'on n'a pas trouvé l'eau malgré le plus grand profondeur du percement.

D'une perspective avec les informations complètes l'échec peut être évalué comme suit:

• On ne doit jamais renoncer à la vérification des hypothèses de base importantes.

• À l'avance, des scénarios d'urgence doivent être élaborés, qu'on peut réagir aussi dans un cas d'échèc imprévu.

Grand effort

Le dernier exemple veut illustrer un cas couronné de succès mais quand même problématique de recherche à l'eau:

• On a commencé avec une méthode éprouvée (percement verticale) sans vérifier si cela est le mieux pour les conditions actuelles.
• Quand on a réalisé que c'est impossible d'atteindre le but de cette façon, on a changé la direction pour sauver le premier percement. Cependant, on n'a pas remarqué, que le percement était déjà trop profond.

• Finalement, on était si près du but et avait seulement bésoin d'un petit percement verticale vers le haut. Bien que cette dernière pièce a causé des extrêmes difficultés techniques, il a été finalement réalisé.

D'une perspective avec les informations complètes on peut analyser ce scénario comme suit:

• Le premier commencement avec un percement vertical était vraiment mauvais, parce qu'un percement horizontal en haut par le bas de la montagne serait beaucoup plus facile.
• Même après avoir atteint le point d'extrémité horizontale ci-dessous du lac, il aurait probablement été encore moins cher de remettre le percement précédent et au lieu de cela, recommencer un nouveau percement horizontal au pied de la montagne.
• Évidemment, les dépenses pour les 5 derniers pourcents de la solution étaient sous-éstimées.

• Comparé aux alternatives simples qui étaient possibles, la conception existante est techniquement inutilement complexe et nécessite un entretien coûteux à l'avenir.

Conclusion de la "Recherche de l'eau"

Les commentaires pour les exemples de scénarios sont basés sur une "perspective avec les informations complètes" qui ne sera jamais atteint dans la réalité:

• Quand on échoue, comme montré dans les scénarios, on ne sait pas quelle est la distance à une solution possible ou dans quelle direction elle se trouverait.

• Même avec le dernier exemple dans lequel le but était encore atteint, dans la pratique on ne trouverà pas d'équipe de projet, qui postérieurement relativise son propre succès et admet par exemple: "Ça pourrait être atteint beaucoup plus facilement!" Plutôt on va souligner l'exceptionnelle exécution technique qui a permis, malgré toutes les difficultés, la réalisation du dernier percement.

Perspective distordue aux ébauches de solution

Si, dans une situation réelle, on veut évaluer d'avance la praticabilité des solutions possibles et postérieurement les résultats obtenus, on probablement trouve plusieurs opinions différentes:

• Les décisions sur la méthode à la recherche des solutions sont souvent faites sur la base des informations pas complètes et laissent une grande marge pour des interprétations personnelles.
• Dès que nous devons entrer dans un territoire inexploré, au moins pour une partie du projet, nous généralement essayons de choisir des solutions basées sur des expériences positives des projets déjá réalisés. Dans ce cas, la sélection disponible dépend naturellement sur la disponibilité des expériences déjá existantes dans l'équipe de projet.

• En outre, l'environnement organisationnel du projet exerce, directement ou indirectement, une influence notable sur la liste de la première selection.

Ainsi, dans la recherche de solutions se dévéloppe une forte dynamique propre dépendente de la situation spécifique du projet, avec laquelle on ne peut guère décider d'avance, si la solution choisie est la meilleure ou sera couronné de succès. Même postérieurement, on ne peut pas constater, si une autre méthode aurait donné de meilleurs résultats ou quelles autres solutions n'aurait pas échoué. Dans ces circonstances, aucun effet d'apprentissage peut se produire, qui conduit à des meilleurs résultats au moins dans des projets suivants.

Compensation du manque d'informations

À notre avis, la meilleure façon de traiter ce dilemme est de neutraliser les conséquences qui résultent des nombreuses informations manquantes au début du projet:

• Généralement, nous préférons de mesurer au lieu d'estimer. Aucune décision technique qui produit des efforts considérables, doit être faite sans base d'information suffisante. Par rapport à nos exemples, cela signifie qu'on doit préparer les percements exploratoires aussi élaborés que nécessaire.

• Dépendant de la tâche, il faut être ouvert à un grand spectre de technologies basé sur lesquelles on travaille sur la solution. Par rapport à notre exemple du succès trop coûteux, cela pourrait signifier, par exemple, d'executer le percement horizontal, ou au lieu de cela, de poser un pipeline à travers la montagne.

Conséquences pour le développement

Naturellement, toutes les certitudes obtenues ont leur prix dans la forme d'un effort supplémentaire au début du projet. Cependant, ces dépenses se relativisent considérablement par les raisons suivantes:

• Le terme "mesurage" utilisé ci-dessus peut être considéré comme une série de prototypes en développement de logiciels. Surtout dans un environnement partiellement inconnu des prototypes significatifs devraient être une première étape évidente pour éviter des coûts avancés qui résultent des obstacles inattendus.

• Si nous nous bornons à l'essence d'une question, il est généralement étonnamment facile de recevoir des résultats sérieux prototypiques. Tester plusieurs approches différentes est donc pas de véritable problème d'effort. Un prototype peut être réutilisée pour extraire la quintessence d'une conception modulaire finale, et que ce soit seulement en termes de connaissance exacte des besoins réels.

Du point de vue d'un développeur il y a la possibilité de compenser l'incertitude dans la recherche de solutions au moyen de compétences techniques. Pour minimiser les dépenses supplementaires, les compétences techniques suivantes sont les plus importantes:

• créer rapidement des prototypes raisonnablement réduits, même pour des tâches compliquées
• haute qualité de la mise en œuvre prototypique de telle sorte qu'il sera plus tard possible de prendre en charge des éléments essentiels dans la conception finale avec peu d'effort

• avoir un bon sens de la façon de traiter les différentes technologies pour choisir la plus appropriée qui convient à l'environnement du projet et à l'application