Laurent HAUSERMANN

Parmi mes différentes lectures autour du Génie Logiciel, le livre Rapid Developpement a été pour moi un des plus importants. Son auteur est un des consultants senior du monde Software les plus reconnus Outre-Atlantique. Il a oeuvré au sein de Microsoft afin d'améliorer leurs processus et leurs "Best Pratices".

Steve McConnell définit dans cet ouvrage un concept essentiel, que j'appelerais le "McConnell's Triangle" (que d'autres appeleront, "Triangle of Truth" or "Gold Triangle").

Il s'agit en réalité de comprendre qu'en terme de réalisation de logiciels :

Le planning (schedule), le coût (cost), et le produit (product) forment un équilibre.

 

Prenons un exemple :

Vous êtes responsable de la nouvelle version 3 d'un superbe application de gestion... Vous souhaitez rattraper votre concurrent qui propose déjà un produit plus complet que le vôtre (ie la version 2.6 déjà sortie). Vous souhaitez rattraper ce manque fonctionnel... c'est d'ailleurs ce que demande votre département Marketing ! Mais dans le même temps, votre entreprise cherche à faire des économies et votre PDG a engagé un cost killer. Et pour couronner le tout, vos commerciaux font des pieds et des mains pour remporter un énorme appel d'offre, ce qui demande de livrer un produit en temps et en heure. Bref, vous avez à trouver un équilibre entre :

• Product : Ce que vous voulez faire .... par exemple un large jeu de fonctionnalités ou alors un ensemble plus restreint mais offrant une meilleure ergomie et un meilleure productivité
• Schedule : Quand votre produit sera sur le marché ... c'est à dire concilier le Time to Market (si je sors mon produit après que le marché soit équipé, la partie est perdue d'avance) et le Time to Build (neuf femmes feraient-elle un enfant en 1 mois ?)
• Cost : Avec quels moyens vous allez réaliser votre produit ... allez-vous utiliser vos ressources internes ? rechercher des partenariats ? Bref, répondre à question Make or Buy ?... Ou même Make Offshore désormais.

Quel dilemme ! D'autant qu'il faudra, durant les spécifications, le développement et les tests, veiller à maintenir cet équilibre... et ce, jusqu'à la General Availability du produit ! Vous avez interêt à conserver ce schéma en tête qui vous aidera à répondre aux questions comme "Pourrait-on faire cette feature en plus ?" ou "Il me faut le produit dans 6 mois" (You said "Release Often" ?)

Pour conclure, je dois avouer que je suis réellement enthousiaste avec ce concept d'équilibre. Gérer les risques, négocier, comprendre les besoins internes et externes autour du produit, font des metiers de création de produit et de valeur des jobs attractifs et excitants. Non ?

PS: J'ai faillé appeler cette note "Triangle de Hausermann", tellement ces concepts me semblent être la "vérité"... mais rendons à César ce qui est à César ...

"Libérez cette nouvelle version", semble être l'injonction à la mode dans le monde de l'open source et du Logiciel en général.

J'évoquais déjà notre envie à tous de voir sortir plus souvent nos logiciels préférés. En effet, dans les temps qui cours, on ne peut pas rester plus de 6 mois sans apporter de nouvelles versions, de nouvelles fonctionnalités à ses utilisateurs, à ses clients.

Il est vrai que les usages en matière de gestion de cycle de vie sont extrêmement variables en fonction des entreprises et des projets open source majeurs. Ainsi, Microsoft explique en détail sa politique de gestion du cycle de vie de gestion du cycle de vie de ses produits (on notera un effort d'explication remarquable de la part de l'éditeur) et distribue de ses produits environ 5 ans. Suite à ces 5 années (une moyenne), le support se poursuit pour environ 2 années après la fin des ventes. On notera tout de même une accélération du cycle de vente car on passe d'un cycle sur 7/8 ans pour MSDOS 6 (!), à un cycle sur environ 5 ans pour Windows XP.

Les projets open source ont, quant à eux, des politiques de sortie de versions très diverses, allant du vieil adage "When it gets ready" (entendez, "quand ca sera prêt"), à des cycles plus stricts de 6 mois comme les projets Gnome, ou OpenBSD. Mais ces projets open source ressentent aussi la même pression de leurs utilisateurs et il est fort probable que la gestion des sorties, le rôle de Release Manager, devienne prépondérant au sein des communautés.
Ainsi, le projet Debian, qui doit renouveler son "Debian Project Leader"s'anime autour de la question de la gestion des release.

"Libérez !", sembleraient donc dire les usagers des logiciels et les producteurs de logiciels de s'adapter en conséquence...

Mais plein de contradictions, nous cherchons des logiciels qui durent (l'affaire Bouygtel nous l'avait rappelé).

J'en veux pour preuve l'émotion que suscite l'arrêt par Microsoft du support gratuit et du développement de VB.6.
Certains vont même jusqu'à lancer des pétitions à Microsoft pour que la société éditrice continue à faire vivre le langage. La grogne des développeurs est compréhensible : après avoir investi tant d'années dans des développements VBA et VB6, pourquoi devraient-il continuer à investir dans la technologie VB.NET pour refaire ce qu'il ont déja ?.
Joel Spolsky, enfonce le clou :

