Agile France

L'association XP France change de nom et devient Agile France, ce qui confirme les tendances de cet été et correspond plus à la réalité de celle-ci ou l'on parle aussi bien de Scrum, d'XP ou de Lean.

Les trois évènements majeurs de cette association sont les XP Days, et son tout nouveau site, l'Agile Open France, cycle de conférences au format Open Space dont je parlerais en janvier et l'Agile Tour: Dernier né de l'association sous l'impulsion de Patrice Petit d'Agilii, cet évènement a montré la maturité de l'Agilité aux quatre coins de la France.

Et à Rennes?

Déjà 25 membres à AgileRennes avant notre premier rendez-vous le 7 janvier 2009. Praticiens ou simples curieux de l'Agilité, n'hésitez pas à venir exprimer vos besoins et vos attentes lors de cette rencontre informelle: Ce sera l'occasion de découvrir les acteurs rennais et nous en profiterons pour initialiser le product backlog du groupe pour 2009.

Alors pensez à amener vos post it!

En 2009, "Pensez Agile"!

Découvrez le programme de la formation "Pensez Agile" que nous avons conçue en collaboration avec Timwi consulting pour des sessions inter entreprise sur Rennes en janvier, février et mars 2009.

Nous restons à l'écoute pour vos besoins spécifiques en formations agiles ou des sessions intra-entreprise.

Agilité : A monter soi-même

De retour de la soirée des praticiens de Nantes avec un atelier facilité par laurent Bossavit sur l'Agilité à monter soi-même. L'approche s'est faite par une analyse systémique de nos problèmes du moment. Cette analyse s'appuie sur le Diagramme d'effet de Weinberg.

On était près d'une trentaine en quatre groupes à faire cet exercice de modélisation.
Le but de l'exercice est de montrer que les pratiques agiles peuvent réguler ou amplifier certaines boucles de notre système.

J'ai pu retrouver des visages connus aux derniers XP Days.
Le diner qui a suivi était très enrichissant et ça m'a donné plein d'idées pour AgileRennes!

Merci à Tremeur pour l'organisation de la soirée.

Valtech Days : Les présentations

Vous trouverez toutes les présentations des Valtech Days ici, en particulier celles sur lesquelles j'ai fait un retour ici et ici: Au menu Agilité, industrialisation, Architecture, e-business et web2.0.

Agilité vs CMMI: 0-1?

source© 2008 Patrick Debois

Je me réveillais doucement dimanche matin en lisant 01Informatique lorsque je suis tombé sur l'article "Agilité et CMMI en voie de réconciliation". Il fait suite au rapport du Software Engineering Institute dont j'avais parlé ici.
Si vous êtes un lecteur assidu de mon blog et du journal, vous aurez peut être remarqué que la fin de son article ressemble très fort au début du mien :o)

Bref, je réagis à l'article lorsqu'il évoque les

"quelques vives critiques provenant de la communauté agile n'y voyant qu'opportunisme..."

Je tiens à rappeler que nous sommes quelques uns à aller dans ce sens ou à en être l'écho.

Que si la parution de l'article du SEI a fait réagir la communauté Agile, je pense que globalement les idées qui en ressortent ne sont pas des critiques, mais une peu de scepticisme; Mais je note surtout une ouverture pour échanger sur le sujet au cours d'Open Space, de jeux ou d'ateliers comme ceux des XP Days Benelux 2005.

Reste à créer ces échanges ou avoir plus de retours d'expérience sur le sujet.

Coaching, playmobil et rétrospective

De retour de ma formation l'Art du coaching (individuel) à Paris ou j'ai pu profiter de la soirée agile Octo. Je ne suis pas le seul à être intéressé par ce sujet en ce moment.

Coach Agile, c'est avant tout un coach d'équipe mais qui se doit d'avoir une approche individuelle pour gérer les relais d'opinions, qui peuvent être des accélérateurs ou des freins pour l'équipe.

Pour faciliter son adoption, le Scrummaster doit également accompagner le manager qui peut voir sa fonction changer de manager directif à celui de leader / coach. Il faut pouvoir expliquer et l'accompagner dans ce rôle.

La formation était très enrichissante et a eu de nombreux échos en moi: dans mon rôle de Scrummaster et par la continuité avec mes autres formations d'efficacité personnelle et d'accompagnement du changement à base de management comportementale.
Elle est principalement constituée d'ateliers de réflexions personnelles et de co-coaching.

J'ai naturellement trouvé un autre écho dans le livre que je viens de finir: Agile Retrospectives, merci à laurent bossavit pour la référence. Notamment entre les étapes d'une rétrospective et celles du coaching, également dans l'état d'esprit. Ce n'est pas plus étonnant que ça mais les liens permettent un meilleur ancrage. Sinon ce livre est à lire pour tous les facilitateurs de rétrospectives d'itérations. Il parcours toutes les pratiques étape par étape, permettant de choisir le bon atelier au vu du contexte et de pouvoir varier d'une rétrospective à l'autre. Casser la routine des rétrospectives, cela me rappelle des thèmes récurrents d'Open Space, notamment le dernier ou comment ajouter du fun aux rétrospectives (comment avoir une vue systémique de son équipe … avec des playmobil: et bien on s'en est servi tout au long de la session!)

Appel aux praticiens de Rennes

La dernière formation Scrum de Jeff Sutherland a encore certifié quelques bretons et au moins deux Rennais (salut Sylvain et Jerome).
La communauté émergente des "agilistes" (XP, Scrum, Lean, ...) rennais et ses environs semble maintenant suffisamment importante pour se regrouper dans le but de se connaitre, échanger nos expériences et bonnes pratiques à la manière des praticiens des autres villes : Paris, Nantes, Rhones Alpes, Toulouse et les autres.

Au-delà de Rennes, des ponts peuvent être créés avec les praticiens de Nantes, Brest, Lannion, ...

Afin d'organiser une première rencontre informelle, je vous propose déjà de créer un mailing list.
Si vous êtes interessé, laissez moi un commentaire avec une adresse mail, un mail ici ou directement sur la page du groupe AgileRennes.

AgileRennes

Visiter ce groupe

