Note : 4 ; Une prétention encyclopédique qui tombe un peu à plat.
Ce n’est certainement pas le premier ouvrage à nous parler de développement agile. Vu son âge vénérable, nous lui concèderons aussi de faire partie de la première génération de livres consacrés à l’agilité. Nous ne nous étonnerons pas non plus que la pratique se consacre à Extreme Programming, mais sans aucune velléité dogmatique pour autant.
Avec près de 400 pages presqu’exclusivement couvert de texte, l’ouvrage est particulièrement dense. Il a des prétentions bibliographiques, car en grande partie consacré à des descriptions de pratiques qui sont loin d’extreme programming en grande partie. En cela ce titre est particulier. Il est structuré en 3 parties et totalise 15 chapitres. La première partie, « getting started » regroupe les 4 premiers sur environ 65 pages. Elle débute par un chapitre nous aidant à répondre au « pourquoi » de l’agilité. Il n’y a guère de surprise ici. Il est intéressant toutefois de voir l’auteur articuler son propos à la croisée des succès techniques, individuels et organisationnels.
Le « comment » devenir agile ne réserve guère plus de surprises, moins même. Les quelques pages qui lui sont dévolues se concentrent sur le manifeste agile : les valeurs et les principes, sans entrer dans les détails. Les détails, ils sont pour le chapitre 3 qui couvre XP, ou plus exactement l’interprétation par l’auteur de XP. La description est déjà colorée de pratiques et de rôles qui n’appartiennent pas au corpus d’extreme programming. La méthode originale en est difficile à reconnaitre. Le chapitre 4 « adopting XP » permet mieux de reconnaitre la méthode et ses vecteurs d’adoption. A une différence de taille : la recommandation d’adopter XP pour les projets « page blanche » qui me semble à la fois réducteur et en décalage avec le monde réel.
Note : 6 ; Quand planifier rime plus avec visibilité qu’avec « estimer ».
L’extrême programming se focalise sur des cycles de développement fortement itératifs, au sein desquels l’interaction avec le client et permanente et le formalisme réduit au minimum. Dans ce cadre, écrire un livre sur la planification d’un tel processus peut sembler une gageure. En fait, ce livre ne traite guère de métrique d’évaluation ou de consommation du développement, mais se focalise sur les aspects humains. Planifier en Extreme Programming, c’est avant tout s’assurer que l’on travaille sur les choses les plus importantes et pouvoir se coordonner avec les autres (le sujet du 1er chapitre). Pour faire cela, il faudra aussi estimer, mais différemment.
Cet ouvrage, co-écrit par deux grands noms de la communauté, n’est guère long : 130 pages ! A l’instar de nombreux volumes de l’XP series, il compte beaucoup de chapitres, il y en a 27. Les passer tous en revue serait fastidieux, je vais me contenter de relever quelques éléments qui m’ont marqué ou que j’ai aimé.
Suite du compte rendu d’Agile France, après la journée de Jeudi disponible ici et ici.
De bon matin…
De bon matin, ce n’est pas moi. J’arrive à temps pour le café et discuter un peu avec les autres. Mais quand j’arrive, un petit groupe se livre déjà à des exercices de Qi Gong.
Je retrouve les autres dans la salle commune. On discute, Alex Tweet. Business as usual…
Assez plaisanté ! La journée va commencer, place à la keynote !
Coaching Teams Through Change
Rachel Davies nous avait déjà gratifié d’une session il y a peu lors du ScrumDay. Fort heureusement, ce ne fut pas la même. J’ai d’ailleurs préféré cette keynote.
Rachel travail pour Unruly, une société spécialisée dans le « social media advertising ». C’est un domaine où les spécifications changent véritablement tous les jours. L’objectif est ainsi de déployer effectivement tous les jours !
Le début d’un changement
Au début les départements produit et développement étaient deux directions séparées. C’est le départ du directeur produit qui a permit d’enclencher un changement de structure.
Ce changement, c’est l’organisation en équipes de 3 à 5 personnes pour développer le produit. Et pas seulement développer : ces équipes prennent en charge la totalité des activités entourant le développement : l’écriture des user stories, les tests, etc. Ce sont eux qui vont solliciter les différents interlocuteurs (produit, marketing, commercial) quand cela s’avère nécessaire. Pas de product Owner qui est la seule voix du client, l’équipe va parler directement à tous les interlocuteurs ! Parmi ces interlocuteurs, nombre d’entre-eux ne sont accéssibles qu’à distance : l’équipe utilise Google Hangout pour communiquer. La conversation s’engage avec les interlocuteurs pour trouver la plus petite chose utile à construire, ce qui nécessite de prendre en compte tous les point de vue.
Lone rangers et development owners
Tout le développement est réalisé en binômes. Mais les équipes sont constituées d’un nombre impair de personnes ! En fait, par rotation, l’une d’entre-elle est le « lone ranger ». Elles s’occupe de diverse choses dans l’équipe, mais pas du code de production. C’est aussi à cette personne que les intervenants extérieurs à l’équipe s’adressent, afin de ne pas perturber les binômes en train de travailler.
L’équipe a aussi développé l’idée de « owner of the development area » : un développeur plus expert au sein d’un sous-ensemble fonctionnel. C’est lui qui élabore une proposition par rapport à un besoin exprimé. Les propositions sont traitées en planning meeting. Celui-ci n’est pas un planning meeting classique XP : seule la priorisation des propositions y est traitée, il n’y a pas d’engagement de charge. Ces planning sont donc très courts : ils n’excèdent pas 30 minutes !
Gold card
A l’image de ce que Kniberg décrit pour Spotify, Unruly fait des efforts particuliers par rapport au bien être des équipes. Outre divers évènements sociaux, la société applique la politique du 20% free time inspirée de Google (bien qu’elle disparaisse progressivement de Google, justement). Ici elle s’appelle « gold card day » et sert de sources d’inspiration pour creuser de nouvelles idées.
Ce que j’en ai pensé
Sans être exceptionnelle, cette présentation nous offre l’opportunité d’avoir un retour sur une organisation d’équipe différente de ce que l’on voit aujourd’hui :
Les itérations s’estompent au profit de la déliverie continue, mais des points de priorités réguliers contrebalancent l’effet « court terme » du flux.
Pas de « product owner » ici : c’est l’équipe qui fait le lien avec les divers interlocuteurs. Le périmètre de responsabilité de l’équipe s’accroit, mais on évite ainsi l’effet paravent du PO !
Je change mon programme à la dernière minute. Je choisis en 15 secondes d’aller à une présentation résolument technique. Grand bien m’en a pris !
Le mythe du framework agile
Jean-Baptiste Dusseault vient mettre fin à quelques idées reçues concernant ces frameworks qui doivent nous agilifier / faciliter la vie. Au départ de ce « ras le bol » un titre de livre : Agile Web Developement with Rails ! Même co-écrit par l’un des signataires du manifeste agile (et par l’auteur de Rails), ll y a un problème ici. Probablement plusieurs même. Le premier est la taille du livre : près de 500 pages !
Le framework maison
Mais commençons par le commencement. Et le commencement, puisque nous parlons ici de frameworks « full stack », c’est le fameux framework d’entreprise. Un bon point : nous n’avons que trop rencontré ces pantalonnades. Lâchons-nous, ça va faire du bien !
Le but de ces frameworks, c’est d’avoir le « meilleur du moment », tout bien branché ensemble. On met les pantoufles, on débranche le cerveau, et l’on peut tranquillement produire plein d’applications en un tournemain ! Sauf que ça ne se passe pas comme ça. Ces braves frameworks transforment notre vie en enfer !
Citons dans le désordre :
Prévus pour être simples, ils s’avèrent en fait ultra-compliqués ! Peut-être leur conception et leur réalisation par des « équipes transverses » explique-t-elle quelque chose ?
Ils sont difficiles à tester et très bugués. Là encore, leur réalisation détachée des projets n’a pas contribué à leur testabilité. Utilisés uniquement par quelques projets de l’entreprise (au mieux) le « durcissement » du framework n’a jamais vraiment eu lieu…
pas de support : souvent les équipes ayant réalisé le framework sont parties depuis longtemps…
Qu’en est-il des « full stack » reconnus ?
Ici on parle des rails, Play, etc… Ils nous font la même promesse d’accélérer les développement du sol au plafond. En vérité, ils prennent des décisions d’architecture pour nous ! Jean-Baptiste va plus loin : en déléguant les choix d’architecture au framework, on laisse celui-ci nous utiliser !
Nous n’utilisons pas les frameworks “full stack” : ce sont eux qui nous utilisent.
Ce biais a des conséquences, on va le voir bientôt.
D’où vient leur succès ? Ils permettent de faire très vite 80% de l’application. Mais on galère sur les 20% restant ! Généralement, la réalisation en suivant le tutorial va vraiment vite.
Hélas, ils encouragent certains comportement. La partie « basse » entité et persistance est plus ou moins câblée. Il n’est pas possible d’y intervenir facilement. Et les entités ressemblent beaucoup aux tables de la base de données (ça rappelle les outils RAD client/serveur). On hérite donc d’un couplage vertical sur la base de données.
En fait, le seul endroit où l’on peut réellement raccrocher du code, c’est le contrôleur ! On l’accroche comme on peut. Et si des comportements communs apparaissent dans le code tartiné sur deux contrôleurs, le seul moyen efficace de le partager est le copié-coller ! Beurk !
Bref nous obtenons :
Des architectures monolithiques.
Des frameworks optimisés pour l’écriture de code … mais pas pour sa maintenance !
Des couplages forts avec la représentation et la base de données.
De grosses difficultés pour sortir des clous via des « plugins » et autres joyeusetés du genre qui ont de grosses courbes d’apprentissage.
Une testabilité rarement au rendez-vous.
Mais alors, c’est quoi un framework agile ?
Plutôt que de framework agile, parlons d’architecture agile, et des propriétés qu’elle devrait avoir.
Elle doit nous permettre de retarder les décisions
Elle minimise les couplages.
Elle est facile à changer.Elle est testable (via TDD et ATDD)
Une proposition et des inspirations
Pour Jean-Baptiste Dusseault, une telle architecture c’est :
Au centre un véritable modèle du domaine d’inspiration DDD, comme les proposent l’architecture hexagonale d’Alistair Cockburn ou la Clean Architecture de Bob Martin. Ce modèle ne dépend de rien et ne connait pas la persistence ni aucun système tiers, mais expose une API métier.
Une couche « commandes » implémentant les cas d’utilisation du modèle du domaine. Des idées que l’on retrouve dans la Lean Architecture de Jim Coplien.
Au-dessus un couche d’accès type CQRS dialoguant en asynchrone avec la couche commande et routant différemment les évènements commande (vers la couche commande) des requêtes qui sont adressées directement à la couche d’accès à la base de données.
Bien sûr le postulat de cette architecture, c’est que le métier est au centre des préoccupations. On n’évoque pas non plus l’architecture en micro-services qui me semble pourtant adaptée mais peut-être pas facile à concilier avec une architecture hexagonale…
La présentation de Jean-Baptiste est évidemment en HTML5 et elle est accessible en ligne ici.
Ce que j’en ai pensé
Cette session est une agréable surprise. Si le bashing des « frameworks agile » ne fait que confirmer ce que je pensais, les idées développées sur l’architecture agile me font beaucoup plus réfléchir, pour ne pas dire qu’elles soulèvent mon enthousiasme !
Comment j’ai développé mon muscle de l’amélioration continue en faisant mes courses
Ayant décidé de bouleverser mon programme, je n’ai de nouveau que 2 minutes pour changer mon programme. De nouveau, c’est une bonne pioche avec la session de Cyrille Deruelle !
Tout d’abord : pourquoi faire des exercices d’amélioration ? Pour que cela devienne une habitude, rendre cela naturel. Et Cyrille s’est livré à cet exercice en faisant ses courses du Samedi : c’est drôle et instructif !
Bien sûr tout ça n’a pas très bien marché du premier coup (d’où la nécessité de s’améliorer). Au départ, Cyrille a essayé d’impliquer son épouse (Product Owner des courses) dans la résolution des problèmes qu’il rencontrait. C’est une première leçon :
Les gens se foutent de la manière dont nous résolvons les problèmes.
Au hasard des améliorations, on va trouver :
« t’as rien oublié » … où comment suivre que l’on a tout acheté ? A l’aide d’une liste de courses et d’un gros feutre noir (le stylo fin ne convient pas).
Grouper les courses par catégorie : afin d’optimiser le parcours dans le magasin.
Prendre une photo des rayonnages pour les produits compliqués … afin de permettre à son épouse d’indiquer le produit souhaité. Le choix de la lessive a été vaincu ainsi !
Gérer les dates limites de consommation en les pré-calculant par rapport aux courses suivantes : afin d’éviter les erreurs pendant les courses.
Sortir des éléments du process : Les packs d’eau, c’est ingérable ! Alors on ne les sort du processus standard et on fait de temps en temps des ravitaillements en eau (en grande quantité) !
Les conclusions de Cyrille
Mes problèmes sont mes problèmes : Il n’est pas possible de s’en décharger sur d’autres personnes.
Il n’y a pas de choses simples : l’amélioration continue est une quête !
Les actions d’amélioration sont fragiles et difficiles ; c’est une discipline de tous les jours.
Mesurer l’impact d’un problème, c’est déjà 50% de la résolution
Enfin parfois, les améliorations ne sont pas possible, c’est le CCMCCC : C’est Con Mais C’est Comme Ca !
Grâce aux actions d’amélioration, Cyrille n’a pas seulement rendu son processus de meilleure qualité et plus efficace, il l’a aussi rendu fun !
Ce que j’en ai pensé
Une très bonne session : amusante et instructive. Bravo !
Refactorer du Legacy
Pas besoin de changer de salle pour la session de Johan Martisson. J’ai rencontré Johan lors du ScrumDay 2014. Ou plus exactement, Jean-Laurent de Morlhon me l’avait présenté. D’ailleurs Jean-Laurent était là à cette session résolument intimiste orientée craftmanship, avec des vrais morceaux de « live coding ».
Johan nous parle et nous démontre son approche de la reprise en main du code legacy, à l’aide de la librairie ApprovalTests. Pour résumer l’approche en quelques points :
On construit un harnais de tests résolument temporaires de manière rustique mais rapide.
On construit de manière assez brutale des combinaisons de conditions d’entrée pour couvrir une combinatoire de cas couvrant l’espace du problème.
On exécute une première fois les tests pour constituer la référence, sans se soucier de la justesse des résultats : il s’agit juste du comportement courant de la librairie.
On vérifie la stabilité du comportement du soft en comparant les résultats par rapport à la référence.
Au fur et à mesure du refactoring, on construit des tests unitaires définitifs. On peut envisager de se débarrasser définitivement des tests temporaires, de manière progressive.
Ce que j’en ai pensé
Au début de la présentation, je mes suis demandé où Johan essayait de nous emmener et j’ai pris conscience avec un peu de retard de l’efficacité et de la rapidité avec laquelle Johan mettait en place son harnais de tests ! Je dois dire que c’est très convainquant. Une petite vidéo pour vous en convaincre.
J’avais prévu d’être un peu plus long sur le descriptif de ce que Johan nous a montré avec l’outil, mais il le fait mieux que moi sur son blog. Je vous invite donc à le lire.
Pause déjeuner
Par une curieuse coïncidence, c’est de nouveau avec Jean-Luc Lambert que j’ai échangé lors de cette pause. Et nous avons parlé éducation et « génération Y ». Jean-Luc évoque avec enthousiasme le challenge que représente l’enseignement avec cette population.
Elle ne prend pas pour acquis les propos de l’enseignant. Le cours magistral a une vertu pour le moins limitée.
Ils sont « multi-tâches ». C’est assez déroutant, mais il faut faire avec !
Ils sont réceptifs aux jeux et aux exercices libres. Les techniques type « from the back of the room » leur sont bien adapté.
Ils ont beaucoup d’autonomie et sont entreprenant.
Ils ne se sentent pas beaucoup d’attache ni de fidélité pour la société pour laquelle ils travaillent.
Voilà pour cette dernière matinée. Je vous retrouve très bientôt pour la dernière partie de cet Agile France 2014 !
Note : 7 ; Plutôt bon, mais un livre qui ne présente pas le même niveau d’intérêt pour tous les publics !
Laurie Williams est reconnue dans la communauté agile pour être une grande spécialiste des aspects collaboratifs, il est donc logique qu’elle soit l’auteur de l’ouvrage de référence sur le pair programming, avec Robert Kessler, son mentor.
Le « pair programming » est probablement la pratique qui fait l’objet du plus de résistance lors de la mise en place d’une méthode agile. A cet égard, il n’est pas illogique de chercher à blinder la mise en place de cette pratique, par exemple à l’aide de ce livre. On reconnaitra que le texte cherche vraiment à traiter toutes les facettes du pair programming.
La première partie a trait à la compréhension de ce qu’est vraiment le pair programming. C’est sur cette partie qu’il faudra construire l’argument pour convaincre. L’auteur s’attaque aux mythes justifiant l’opposition à cette pratique avant d’évoquer les aspects bénéfiques. Vient ensuite le plat de résistance : convaincre le management. J’avoue que c’est du solide, avec des arguments, des chiffres et tout et tout. Cette partie se termine par l’évocation des difficultés qui peuvent se rencontrer à la mise en place du pair programming. Somme toute, cette première partie est une sorte de préambule à la mise en place de la pratique : pour convaincre, anticiper les obstacles et les objections, etc… Il n’y a rien à jeter et on a vraiment des choses solides sur les 60 pages de cette partie.
Longue d’une trentaine de pages, la seconde partie intitulée « getting started » m’a paru moins utile. Beaucoup d’éléments qui y sont présentés viennent simplement du bon sens et l’on a guère besoin du texte pour y arriver. Mais peut-être n’est-ce pas si mal d’avoir cela écrit quelque part ? Une mention particulière au chapitre 11 « tips ‘n tricks » qui donne pas mal de trucs utiles.
La troisième partie est la plus longue du livre avec une centaine de pages. Elle est écrite sous forme de patterns avec les différentes configurations de pairing (expert / novice, expert/expert , etc…) et différentes situations émotionnelles. L’idée est de fournir des solutions sous forme de scénarios afin de rendre possible ces différentes dynamiques de travail. Je ne suis pas convaincu que tout cela marche d’une manière aussi simple, mais au moins cela donne des pistes de réflexions.
La dernière partie enfin évoque différents aspects rassemblés ici de manière un peu hétéroclite : aspects économiques, les bonnes habitudes, pair programming versus code inspection, etc..
Le texte n’est pas mal écrit et plutôt plein de bon sens. De plus il est abondamment émaillé de références bibliographiques (l’auteur les a même fait figurer en fin de chaque chapitre). La première partie est littéralement de l’or en barre et on trouve clairement du matériel intéressant dans les autres. Beaucoup de matériel reste surtout intéressant pour ceux qui portent un intérêt académique au sujet (c’est mon cas). C’est un livre que je conseillerais sans hésiter au coach qui va y trouver beaucoup de matière première pour guider les pratiques d’une équipe. Le manager va y trouver des arguments pour défendre cette pratique, mais le développeur aura sans doute la sensation de perdre son temps à cette lecture.
Référence complète : Pair Programming Illuminated – Laurie Williams & Robert Kessler – Addison Wesley 2002 – ISBN: 0-201-74576-3
Note : 8 ; La mise en pratique réelle et concrète d’un projet XP.
La littérature ne manque pas, concernant l’extrême programming. Aussi, il peut être difficile d’y faire son choix. Le mien s’est arrêté sur « Extrême Programming Installed ». En effet, celui-ci se distingue des autres ouvrages par son coté résolument pratique, intégrant les retours d’expérience au texte. Les auteurs ont en effet partagé le même projet, ils nous font profiter de l’expérience issue de leur collaboration, ainsi que de projets XP antérieurs. Il est souvent difficile de se faire une idée concrète de la mise en œuvre d’un processus décrit non par le menu, mais par ses principes. Ici, les auteurs nous livrent des extraits de dialogues, des exemples de « user stories », des « minutes » d’une séance de test-first design et des exemples de tests unitaires, entre autre choses. Autre point intéressant : le livre répond clairement à certaines questions souvent laissées sans réponses : qui écrit les jeux de tests d’acceptation, qu’en est-il des erreurs provenant non des classes elle-même, mais de la collaborations entre classes, etc.. On regrettera cependant les prises de positions parfois “élitistes”, la pire d’entre elle étant le choix d’expliquer des choses en Smalltalk, qui ne peut être guère considéré comme un standard du marché. Le XP doit sortir de sa position de dédain envers le monde extérieur !
Ce livre, relativement succinct, comme tous les volumes de la « XP series » d’Addison Wesley, avec ses 240 pages ne compte cependant pas moins de 34 chapitres ! Seuls 23 d’entre eux (175 pages) constituent la partie principale de l’ouvrage, les 11 derniers sont considérés comme des « bonus tracks ». Celles-ci rassemblent des techniques particulières alternatives qui furent marquantes au cours du projet. Pour ma part, je retiendrais « It’s Chet’s Fault », où comment couper court aux stériles recherches de coupables afin d’aller vers l’avant. Les 23 chapitres principaux ne sont pas organisés de façon chronologique comme on aurait pu s’y attendre, mais par principes et techniques d’XP, considérant les valeurs fondamentales de la méthode comme acquises.
Finalement, plus que “Extreme Programming explained”, j’ai trouvé que cet ouvrage, par son coté vécu et le retour d’expérience qu’il relate, était le mieux à même de faire comprendre l’essence de l’Extreme Programming. Le style est vivant et le propos concret, c’est tout ce dont on a besoin pour se faire une idée de la méthode. Une lecture critique est cependant nécessaire, car le propos souvent dogmatique est quand même gênant.
Référence complète : Extreme Programming Installed – Ron Jeffries, Ann Anderson & Chet Hendrickson – Addison Wesley / XP series 2001 – ISBN: 0-201-70842-6
Note: 6 ; Le tribun des méthodes agiles … mais quelle longue narration !
Si vous souhaitez avoir une vue d’ensemble sur les méthodes agiles, quelle en est leur essence, quelles sont-elles et quelles sont leurs différences, alors voici LE livre. Jim Highsmith est lui-même l’auteur d’une de ces méthodes, mais cela ne l’empêche pas de présenter les autres avec une grande honnêteté et égalitarisme. En fait, bien qu’il joue sans ambiguïté dans le camp des agiliste, il met en vis à vis des méthodes présentées les approches traditionnelles plus prescriptives (analyse structurée, UP et basées CMM), toujours avec honnêteté.
Le plus grand défaut de ce livre, à mon avis, c’est sa longueur: il est étonnant de voir cet ouvrage s’étendre sur 400 pages alors que les différentes approches sont seulement survolées (seul leur “essence” est vraiment décrite, et c’est bien). Mais Jim Highsmith est un bavard, et même si leurs valeurs des méthodes agiles tiennent en une poignée d’idée, cela n’empêche pas l’auteur de s’étaler sur de longues pages de texte (les 400 pages ne comprennent quasiment pas de diagrammes ni autres illustrations). Fort heureusement, le style du narrateur n’est pas ennuyeux et sa longue expérience et son importante culture gardent le texte agréable, tout comme les interviews (eh oui!) des gourous des méthodes agiles. La moitié du volume aurait suffit, mais la lecture ne m’a cependant pas paru pesante.
Si un tour d’horizon de l’agilisme vous intéresse, nul autre ouvrage ne saurait remplacer celui-ci.
Référence complète : Agile Software Development Ecosystems – Jim Highsmith – Addison Wesley / ASD series 2002 – ISBN: 0-201-76043-6
J’ai posté il ya quelques jours une liste de mes “book of the year”. Voici une autre liste que j’entretiens: les “book of the decade”
Quels sont les livres qui ont vraiment fait changer votre façon de voir votre métier ? ceux qui ont réellement fait évoluer vos pratiques et peut-être même votre carrière ?
En découpant par tranche de 10 ans, j’ai relevé un livre qui fut chaque fois marquant. J’ai bien un peu triché dans mon découpage, mais que diantre: ce sont MES “books of the decade” ! On retrouve ces titres dans la liste des “book of the year”. C’est assez logique, mais en fait ce n’est pas un critère !
1981-1990 : Gödel, Escher, Bach: Les brins d’une guirlande éternelle – Douglas Hofstadter – InterEdition
1991-2000 : Design Patterns, Elements of reusable object oriented software – Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides
Software Freethinker 