But here's the thing. If you have a million line code base that's mission critical, as many companies do, and VB suddenly changes, as it did, you have a choice: keep using VB 6 or spend a lot of time (=money) upgrading to VB.NET. If you keep using VB 6, eventually new things will come out that will not be supported from VB 6, and you'll be stuck using the yucky old VB 6 IDE until the end of time. Already most of the big component vendors are doing all the new components as .NET components, not OCXes.

If you spend the money to upgrade to VB.NET, well, you just spent a lot of money to stand still. And companies don't like to spend a lot of money to stand still, so while you're spending the money, it probably makes sense to consider the alternatives that you can port to that won't put you at the mercy of a single vendor and won't be as likely to change arbitrarily in the future. So as soon as people with large code bases start hearing that they're going to have to work to port their apps from VB to VB.NET with WinForms, and then they start hearing that WinForms isn't really the future, the future is really this Avalon thing nobody has yet, they start wondering whether it isn't time to find another development platform.

J'avais d'ailleurs senti un sentiment de frustration chez les développeurs de la communautés Microsoft qui n'ont pas aujourd'hui les idées claires. Quelles seront leurs "fondations" de demain avec des technologies de développements Microsoft évoluant très (trop ?) vite. Lors des DevDays nombreux étaient ceux qui se faisaient du soucis pour leurs anciens applicatifs...

Quelle autres alternatives ont ces développeurs ? Migrer vers des langages de développements open source, qui leur garantissent une maintenance facilitée , car avec les sources, à coeur vaillant, rien d'impossible :). Ces langages, tels que Perl, Python, offrent surtout un processus d'évolution pragmatique, et permettant aux communautés d'utilisateurs/développeurs d'influer sur les modifications, les évolutions. En quelque sorte, ces projets permettent un contrôle par les usagers de leur outil de travail (qu'est-ce qu'un langage de développement sinon ?).

Bref, si on doit aujourd'hui offrir toujours plus de fonctionnalités et de nouveautés, il faut toujours veiller à faire progresser sa base installée vers ces nouvelles versions.
Les investissements réalisés aujourd'hui autour des logiciels et des réseaux ne peuvent pas être remis en cause, tous les 5 ans, à cause de la politique Marketing d'une grande société. L'open source, par la capacité de maintenance qu'il offre à ces utilisateurs permet de construire aujourd'hui des logiciels qui seront maintenus demain.

Note à toutes les entrepreprisies : vos clients d'hier seront sûrement ceux de demain, il serait donc plus prudents de ne pas les semer en route... (qu'on se le dise à RedMond !)

"Continuer à innover" doit rester la devise des sociétés produisant de nouvelles technologies et de nouveaux logiciels.

Sans innovation, point de salut, car toutes ces entreprises sont en concurrence avec :
o d'autres entreprises "similaires", déjà installées sur le même marché
o d'autres entreprises en cours de création ou de gestation ...

En effet, les startups ont souvent ce rôle de "casseur" de marché via une innovation double car à la fois technologique et marketing... C'est de cette façon qu'Handspring a grignoté des parts de marché à Palm Computing ou que Sony (quoique n'étant pas une startup ;) avait "déboullé" sur le marché de la console de jeux avec la PlayStation (quel succès !).

Nous avons aussi déja débattu ici, comment Firefox réussit, en innovant, à conquérir des parts de marché.

Et j'ai l'impression que l'entreprise BlogSpirit, l'a bien compris : avec la création des communautés (voir aussi ces conseils), BlogSpirit se démarque et offre un véritable plus à ses usagers.

Je publie cette note dans la Communauté Innovation, qui m'apporte quotidiennement des nouvelles sur les technologies et les secteurs où la
recherche et l'innovation avancent. Je vous invite à rapidement vous abonner à ce flux d'informations qui vous permet de *sélectionner et trier* à l'avance les informations qui vous arriveront.
Vous y trouvez aujourd'hui les blogs suivants :

o Programme Parthénon,
o E-Mergences, "la fabrique du futur"
o Denis FAILLY, Matière(s) à penser autrement Marketing et Management en environnement incertain et complexe
o Ma Revue De Web, Une sélection, par votre serviteur, des meilleures "brèves" pêchées ici et là…
o et les notes de votre serviteur ...

Bravo pour cette innovation !

Suite à mes notes (ici, ici et là) sur les brevets, les standards et diverses stratégies d'entreprises, voila un nouvel élément (via LinuxFR) :
IBM décide d'autoriser certains projets OpenSource à "violer" 500 brevets détenus par IBM.

Ce qui est significatif de leur stratégie et de leur vision de l'innovation :

While IP ownership is an essential driver of innovation, technological advances are often dependent on shared knowledge, standards, and collaborative innovation. IBM's IP framework enables both while protecting truly new, novel and useful inventions. Open standards can accelerate the interoperability and expansion of the global infrastructure.
"True innovation leadership is about more than just the numbers of patents granted. It's about innovating to benefit customers, partners and society," said Dr. John E. Kelly, IBM senior vice president, Technology and Intellectual Property.

J'aime assez cette idée qui voudrait qu'on ne pourrait innover correctement qu'après avoir échangé et établi des standards avec une communauté "ouverte". Notez qu'IBM ne présente pas les choses comme "un cadeau", mais comme une nécessité pour avancer.

Qu'en pensez-vous ? N'hesitez pas à réagir sur mon blog !

MAJ : Acceuil Mitigé pour IBM