Soirée Agile
De retour de la soirée Agile chez Octo (merci pour l'accueil et la boite à meuh, merci encore à Luc pour l'organisation de l'Open Space).
J'ai suivi deux sessions, une sur les rétrospectives et une sur l'équipe auto-organisée à partir d'atelier théatrale : Manu a brillamment animé cette session expérimentale.

Prochaine évènement agile pour moi: l'Agile Open France, 3 jours d'Open Space en Alscace!

Scrum et XP depuis les tranchées

Il est sorti en français!
Annoncé sur le groupe XP France aujourd'hui, je ne saurais que vous conseiller la lecture de ce livre qui fait référence (préface de Jeff Sutherland et Mike Cohn) sur la mise en pratique de Scrum et XP.

Rédiger des cas d'utilisation efficaces

J'ai acheté ce livre juste après la formation Gestion de projet RUP et surtout parce que c'est un livre d'Alistair Cockburn, un des signataires du Manifeste Agile, et avant de me plonger dans le livre de mike Cohn, très prochainement: D'abord le livre est vraiment trop très complet, plein d'exemples: à lire si vous devez écrire des cas d'utilisation. Il survole les 3C d'XP, comme étant un résumé des cas d'utilisation et finalement faisant partie de la vision d'ensemble du projet. On trouve d'autres commentaires sur sa vision des users stories vs use case. On retrouve des problématiques communes avec les user stories, trouver la bonne granularité, la portée des descriptions d'exigences, entre autre. Au passage, les niveaux décrits par Cockburn sont assez intéressants nuage, cerf-volant, mer, poisson: on nage en plein dans la métaphore du niveau de la mer avec laquelle j'ai bien accrochée. Ce qui me bloque avec les cas d'utilisation, et avec RUP pour la même raison, c'est qu'un cas d'utilisation peut recouvrir plusieurs itérations. On est dans un processus itératif non incrémental, à mon sens, bien que tout dépend de l'échelle de temps avec laquelle on mesure ces incréments, lire ici un post d'Alistair sur le sujet, des "nano-incréments" d'XP à l'incrément-release. Cela peut se traduire par exemple par une version simplifiée d'un cas d'utilisation dans une itération et une version complète dans une itération ultérieure. La longévité d'un use case est plus grande qu'une user story ou 3C. Quels bénéfices peut-on attendre d'une approche incrémentale? Il s'agit de livrer à chaque fin d'itération un ensemble de fonctionnalités finies au client, avec une définition partagée de finie pour tous. L'équipe peut s'engager sur le contenu de l'itération à réaliser. Le client peut donner son feed-back puisque l'on peut faire la démo de ces fonctionnalités. Si le client a validé l'incrément, on ne revient plus dessus et il peut repartir avec. Pour l'équipe, ces petites victoires successives donnent du rythme et du courage pour le projet. Pour le product owner, on peut réellement prioriser l'itération suivante puisque rien ne traîne dans le Sprint Backlog. On perd beaucoup de bénefices à mon avis à ne pas être incrémentale (à chaque itération). Trop flemmard pour lire le livre, je vous propose un podcast de Pascal Roques sur les bonnes pratiques autour des cas d'utilisation (sans lien avec le livre). Et pour suivre une discussion en cours sur la documentation agile, c'est ici.

Open Coffee Club de Rennes

La communauté Web2Rennes, regroupant les entrepreneurs, développeurs, investisseurs, ..., du monde internet à Rennes, organise régulièrement des rencontres informelles.

Cette communauté a un nouveau site OpenCoffeeRennes pour rejoindre les communautés OCC de France (Nantes, Sophia, Lilles, Lyon).

Nous serons présents au Forum West Web Valley : le Web2.0 dans tous ses états! à Rennes demain, organisé par le MEITO, avec notamment une Keynote de Loic LeMeur depuis la Silicon Valley.

Cliquer ici pour voir le diaporama du Forum et ici pour le compte rendu de Lidia.

Agile CMMI?

CMMI et Agile sont dans un (même) bateau...

De retour de formation CMMI, je partage le point de vue de QualityStreet et plus généralement ce que j'avais déjà souligné ici, à savoir que CMMI et Agile peuvent faire bon ménage et converger. Ils partagent certains fondements notamment celui d'apporter plus de valeurs au client dans une démarche d'amélioration continue alignée avec le métier.
Si le CMMI adresse le "Quoi" via les objectifs et propose bonnes pratiques et activités typiques pour y répondre, les méthodes Agiles implémentent des "Comment" alternatifs et acceptables pour le CMMI. Ce n'est pas nouveau mais je l'ai vraiment ressenti pendant ces trois jours avec des échos côté Lean, 6 sigma, RUP, Scrum ou XP.

Compatible aux niveaux de maturités 3 & 5

On trouve une littérature assez complète sur le mapping ici ou là entre pratiques Agile et objectifs CMMI, en français avec afoucal.
Le niveau de maturité 3 du CMMI est bien couvert avec des modèles comme MSF et son implémentation Agile par David Anderson ou encore Agile+.

On peut lire récemment des retours d'expérience sur le niveau de maturité 5 par Jeff Sutherland.

La revue par les pairs en Agilité?

Le mapping n'est pas suffisant pour se rendre compte de ce que la convergence implique. Je propose pour cela de faire un focus sur l'activité de revue de pairs du domaine de processus Vérification SG2 (Niveau de maturité 3)

Les revues par les pairs consistent en un examen méthodique des produits d'activité par les pairs de ceux qui les ont réalisés, afin d'identifier les défauts à éliminer et de recommander les modifications nécessaires

Et la pratique correspondante XP le binomage (Pair programming): Puisque la revue de code est une bonne pratique autant la faire en permanence!

Mais le pair programming ne se limite pas à cela: c'est aussi une séance de conception et de revue de conception continue grâce au refactoring.
Les critères de vérification et la préparation de ces revues sont constitués par les pratiques XP liées au pair programming : coding standards, simple design, métaphore, testing.

Source igan sur Flickr

En plus du pair programming, on pourrait également parler de toutes les réunions collectives qui sont autant d'occasions de revues informelles.

• Les revues de conception / estimation / planification pour l'aspect technique
• Les rétrospectives, les cercles de qualité du Kaizen pour l'aspect processus
• Et plus généralement la transparence, vis à vis de l'organisation avec le radiateur d'informations ou les daily scrum, qui créée les conditions pour des revues potentielles.
  

Omni présente mais est-elle suffisante?

On voit que l'on est bien armé face à cet objectif de revue par les pairs à différents niveaux.
Mais le fait de ne pas avoir de revue structurée telle que l'inspection Fagan et de la faire à l'écran, selon Watts Humphrey, ne permettrait de remonter que 20 à 40% des anomalies contrairement au 60-80% d'une revue structurée. J'ajouterais qu'en binomage on est à la fois juge et partie.
En XP, le but n'est pas de trouver des anomalies mais de ne pas en introduire en couplant cette pratique avec le TDD.

Mais la pratique, malgré son bénéfice, n'est pas suffisante pour le dispositif CMMI dans une perspective d'amélioration continue: Il faut pouvoir suivre quantitativement l'effet de ces pratiques et faire des analyses causales (5W, Ishikawa, ...) des non-conformités.

L'analyse des données de la revue de pairs par le CMMI tourne autour du rendement de la revue (pourcentage de défauts détectés), le taux de revue (page par heure) et le cout (heures passées) par défaut découvert, entre autre...
Alors quelles métriques dans une équipe XP? Le nombre de défauts non introduit dans le processus? Ou bien estimer la dette technique comme le propose récemment Martin Fowler, bref difficile à quantifier... Et à mettre en pratique?

Des pistes pour converger?

D'abord côté CMMI et plus généralement, les spécificités des équipes et projet Agiles se retrouvent dans le domaine IPPD (Integrated Product and Process Development) qui

[...] recouvre aussi l'établissement d'une vision commune du projet et l'établissement d'une structure d'équipe pour les équipes intégrées qui vont favoriser la satisfaction des objectifs du projet".

Une équipe auto-gérée Scrum/XP est une équipe intégrée avec le client sur site, les développeurs, les testeurs...

De l’autre, pour la revue de pairs, le binomage n'exclut pas une revue par les pairs formelle en fin d'itération qui, elle, peut être quantifiée avec des éléments d'actions à suivre. Cela peut avoir un sens pour une équipe en plateau de vélocité: Les analyses causales sont intéressantes sur des processus stables sans quoi le signal émis n'est pas forcément pertinent.

Cette approche quantitative/statistique est peu présente dans l'approche Agile, délibérément puisque d'un côté Lean nous rappelle de ne suivre qu'une poignée d'indicateurs qui font sens plutôt qu'une multitude de métriques qui ne servent pas: La collecte et l'analyse de ces métriques a un cout important; d'avoir un management visuel (Radiateur d'info) et des métriques orientées client (Business Value cumulée, Story points implémentées, ...) et beaucoup moins processus et organisation.

