Les choses qui importent le plus ne doivent pas être à la merci de celles qui importent le moins.
Goethe
Note de lecture : Gestion de projet agile, avec Scrum, Lean, Extreme Programming, par Véronique Messager-Rota
Note : 5 ; Un point de départ pour le chef de projet débutant, complété par des évolutions mineures, au fil des éditions.
Il est certainement une chose plus difficile que donner une note et un avis sur un ouvrage auquel on a participé : c’est se livrer au même exercice sur un livre dont on est l’auteur ! Je n’en suis pas là, mais cet exercice reste bien assez difficile pour moi.
Ce livre n’est pas une bible de la gestion de projet agile. Je doute d’ailleurs qu’une telle chose puisse exister. Il s’adresse plutôt à un publique junior ou en tout cas nouveau venu dans l’agilité et adresse deux questions essentielles :
- Quelles sont les activités que doit mener ou maîtriser le chef de projet : Ce sujet est traité tout au long du livre, car les différents chapitres traitent chacun un aspect spécifique des disciplines à maîtriser : ébauche de la vision, gestion des besoin, suivi des hommes et pilotage du projet. Il manque hélas une partie consacrée aux tests, et je regrette de mon coté que la facette plus technique du projet ne soit pas abordée, car je considère le rôle du chef de projet comme davantage holistique.
- Quel style aborder pour gérer les projets ? Le titre du livre réponds à cette question, bien que parfois le texte ne nous laisse pas clairement comprendre quelle approche est la bonne. Toutefois mettre les approches classiques et agiles en perspective est un bon exercice.
L’une des particularités du livre est certainement de laisser une part importante aux retours d’expériences (y compris ceux de votre serviteur) pour éclairer le propos. Sans être réellement aride ni académique, celui-ci est souvent un peu trop formel à mon goût.
Ce livre en est maintenant à sa 3ème édition. Que dire des évolutions entre la première mouture et le dernier rejeton ?
Tout d’abord que ces deux nouvelles éditions répondent en premier lieu au « business model » d’Eyrolles consistant à publier très régulièrement de nouvelles éditions de ses best-sellers. Donc il s’agit d’un best seller ! Comme chacun sait, cela n’est pas synonyme de qualité, mais en l’occurrence ce texte atteint bien sa cible (celle que j’ai évoquée plus haut) et le succès du livre en est témoin.
Dans la seconde édition, l’auteur a profité de l’occasion pour rafraîchir sa prose, même si c’est de façon mineure. Cela se voit dès la pagination, le volume total passant de 230 à 250 pages (hors annexes). Il s’agit surtout d’ajouts à l’intérieur des chapitres existant, le texte de base me paraissant inchangé. Ainsi le chapitre 2 qui exposait déjà de manière synthétique et avec brio les différentes méthodes agiles, ajoute « Lean » à sa panoplie. Le chapitre 3 se voit étoffé d’un court comparatif entre les users stories et les cas d’utilisation. Utile en soi, ce comparatif est je pense matière à débat. En clair : il faut qu’on en reparle, Véronique ! Le chapitre 7, consacré à l’adoption des méthodes agiles est celui qui bénéficie le plus d’ajouts : mesure de l’adoption et accompagnement de la conduite du changement.
L’apport le plus important à l’ouvrage est la section consacrée aux apports du coach (toujours dans le chapitre 7). Ces quatre pages supplémentaires ciblent les apports du coach par rapport à l’équipe et au management sur le « savoir être ». Il s’agit d’une prémices du prochain livre de Véronique !
La troisième édition qui n’apporte à nouveau que des bribes de nouveautés. On notera ainsi :
La section dédiée aux organisations agiles, au chapitre 2, qui permet de valoriser les idées avancées par Jérôme Barrand. Le chapitre 4, se voit lui, gratifié d’une page consacrée au pomodoro, ce qui est un ajout original et sympathique. Au chapitre 6, un petit ajout est fait sur le thème de la facilitation.
Sans avoir réellement vieilli, le livre voit son public se restreindre d’année en année : s’il adressait un public d’early adopter lors de sa sortie, il s’agirait maintenant plutôt de late adopters, pas forcements enclins à aller rechercher activement de l’information. Véronique Messager ne semble guère souhaiter poursuivre la politique de retouche mineures du texte et c’est à son honneur.
Si vous débutez en gestion de projet et vous posez la question de l’adoption d’une approche agile, ce livre est pour vous. Il vous permettra de poursuivre plus facilement votre apprentissage par des textes plus avancés ensuite.
Référence complète : Gestion de projet agile, avec Scrum, Lean, Extreme Programming, 3ème édition – Véronique Messager-Rota – Eyrolles 2010 – EAN : 978 2 21212750 8
Note de lecture : Pair Programming Illuminated, par Laurie Williams & Robert Kessler
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
Le bon sens est la chose au monde la mieux partagée : car chacun pense en être bien pourvu.
René Descartes
De l’usage des exceptions en C++
J’ai écrit cette petite synthèse il y a environ 14 ans, pour contribuer aux réflexions sur l’usage, les contraintes et les pièges liés à l’emploi des exceptions en C++. Beaucoup d’éléments restent d’actualité aujourd’hui, je pense.
En tout cas, il s’agit d’une invitation à se méfier d’une approche naïve “si ça compile, c’est que c’est bon". La compréhension et la bonne utilisation d’une caractéristique du langage vont bien au-delà de la compilation ou même de l’exécution et du passage des tests ! Le C++ est bien connu pour cela, mais c’est aussi vrai pour la plupart des langages et trop souvent ignoré.
Note de lecture : 97 Things Every Software Architect Should Know
Note : 4 ; Un concept intéressant, avec un contenu plutôt hétéroclite, mais aussi certaines entrées plutôt pertinentes
Voilà un concept vraiment original : un livre collaboratif, publié en open source, compilant 97 conseils écrits par presque autant d’auteurs différents, chaque conseil tenant en 2 pages (en réalité plutôt un peu moins, environ 1 page et demi). L’intérêt de ce concept est que chaque « thing » est nécessairement concise, efficace et se doit d’aller au but, on n’a guère le temps de s’ennuyer. Le volume du livre reste aussi de taille plus que raisonnable : 195 pages dont j’estimerais que cela correspond à 150 pages d’un ouvrage plus classique.
L’ouvrage souffre quand même d’une faiblesse due au sujet traité : qu’est-ce qu’un architecte et quel est son travail ? Ainsi les conseils traitent d’aspect très diversifiés, ce qui peut être vu comme un bénéfice en élargissant le spectre des aspects traités : aspects fonctionnels, humains, performances, infrastructure matérielle, conceptions, technologies et frameworks, etc… Mais cela ressemble finalement à un grand « melting pot » qu’à un tout cohérent.
Il est d’ailleurs intéressant de voir à quel point les avis d’experts sont variés, allant de la figure paternaliste aux travail d’architecture réparti chez les développeurs eux-mêmes. Parmi les tendances que je vois se dessiner au long de ces 97 conseils :
- La nécessité de connaître la substance de base : les patterns, qu’ils soient architecturaux ou de conception.
- L’importance du facteur humain.
- L’importance des facteurs « environnementaux » : le lien avec le contexte métier, la contrainte d’entropie du système, etc..
Au final, il y a certes des choses à jeter, mais aucun article n’est mal écrit (ils sont courts, donc les auteurs doivent faire très attention), et il y a nécessairement des choses valables.
Ce n’est pas le livre de l’année, mais je le classerais volontiers dans les « lectures amusantes ».
Référence complète : 97 Things Every Software Architect Should Know – Richard Monson-Haefel edt. – O’Reilly 2009 – ISBN : 978 0 596 52269 897
Les deux choses les plus importantes n’apparaissent pas au bilan de l’entreprise : sa réputation et ses hommes.
Henry Ford
En finir avec …
Mare du dogmatisme ? Besoin de fraicheur ?
Cet été je vais me métamorphoser en grand sacrilège du Scrum ! Non que je ne crois plus en Scrum, mais plutôt que je voudrais m’insurger contre une utilisation un peu mécanique de la méthode qui va à l’encontre même de l’agilité
En finir avec les zombies !
Je vais intitulé ma série d’article “en finir avec …”. Pour l’instant je n’en ai écrit aucun, j’espère que j’arriverais à tenir ce que je dis. Je ne m’engage pas sur un nombre d’article, vous verrez bien ce qui arrivera, mais ça arrivera entre maintenant et la mi-spetembre, qu’on se le dise. Ca vous oblige aussi à rester à l’écoute, du moins ceux qui pensent que je peux les intéresser.
Mais pourquoi “en finir avec” ?
Par provocation, d’abord !
Ensuite pour stigmatiser que rien n’est coulé dans le béton. Les éléments constitutifs de Scrum ne sont ni une fin en soi ni une justification. Ce sont juste des moyens, un guide pour faire des projets agiles. Si je dois choisir, je préfère un projet agile sans Scrum, qu’un projet déguisé qui s’auto-proclame agile (mais qui ne l’est pas) sous couvert de backlog, product owner, stand-up, etc…
Pensez plutôt que d’appliquer !
Je constate, et hélas je ne suis pas le seul, une augmentation des projets Scrum Canada Dry. Peut-être est-ce le prix à payer pour cette extension rapide de Scrum que nous observons aujourd’hui ? Beaucoup d’organisation dépourvue d’ADN agile tentent l’agilité en mimant ses rituels. C’est le “cargo culte”.
Mon but est de réagir, de nous éloigner de l’aspect rituel afin de nous concentrer sur l’aspect fondamental et initial de l’agilité. Je ne le ferais pas en citant une nouvelle fois le manifeste agile, bien que j’avoue que ce soit un bon moyen mais en faisant oeuvre active de déconstruction !
Attention, ça commence bientôt …
Action !
Ce prologue va me forcer à entrer en action, car je n’ai encore rien rédigé. Voici donc l’agenda :
- A partir de la semaine de cet été jusqu’à la mi Septembre, une série de posts sur ce thème ! Je ne sais pas encore combien, cela va dépendre de mon courage et de mon inspiration.
- Une proposition de Lightning talk pour l’agile tour nantes ! Ca c’est pour très bientôt, mais les délibérations pour l’acceptation des sessions ne seront connues que le 17 Septembre. J’ai horreur du travail à la chaine, je ne soumet donc mon sujet qu’à un seul évènement, avec l’espoir qu’il sera retenu. Nous verrons bien.
A très bientôt !
Vie artificielle épisode 13 : l’émergence
En écho ou plutôt sur le même sujet que mon Lightning Talk, cet épisode du Podcast “Vie Artificielle” propose quelques reflexions sur l’émergence par rapport au déterminisme comme mécanisme fondamental de l’évolution.
Note de lecture : The Usability Engineering Lifecycle, par Deborah J. Mayhew
Note : 8 ; Book of the year 2000! Un processus complet et à l’ancienne pour l’interface homme machine, complété d’un matériel prêt à l’emploi.
L’ergonomie fait, partie du recueil des besoins est rarement intégrée au processus de développement logiciel. C’est là une grande part du mérite de cet ouvrage: proposer un processus complet de gestion des exigences ergonomiques intégré à la capture des besoins fonctionnels par le biais des Use Cases. Oui, c’est vrai je viens de parler de processus et cela a une odeur pas très agile. Et effectivement dès les premières pages l’auteur propose un « usability lifecycle » qui ferait facilement froid dans le dos. Nous pouvons nous y arrêter un peu car ce cycle de vie structure le livre lui-même.
- La première étape est le recueil des besoins. Elle est couverte par 6 chapitres sur 160 pages. Elle couvre les 4 facettes identifies de cette étape : l’analyse des profils utilisateur, l’analyse des tâches, les objectifs d’utilisabilité et les principes généraux de l’IHM.
- La seconde étape est bien plus dense car le schéma du processus nous montre pas moins de 7 sous étapes regroupés en 3 cycles internes. C’est presque une surprise de voir cela couvert en seulement 180 pages, sur 10 chapitres ! Les activités proposées vont du modèles conceptuel à la reconception des tâches en passant par la conception d’écrans.
- La dernière étape a trait à l’installation. Il n’y a qu’un seul chapitre, mais il fait 50 pages ! Cette partie couvre le feedback utilisateur.
- Enfin une dernière partie de l’ouvrage est consacrée aux aspects organisationnels. Elle est longue de 100 pages sur 4 chapitres avec en plus des aspects strictement organisationnels, l’évocation de la planification de projet ou la justification des coûts (une des spécialité de l’auteur).
Au total, le livre est quand même très lourd, car il totalise 560 pages ! Sa structure est entièrement guidé par le processus proposé par l’auteur ce qui tend à rendre la prose très longue, je l’ai déjà constaté. Ce fil extrêmement rigide est tout sauf agile. Mais le contenu est loin d’être inintéressant. En effet le texte est méritoire par le fait qu’il accompagne chaque activité proposée du processus de gestion des exigences d’artéfacts (plans types, questionnaires, etc…) et de guidelines immédiatement applicables. J’ai rarement vu des livres donner autant de matière directement utilisable.
Chaque chapitre traite des aspects de la spécificité des applications Web dans une section et propose des “activités alternatives” si le processus a besoin d’être abrégé.
Outre que le livre reste très lourd (même en considérant le matériel inclus) et qu’il est structuré par un processus très rigide, il prend aussi un sérieux coup de vieux avec la seconde vague du Web. Mon conseil ? Prenez du recul par rapport au texte, démontez les morceaux du processus. N’utilisez pas le processus, mais réutilisez les morceaux, les idées et la matière première d’une manière plus légère et plus agile. L’auteur a beaucoup d’expérience et de savoir-faire dans son domaine qu’il serait dommage de snober.
Un très bon ouvrage que je recommande fortement, surtout si vous n’avez pas de connaissances préalables dans le domaine de l’ergonomie.
Référence complète : The Usability Engineering Lifecycle – Deborah J. Mayhew – Morgan Kaufman publishers 1999 – ISBN: 1-55860-561-4; EAN: 978-1-558-60561-9
Software Freethinker 
