10/11/2005
Triangle de McConnell
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 ...
00:50 Publié dans Software Mentors | Lien permanent | Commentaires (2) | Envoyer cette note | Tags : Innovation
Commentaires
Le triangle devrait être une pyramide... il manque un élement essentiel qui est la qualité.
Elle est transversale à ces trois concepts :
- elle peut (ou pas) avoir un impact sur le coût total du développement
- elle peut (ou pas) avoir un impact sur la date de sortie
- elle peut (ou pas) avoir un impact sur les fonctionnalités faisables dans l'enveloppe de temps et de fonds allouée
Si on part dès le départ avec un focus sur la qualité logicielle, on peut supposer que le coût de développement des fonctionnalités sera plus faible, le temps plus court et donc, à budgets égaux, le produit sera meilleur.
Si on fait des compromis sur la qualité, on tire forcément sur l'un des trois bouts du triangle, et donc le modèle du triangle n'est pas auto-suffisant.
Ecrit par : R. | 10/11/2005
Tout à fait R !
La qualité manque dans ce schéma... qui pourrait passer de triangle à carré... mais j'aurais tendance à considerer la qualité comme un "MUST" non négociable.
Nos clients exigent des produits de qualité et il n'est pas possible de la négliger, ni même de la négocier.
A moyen terme, je pense qu'on finit toujours par payer les compromis fait avec la qualité. Il s'agit donc plus d'un constante au produit, tout comme la maturité logicielle (ie ces processus) l'est pour l'organisation.
Ecrit par : Laurent | 11/11/2005
Les commentaires sont fermés.