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
Agile incremental construction: some tips
Ecris le 31 août 2005
Dans la catégorie Uncategorized | Leave a Comment
Since some time now, I help my customers to design and build their Information System by an incremental approach. I noticed that obviously the term “incremental” does not mean the same thing for every body. For the most common case, the team try to slice its system into layers and build each layer one after the other: for instance the data layer comes first, then the process and finally the GUI. This slicing is driven by technical constraints as you can see in the future application where the database will stand, and when the associated tools will be used to build this particular part.
The drawback of this approach is well known by the agile community: if you fail to finish one of the layers in the planned time and budget, you can be sure you will exceed the project budget. Unfortunately, if your budget was fixed, you project will be a total failure for one problem on one layer.That?s why the agile approach suggests slicing your project into iterations, but also that all iterations must be functionally and technically coherent to be production candidate. That mean each iteration should have a little bit of data, a little bit of process and a little bit of GUI.The question is: how can I slice my big project into coherent slices (or iterations)?
In most case, after some study, or not, the project is launched for a given budget, estimated with more or less precision (generally, the precision is very low at this stage). Let say your budget is 1000. You want to slice your project into 5 iterations of 200. The approach I follow generally is to apply the following simple algorithm:
- Suppose your project budget was only one iteration (200 is this example)
- Determine what you should do for 200: this is your first iteration
- For each following iteration, determine what you should do to improve the application by adding features, or refactoring, for a value of 200.
- Stop the algorithm when your budget is reached.
The idea is that if you burn all your budget (1000) on the first iterations, at least, their functional scope has been designed to have the highest value for the customers. XP calls this practice “the planning game”. Of course, downsizing a 1000 project to a 200 one is not easy and request to have a strong knowledge of the domain to know what is REALLY the core of the business. Domain Driven Design can help you during this process.
Anyway, slicing a project in such a way is a difficult task, but that’s the cost of monitoring your risk efficiently: nothing comes for free!
Social Bookmarking
Commentaires
20 years old agility advices
Ecris le 17 juillet 2005
Dans la catégorie Uncategorized | Leave a Comment
I was recently reading one of the online available books on the Stephane Ducasse web site: Smalltalk V 286 Tutorial from Digitalk Inc. The book has been published in 1986, and it is amazing by itself to see what was possible on such simple PC in those days, compared to the visual C. The book by itself is a very good tutorial, strongly advised if you plan to learn Smalltalk, or just programming. If you are more advanced, you could have a look to chapter 12.
Here is an extract from the conclusion:
- Don’t over plan. Know enough to get going, then go. Smalltalk/V is designed to work with you in evolving, incremental process.
- When re-working a copied method, edit the comment first. Then let the changes made to the comment point the way to lines in the method source code which implement those aspects of the method whose description in the comment has changed. And remember, comments are a critical means of communication among Smalltalk/V programmers.
- Keep moving. Keep your productivity high by writing the “easy ones” first. Very often the act of writing other methods or incubating on a tough one will result in insights to conquer almost any Smalltalk/V programming problem.
A very nice piece of early agile concepts, isn’t?
Those advices are almost 20 years old. It’s time to apply them.
Social Bookmarking
Commentaires
Agile Open 2005 : the feedback
Ecris le 8 mai 2005
Dans la catégorie Uncategorized | Leave a Comment
Open Agile was a very interesting event. It was great for the content of the conference, but also for the form
The form
It was an Open Space format. It was the first I intend this kind of conference. The benefices are numerous:
- You can really interact with other people. You are not just sitting to wait somebody pushing its slides, you actually interact with him to give direct feedback, to expose your thoughts about what is discussed and then get feedback on your own ideas.
- The agenda is not fixed in advance. You can come with your own subject and propose it to the audience. If enough persons are interested, the session is set up!
The sessions
I intended the following sessions:
- Agile Tooling
- Community of trust
- Cynefin Experiential
- Agile Documentation
- Crossing the chasm
- Balancing act
All of those sessions were very interesting, and you can look to the wiki pages to have some ideas of the outputs.
Balancing act
This session was special to me. It is strange, because at first, I did not vote for it: it seemed to complex or out of my scope. Basically, it was an experiment around the Virginia Satir model of communication. I read about it in some books of Gerald Weinberg, but I did not know it in details.
Willem, Nynke and Marc exposed the model to all of us, and encouraged to try it during the session. The session was very interesting, however I did not get the “aha!” effect during it. The effect came later.
I always had the feeling that it what not possible to improve my communication or management skills. It was possible to improve the technical skills, but not the “soft” skills: one was a communicator or was not. Actually, this is false. It is possible to improve your communication and your management skills: that’s what did the Balancing Act for me.
I did get many positive feedback from my improvements, from many different sources. However, I dont want to share those experiences here: this is not the purpose of this blog. All I can say is a recommandation: seek for the Congruence in Action session in the agile conferences to come, which seems to be an improved version of the Agile Open Balancing Act.
Social Bookmarking
