Manager une équipe de développement Web

Backlog de galets, de coquillages, de sable et d'eau de mer

Depuis longtemps, je me dis que je devrais relire les ouvrages de Stephen Covey à la lumière de l'agilité en générale et de scrum en particulier. Un joli sujet de thèse en perspective pour un futur Docteur en Management. Avis aux amateurs...

L'histoire suivante est adaptée de Covey, adaptée au temps des vacances et des plages surchargées d'enfants chahuteurs.

Jean-François, appelons le Jeff, est animateur au club Mickey. Ce matin-là, il rassemble devant lui le groupe d'enfants dont il a la charge, avec la mission délicate de capter leur attention pendant au moins une demi-heure. Les enfants sont assis sur le sable. Jeff prend un seau, un grand seau. A côté de lui, une pyramide de galets roulés par la mer. Il prend les cailloux un à un, en les déposant avec soin dans le seau, jusqu'à ras bord. Alors, il demande à sa jeune assistance : "Le seau est-il plein?", "Oui, il est plein", répondent les enfants en choeur.

Jeff hoche la tête. Il se lève et prend un petit seau, rempli de petits morceaux de coquillage brisé : coques, huitres, moules, chapeaux chinois... de toutes les couleurs, nacrés, emiettés. Il verse le contenu de ce seau dans le grand seau plein de galets. Et là, ô miracle! devant les yeux des enfants médusés, les brisures de coquillages se frayent un chemin entre les galets et se déposent au fond du seau. Jeff vide les coquilles jusqu'à ras bord. Alors, pour la seconde fois, il demande aux enfants : "Le seau est-il plein?", "Oui, il est plein, plein, plein!", répondent-ils tous d'une seule voix.

Jeff hoche de nouveau la tête. Il pose ses mains sur le sable, sur le sable chauffé à blanc par l'été, bien sec, fin comme de la poussière, puis en prend une poignée, et la verse sur le seau. Les grains de sable coulent doucement, entre les galets, entre les coquillages brisés...Jeff recommence plusieurs fois, jusqu'à ras bord. Alors, pour la troisième fois, il demande aux enfants : "Le seau est-il plein?". Cette fois, ils hésitent. Ils ne ssavent plus trop quoi penser. Pourtant, une nouvelle fois, ils répondent, mais plus timidement "Oui, le seau est plein".

Jeff hoche la tête. Il prend le petit seau qui avait conteu les coquillages et demande à un grand dadais d'aller le remplir d'eau de mer. A son retour, Jeff prend le seau d'eau puis, goutte après goutte, le verse sur le grand seau déjà rempli de galets, de coquillages et de sable. Chaque goutte s'enfonce dans le mélange, bu par le sable, qui change petit à petit de couleur. Les enfants applaudissent, fascinés par cette démonstration.

Jeff demande alors : "Quelle est la morale de cette histoire?". Certains réfléchissent, d'autres répondent : "Quand on croit que c'est plei, en fait, c'est pas encore plein!".

Jeff hoche la tête. "Non, les anfants, cette histoire n'a pas de morale. C'est en mettant cette histoire à l'envers, qu'il y a une morale.". Alors, Jeff se lève, prend un nouveau seau, aussi grand que le premier, et le remplit d'eau de mer. Puis, se rasseyant devant les enfants, il prend du sable fin dans ses mains et le verse dans le seau plein d'eau. A chaque nouvelle poignée de sable, l'eau déborde. Puis il prend un petit seau rempli de coquillages cassés, et le verse par dessus. Cela fait un petit tas, une petite pyramide pointue. Puis il tente de poser par dessus des galets. Ceux-ci roulent les uns après les autres, sur les côtés de la pyramide de coquillages, et tombent à côté du seau.

"La morale de cette histoire, reprend Jeff, c'est que si vous commencer à faire les petites choses avant les grandes choses, vous n'y arriverez jamais!". Puis il lance un sprint, le dernier dans la mer fera dix pompes. Et tous s'en vont en courrant, dans un brouhaha indescriptible.

Ce que ne savent pas les enfants, c'est que Jeff est Product Owner, dans la vraie vie. Et qu'il gère bien son backlog. Avec des priorités bien spécifiées. Une priorité de 100 pour le projet le plus important en terme de business. 200 pour le suivant, 300 pour le troisième,etc... Jusqu'à 1000, ce sont ses galets. De 1000 à 2000, ce sont ses petits coquillages. De 3000 à 4000, ce sont ses grains de sable...

Ne me parlez pas de ressources

Une fois n'est pas coutume, j'avais pris le 01 Informatique de la semaine pour lire pendant mon voyage de retour. Je suis tombé sur cette petite citation d'un responsable informatique "On trouve toujours une solution aux soucis techniques. Le succès ou l'échec d'un projet dépend des hommes.".