Malgré tout, on a des mesures "agiles" à suivre, les radars des rétrospectives, les enquêtes à la Yahoo sont autant d'indicateurs dans un contexte d'adoption d'un processus au niveau projet ou organisation et pour la remettre dans son contexte.

Des pistes pour s'améliorer?

Les méthodes Agiles s'adaptent et s'améliorent dans leur contexte projet de manière qualitative avec les rétrospectives, les suivis de tendances (burndown chart, vélocité). Pour dépasser ce stade projet et se répandre dans l'organisation, un suivi plus quantitatif et contextuel est donc important. Mais n'est pas suffisant, comme le note encore Watts Humphrey, et met en avant avec le CMMI le support de transition: Le framework de transition de Mike Cohn en est une bonne illustration.

Conclusion

Nous avons vu qu'une simple réflexion autour du binomage XP et des revues de pairs CMMI permet déjà de mesurer l'effort pour converger là ou il semblait que le mapping était suffisant. Que cet effort pointe du doigt la gouvernance des projets Agiles, leur contextualisation pour atteindre l'organisation elle-même, sujet d'actualité, et qui explique qu'on puisse se tourner vers le CMMI pour avancer sur cette question.

--Ajout 12/11/08

Le SEI (Software Engineering Institute) a publié aujourd'hui le papier CMMI or Agile : Why Not Embrace Both! co écrit par le SEI et David Anderson entre autres.

Ils scellent leur volonté d'être compatibles voir complémentaires en faisant un appel aux experts CMMI d'un côté et aux experts Agile de l'autre pour aller dans ce sens. Une demande de changement a été émise pour inclure l'approche et les principes Agiles dans les modèles CMMI. La machine est en marche!

-- Ajout 23/11/08

La machine n'est pas en marche pour tous dans la communauté XP France!

Agile Estimating & Planning

Ce livre est indispensable à toute bonne bibliothèque Agile. Il aborde tous les sujets de l'estimation et du planning en étayant ses propos. Ce livre m'a réellement aidé à affiner ma compréhension de ces thèmes. On retrouve pas mal de ses propos dans ses différentes et nombreuses présentations. Le livre finit sur une histoire de Jeu de Havannah plutot sympa à lire et qui illustre bien évidemment ses propos. De manière anecdotique, il utilise des métaphores sur la voile qui m'avaient échappées à l'époque mais qui ravissent le marin qui gronde sommeille en moi (pas pour longtemps, un nouveau projet se prépare...). Et puis un auteur qui cite du Clint Eastwood, ça mérite du respect, d'ailleurs je ne résiste pas: If you want a guarantee, buy a toaster à sortir tel un Mantra à tous les sceptiques de l'agilité.

Pour finir, je pars faire une formation de 3 jours d'introduction au CMMI, puisque c'est tendance... enfin c'est plutôt la suite de ma formation ITIL.

Retour Valtech Days 2008 - Suite & Fin

J'ai fini de lire le livre blanc Agile de Valtech distribué lors des Valtech days, plutôt bien fait abordant notamment les thèmes du TDR, CMMI, contractualisation et Lean par Elisabeth Ducarre qui reprend en partie sa session sur le Lean et les pratiques agiles, plutot convaincante avec des retours d'expérience.
Pour la session couplage TDD/TDR , je n'ai pas appris grand chose mais j'avais déjà suivi la présentation de Gilles Mantel aux XP days sur ce thème.
Le lighting talk sur l'étude d'opportunité et la contractualisation Agile se retrouve dans le livre blanc donc un peu de patience.
On peut trouver un peu plus d'info sur le wiki des Valtech days notamment les notes sur le coding Dojo ou la liste des blogs qui en parlent.

A propos de l'Open Space, j'ai noté les thèmes proposés dont voici un large extrait:

Dojo Randori, Pertinence des séances d'estimations, Agilité & CMMI, Organisation agile dans une équipe transverse, Introduire l'Agilité au sein d'un projet existant, Scrum est-il dangereux (thème qu'on a retrouvé pendant la rétrospective), Agilité et entreprise, durabilité de l'effet agile, Framework MockObject, Contrat Agile, MDA & Agilité, Coding Dojo refactoring Code Legacy, Programmation Post Moderne, Perception par l'équipe Offshore du donneur d'ordre, Equipe Scrum :jeu & animation, Comparaison des styles de codage, traçabilité des exigences de l'expression au Burndown chart, métriques importantes dans une usine logicielle, Focus factor, Adoption du TDD par les développeurs, Itération 0, ROI de l'approche SOA.

J'ai participé à la session portée par Jeff Mc Kenna, sur l'entreprise Agile et voici les questions qu'y ont été posé

Une équipe agile dans une organisation non agile (et oui, encore)?
Le rôle de QA dans une équipe Agile?
Le chemin pour devenir une entreprise agile (vaste question...)?
Une entreprise peut-elle devenir Agile?
et d'ailleurs c'est quoi une entreprise Agile?

On peut trouver un bout de réponse avec ce livre dont l'auteur était invité d'honneur de l'Agile Tour Grenoble « Prospective de l’entreprise : vers l’agilité »

Arguments pour convaincre de devenir Agile?
Combien de temps, les étapes, ... bref toutes les questions autour de la transition Agile?
Et d'autres questions plus surprenantes : Comment rester Agile ou encore l'agilité un objectif ou un moyen :Quels objectifs pour une entreprise.

Morisseau Consulting

Depuis quelques semaines, je suis à mon compte. Un retour au source puisque j'ai commencé comme indépendant il y a treize ans.

C'est donc reparti avec Morisseau Consulting pour plein d'accompagnement Agile et des projets .Net, principalement sur la région Ouest et Paris.

Pour me contacter.

Au passage un Merci à claude Aubry pour son lien.

Retour Valtech Days 2008

Comme je l'avais évoqué dans la précédente note, je reviens des Valtech Days. Autant le dire tout de suite, cela a été à la hauteur de mes attentes.


D'abord la Keynote de Jeff Mc Kenna, chef évangéliste agile chez Serena, sur l'agilité gravissant un nouveau palier dans son adoption - "Crossing the chasm", rappelant que l'enjeu de l'agilité est aujourd'hui bien au niveau de l'entreprise, faisant ainsi écho aux tendances de l'Agile 2008.





