I’ve heard people say something like “You shouldn’t install Beta software unless you’re prepared to wipe your hard drive and reinstall everything, OS included”
Méthodologies
Sur son blog, After the Bubble, Fabien Benoit regrette de ne pas trouver de développeur français parlant des problèmes de méthodologies de développement. Et il pose la question du “Combien de design?”. La réponse est comme bien souvent: “ça dépend…” Voici donc quelques éléments que je vous invite à compléter pour alimenter la réflexion.
Vue d’ensemble
Lorsque je discute méthodologie j’aime bien débuter avec le RUP, autant les outils rational me donne des boutons autant je trouve le RUP utile. Si vous avez l’occasion d’être formé à RUP ou d’avoir accès à la documentation RUP foncez. La méthode donne une vision d’ensemble du processus de développement notamment à travers ce fameux schéma:
Vous pouvez retourner le problème dans tous les sens, un projet informatique est une série d’activité qui (devrait) se déroule(r) dans l’ordre suivant:
Ces activités se répartissent en différentes phases:
– Inception (ou démarrage)
– Élaboration (ou conception)
– Construction (ou développement)
– Transition (ou recette et mise en production)
Selon la méthodologie chacune de ces activités ou phases sera plus ou moins importantes ou nommées différemment mais on fini toujours par les retrouver.
D’ailleurs je qualifierais le RUP de meta-méthodologie. En effet la première étape d’une démarche RUP consiste à le configurer pour instancier sa propre méthodologie. Rien n’empêche de faire de l’XP dans une démarche RUP.
Les cycles de vie d’un projet
Je viens d’affirmer que les activités devaient toujours se dérouler dans le même ordre mais ça n’empêche pas d’organiser leur déroulement de nombreuses manières.
Le cycle en cascade
Le cycle classique, les activités sont exécutés les unes après les autres une seule fois.
Gros défaut de ce cycle: Si les premières phases (inception/élaboration) se déroulent mal, on ne s’en rend compte que dans les phases de fin de projet (construction/transition) c’est l’effet tunnel.
Mais pour un projet simple avec peu d’incertitude c’est ce qui fonctionne le mieux.
Le cycle incrémental
Le projet est découpé en lot chaque lot est réalisé successivement ou en se chevauchant selon un cycle en cascade. Ce découpage permet de réduire la durée d’un cycle complet ce qui limite l’impact de l’effet tunnel.
Ce cycle permet de traiter des projets relativement complexes mais reste inefficace si le besoin évolue en cours de projet.
Le cycle itératif
Consiste à dérouler plusieurs fois de suite un cycle en cascade. A chaque nouvelle itération on affine les spécifications et on corrige les erreurs de l’itération précédente.
Ce cycle permet de s’adapter en cours de projet aux changements mais ne permet pas forcément de traiter de gros projet.
Le cycle en spirale
Il s’agit de combiner les cycles itératif et incrémental. A chaque nouvelle itération on ajuste ce qui a déjà été réalisé et on l’enrichit en traitant un spectre fonctionnel plus large.
Ce cycle est le plus adapté pour traiter des projets complexe et incertain. Gérer un projet de cette manière est bien plus compliqué que de suivre un simple cycle en cascade il nécessite donc à sa tête un chef de projet expérimenté.
Le cycle en Y
Utilisé par la méthode 2TUP de Valtech ce cycle propose de séparer en 2 branches les activités de recueil des besoins et d’analyse: une branche dédié au fonctionnel l’autre à la technique les deux pouvant se dérouler en parallèle.
Ce cycle est adapté aux projets nouvelles technologies car il permet de lever au plus tôt les incertitudes techniques caractéristiques de ce type de projet.
Il est compatible avec les autres approches.
Globalement les projets étant toujours incertains et complexe on ne fait plus des cycles en spirale, si en plus il y a du nouveau concernant les technologies utilisé, le cycle en Y est fortement recommandé.
Malheureusement tout cela n’est que la théorie, en pratique il se passe trop souvent ceci:
En raison de multiples contraintes les phases de recueil des besoins et de spécification sont réduites à leur portion congrue, les développements démarrent en avance de phase et comme ça coûte cher, on demande au développeur de faire la conception en même temps que les développements. On déploie et ensuite on teste.
Les méthodes agiles
Les méthodes agiles ont émergé en réaction à la situation décrite précédemment et partent des constats suivants:
– Les utilisateurs ont de grandes difficultés à exprimer leur besoin sous une forme exploitable par les équipes techniques.
– Les spécifications n’arrêtent pas de changer.
– Les projets l’engluent dans la gestion de projet et la rédaction de documents qui ne sont jamais lu.
– …
Le remède: exit les specs, exit la gestion de projet lourde, exit la doc.
La méthode agile la plus connue, XP, se base sur un cycle en spirale très condensé avec une injection permanente des besoins en direct par le client (client sur site).
Avec la méthode XP le formalisme lourd des méthodes non agile est remplacé par un ensemble de pratiques centré sur le développeur, au premier rang desquelles on trouve les tests unitaires, l’intégration continue et le refactoring.
Les méthodes agiles répondent bien au besoin de faire avancer un projet alors que le client ne sait pas exactement où il veut aller. Par contre il ne faut pas se leurrer, XP s’adresse à des développeurs expérimentés. Les tests unitaires et le refactoring ne sont pas des pratiques à la porté du développeur débutant. Évidemment la pratique du pair programming permet d’atténuer ce problème en associant un développeur débutant avec un autre plus expérimenté. Mais je n’ai encore jamais vu aucun manager accepter de mettre 2 ressources là où une seule peut suffire.
Enfin XP ne permet pas de connaître à l’avance les fonctionnalités, la durée et le coût d’un projet, ce qui reste le fantasme la préoccupation n°1 des décideurs. Cette question du coût, des délais et des fonctionnalités fera l’objet d’un autre billet.
Une méthode idéale ?
Il n’y en a sans doute pas, mais j’ai pu observer de bon résultat en combinant:
– Un cycle en spirale pour gérer les évolutions et maîtriser la complexité.
– Une approche en Y pour lever les incertitudes technologiques.
– Certaines pratiques XP pour garantir la qualité de l’application
Ce sont des pratiques qui sont de plus en plus répandues, en raison de leur relative complexité elles ont peu de chance d’aboutir sans s’appuyer sur des ressources expérimentés.
Combien de design ?
Avec une méthodologie agile et une équipe expérimenté capable de pratiquer le refactoring, c’est à dire du design en continue, on peut sans doute se passer du “Big Design Up Front”. Mais agile ou pas, un élément reste indispensable: le cahier des charges. De préférence sur 2-3 pages, allant à l’essentiel et permettant de donner une direction au projet plutôt qu’un fourre tout de 50 pages rédigé dans un langage juridique et qui tenterait de tout prévoir à l’avance.
Pour poursuivre la réflexion je vous invite à visiter la page: état de l’art des méthodologies sur le site de la direction des systèmes d’information du CNRS.
WS-machiavellian ?
I remember talking with Andrew Layman, one of the SOAP architects at Microsoft. He let slip that it was actually a Microsoft objective to make the standard sufficiently complex that only the tools would read and write this stuff, and not humans. So that was a strategy tax that was imposed by the big companies on some of this technology, where they made it more complicated than it needed to be so they could sell tools.
Tim O’Reilly (source: WS-* vs. the REST )
Intégration SOA avec Google reader et SimplePie
La lecture de ce retour d’expérience m’a ouvert les yeux: SOA integration with Flickr and del.icio.us. Comme Mr Jourdain fait de la prose, je fais de la SOA sans le savoir avec ce blog!!
En effet, le comité de pilotage exécutif de ce site de gestion personnelle du savoir et de la connaissance a récemment décidé d’intégrer à cette application des informations à haute valeur ajouté en provenance de notre application d’agrégation de nouvelles. Cette évolution nous permet d’enrichir l’expérience utilisateur afin de créer de la valeur, de développer notre part de marché et d’asseoir notre position de leader dans notre secteur d’activité.
Cet article détaille le travail de nos équipes ayant permit de relever ce défi. Après 10800 secondes/homme d’effort, l’utilisation d’une architecture SOA on demand et d’outils innovants à la pointe de la technologie nous ont permit d’obtenir une qualité de service optimale pour un coût de gestion réduit. Le retour sur investissement a été immédiat avec une croissance de +50% de notre trafic.
Le défi a relever:
Dans l’optique de minimiser les coûts et d’assurer une qualité de service irréprochable l’ensemble de notre système d’information est outsourcé sur la plateforme mutualisé du leader de l’hébergement haute performance: textdrive. Afin de fournir à nos utilisateurs cette application de gestion personnelle du savoir et de la connaissance nous avons déployé l’application open source de gestion de contenu WordPress qui a été enrichie des extensions fournie par K2.
Dans un marché en pleine expansion nous avons sélectionné l’aggrégateur/lecteur de news le plus adapté à notre besoin: Google reader. Extrêmement bien positionné dans les quadrants magique du Gartnerr, la commercialisation gratuite de cette offre en mode ASP en a fait un choix incontournable.
Nous avons fait appel à une équipe de consultants experts pour faire apparaître dans notre application de gestion du savoir et de la connaissance des informations à haute valeur ajouté sélectionné dans notre lecteur de news.
La solution
Pour répondre aux attentes du marché nous nous sommes naturellement orienté vers une solution de type SOA. Suivant les best pratices de la profession un système intermédiaire d’intégration d’application a été mis en place pour faire communiquer les deux systèmes entre eux, ce choix permet d’atteindre les objectifs de couplage lâche de toute architecture SOA.
Nous avons sélectionné l’EAI de type ESB-lite: SimplePie. Bien qu’en bêta le produit de cette startup en forte croissance propose déjà des fonctionnalité de niveau entreprise et le support des tout derniers standards du W3C: ATOM, WS-HTTP et WS-BLOG.
SimplePie fournit “out of the box” l’ensemble des fonctionnalités requises pour l’intégration d’application dans les entreprises conçue pour répondre au changement. Dans le même temps SimplePie est facilement customizable pour s’adapter aux besoins spécifiques de chaque client.
La preuve par les faits: notre directeur de la publication a pu lui même customizer et paramétrer SimplePie pour réaliser l’intégration de googleReader dans WordPress comme vous pouvez le constater sur la droite dans la section: “Dernières lectures en direct”.
Dans un premier temps, en raison de l’afflu de visiteur, le site a connu quelques problèmes de performance. Heureusement grâce à notre un contrat de support on-site 24/7 +1 un expert a depuis chez lui et en caleçon pu activer une fonction tout a fait innovante de SimplePie permettant de régler ces problèmes de performance. Il s’agit de la fonction: “cache”. SimplePie est le premier produit du marché à implémenter cette technologie ultra sophistiqué issue des travaux du MIT.
L’utilisation de l’architecture SOA et de produits à la pointe de la technologie participent pleinement à la réalisation de nos objectifs et nous donne une longueur d’avance sur la concurrence.
Le futur:
Nous prévoyons aussi l’intégration d’image en provenance de Flickr. Mais le cas Labnotes nous a mis en garde concernant les difficultés relatives aux différente tailles d’images. Nous avons donc commandé une étude à notre réseau de partenaires/consultants à valeur ajouté. Ils ont immédiatement identifié une difficulté supplémentaire: les images peuvent nous parvenir en noir et blanc mais aussi en 256 couleurs, voir en plusieurs millier ou million de couleurs! Au moment où j’écris ces lignes, nos experts ont encore des doutent sur la capacité de notre solution initiale à supporter une telle monté en charge.
Les ventes de livres O’Reilly
Une manière de suivre les “tendances” dans le monde des technologies et de se rendre dans une librairie et de mesurer la taille des rayons ou de compter le nombre de livres dédié à telle où telle techno.
Je vous l’accorde, la méthode est un peu rustique et peu fiable. Mais quand c’est Tim O’Reilly, l’éditeur, qui se livre à ce petit jeu en utilisant les chiffres des principaux point de ventes aux USA, ça devient très intéressant.
A lire State of the Computer Book Market, Part 1 pour découvrir la méthode, et part 2 pour rentrer dans les détails.
Par exemple sur le graphique languages de programmation: évolution des ventes de livres O’Reilly aux USA entre les premiers trimestres 2005 et 2006 on trouve:
java -6%
C# +68%
Ruby +733%
Note: en volume java reste 1ere devant C#, Ruby reste loin derrière.
Je vais donc poursuivre ma lecture de ce bouquin sur Ruby… La Ruby On Rails mania m’a contaminé 😉 On en reparle dans un autre billet.