Cette citation me fournit l'occasion de reparler un peu du premier principe du Manifeste Agile, le plus important d'ailleurs à mes yeux : "Les individus et les interactions doivent primer sur les processus et les outils", qui dit donc bien la même chose que ce responsable informatique.

Il y a peu, j'ai été très énervé lorsque l'on m'a demandé "si j'avais des ressources qu'il était nécessaire de former". Des ressources? Quelles ressources?

Avant, on parlait de "Service du personnel". Ce terme au passif un peu difficile, on l'a renommé en "Service des ressources humaines". Cela faisait "plus humain". Le problème, aujourd'hui, c'est que l'on a enlevé le mot "humain". On ne parle plus que de "ressources". Combien te faut-il de ressources pour l'année prochaine? Cette ressource est-elle valable? On peut mettre cinq ressources dans ce bureau, huit dans celui-là. Je ne suis plus manager, je deviens gestionnaire de ressources.

Donc, n'oublions jamais que "Les individus et les interactions doivent primer sur les processus et les outils". Je vais d'ailleurs de ce pas le rajouter en entête de mon blog.

Epopée ?

Comment traduisez-vous "epic", vous?

Mike Cohn, dans sa bible des "user story", évoque le terme "epic" lorsqu'une story est trop importante pour être intégré dans un sprint. Elle doit être décomposée en user stories plus fines. Par exemple "En tant qu'internaute, je souhaite réserver un voyage en ligne" est une "epic". Il parle aussi d'epic à propos de user stories très complexes, ou qui nécessitent de plonger dans l'inconnu, sans vraiment avoir la possibilité d'une décomposition simple en stories plus petites. Il faut alors tâcher de les décomposer en story d'investigation d'un côté, et de mise en oeuvre, de l'autre.

Dans un projet pour lequel j'interviens en phase d'étude de faisabilité technique, j'ai synthétisé l'ensemble des besoins clients en sept grosses "user stories". Je trouvais ce matin interessant de communiquer sur ces sept méga-stories, mais le terme "epic" ne me satisfaisait pas du tout. Autant, je trouve que l'expression "user story" est parlante en elle-même, et compréhensible pour tout un chacun, parce qu'on a tous vécu des love story, qu'on comprend globalement la signification des storyboards, et que même la notion de use case, finalement, est assimilée par un grand nombre de personne. Mais allez dire à votre boss "je découpe ce projet en 7 epics" sans qu'il lève le sourcil d'un air soupçonneux! Et osez poursuivre plus tard devant le Directeur métier ! A mon avis, on vous prendra vite pour un joyeux félé.

Après réflexion, j'ai adopté l'épopée ! On pense à la Chanson de Roland, à la quête du Graal d'Arthur, à la légende d'Yvain... une petite pointe d'héroïsme pas très éloigné du quotidien des projets informatiques.

Le Manager agile

Au début, juste après avoir commencé la lecture du livre de Jérôme Barrand, "Le Manager Agile", j'avais eu quelques regrets d'en avoir fait l'achat. Car cet ouvrage s'adresse au directeur général d'une entreprise, à un manager de haut niveau qui souhaiterait impulser une nouvelle dynamique de management par la posture "agile".

J'étais donc un peu désappointé. En tant que responsable de développement informatique, ce livre était a priori hors de mes compétences.

Puis après l'avoir laissé trainer quelques mois sur une étagère, je l'ai ouvert de nouveau. Cette seconde lecture m'a semblé beaucoup plus enrichissante que la seconde. Je conseille donc cet ouvrage, pour tout les managers informatiques intéressés par l'agilité, et qui sont prèts à prendre un peu de hauteur, et s'interroger sur la signification pratique de la posture agile, en tant que principes généraux de management d'entreprise. L'écriture est parfois rude, mais le contenu est passionnant.

Le coeur de l'ouvrage dresse des outils d'aide au diagnostic d'agilité d'une organisation. Comme on peut s'en apercevoir assez vite, la mise en place de Scrum au sein d'une équipe de développement permet, à son niveau, d'atteindre l'ensemble des critères énoncés.

En voici la synthèse.

D'abord, les septs critères de définition d'une stratégie agile :