La première session que j'ai suivie est celle des rétrospectives par Eric Lefèvre et laurent Bossavit sur les rétrospectives d'itérations et post mortem: différences et points communs. Exercice difficile que de rentrer dans le détail de ces deux vastes sujets en 3/4 d'heure mais rien ne vaut la démonstration par l'exemple. Les deux présentateurs ont donc organisé la rétrospective des deux jours avec frise du temps, rétrospective et conclusion: exercice concluant.

Source elefevre sur flickr (je suis en bas à gauche de la photo)



La session suivante portait sur un coding dojo kata TDD en Ruby par Etienne chavignon et Emmanuel gaillot. Le format et les échanges de la session m'ont réellement convaincu. J'ai d'ailleurs enchainé le lendemain sur un Open Space dédié à un coding Dojo randori sur le refactoring de code légataire. Vous pouvez trouver des informations utiles sur le coding Dojo ici ou là.



La session de Gilles Mantel sur un "Tests Manifesto" m'a également capté par sa simplicité et sa pertinence. C'est une version un peu plus longue que celle présentée à l'Agile 2008.

Conduite du changement

Avant de partir pour les Valtech days la semaine prochaine, un petit mot sur la conduite de changement que j'ai creusé ces derniers temps:

Le livre d'abord: Très clair, exhaustif. C'est un livre accessible et très opérationnel offrant des outils de diagnostique et de pilotage du changement. Entre le pourquoi et le comment de la conduite du changement, les auteurs nous aident à réaliser un plan de communication et de formation mais surtout sensibilisent à la gestion des résistances au changement.

La formation Orsys, Accompagner le changement, s'est déroulée la semaine dernière. Complémentaire au livre, la formation aborde l'aspect comportemental lié au changement et le management adaptatif qui doit en découler. Cette formation a un socle commun avec la formation Efficacité personnelle que j'ai suivie l'année dernière. Ces deux formations sont passionnantes à suivre mais un peu difficiles à assimiler.

Elle m'a permis entre autre de comprendre les enjeux spécifiques de l'amélioration continue dans le cadre d'une équipe autonome, au cœur de l'agilité grâce aux rétrospectives ou au lean avec le Kaizen.

Update 20/10/2008: Le problème est d'actualité comme l'écrit très bien emmanuel Chenu dans sa note sur le changement et les conflits.

Concernant les Valtech days, l'agenda est bien chargé mais j'attends tout particulièrement, au-delà des présentations, le Coding Dojo et l'Open Space Technology, que je n'ai pas encore eu l'occasion d'expérimenter.

Objectif Lean

Objectif Lean Ce livre se compose de deux parties, l'une ou les auteurs expliquent les 3 piliers du système Lean (opérationnel, management et culture d'entreprise). La seconde partie retrace une mise en place Lean de manière romancée agréable à lire. On y découvre la démarche, les situations notamment comportementales des intervenants, une des causes majeures de l'échec d'un tel projet: Impliquer tous les acteurs, surtout les leaders d'opinion, avec un soutient fort des décideurs. La lecture conforte dans l'idée que l'adoption Lean ou de méthodes agiles, au-delà du lancement d'un pilote, doit se préparer au travers la conduite de changement; d'ou mon nouveau livre de chevet et surtout ma formation la semaine prochaine chez Orsys sur ce même thème.

Le plein de formations

Formation Coach XP chez Agilii

Une formation de deux jours qui a permis des échanges très constructifs allant bien au-delà des seules pratiques et valeurs XP, notamment autour de l'Agile Tour dont ils sont à l'initiative.

Formation RUP chez Valtech
4 jours de formation assez sereins car il faisait beau, et nous n'étions que 5 avec le formateur, fort sympathique au demeurant. Cela nous a laissé toutes les opportunités de poser nos questions assez ciblées sur nos propres problématiques.
La formation, bien qu'un peu formelle, était adoucit par une volonté d'aller vers l'agilité, volonté renforcée par le formateur, également Scrum Master.
Un des faits marquants de cette formation est la confrontation des deux cultures de la gestion de projet:
Pour les chefs de projet traditionnel, l'aspect émergent de RUP (au niveau recueil des besoins et de la conception) est vu comme un frein à l'adoption.
Pour ceux qui ont une culture agile, RUP peut être vue au contraire comme un levier à l'adoption de l'agilité dans des contextes culturels fortement ancrés, par son aspect formel justement: RUP comme une vitrine, une interface.
Dans les deux cas, le coeur du problème était la transition vers l'agilité.
Une partie du contenu se trouve diffus dans le livre Gestion de projet - vers les méthodes agiles.

Tendances 2008 Agile

Les dernières tendances Agile ont été largement soulignées cet été lors de la rencontre Agile 2008 à Toronto. Les différents billets que l'on peut lire sur cette rencontre montrent bien une nette tendance de l'agilité à se regrouper et à élargir son spectre à l'entreprise:

Scrum et XP d'abord
Ce n'est pas nouveau, Scrum avait déjà adopté certaines pratiques XP (notamment le planning poker) comme des bonnes pratiques pour Scrum mais on franchit une étape supplémentaire avec gojko et un début de formalisation avec le Just Agile, avec laquelle on en revient à bricoler sa méthodologie par rapport à son contexte...
Cette tendance ne se retrouve pas (encore?) dans les (bons!) chiffres, si l'on compare les résultats 2007/2008 de l'enquête de Version One: Scrum/XP hybrid est stable avec 22-23% des méthodes agiles adoptées , contre Scrum qui passe de 37% (2007) à 49%(2008), à voir aussi Scrum vs XP avec Google trends, de Scrum breakfast.

Agile et Lean
On savait déjà que l'origine de Scrum avait un lien indirect avec Lean, que Scrum est compatible avec Lean (à lire dans ce livre), même s'il n'adresse pas certains concepts tels que le Pull (qu'on ne retrouve pas dans le Manifeste Agile). Retrouver le meilleur des deux mondes avec le Kanban à l'exemple de l'excellent Scrum Ban de Corey Ladas ou avec Laribee, au prix de l'abandon de certaines pratiques (itérations, planning, ...).

Agile vers CMMI
La profession de foi de David Anderson, relayée par claude Aubry, reprend le propos précédent sur le Kanban, et surtout insiste sur l'ouverture d'esprit de la communauté Agile pour savoir répondre aux enjeux de scalabilité et de maturité, en particulier de s'appuyer sur le CMMI, QualityStreet a enfin été entendu! Scrum a déjà été implémenté dans des entreprises CMMI 5, implémentation pilotée par du Lean, comme le ici rapporte Jeff Sutherland.

Pour faire un lien avec ma lecture du moment, le méta modèle MSF de Microsoft propose d'ailleurs un template pour l'agilité avec MSF for Agile Software Devlopment et un template pour CMMI avec MSF for CMMI.

On peut se réjouir de cette lame de fond car elle va permettre d'adresser de manière plus globale les problématiques informatiques des pratiques d'ingénierie, de gestion de projet à l'organisation et au management.

