BrunoLegros.net

A quoi ça sert Scrum ?

A amuser les développeurs pardi !!

(Lecteurs non-informaticiens, vous pouvez vous arrêter là :-P)

C’est à peu près le langage qu’à tenu un des animateurs du dernier Paris JUG en présentant Scrum, une méthode de développement logiciel agile dans la lignée de l’eXtreme Programming. Scrum propose un cadre plus construit que ces prédécesseurs et une organisation crédible. Il tend à positionner l’équipe de développement au coeur du projet informatique et à la rapprocher considérablement du client final.

Je fus assez surpris par le recul de cet animateur et par la véracité de son affirmation : quel argument en faveur de Scrum !! Mais oui, c’est évident ! Un des avantages majeurs d’XP, Scrum, de l’esprit communautaire du développement logiciel, du javablackbelt, etc., c’est bien sûr d’amuser les développeurs ! De leur donner enfin la reconnaissance qu’ils attendent et qui va les motiver ! Et comme partout, un développeur motivé en vaut 5.

Qui s’ennuie dans son métier de développeur ?

Un quart de la salle lève la main…

Les méthodes de développement de type RUP, prônant la modélisation à outrance, ont progressivement réduits les développeurs à de simples traducteurs d’UML en code, offshorisables. Face à ce constat, les méthodes agiles apparaissent comme une délivrance, comme un moyen de reconnaissance, un moyen de redorer le blason des métiers du développement logiciel.

Le développement n’est plus vraiment dans mes préoccupations premières aujourd’hui, mais ayant cotoyé ce milieu pendant un certain temps, adopté et défendu ses idées, j’y suis encore un peu attaché et j’aime à me tenir informé de ses évolutions (et en informatique, se tenir informé, ça s’appelle l’instinct de survie). La présentation fut pédagogique et fort instructive, surtout pour un ex-développeur

Merci les JUGgers !

Ian Rogers, directeur général de Yahoo Music dit en parlant des DRM :

« Combien d’opportunités avons-nous perdues en huit ans ? [...] Je suis venu ici pour vous dire que je ne tomberai plus dans le piège. Je ne laisserai pas Yahoo dépenser encore de l’argent dans des pratiques désagréables pour l’utilisateur. »

Ca fait plaisir mais ça s’est fait un peu tout seul… Je ne suis pas sûr que manifester contre les DRM ait servi à quelque chose. Les maisons de disque ont foncé dans le mur et ont entraîné leurs partenaires crédules avec eux. le réveil est brutal mais les anti-DRM ne pourront que dire “On vous avait prévenu… mais notre action a été inutile”.

Comme vous le savez peut être, en France, un projet informatique est organisé en strates :

• Le client : Le roi, c’est lui qui a le besoin, c’est lui qui paye, c’est lui qui gueule.
• La maîtrise d’ouvrage ou MOA : Souvent confondue avec le client (à tord), c’est elle qui assure le lien entre client et MOE. Elle formalise les besoins des clients et s’assure que la solution fournie par la MOE réponde bien à ce besoin.
• La maîtrise d’oeuvre ou MOE : C’est l’entité qui réalise la solution spécifiée par la MOA qui répond au besoin du client.
• L’exploitation : En charge de l’installation et de l’exploitation de la solution en production.

En plus de ces 3 couches “classiques”, on trouve régulièrement dans les grandes entreprises françaises les couches intermédiaires :

• L’assistance à maîtrise d’ouvrage ou AMOA (parfois appelée MOA déléguée) qui se situe entre MOA et MOE
• L’assistance à maîtrise d’oeuvre ou AMOE (parfois appelée MOE déléguée) qui se situe entre MOE et Exploitation

Je n’entrerais pas ici dans le débat stérile et polémique de l’utilité de ses couches. L’important est de constater que la MOA doit au moins faire confiance à 2 voir 4 couches pour la bonne réalisation de sa solution. Ajoutez à celà que la plupart des projets français suivent un bête cycle en V non itératif et que la MOA ne peut donc “voir” le résultat de la solution qu’à la fin du cycle complet. Elle doit donc faire confiance à toutes les strates sous-jacentes pendant toute la durée du projet (souvent plusieurs mois !).

Comment alors ne pas stresser lorsqu’on fait partie de ces couches supérieures ? Lorsqu’on a finalement aucun point de contrôle intermédiaire et donc aucune maîtrise du résultat final ? Les couches supérieures sont bien dépendantes des couches inférieures et pas l’inverse.

Ceci me rappelle une petite fable sans auteur (Si vous trouvez l’auteur, faites moi signe :-)) :

Lire la suite »

Comme je le disais dans ce post, J’ai participé à un forum traitant du SOI au Palais des Congrès de Paris le 24 octobre 2006. J’ai fait un retour sur le module “Services Management” du forum à ma boîte ainsi qu’un résumé de chaque présentation. Je livre ici simplement le retour : Lire la suite »

On vend souvent la SOA en mettant en avant sa capacité à produire des services réutilisables. La réutilisation des composants est une espèce de GRAAL de l’informatique déjà promis par la programmation orientée objet. On voit bien aujourd’hui que la OOP n’a pas tenu cette promesse. Mais qui remettrait en cause les bienfaits de la OOP ? De la même manière, je pense que c’est une erreur de parler autant de réutilisabilité avec SOA pour plusieurs raisons :

• La réutilisabilité ne s’obtient qu’au bout d’un certain temps qui se mesure certainement en nombre d’années concernant SOA. En effet, pour qu’il y ait réutilisabilité il faut qu’il y ait plusieurs applications utilisant les mêmes services et celà prend du temps. Un client qui ne constate pas la réutilisabilité promise dans l’immédiat peut être frustré.
• La réutilisabilité mesurée aujourd’hui est très faible. Gartner parle de 20% de réutilisation potentielle de services, ce qui paraît déjà beaucoup.
• SOA a tellement d’autres atouts (meilleure vision des services métiers, orchestration, couplage lâche, agilité …) que parler de réutilisabilité, qui n’est qu’une infime conséquence de la mise en place d’une SOA, paraît purement marketing voire destructeur du concept.

–

Ajout du 11/11/2006

Petit clin d’oeil de Miko Matsumura sur la réutilisabilité: 100% des services sont réutilisés puisque ce ne sont que des expositions de fonctions existantes, donc déjà utilisées :p