• un processus participatif de prise de décision : autrement dit, adieu le roi de droit-divin!
• un partage de la finalité : la mise en avant de la coopération doit être mise en avant, à tous les niveaux de l'entreprise.
• le leadership : c'est le Scrum Master, c'est Pablo Correa avec l'équipe de foot de l'AS Nancy Lorraine, c'est le chef de convoi cher à Jean-Claude Denis dans ses formations au management
• l'évaluation de la performance : on passe du contrôle à la mesure, du résultat au fonctionnement, de la performance individuelle à la performance collective. La victoire est celle de l'équipe, et non celle du Directeur Générale ou du chef de projet.
• la reconfigurabilité des ressources : la stratégie doit développer les ressources de l'entreprise en pensant à l'adaptabilité de ces ressources selon le contexte et l'environnement.
• la création de valeur : innover, innover, innover mais innover pour augmenter la satisfaction client.
• l'intensité des coopérations : stimuler toujours et encore la coopération entre les services, les personnes, les disciplines, horizontalement et verticalement.

Après la stratégie de l'entreprise, ce sont sept principes agiles auquel il s'agit de vérifier l'adhésion :

• l'anticipation
• la coopération
• l'innovation
• la culture client
• la culture du changement : le changement n'est pas une menace, mais une extraordinaire opportunité de progrès
• l'offre globale : au delà du produit, apporter aux clients services, coopération, relation privilégiée, respect, partage ...
• la complexité réduite à l'échelle humaine

Après les principes agiles, il faut se poser la question des comportements agiles, décrits selon cinq critères :

• le partage
• la confiance
• la responsabilité
• l'hybridation : la performance est toujours le résultat du mélange des profils, des compétences, des envies, des motivations (celà ne vous rappele pas les qualités d'une Scrum Team?)
• l'aptitude au changement : sur cette aptitude face au changement, Jérôme s'oppose à l'attitude classique de "gestion du changement". Il ne faut pas gérer le changement, mais bien vivre avec une culture du changement, et prendre conscience que le changement est une source intarissable d'enrichissement personnel et collectif.

Et pour finir, au quotidien, dans les pratiques de l'entreprise, statégie agiles, principes agiles et comportements agiles définissent des pratiques managériales, qu'il convient de mesurer selon dix critères d'agilité :

• le fonctionnement par processus : chaque acteur d'un processus est évaluer par l'acteur amont et l'acteur aval, et non plus par le supérieur hiérarchique
• la symbiose environnementale : savoir faire, réagir, anticiper de manière proactive
• la modularité synergique : une organisation mobile, ni verticale, ni matricielle, mais plutôt neuronale
• l'autonomie
• la pédagogie managériale
• la communication
• l'interopérabilité
• la veille
• les dynamiques collaboratives
• les perspectives d'épanouissement

En conclusion : l'entreprise Scrum est une entreprise agile. Alors, parlera-t-on bientôt du Scrum Master de Total ou du Scrum Master de Vinci ?

Notre radiateur d'informations

Afin de conserver à chaque instant une vision claire du projet et de son avancement, Jerry et moi-même construisons un radiateur d’informations sur le mur vitré de notre bureau. Quelques feuilles A3 scotchées au mur, puis nous choisissons des post-it jaunes pour les user stories, et des post-it verts pour les tâches. Les user stories (post-it jaunes) sont disposées horizontalement par ordre de priorité sur la ligne du haut : on y retrouve leur intitulé, leur priorité, leur charges relatives en user story points et leur numéro d’identification dans Team Foudation Server. Sous chaque user stories, nous disposons les tâches associées, avec leur charge.

Bien entendu, les post-it peuvent s’envoler, se décoller…et toutes cette information est aussi disponible au sein de Team Foundation Server. Le cube Olap Services de Sql Server nous permet de générer un grand nombre de rapports, de listes de user stories et de tâches associés, de calculer et d’estimer notre vélocité. Tous ces rapports sont disponibles au sein de Visual Studio, dans l’espace de travail des développeurs, mais aussi sur le site Share Point du projet, pour être accessible de toutes les personnes intéressées par le projet. On peut y voir par exemple un aperçu de notre vélocité.

Ou encore, on peut y retrouver à tout instant une photo des tâches en cours, de leur affectation, du temps estimé et du temps restant.

Management de projet agile avec Scrum

Même si le logo de Microsoft s'affiche en gros sur la couverture de cet ouvrage, l'auteur en est bien Ken Schwaber, le co-fondateur avec Jeff Sutherland de la méthodologie Scrum.

Ce livre est indispensable pour au moins deux raisons. La première tient à la définition complète et exacte de l'ensemble des règles et artefacts de la méthode Scrum, en annexe 1 de l'ouvrage. Comme elles sont rédigées par Ken, on est sûr de leur véracités. Il est important de s'y référer régulièrement, pour vérifier si l'interprétation au quotidien ne nous éloigne pas trop des "règles", car on constate vite que certains petits détails auxquels on n'aura pas forcément fait attention, peuvent prendre toute leur acuité, quand on est confronté au réel.