Lean montre la voie pour élargir l'agilité à toute l'entreprise, c'est d'ailleurs le chemin pris par Net Objectives, avec Scrum#. D'autre part les décideurs sont plus sensibilisés au Lean qu'à Scrum ou XP, il est plus facile de l'aborder dans ce sens pour une approche Top-Down.

Les livres de l'été

Consultants Livre intéressant sur le positionnement d'un consultant, comment développer son réseau, préparer ses entretiens avec ses prospects, les traduire en mission, comment conclure une mission. Un livre à lire dans la continuité du guide du métier de consultant afin de formaliser son approche, avoir les bons comportements. L'approche est assez opérationnelle.

Gestion de projet vers les méthodes agiles C'est le livre par lequel commencer pour un chef de projet souhaitant découvrir des méthodes alternatives de gestion de projet. On y parle de recueil de besoin, planification et estimation agile et traditionnelle, pilotage. Un tour d'horizon des différentes méthodes agiles est abordée même si, en toile de fond, on ressent une forte connotation Scrum et XP. On trouve tout au long du livre des notes de coach XP ou SCRUM, dont Claude Aubry, Laurent Bossavit, qui m'ont permis de découvrir notamment Antoine Contal dont les notes sont particulièrement bien senties. Les derniers chapitres, sur la gestion des hommes et la transition vers l'agilité, sont intéressants car rarement évoqués en générale.

La course au large, une entreprise agile?

Comme je m'y étais engagé lors de ma rétrospective des XP Days, j'ai pris le temps d'écrire une métaphore sur la course au large et Scrum.

J'ai tellement pris le temps que j'ai également creusé autour d'XP puis lean pour enfin me poser une question plus fondamentale:

La course au large, une entreprise agile?

Sans donner de réponse d'ailleurs car cette question était plus un prétexte pour nourrir mes réflexions et penser à mes expériences nautiques faute de temps maintenant pour naviguer.

En débobinant le fil de mes souvenirs en même temps que j'avance dans l'agilité, je découvre une certaine résonnance entre mes différents univers:

*D'abord la course au large qui m'a permis de vivre l'agilité différemment que dans ma vie professionnelle.
*Mes études à l'ENSTA, avec un enseignement par la recherche sur les méthodologies de conception (génie maritime, logicielle, aéronautique, architecturale,..) .
*Puis l'architecture navale, mon premier métier, avec sa conception en spirale et son approche systémique.
*Evidemment le développement logiciel depuis pas mal d'années maintenant avec des projets aux deux extrêmes des méthodologies traditionnelles et agiles.
*Et enfin, bien que moins évident, avec la philosophie orientale et notamment japonaise que j'ai dévoré il fut un temps:
Certains l'abordent par le biais des arts martiaux, en pratiquant au Dojo, et le shu ha ri ou expliquent une partie des origines de scrum avec le concept ba, lorsque d'autres tentent d'aller chercher le zen dans ce kaizen.

Cet état d'esprit permet aussi d'améliorer notre communication avec des présentations Zen.

En forcant le trait, j'aurais presque l'impression d'être aujourd'hui au carrefour de ces différents univers que l'agilité cristallise, comme sous l'effet d'une vague pyramidale pour rester sur le thème de la mer, certains appellent cela "the zen of agile", mais tout ceci est bien présomptueux.

Car si l'étude du bouddhisme et la pratique du yoga m'ont appris une chose, c'est que les choses les plus simples mais les plus essentiels sont quelque fois les plus difficiles à atteindre.

Alors il est temps de pratiquer zazen et "permettre au ba de s'exprimer dans une équipe composée de personnes en état de kaizen", comme l'écrit jefute.

Enterprise Scrum

Enterprise Scrum de Ken Schwaber Je reste un peu perplexe à la lecture de ce livre car certains chapitres sont très intéressants et d'autres vraiment bateaux. Le corps du livre ne fait que 100 pages, le reste est constitué d'appendices dont on trouve une bonne partie ici. Allez-y c'est ma tournée... Ca va du très général (et donc un peu réchauffé) au très particulier à l'image de l'agenda de la réunion de Kick off Scrum. On y trouve évidement des informations sur la transition d'une entreprise vers Scrum, comment multiplier les équipes Scrum, les Scrums de Scrums, la résistance au changement. Mais on trouve le même niveau d'information en cherchant un peu sur le Net, notamment au travers des études de cas à lire sur the Scrum Papers de Jeff Sutherland. On y retrouve des cas d'écoles à la manière de son précédent livre . On peut noter la tentative de formalisation de Scrum au niveau entreprise par NetObjectives avec Scrum#.

Certification Scrum Master

Après avoir raté la session de Mars, j'ai enfin assisté à la certification Scrum master de Jeff Sutherland, qui visiblement a profité de son voyage, avec Xebia.

Je n'ai pas d'avis sur l'aspect certifiant de la formation, il est vrai qu'on ne passe pas d'exam. Cependant, pour avoir passé la certification ITIL validée par un QCM le troisième jour, ce n'est pas plus satisfaisant.

Par contre sur la formation, je ne regrette pas d'avoir eu affaire à Jeff Sutherland. Il communique beaucoup sur sa propre expérience, à la sauce de ken Schwaber, et sur quelles bases cela repose: J'ai en particulier apprécié les liens avec le Lean thinking et découvert le concept ba. Du coup, on peut reprocher un peu de confusion dans le cours. Même en reprenant le support du cours, le fil directeur n'est pas clair. Mais le message délivré l'est, c'est l'essentiel.

Deux moments forts pour moi au cours de cette formation:

Scrum 59' et les XP Game, encore, mais avec une version Scrumisée très interessante avec pour chaque équipe un Product Owner et un Scrum Master.

Dommage que l'on ait été trop nombreux pour ces workshop ( 25 quand même) ce qui ne laissait pas le temps de faire des retrospectives pourtant une des pierres angulaires des méthodes agiles.

Extreme Programming Adventures in C#

Extreme Programming Adventures in C#,par Ron Jeffries Ou les aventures informatiques de Ron en C#! Pourquoi une aventure? car il ne connait pas C# et va le découvrir au cours du projet. Prenant prétexte de développer une application de type XML Notepad avec Visual Studio, on va suivre la pensée de l'auteur et voir comment ses pratiques XP l'aident à avancer: Plus que de la conception émergente, on assiste aussi à de la connaissance émergente! L'approche XP de faire aussi simple que possible Everything should be made as simple as possible, but not one bit simpler, A. Einstein est particulièrement pertinente dans un contexte de découverte d'un nouvel environnement et/ou d'un nouveau language: La construction se fait au fur et à mesure que l'on avance dans le projet et dans la connaissance du C#. Pour les tests utilisateurs, il nous fait une belle démonstration de l'importance des tests et non d'un framework de tests. Même si la solution est très contextuelle, elle est simple, adaptée au problème et sa conception a évoluée avec le code lui-même. Efficace. Il nous livre également une expérience intéressante sur la stabilité du code fasse au changement: une fonction Undo arrive assez tard dans les demandes utilisateur. Une question se pose alors: Est-ce qu'une conception amont intégrant cette fonctionnalité aurait été plus pertinente? Une première implémentation arrive assez rapidement au détriment de l'efficacité. L'utilisateur est content mais le développeur moins et prévoit donc une étape d'optimisation de la solution. Après quelques faux départs s'appuyant sur de la conception papier, la solution d'optimisation apparaitra simplement par itérations sur la solution initiale. Toutes les pratiques XP ne sont pas utilisées puisqu'il travaille seul et est son propre client, mais on assiste tout de même à quelques séances de pair programming et à ses doutes lorsqu'il travaille seul. Concernant le Refactoring, l'essentiel de sa pratique est de supprimer la duplication de code "Once and only once" de martin Fowler "Don't repeat yourself" (DRY) des Pragmatic Programmers Ce n'est donc pas un livre pour apprendre le C# mais bien pour voir de l'extreme programming en oeuvre dans un contexte certe un peu particulier qui apporte un éclairage différent.

