Dessine moi un logiciel
Ecris le 11 décembre 2007
Dans la catégorie Articles | Leave a Comment
Choisissez un collègue informaticien, n’importe lequel, qu’il porte le titre de développeur, d’architecte, d’urbaniste ou de manager. Demandez-lui de dessiner une application informatique.
Il y a toutes les chances que le dessin qu’il vous fera sera constitué de boites, de flèches, et peut être de cylindres. Tous les livres, toutes les méthodologies d’architectures ou d’urbanisme reprennent ce même type de schéma. Certains en ont mêmes fait une science en tant que telle. Il existe autant de types de boite que d’applications. J’ai résumé pour vous ceux que je croise les plus souvent : base de données, écrans, couche service, framework techniques, socle d’échange, gestion des authentifications, référentiel, gestion des habilitations, mapping objet-relationnel, moteur de workflow, etc… etc…
Dés lors que nous avons fait ce constat, nous ne sommes plus surpris par la manière dont sont construites les applications dans la vaste majorité des cas. L’équipe, ou le manager, choisit une boite et commence à l’implémenter. Il commence par exemple par la base de données. Puis il passe à la suivante. Puis une autre. Jusqu’à ce que toute l’application ait été construite. Ce chemin de construction est parfois résumé dans un diagramme de Gantt.
Cette approche présente l’avantage d’être facile à comprendre, par tout le monde. Elle est facile à expliquer et donne le sentiment d’être facile à suivre, facile à piloter.
Elle présente aussi des inconvénients :
- L’application n’est pas fini tant que toutes les boites et cylindres n’ont pas été implémentés
- Si le design d’une boite en cours de construction est influencé par le design d’une boite à venir, il y a toutes les chances que cette dépendance soit découverte plus tard, trop tard.
- Il est difficile de tester l’application tant que toutes les boites n’ont pas été construites.
- Certaines boites vont se révéler inadaptées dans la suite du projet. Il sera plus difficile de les remodeler si elles sont totalement achevées avec l’ensemble de leur complexité.
Si vous choisissez de suivre une approche agile pour la construction de votre application, vous aurez le choix de procéder autrement. Vous pourrez bénéficiez d’une caractéristique unique de la “matière” informatique : tout peut changer, tout le temps.
Ralph Johnson nous le rappel dans un article de Martin Fowler :
There is no theoretical reason that anything is hard to change about software.
Plus qu’un jeu d’éléments qui s’emboitent les uns dans les autres, je vois la construction de logiciel comme la création d’un tableau. L’artiste commence par une esquisse. Le sujet est posé et les grandes masses apparaissent. Mais les détails sont encore flous et la finition n’est pas idéale. Puis il rajoute de la peinture, il fait des mélanges pour voir ce que ca donne. Il revient parfois en arrière par endroit, pour mieux garder une harmonie d’ensemble. Petit à petit, le tableau devient de plus en net, plus précis. Jusqu’au moment où c’est terminé.
L’informatique vous offre la liberté de procéder de la même manière pour construire votre logiciel. Vous avez le choix de commencer par l’implémentation de plusieurs boites dés les premières itérations de votre projet. Vous aurez déjà un premier aperçu de votre application. Ce sera un embryon de ce que vous pourrez obtenir plus tard, mais vous pourrez déjà le montrer à vos clients et obtenir leurs feedback. Ils vous diront ce qu’ils aiment dans ce que vous avez déjà réalisé, ce qu’ils souhaitent que vous changiez et ce qui leur manquent. Tenez en compte pour la suite de votre projet.
Puis ajoutez, affinez, complétez votre application. D’itération en itération, votre vision deviendra plus précise et convergera vers le meilleur compromis possible compte tenu du temps impartis, du budget et ce qui apporte le plus de valeur à vos clients. La construction d’application peut être autre chose qu’un assemblage de briques d’un jeu d’enfant. Elle peut aussi être la création d’une image de plus en plus nette, que vous pourrez recadrer, retravailler tout au long de votre projet.
Social Bookmarking
Commentaires
XP Days France 2006
Ecris le 20 mars 2006
Dans la catégorie Evénements | 1 Comment
La conférence sur l’agilité en France, c’est cette semaine !
Les premiers XP Days de France se tiendront les 23 et 24 mars : il ne vous reste pas beaucoup de temps pour vous inscrire, d’autant plus que je crois savoir que la conférence aura lieu à guichet fermé.Pour ma part, j’animerai une session sur la construction incrémentale. J’espère avoir l’occasion de vous y croiser ;-).
Plus d’information ici : http://www.xpday.fr/
Social Bookmarking
Commentaires
A380 is not a banking software system
Ecris le 21 janvier 2005
Dans la catégorie Uncategorized | 2 Comments
A current discussion on the XP mailing list is about the A380 project success story, and what lessons could be learned from it.This is a quite common mistake to try to compare software development activity for business systems and the industry. The two domains are radically different for many reasons. Let me point two of them.The plane usage conditions are totally knownAll the physical laws that will constitute the plane usage environment are known. It is hence quite easy to design the solution (the plane), and to automate its construction.This is not the case for the software. Most of the time, nobody knows how will be used the system, in what context, and for which purpose. And if at some stage we can know it, there is good chance that those context and purpose will change, and quite rapidly.The manufacturer knows what he’s doingIn the plane industry, everybody knows what a plane is. Even the guy who puts the bolts knows why he is doing it, how this bolt will interact with other piece of the plane, and what will happen if his work is not well done.Again, in software development context, the programmer does not know the business he is coding. He is not an accountant, or an air travel broker. He does not what is complex, or not, and what is important. Even worst, in some case, even the users don?t know it.I think we should stop to try applying industry solutions designed for industry context, to software construction. I am sure, however, that XP is a good solution to real problems of the software development activity.A380 context is driven by physical laws, banking software systems are driven by human activity. That’s make all the difference.
Social Bookmarking