La seconde raison est le très grand nombre d'applications, avec le regard et l'expertise de Ken, qui relate dans le détail les erreurs commises, et à ne pas reproduire. Chaque grands rôles de Scrum (le directeur  produit, le scrum master et les membres de l'équipe) est mis en action, sur des projets réels auxquels Ken a participé en tant que consultant externe.

Si je ne devais retenir que deux de ces histoires de projets où la méthode scrum prend petit à petit le pas sur des méthodes traditionnelles qui ne fonctionnent plus vraiment, mais où justement le passage de l'une à l'autre n'est pas chose aussi simple, je citerais d'abord celle du "Scrum master absent" et celle du "Scrum master chef de projet".

Dans l'histoire du "Scrum master absent", le responsable projet, qui doit logiquement endossé son nouveau manteau de scrum master, n'est pas là lors du lancement du sprint. Il a un rendez-vous à l'extérieur qui l'a empêché de conduire le lancement du sprint. Ken est furieux et allerte le boss du responsable projet, qui comprend tout de suite l'erreur : un scrum master ne doit à aucun moment abandonner son équipe au profit d'autes activités. Une autre personne est alors  nommé scrum master à sa place. Le scrum master apparait ainsi comme le chien de berger qui veille sur le troupeau, afin d'éloigner les loups qui rôdent aux alentours.

Dans l'autre histoire, celle du "scrum master chef de projet", tout à l'air de bien fonctionner. Le sprint avance. Les scrums du matin ont bien lieu, etc ... Cependant, en assistant à un scrum, Ken s'aperçoit bizarement que les questions posées ne sont pas "Qu'est-ce que tu as fait hier concernant ce projet?" et "qu'est-ce que tu vas faire aujourd'hui?" mais "As-tu fait ce que je t'avais donné hier?" et "Aujourd'hui, tu feras ci et ça". Quant à la dernière question "Est-ce quelque chose t'a empêché d'avancer aussi efficacement que possible?", elle devenait collégiale et personne n'y répondait. Ce scrum master était resté chef de projet dans l'âme, et n'avait finalement pas compris le principe essentiel de la méthode scrum : l'auto-affectation des tâches par l'équipe elle-même.

Estimation et planification agile de Mike Cohn

J'ai découvert ce livre par hasard, par le biais d'un commentaire de l'un de ses lecteurs qui écrivait que s'il ne fallait lire qu'un seul livre sur l'agilité, ce serait "Agile Estimating and Planning" de Mike Cohn.

Je suis tout à fait d'accord. Ce livre est devenue une source d'inspiration inépuisable dans mon activité professionnelle de tous les jours, comme dans les projections à 6 mois, un an voire plus.

La particularité de cet ouvrage est son découpage en deux parties.

Dans la première, classique, on y trouve l'exposition des principes, objectifs et méthodes d'une part, de l'estimation agile, et de l'autre de la planification agile. Ces principes se mettent en oeuvre dans tout projet de développement informatique, quelle que soit la méthode adoptée (Scrum, XP, ...).

La seconde partie du livre reprend tous les principes énoncés sous forme romancée : une petite équipe de développement doit mettre sur le marché un nouveau jeu. On trouve Franck, le responsable produit, Delanay, l'analyste, Sasha et Allan les développeurs, Prasad le testeur, Rose la dessigner et Carlos, le consultant chargé de mener tranquillement toute cette petite équipe vers l'agilité. Tous les thémes des chapitres précédents y sont repris, comme dans la vraie vie d'une équipe de développement, basée sur les échanges et la communication.

Je conseille vivement de commencer la lecture de ce livre par cette étude de cas, qui permet de bien comprendre tout l'intérêt des "users stories", du planning poker, des estimations relatives, du découpage en tâches et de leur évaluation, du burndown chart, du sprint review, etc...

C'est d'ailleurs sous cette forme de journal de bord que j'ai choisi d'évangéliser autour de l'agilité, en décrivant jour après jour ce que nous faisons, rendant chacun des membres de l'équipe le héros extraordinaire d'une épopée passionnante. Car finalement, en adoptant une posture agile, chacun obtient des supers pouvoirs.

En parallèle de cette lecture, des visites assidues sur le site de Mike s'impose : Mountain Goat Software.

Veille technologique #6 : scrum et offshore

Deuxième partie de mes notes prises au ValTech Days.

Agile et offshore : retour d’expérience en milieu bancaire.

Présentée par Patrick LeGo, consultant sénior chez Valtech.

Où comment l’agilité en générale, et Scrum en particulier, apparaît comme une technique de survie en milieu bancaire.

Patrick intervient depuis deux ans en tant que chef de projet agile dans une banque d’investissement qui pratique l’offshore depuis 2001. Dans un tel établissement financier, le système d’information est LE moyen de production de l’entreprise, c’est sa valeur. Les nouveaux produits financiers sortent en flux continu, l’ouverture du SI sur l’extérieur est de plus en plus grande, avec la généralisation des marchés électroniques. La performance du système d’information dicte la capacité de survie de l’entreprise.

Cet établissement a fait le choix de l’offshore internalisée, avec deux équipes parallèles : une à Paris, et une en Inde. L’objectif de ce choix était double : augmenter sa capacité de production par l’offshoring de ressources en Inde, mais conserver la maîtrise du système d’information et la connaissance métier en conservant les équipes en interne.

A l’arrivée de Patrick, les deux équipes ont des caractéristiques bien différentes.

Une équipe parisienne, organisée en pool de ressources, qui touche à tout : des projets de grande envergure, des petits projets de 15 jours de charges, de la maintenance. Beaucoup de postes en régie de long terme, aux cultures méthodologiques disparates, mais fortement expérimentée, que ce soit techniquement ou fonctionnellement.

Une équipe indienne répartie par projets, certifiée ISO9001, sans leader technique ou fonctionnel, inexpérimentée, au turn over élevé, mais dont la méthode et les procédures permettent de s’en sortir.

L’audit des équipes dévoile encore un manque de confiance mutuelle, sans doute alimenté par la distance géographique et culturelle, mais aussi par les caractéristiques des un et des autres : désorganisation d’un côté et faible niveau technique de l’autre. De plus, l’équipe indienne est réduite à la maintenance de code dont elle n’est pas l’auteur : toute correction de bug met des jours, là ou quelques heures devraient suffire. Côté projet, les indicateurs sont flous, l’effet tunnel est permanent.

Face à ce constat, et sauver l’entreprise, une seule solution : le développement agile !

Un premier projet agile est lancé : le portage d’une application Java vers le C# et le framework .Net. Les spécifications sont embryonnaires, la conception et le code sont fait offshore. Le suivi local est insuffisant. Les performances sont mauvaises. 50% du code doivent être refactorées. Le délai et les charges doublent !

Que s’est-il passé ? Un échec de l’agilité ?

En fait, une erreur principale avait été commise : nouvelle équipe, nouvelle méthode, nouvelle technologie.

Après ce premier échec, l’agilité n’a pas été vouée aux gémonies. La phase suivante a consisté à mettre en place Scrum, avec un certain nombre d’artefacts :
– Mise en place de la collaboration : esprit d’équipe, partage de l’outil de développement et de suivi
– Renforcement et maîtrise de la gouvernance du SI : suivi du budget et des délais, suivi de la qualité, suivi quotidien, suivi sur les faits, ce qui est effectué, disparition des effets tunnel, revue de conception et de code
– Evolution de la technologie Java vers C#, partage de l’usine de développement, automatisation de tests et  build continu, condition a minima d’un développement agile
– Modification de la typologie des projets : aller de la maintenance vers l’applicatif, et du waterfall vers l’agilité.

Le processus est global :

– Itération pilotée par les risques
– Les points d’accord sont partagés par tous et écrits
– Les itérations sont de longueur fixe (ce sont les Time Boxes)

Pour se faire une idée précise de la mise en pratique de Scrum dans ce cadre de développement offshore, Patrick nous décrit le modèle d’itération :

– Le premier lundi : lancement de l’itération (1 heure). La conception et les spécifications sont effectuées par l’équipe française, le code et les tests sont faits en Inde.
– Tous les matins, le meeting classique Scrum
– Une réunion de Sanity Check à la fin de chaque semaine pour vérifier que tout le monde est bien en phase
– Les équipes sont réduites : 1 chef de projet, 1 business analyste, 1 architecte, 3 développeurs
– L’estimation des charges est effectuée par les intervenants eux-mêmes, sur la base de 6 heures de travail efficace par personne et par jour
– Le mercredi de la 3ème semaine : on gèle le code et le build, on planifie la prochaine itération, le plan doit être accepté par chacun, on effectue la revue du produit

Pour que l’ensemble fonctionne correctement, un certain nombre de moyen de communication ont été mis en place, spécifiquement à cette application de Scrum au contexte offshore :

– Des voyages fréquents France-Inde, pour les transferts de compétence, parfois plusieurs semaines de suite
– Des téléconférences pour les Scrum de Scrum, qui, de 45 minutes dans les premiers temps, sont passés à 15 minutes, comme le temps nécessaire à un Scrum classique
– Des wikis, (un par projet) qui au début n’ont pas été pris au sérieux, mais qui ont finalement été bien adoptés, pour leur supériorités sur les autres moyens d’échange que sont les forums (risque de réponses qui partent dans tous les sens) et les emails et chats (à déconseiller fortement). Seuls les wikis permettent réellement de partager les règles de bonnes pratiques.

Au départ, une dérive en charges et délai a été constatés sur les premiers projets, allant jusqu’à 250% du temps prévus. Les écarts se sont réduits ensuite. En partie par une maîtrise de la nouvelle méthode agile, mais aussi par que Scrum en particulier, et les méthodes de développements agiles en général, permettent de mieux prévoir temps et délai.
En résumé, l’adoption de Scrum a permis :

– Une meilleure visibilité
– Un contrôle amélioré
– Une plus grande qualité de développement et de conception
– Une collaboration efficace entre les différentes équipes
– La réduction du turn over
– Une efficacité renforcée
– Et même le renouvellement de la certification ISO 9001 pour l’équipe indienne : un beau challenge, sachant que les certificateurs ne sont pas forcément très connaisseurs des méthodes agiles.

Bien sûr, ces bénéfices très importants reposent au préalable sur certains facteurs clé de succès qu’il ne faut pas négliger avant de se lancer dans l’adoption du développement agile :

– L’engagement de la DSI en terme budgétaire
– Les utilisateurs en terme de patience
– Un effort dans le recrutement
– La motivation des équipes

Mais les résultats sont bien là, et les efforts consentis au départ ont largement été récompensés.

Depuis ce jour, je n'ai qu'un seul "rêve" : SCRUM !

Veille technologique #5 : SOA, urbanisation et agilité

Quelques notes que j'avais prise lors des remarquables Valtech Days des 23 et 24 octobre 2007.

Comment aborder la SOA dans son SI ?

Session présentée par Philippe Richard, architecte SI à la CDC et Yann LeTanon, consultant senior chez Valtech.

J’ai noté deux idées générales dans cette session :

– L’interaction SOA et urbanisation du SI
– L’approche agile, pour commencer rapidement en allant étape par étape dans la mise en oeuvre

Le concept d’urbanisation (rationalisation et alignement du SI sur les processus métiers), né dans les banques il y a une douzaine d’années, fait peur, car on lui attache en général l’idée d’une reconstruction complète du système d’information. Le concept de SOA (architecture de services), comme beaucoup de mot à la mode, a donné naissance à beaucoup d’outils, mais n’a pas vraiment abouti sur une démarche.

Ce que propose Valtech, c’est l’urbanisation comme démarche pour la SOA, et la SOA comme levier pour l’urbanisation.

Alors, comment ça marche ? Comment la démarche a-t-elle été mise en œuvre à la CDC ?

Première phase : le découpage par métier, sans du tout tenir compte de l’organisation :

– Banque
– Retraite
– Investissement
– Prêts
– Etc, mon but n’étant pas d’être exhaustif, mais de ressortir l’essentiel de ce séminaire.

Ensuite, une analyse du SI, fortement morcelé, avec par exemple :

– J2EE et IIS pour le Web
– PowerBuilder, Citrix, NSDk pour l’architecture client/serveur
– BO, Oracle, SAS pour le décisionnel
– Domino côté processus
– Excel, access, Interdev, forms pour les applications hétérogènes

Un SI comme une penderie dans laquelle on retrouverait toutes les modes. En bref, un SI comme tous les autres !

Troisième phase : la route vers la rationalisation.

On réduit le nombre de composants. On abandonne les technologies devenues obsolètes dans un temps fixé. On fixe un plan d’urbanisation. Et surtout, on généralise l’EAI.

Un nouveau palier :

– Un système d’information plus agile
– Un système modulaire, avec des couplages faibles entre les modules
– Des échanges normalisés, et réduits

Dans la stratégie à trois ans, deux grands objectifs :

– Une architecture technique orientée service pour l’infrastructure
– Une architecture applicative orientée service pour les métiers

Ces objectifs se déclinent dans la construction d’un SI en quatre couches :

– Niveau 1 / couche applicative : ressources applicatives, données et traitements, mainframe, progiciel, référentiel, bases de données
– Niveau 2 / couche de services : exposition du modèle pivot, langage commun du SI, web services, grammaire XML. Les composants services (par exemple, service virement, titre, compte) sont autonomes, et encapsulent toutes les règles métier et les règles d’intégrité. La façade des services permet de rationaliser l’accès au SI, de manière propre, et surtout indépendante de la couche applicative
– Niveau 3 / processus métier, orchestration (pas encore mis en place à la CDC)
– Niveau 4 / interaction avec les acteurs internes et/ou externes : web, portail, qui interagissent actuellement avec la couche 2.

Les étapes de la démarche, baptisée « Think Service » par Valtech :

– Construction de la cartographie du SI, partage de cette cartographie avec l’ensemble des acteurs et liste des échanges points à points
– Définition des règles d’architecture cible et passage des échanges point à point vers un échange de formats pivots
– Mise en place d’un réseau de référents applicatifs chargés de l’évangélisation SOA
– Montée en compétence de tous les collaborateurs de la DSI sur l’urbanisation et la SOA

L’application de la démarche suit ensuite la voie du pragmatisme : on prend les projets au fur et à mesure de leur apparition et on « Think Service ».

J’ai aimé ce retour d’expérience : ne pas mener une SOA en Big Bang, mais y aller étape par étape, et dans la partage. C’est un projet d’entreprise, un projet stratégique, que tous doivent s’approprier :

– Démarche : refuser la mise en place de tours d’ivoire, l’information doit redescendre, il faut fonctionner en réseau.
– Architecture : exploiter au mieux l’existant par la mise en place de façades par les services et utiliser une typologie de services simples.
– Organisation : la démarche SOA doit être portée par la direction et descendue vers le plus grand nombre, et non ps par quelques architectes experts en leur domaine.

La clé du succès : communiquer au plus tôt et concrétiser au plus vite.

A mon avis, bon nombre de projets ambitieux de refonte de SI et d’urbanisation se sont plantés pour ne pas avoir su suivre cette voie.

Abonnez-vous au Visual Studio Talk Show !

Je vous invite vivement à visiter le Visual Studio Talk Show, un site de podcast spécialisé sur le développement .Net avec Visual Studio, l'apport de la suite Team System et du serveur Team Foundation Server dans les méthodologies de développement agiles, le cycle de vie des projets de développements et d'autres sujets, toujours autour du framework .Net : Ajax, Silverlight, LinQ, Windows Communication Foundation ... enfin, tout ce qui peut interesser chef de projets, architectes, développeurs, voir maîtrise d'ouvrage un tant soit peu attentif aux technologies Microsoft.

Les émissions sont toutes en français, animées par Mario Cardinal et Guy Barrette , tous deux consultants séniors à Montréal, spécialisés dans les architectures autour des technologies .Net, Mario Cardinal ayant aussi un champ d'expertise avancé dans les processus agiles de développement.

Mise en garde : plus fort que Lost, Grey's Anatomy ou Prison Break, le site est addictif!

Des personnages bien campés pour des scénarios bien ficelés

Dans la méthode MSF pour Agile, l'une des innovations les plus intéressantes est la notion de personnages. Un personnage représente une personne physique, avec un nom, un slogan qui le résume en quelques mots, des caractéristiques sociodémographiques, des objectifs, des compétences, des connaissances. Les personnages doivent être écrits par les analystes métier en tout début de projet, à l'instar des personnages d'une pièce de théâtre ou d'un film de cinéma. Et chaque scénario, ensuite, sera écrit en tant qu'interaction d'un personnage avec le système en cours de développement.

Gadget? C'est un peu ce que j'ai pensé, au départ. En fait, pas du tout. Je suis maintenant persuadé que c'est un moyen très efficace pour que chacun garde bien à l'esprit, pendant toute la durée du projet, pour qui le site web est développé, à quel type de personne doit-il s'adresser, etc ....

Les analystes, bien sûr, ont à charge de décrire les bons personnages, en s'aidant de tables rondes, par exemple. Comme il n'y a pas de bon film sans bon scénario, et qu'il n'y a pas de bon scénario sans bons personnages, la réalité est identique dans le développement de sites web.

Imaginons un projet de développement d'un site web proposant à la fois des séjours de vacances et des loisirs (spectacles, sorties, évènements sportifs).

On peut dessiner par exemple nos quatre premiers personnages, auxquels l'équipe de dévelopement devra penser tout au long des différentes itérations du projet. Il est fort probable que nos quatre personnages, Marna, Pierre-Alain, Charles et Kathleen ne naviguerons pas sur le site de la même manière.

Marna, jeune, sportive	Pierre-Alain, parisien pantouflard
Charles, un rien branché	Kathleen, mère de famille londonienne

Marna y chercherait d'abord un voyage original à l'autre bout du monde, alliant trekking de haute montagne et visite de temples boudhistes, puis aussi quelques cours de stretching pour vitaminer sa forme physique avant son départ. Pour Pierre-Alain, ce serait bien d'avoir une entrée sur le site destiné aux parisiens, aux lyonnais, aux marseillais, proposant musées et exposition à deux pas de chez eux. Charles, c'est clair, aimerait y trouver tous les hauts lieux de la vie nocturne, près de chez lui, aussi. Enfin, pour Kathleen, l'internationalisation du sites s'imposerait, afin qu'elle puisse trouver à organiser un séjour linguistique pour ses enfants.

Personnages, scénarios, développements, tests, affinage des personnages, scénarios, développements, tests, etc ... itérations après itérations.

Pas mal, non?

Agile ou CMMI ?

Avant de partir en vacances, mon boss m'a confié une tâche assez intéressante : construire un argumentaire détaillé prouvant qu'Agile est plus adaptée à notre contexte. La démarche en elle-même a du sens : elle prouve aussi que la réflexion a été mener sans a priori de départ, et que les deux méthodologies ont été appréhendées.

Comme je l'avais fait pour MSF pour Agile, je me suis donc plongé dans le Process Guidance de MSF pour CMMI. Et regardé aussi la démarche CMMI d'une manière plus générale. Il est assez clair que, pour du pur développement Web, fondé sur des cycles très courts, des releases mensuelles, et des refontes quasi-semestrielles, les spécifications Agiles doivent être préférées.

En caricaturant un peu le trait, c'est un peu comme si le manifeste Agile avait pris exactement le contrepied des démarches CMMI : les individus au lieu des processus, des développements qui fonctionnent plutôt qu'une documentation exhaustive, la collaboration avec le client plutôt qu'une relation contractuelle, la réactivité aux changements à la place du suivi d'un plan.

Les spécificités du développement web sont telles que :

• la description des processus, leur suivi et leur vérification ne sont guère adaptés. Mieux vaut veiller sur l'évolution des compétences de nos collaborateurs et leur motivation avant qu'ils ne partent ailleurs,
• la documentation est utile, mais face à nos développemnts web qui sont souvent du domaine du jetable, il est assez raisonnable de rester léger en terme de doc,
• en terme contractuel, les délais de fabrication sont si court, qu'il est préférable, en effet, de coopérer avec nos clients, qu'ils soient internes ou externes : la signature du contrat pourrait sinon intervenir après la livraison du site,
• quant au dernier point, qui connaissait Ajax il y a deux ans ? le web 2.0 il y a un an ? Silverlight et le XAML il y a six mois ? la réactivité n'est pas que nécessaire, elle est une question de survie. J'aime bien, d'ailleurs, la maxime trouvée sur le site de Clever Age : "hier, les plus gros mangeaient les plus petits; aujourd'hui, les plus rapides mangent les plus lents".

Des rôles plein d'agilité

J'aime bien cette image prise dans les locaux de Clear Channel Communications lors de leur évaluation de la méthode MSF pour la configuration de TFS et Team System .

Pour ma part, je n'ai pas (encore?) scotché sur les murs de mon bureau la description des rôles, des flux de travail associé, de leurs activités et sous-activités, je me suis contenté de les imprimer (il faut compter une bonne demie-journée!) et de les consigner dans quelques chemises. Je réfléchie encore à un archivage efficace, porte vue ou autre. Mais l'affichage de Clear Channel a celà d'exemplaire qu'elle montre bien la complexité de l'intégration de l'ensemble de ses rôles, de leur compréhension, de leur assimilation, puis dans un second temps, de leur adaptation, personnalisation, customisation à notre travail de tous les jours. Une tâche passionnante, qui demande aussi une certaine dose d'évangèlisme.

Agile Manifesto

C'est fait : je viens de signer le Manifeste Agile.

Tout est parti de Team Foudation Server et de Visual Studio Team Suite, finalement. Partant d'un besoin d'industrialisation de nos développements Web, je nous avais équipés de TFS et VSTS . Nous avions construit nos projets d'équipe selon la méthodologie Microsoft Solution Framework pour Agile Software Development (et non pour CMMI). Il s'agissait au départ de comprendre comment fonctionnait TFS et ce que je pouvais en tirer pour améliorer notre efficacité. Mais très vire, je me suis aperçu qu'avant de comprendre comment fonctionnait l'outil, il était préférable de comprendre la méthode. D'où mon retour au source sur l'Agile Manifesto. 

Pour ceux qui ne le connaisse pas, voici les 4 principes du Manifeste du Développement Logiciel Agile en français :

Les individus et les interactions doivent primer sur les processus et les outils
Le développement logiciel doit primer sur la documentation exhaustive
La collaboration avec le client doit primer sur la négociation contractuelle
L’ouverture au changement doit primer sur le suivi d’un plan rigide

Il me reste à évangèliser mon boss, mes collaborateurs et mes collègues de la maîtrise d'ouvrage. Puis à mettre tout cela en place dans TFS.