Implementing Lean Software Development: From Concept to Cash

Implementing Lean Software Development: From Concept to Cash Second livre de Mary et Tom Poppendieck, qui font partie des premiers théoriciens du mouvement agile dans le développement logiciel. Ce livre est à la fois pratique car il donne des pistes pour un amorçage lean mais également théorique pour permettre de comprendre les fondements de lean. Le livre est quelques fois un peu répétitif même si les éclairages sont différents. Mais globalement, il est très intéressant avec les "Try this" de chaque chapitre, les mythes de chaque valeur, la roadmap pour démarrer. Je serais interessé de savoir si quelqu'un a lu leur premier livre "agile tool kit" et s'il est complémentaire à celui-là?

XP Days 2008 : Jeu du Leadership

Session animée par Yves Hanoulle de PairCoaching

Un workshop de 3 heures avec trois mises en situation de groupe avec un chef, sans chef et avec un coach.

Le tour de salle était intéressant: chacun devant se présenter par ses différences bien que personne ne se connaisse.

Au cours de tous ces workshops, je me fais souvent la réflexion que l'on a, en tant que groupe, à chaque fois la capacité de s'auto analyser et les ressources nécessaires pour s'améliorer avec l'aide d'outils simples comme la rétrospective par exemple.

Cependant il faut savoir faire face à ses faiblesses ou ses erreurs et à chercher à s'améliorer. Ce qui marche bien dans un groupe ou il n'y a pas d'enjeux est plus difficile dans notre réalité professionnelle: car il faut du courage et savoir respecter les autres, des valeurs fortes de l'agilité.

C'est en particulier l'un des enjeux du leader qui doit s'occuper de tous, leur donner la parole. Mais s'il doit être directif sur le processus, il ne doit pas intervenir sur le contenu.

Autre chose assez systématique est l'émergence rapide de leaders dans des groupes auto gérés ou lorsque le chef n'a pas su s'imposer au groupe. Et conclusion connexe, ces leaders peuvent être différents entre une situation de réflexion/conception et une situation de réalisation.

Pour lire le support de cette session, c'est ici et les photos (avec les légos) sont là.

Mise à jour 26/06/08:

Le jeu du Leadership est maintenant téléchargeable ici.

XP Days 2008: TDR

Session animée par Gilles Mantel de Valtech sur le Test Driven Requirements

Pour ceux qui n'ont pas pu assister à cette session, on peut retrouver la première partie de la présentation ici et la source de la seconde partie par Jennitta Andrea ici.
Après cette présentation, On peut s'intéresser au Behaviour Driven Developement
et, entre autre, à une implémentation .Net NSpec.

Le manager agile

"vers un nouveau management pour affronter la turbulence" Ce livre tente de répondre aux questions: Pourquoi l'agilité? Qu'est-ce qu'une entreprise agile? Comment faire un diagnostique d'agilité? J'attendais beaucoup de cette lecture, surtout après la séance de réflexion sur un sujet très proche aux XP days: SSII & Agilité, qui finalement a porté sur notre vision de l'entreprise agile. Mais la lecture de ce livre est sans trop de surprise lorsque l'on est sensibilisé à l'agilité: On retrouve une vision par valeur, principes et pratiques mais avec une portée entreprise et axé management; Et non dédié à l'ingénierie logicielle, ce qui m'a un peu dérouté car il n'y a pas d'écho avec le Lean Software Development pourtant orienté stratégie d'entreprise. Je suis également resté sur ma faim concernant leur outils de diagnostique d'agilité: l'auteur donne le principe de la méthode, les critères avec suffisamment de détails pour s'y intéresser mais pas suffisamment pour l'utiliser. Contrairement à la présentation du livre "cas concrets, exemples et ratios confèrent un aspect très opérationnel à cet ouvrage", ce n'est pas très opérationnel, même si ça reste instructif.

XP Days 2008 : Les neuf cases

Les neuf cases pour bien comprendre son client

session animée par Portia, Bernard et pascal (lire son compte rendu)

Comme je l'avais écrit dans la rétrospective, il y avait beaucoup de sessions sur la communication, l'échange; Celle-ci en fait partie car c'est une technique de dialogue '9 boxes' du solution Selling pour interviewer un client.

L'application directe pour l'agilité est l'écriture des user stories:
On a tous connu un client qui exprime son besoin en terme de solution et qui découvre finalement une implémentation qui ne répond pas à son besoin.

Cette technique permet d'obtenir le besoin réel du client et de l'aider à avoir la vision de la solution réalisable. La technique s'appuie sur des questions ouvertes (son histoire), de contrôles (factualisation de l'histoire) et de confirmation (reformulation).
Il y a 9 étapes à passer avant de pouvoir conclure: le jeu de rôles de la session a montré que c'est plutot difficile d'y arriver dans les temps.
En tout cas, encore bravo à l'équipe pour avoir su animer le jeu dans une salle bondée en cette fin de première journée (et non pascal, nous ne sommes pas venu que pour les chocolats...)

On peut se servir du modèle des "5 Why" de Toyota pour connaitre les causes profondes d'un problème. On peut lire à ce titre la note du très bon blog de QualityStreet à ce sujet.

XP Days 2008 : Laboratoire Extreme Programming

Le labo XP

Atelier animé par Pyxis d'un projet XP Java

Les itérations étant calées sur le rythme des sessions de la conférence, on pouvait entrer dans le projet à n'importe quelle moment de la journée. Les itérations duraient 1h30 avec 3 sprints complets.

J'étais excité à l'idée de participer à cet atelier car je me demandais comment être acteur sur un projet, une techno et avec des gens que l'on ne connait pas sur une durée si courte. Et pour tout dire, je pensais plutôt être spectateur.

Ce sont des conditions idéales pour voir toute la puissance d'XP/Scrum à l'oeuvre, mais je pense que l'équipe de Pyxis y est également pour beaucoup car ils ont de grands talents d'animateurs (déjà vus aux Techdays sur greenpepper), donc merci à eux.

Je passe sur la mise en oeuvre des différentes pratiques pour aller directement à la conclusion: En 1h30, je suis rentré dans le projet, fait un spike, du pair programming, du TDD, intégré tout ça pour livrer un item qui marchait!

Le lendemain, embarquée par la dynamique de la première journée, l'équipe de Pyxis a remis ça et commencé par dédier la première itération à une séance de refactoring, rendue possible par l'ensemble des tests que les membres du projet avaient écrits.

C'est vraiment une belle expérience, complémentaire à un XP Game.

Refactoring Improving the Design of Existing Code

Il est certain que ce livre est une référence sur la pratique du remaniement (Refactoring): L'étude est exhaustive, les patterns de refactoring sont très clairs, les exemples aussi, en java. Au-delà d'un catalogue de pattern et des cas de refactoring, Martin Fowler nous donne une position de compromis entre une conception amont et une conception emergente: la conception réaliste en amont, pouvant être remaniée pendant le développement. Mais bon, ce livre est aussi passionnant qu'un livre de cuisine: lire un pattern me fait saliver les papilles synaptiques autant qu'une bonne recette, mais lire tout le livre est un peu rébarbatif... Pendant la lecture, je me suis fait la réflexion que le remaniement est finalement très analytique: on recherche les invariants (duplication de code par exemple "Once and Only once") d'un système puis on suit la méthodologie pour remanier le code. D'ailleurs, une partie de ces patterns est implémentée dans nos IDE. Qu'est-ce qui fait qu'une pratique analytique (et répandue hors de la communauté agile) devient une pratique agile? Et d'abord qu'est-ce qu'une pratique agile (je n'ai pas trouvé de définition, donc je me lance)? "Une pratique agile applique concrêtement des principes spécifiques au métier (le développement logiciel pour XP) en regard des valeurs de l'agilité" (j'ai bon?) A ce titre le refactoring répond aux critères puisqu'il applique les principes d'amélioration (improvement), des petits pas (baby steps), des similitudes (self-similarity), de qualité... Cette pratique est facilitée par une démarche XP grâce à la pratique des tests d'abord (test-first programming) et permet la conception incrémentale (incrementale design). De même, le remaniement est indispensable au TDD pour garder son code de tests utilisable. Et enfin, toujours dans un contexte XP, ce qui rend cette pratique extreme est que le remaniement doit être permanent. On peut lire sur le site de vanderburg une analyse de dépendances des pratiques XP. Donc cette pratique, bien que plutôt analytique, prend une dimension agile si on la considère d'un point de vue systémique (c'est à dire dans sa dynamique avec d'autres pratiques) dans un contexte XP.

XP Days 2008 - XP Game

Session présentée par Olivier Lafontan

Au départ, ce jeu a été mis au point par Pascal pour expliquer simplement un projet XP:
En 3 heures, les équipes déroulent 3 itérations de 3' après avoir été tour à tour développeurs et clients. Pas de code pour ce jeu mais des ballons, des cartes et des pliages.
Chaque user story est associée à une valeur business et l'équipe qui produit la plus forte valeur business en euro gagne le jeu. Chaque itération commence par une phase d'estimation puis de planning, de réalisation, de livraison et enfin de rétrospective.

C'est assez rapide, la vélocité est calculée en dizaines de seconde. Un des gimmick XP

"If you're going to fail, fail fast"

prend ici to son sens!

Le but est de sentir la dynamique d'un projet XP, comprendre les enjeux de l'estimation et de la planification, des tests d'acceptation, comment passer de la vélocité en seconde à une unité de compléxité propre à l'équipe.

Olivier a fait une analogie très parlante du TDD, de l'intégration continue avec de simples ballons.



Pour avoir plus d'informations sur le jeu, vous pouvez lire ici la description ou bien télécharger les documents ici.


Pour lire une autre rétrospective de cette session par Pascal de Nayima.

XP Days 2008 - Rétrospective

Avant de commencer à rentrer dans le détail des sessions des XP Days, un petite rétrospective:

Bien organisés, nous étions 170 pendant deux jours. L'interêt d'une communauté francophone (France, Belgique, Québec, Suisse romande, ...) émergente est son ouverture, pourtant on y rencontre des références de l'agilité et des gens intéressants. Finalement peu de présentations (en tout cas pour les sessions que j'ai suivi) mais beaucoup d'ateliers , jeux de rôles, labo. Il y était beaucoup question de communication, de compréhension, de collaboration.

Mais, les sessions en parallèle, c'est toujours aussi frustrant...

Je suis un peu passé à côté de la session sur les real options, mais je reviendrais dessus.

Mes actions:

• Blogger sur les sessions
• Adhésion à XP France et sa ML
• Aller voir le site de pascal van cauwenberghe
• Faire un post sur la métaphore de la course au large suite à une discussion que j'ai eu un midi
• Digérer tout ce que j'ai vu

Test-Driven Development: By Example

Ce livre est complémentaire au dernier livre que j'ai lu, mais devrait être lu en premier. Un livre par l'exemple que l'on suit de bout en bout. On regarde Kent beck par dessus l'épaule faire du beau travail... Il met bien en évidence l'interêt des métaphores, la manière d'avoir une interface (API) et un design émergents. Kent montre également la souplesse qu'il faut savoir garder dans la mise en pratique du TDD. Les exemples de la première partie du livre sont en Java, la seconde en Python pour xUnit, ce qui ne facilite pas la lecture du livre. Et la troisième partie est constituée de patterns pour le TDD, les patterns de refactoring associés au TDD. Si Kent est très radical sur les tests unitaires, il n'aborde pas les tests sur les IHM, les bases de données. Ce livre est écrit avec pas mal d'humour ce qui aide à le parcourir. Pour finir on peut retenir que TDD est l'opposé de ce que l'on apprenait "Code for today, design for tomorrow" mais bien "Code for tomorrow, design for today"

News Agile

Quelques notes rapides autour de Scrum et XP:

• C'est bientôt les XP days (5 & 6 mai) à Paris, avec pour moi, un peu de XP game, du lab XP, du test- driven requirements et plein d'autres choses. Tout comme les Techdays, j'essayerais de blogger sur cet évènement


• A noter la sortie de la release R2#4 d'IceScrum, un outils Open Source pour la gestion de projet Scrum. Je n'ai pas eu le temps de tester la dernière version car je travaille en ce moment sur


• VersionOne, qui offre une version communautaire en local ou hébergée. La version hébergée, que j'utilise, est bridée à 5 utilisateurs mais a toutes les fonctionnalités. Jusqu'à maintenant je trouve cet outils plutôt bien.

Test driven Development in Microsoft .Net

L'apprentissage du Test Driven Development par l'exemple est très pertinent tout comme le refactoring, qui sont deux pratiques XP fortement liées. L'auteur propose de construire un site web appelant un web services en construisant les tests avec NUnit d'abord puis avec FIT (Framework for Integrated Test). On suit pas à pas la construction des tests, du code et du refactoring. L'interêt de cet exemple est qu'il adresse les problématiques relatives à chaque couche (présentation, service, web service, DTO, DAL) en séparant bien les tests développeurs des tests clients, avec les problèmes d'isolation que cela pose. L'auteur montre bien la part du TDD dans la conception émergente du projet. Par contre, la partie FIT ne m'a pas convaincue. On peut regretter qu'il ne parle que du framework Nunit sans parler du framework de test unitaires de Visual Studio, le titre est un peu trompeur, je verrais plutôt TDD in C#.

Visual LINQ Query Builder

J'en parlais dans une note précédente, la première release de Visual LINQ Query Builder (VLinq) est disponible depuis quelques jours, sous licence Ms-PL.

Vous pouvez lire la note de Mitsuru ou télécharger le projet directement ici.

Scrum est-il soluble dans ITIL?

Fraichement certifié ITIL Foundation, la préparation de cette certification m'a amené quelques réflexions autour de l'agilité. Je les livre ici à chaud:

Au-delà de la question ITIL est-il agile, je me posais la question d'utiliser Scrum au sein d'une DSI implémentant ITIL?

On peut déjà se poser la question pourquoi cette réflexion puisqu'ITIL adresse essentiellement la gestion de la production informatique. Cependant, un pont est jeté avec les études et développements au travers du processus change management.


On peut partir d'un socle commun à tous ces processus et normes: La roue de Deming.
C'est la partie la plus évidente. Pour Scrum, on pourrait rapidement faire les liens:

• Plan: Sprint Planning
• Do: le Sprint en lui-même
• Check: Le Daily Scrum
• Act: La retrospective

La roue de Deming est un fondement d'ITIL, on la retrouve plus précisément dans le Service level Management avec le programme d'amélioration des services dans une démarche cyclique.

Puis vient le principe de remettre le client au centre des préoccupations avec tout ce que cela implique (besoins métiers, feedback, responsabilisation,...). Même idée pour Scrum ou XP. Cependant, l'implémentation me pose plus de problème. Le change manager consolide toutes les demandes d'évolutions logiciels provenant de la direction métier ou des utilisateurs via le service desk. Avec ma compréhension, il pourrait avoir le rôle de Product Owner cependant ce n'est pas le client final.

La product Backlog existe aussi côté ITIL sous une autre forme avec également une notion de priorisation.


A ce point on rentre sur une zone de divergence entre les approches:

Scrum est l'art du possible. Un but d'ITIL est de remplacer le domaine du possible par des contrats de services. On retombe ici sur une problématique récurrente de contractualisation de projets agiles.

Un autre point de divergence sur les messages forts véhiculés, est la réactivité de Scrum ou d'XP et la proactivité d'ITIL. Cependant, ce point est à mon sens un faux problème car la proactivité s'adresse plutôt à l'aspect production du SI (gestion des problèmes, suivi des performances, plan de capacité, ...).

Remarque XP: Le Test-driven development amène de la proactivité sur l'assurance qualité.

ITIL propose de responsabiliser et professionnaliser les rôles. Ce qui peut sembler contradictoire avec une équipe scrum regroupant tous les rôles. Cependant, on parle ici de processus transverse pour décloisonner les services. Je n'y vois donc pas de contradiction puisque Scrum est également un processus transverse pour le développement.

La professionnalisation des rôles et des équipes permet d'augmenter la productivité en diminuant les bruits, c'est également un des indicateurs que l'on suit avec la velocité.

En terme de scalabilité de projet, je n'ai pas eu de réponse claire pour une démarche ITIL alors que Scrum y répond clairement avec les Scrums de Scrums.

A première vue, il semble possible de faire cohabiter un projet Scrum ou XP dans un processus global ITIL en adaptant le rôle du product owner et le contrat de service pour ce projet.

Agile project Management with Scrum

C'est l'histoire d'un scrum master (et pas n'importe lequel ... Ken Schwaber) qui raconte ses histoires de Scrum. En fait c'est un livre très bien construit car il prend les exemples sous différents angles de vues: Scrum Master, Product Owner, équipe et croise les conclusions pour bien comprendre les rôles et l'implication de cette méthodologie. Par contre, une légère frustration à la fin du livre, en annexe même, lorsqu'il évoque juste les problèmes de contrat; Et toujours en annexe, lorsqu'il pose les liens avec le CMM , cela mériterait de faire un zoom sur ce point, peut être un axe pour mieux convaincre les DSI (à ce sujet, on peut aller fouiner dans l'Open Space Agile CMMI).

DbLinq.MySqlProviders

Comme je l'annonçais il y a quelques temps ici, je travaille sur une version des providers .Net MemberShip et Role s'appuyant sur un premier travail CodeFx.MySqlProviders et le framework DbLinq.
La dernière version de ce dernier, bien qu'ayant quelques buggs (surtout sur la génération du DataContext via SqlMetal), permet une première version de mes providers (Notez qu'elle permet surtout l'utilisation d'Oracle).
J'ai donc mis ce projet sur codeplex sous licence GNU.
La prochaine version devrait embarquer les providers Personnalization et Profile.

Entity Framework et les fonctions SQL

Voulant utiliser une fonction scalaire SQL avec Entity Framework, je me suis heurté à quelques difficultés techniques. Il a fallu chercher la réponse du côté d'Entity SQL et de la couche logique du modèle d'Entity Framework (lire l'article de john Papa pour comprendre les couches d'Entity FrameWork).

Distinguons d'abord les fonctions canoniques des fonctions utilisateurs.
Pour les premières pas trop de soucis d'utilisation (lire la note de Zlatko Michailov), exemple:

MonObjetContext.CreateQuery("select value r from [MaTable] as r where Length('abc')=3;").ToList();

Par contre, pour les fonctions utilisateurs, ce n'est plus si simple (cf. mon post sur le forum que je résume ici). Je remplace la fonction canonique Length par une fonction utilisateur MaFonction.
Le même code lève une erreur à l'execution:

MonObjetContext.CreateQuery("select value r from [MaTable] as r where MaFonction('abc')=3;").ToList();

Pour que ça s'execute bien, EntitySQL doit savoir ou rechercher la définition de cette fonction. La définition va se trouver dans la couche logique de mon modèle (celle qui mappe ma base de données), c'est à dire dans le SSDL (que l'on trouve sous bin\ObjectContext ou directement dans la vue xml de MonEDM.edmx). En regardant de plus prêt dans le fichier MonEDM.ssdl, on trouve le nom du namespace et la définition de la fonction:

<schema xmlns="http://schemas.microsoft.com/ado/2006/04/edm/ssdl" namespace="MonEDM.Store" alias="Self" providermanifesttoken="09.00.1399">

<function name="MaFonction" returntype="int" aggregate="false" builtin="false" niladicfunction="false" iscomposable="true" parametertypesemantics="AllowImplicitConversion" schema="dbo">

Avec ces informations, je peux maintenant appeler ma fonction via EntitySQL en spécifiant le namespace:

MonObjetContext.CreateQuery("using MonEDM.Store;select value r from [MaTable] as r where MaFonction('abc')=3;").ToList();

sans erreur d'execution.

Techdays : Suite et fin

D'autres sessions ont été très intéressantes à suivre mais difficiles à retranscrire, comme la présentation de l'infrastructure et l'architecture de MySpace. Je m'arrête donc là pour mon retour sur les Techdays avec un bilan très positif.

Un grand merci pour les liens:

• Technet
• DotNetGuru

Prochaine conférence: les XP day France sur l'XP et l'agilité.