Scrum et XP depuis les tranchées
[Gratuit et traduit en français]
Henrik Kniberg
Lorsque l'on découvre les méthodes Agile pour la première fois, on se montre souvent sceptique quant aux résultats ventés. On peut donc hésiter avant d'investir dans un ouvrage sur le sujet ou de solliciter un consultant Agile. Ce livre présente l'avantage non seulement d'être un véritable retour d'expérience à lui seul, mais également d'être gratuit, traduit en français et très agréable à lire (sans fioriture). Il permet de passer radicalement de la théorie à la pratique.
Un grand merci à Henrik et aux traducteurs français pour ce don.
Test-Driven Development By Example
Kent Beck
Mes attentes
En choisissant de lire ce livre, j'ai voulu comprendre concrètement ce qu'était TDD. Comprendre comment cette technique se pratique, quels sont ses bénéfices mais également ses limites. C'était important pour moi de bien comprendre et de pratiquer TDD avant d'essayer de motiver mon équipe ou futures équipes à utiliser une telle technique. L'ensemble des mes attentes ont été comblées.
Ce que j'en retiens
Beaucoup de choses. Ce livre est un livre comme je les aime : très riche tout en restant synthétique.
Voici à quelle définition personnelle de TDD, ce livre m'a fait aboutir :
TDD n'est pas une technique de test mais une technique d'analyse, de conception,... Une technique qui structure l'ensemble des activités de développement.
Le fait de commencer par rédiger le test avant le code à tester permet de perdre moins de temps à rédiger ces tests (en économisant par exemple le temps nécessaire à répondre à la question "comment vais je tester le code que je viens de développer" voir le temps nécessaire à rendre le code accessible par les test). Cette approche permet également de s'assurer que son test fonctionne au sens où il alerte bien en cas de régression (cf. rouge/vert/refactoring). Les tests ainsi efficaces, permettent de réduire le stress du développeur et d'éviter de tomber dans la spirale infernale : "plus le développeur est stressé > moins il teste > plus il y a de bugs > plus le développeur est stressé". Ces tests efficaces donnent la confiance nécessaire à l'intrépidité du développeur. Nécessaire elle même au travail de refactoring. Enfin TDD permet d'aboutir à un code simple, sans duplication, peu coûteux à maintenir : "code pour demain, conçois pour aujourd'hui" par opposition à "code pour aujourd'hui, conçois pour demain". TDD permet également au développeur de canaliser ses efforts en évitant de penser à 50 trucs en même temps. Sa feuille de route est sa liste de test à écrire. TDD apporte également un côté fun dans sa pratique au sens où on manie l'art du copier-coller et de la triche en règle avec l'usage du fake (bien entendu tout cela au service de la qualité et de sa sérénité).
Ma compréhension de l'anglais sur cet ouvrage n'a pas été facile compte tenu de mon niveau extraordinaire. Si j'avais su que je ferai ce métier là, j'aurai été plus attentif pendant les cours d'anglais dès le collège. Kent Beck utilise parfois un vocabulaire plus élaboré que d'autres. J'ai par exemple lu bien plus facilement "Agile Project Management With Scrum" de Ken Schwaber.
En gros le bouquin est organisé en différentes parties, les 2 premières sont des exercices de pratiques de TDD. Un premier assez simple et un second plutôt ambitieux : coder un framework xUnit en langage Python en approche TDD (donc sans framework xUnit au début). On pourrait penser que l'auteur a l'esprit tordu, en réalité, c'est plutôt bien vu et au passage j'ai pu apprendre un nouveau langage. Personnellement, j'ai fait le choix de développer à la main les exercices plutôt que simplement les lire. Je trouve qu'on se fait une idée plus précise de la pratique de cette façon.
La suite est plutôt pas mal non plus puisqu'il aborde différents patterns, des patterns de développement en TDD, de refactoring, des design patterns,...
Bref plutôt enrichissant tout ça.
Agile Project Management With Scrum
Ken Schawber
J'ai tout simplement dévoré ce livre. Pourtant l'anglais et moi, ça fait 2. En fait ce livre rassemble ni plus ni moins les aventures du "boss" en matière de gestion de projet Scrum : Ken Schwaber (père de Scrum avec Jeff Sutherland). Un peu dans le même esprit que "Scrum depuis les tranchées" il restitue son expérience sur un ensemble de projets menés avec Scrum. L'approche est redoutable : plutôt que de parler théorie pendant des pages et des pages, on a là quasiment que des retours d'expérience, des résultats concrets suite à des actions concrètes. On voit ainsi comment Ken Schwaber a fait face aux problèmes de la "vraie vie" que tout responsable de projet rencontre sur son chemin.
Evidemment, chaque expérience ainsi restituée a été choisie avec soin. J'ai envie de dire que ce livre est un ensemble de "Project Patterns". Comme des design patterns, ces "project patterns" peuvent apporter des solutions concrètes à des problèmes récurrents rencontrés sur d'autres projets bien que le contexte de ces derniers diffère.
Je n'ai jamais pris autant de plaisir à lire un bouquin de "management" :-)
Là encore, il n'y a pas de superflu, peu de pages, l'essentiel est là.
Je ne peux que recommander la lecture de ce livre à tout ceux qui veulent pratiquer Scrum. Ce livre est votre ami.
Rédiger des cas d'utilisation efficaces
Alistair Cockburn
Avant toutes choses, 2 mots sur l'auteur pour ceux qui ne le connaissent pas. Alistair Cockburn (prononcer "kobeurn") est une des personnes à l'origine du mouvement Agile, il a contribué à la rédaction du manifeste Agile et porte la Méthode Crystal Clear. Il est également la (ou une) référence en matière de rédaction de cas d'utilisation. Ce n'est donc pas un hasard, si mon choix s'est porté sur cet ouvrage.
Mes attentes
Mes attentes vis à vis de ce livre étaient claires, parvenir à rédiger des spécifications fonctionnelles concises, faciles à maintenir, lisibles à la fois pour le client et pour le développeur et dont on peut facilement déduire un plan de test nominal à détaillé.
Voilà encore un livre très utile, rédigé avec le soin de faire gagner du temps au lecteur plutôt que "s'écouter disserter sur le sujet" au risque de noyer le lecteur.
J'ai enfin pu découvrir la règle de l'art en matière de rédaction de cas d'utilisation et de spécifications fonctionnelles au sens large. J'ai beau avoir une certaine expérience, la rédaction des spécifications est souvent un domaine qu'on néglige ou que chacun exécute à sa façon sans trop se demander comment le faire de façon optimale (c'est une erreur évidemment).
Ce livre m'a rapidement permis de conclure que les cas d'utilisation en soi répondent parfaitement au attentes que j'évoque plus haut. A condition bien sûr de maîtriser l'art de les rédiger. Ce livre renferme tous les conseils, exemples et exercices utiles pour y parvenir. Alistair a même pensé à tout en réservant une partie du livre à une synthèse des conseils pour les gens pressés.
Il propose aussi un plan de spécifications transposable d'un projet à un autre très pertinent permettant notamment de guider la rédaction et structurer correctement les informations.
La traduction semble relativement correcte même si je n'ai pas lu l'original.
Gestion de Projets : EXtreme Programming
Jean-Louis Bénard, Laurent Bossavit, Régis Médina, Dominic Williams
Mes attentes
Déjà convaincu par la pertinence des valeurs et pratiques XP, je voulais approfondir le sujet et mieux comprendre comment le tout s'articule.
Ce livre est particulièrement complet. Il détaille bien évidemment chaque pratique XP mais aborde également le sujet épineux de la contractualisation et pour finir restitue 2 retours d'expériences honnêtes et détaillés sur des projets menés en France.
En lisant ce livre, on mesure à quel point l'appellation "eXtreme Programming" est trompeuse. En effet, pour une personne ne connaissant rien de XP, il est difficile d'imaginer avec un tel nom que les pratiques associées couvrent la "gestion de projet" (C'est peut être grâce à cette ambiguïté d'ailleurs que Scrum connaît davantage de succès). XP adresse pourtant ces aspects avec beaucoup de pragmatisme, tout comme le développement. Ce qui fait de XP une des (ou la) méthodes Agile les plus complètes.
Ce livre m'a également conforté dans l'idée que XP redonne ses lettres de noblesse au développeur. Il y a beaucoup trop d'entreprises qui considèrent encore les développeurs comme des exécutants interchangeables. XP au contraire les valorise, les arme de pratiques redoutables, les aide à transformer leur travail en art et à trouver leur vrai place (cf. charte des droits du développeur et charte des droits du client).
Kanban et Scrum - Tirer le meilleur des deux
[Gratuit et traduit en français]
Henrik Kniberg et Mattias Skarin Traduction par Claude Aubry, Frédéric Faure, Antoine Vernois & Fabrice Aimetti
Avant même de rentrer dans cet ouvrage, on peut commencer par saluer le travail des auteurs et des traducteurs et les remercier pour leur temps et leurs efforts. Puisque encore une fois, il s'agit d'un don à la communauté Agile.
Après deux belles préfaces, on trouve 2 grandes parties : la comparaison de Scrum et Kanban pour mieux comprendre leur fonctionnement et leurs atouts réciproques suivi d'une étude de cas "vraie vie". Une fois de plus l'ouvrage se lit vite et agréablement (pas de fioriture), les conseils sont bien sentis avec quelques rappels qui font pas de mal. Personnellement, j'ai eu un peu de mal à me retrouver dans l'étude de cas. Je me demande si on n'aurait pu trouver un cas de figure qui touche plus de monde. C'est une question ouverte bien entendu, après tout mon sentiment est sans doute lié au contexte de mes projets (missions client/fournisseur et non pas plusieurs projets en interne).
Agile Estimating and PlanningMike Cohn
Je dois dire que j'avais un petit apriori concernant Mike Cohn en constatant la taille de ses livres (par comparaison avec d'autres auteurs du monde Agile comme Ken Schwaber par exemple). 330 pages pour traiter uniquement d'estimation et de planification Agile, 270 pages pour traiter uniquement des User Stories (cf. livre "User Stories Applied"), ça me semblait beaucoup. Je me suis dit que cet homme devait manquer d'esprit de synthèse alors que l'approche Agile consiste justement à maximiser ce qui n'est pas à faire (ou à écrire).
Mais dès les premières pages, j'ai pris conscience que je me trompait lourdement. Pire encore j'ai réalisé à quel point ce livre aurait pu me faire gagner du temps, autrement dit j'aurai du commencer par celui ci.
Cet ouvrage est particulièrement complet, il regorge de techniques, d'astuces, de citations, de retours d'expérience,... Il est organisé en 7 parties. - La première pose le problème de la planification d'un projet, soulève les difficultés associées et introduit l'approche de planification Agile.
- La seconde traite des techniques d'estimation (story point et ideal days)
- La troisième traite de la planification par la valeur et propose différentes techniques de priorisation (simples et efficaces) qui intéresseront certainement les MOA/AMOA
- La quatrième traite de la planification pure (planification de release et d'itération, utilisation et mesure de la vélocité, gestion de l'incertitude, approche pour des projets multi-équipes,...)
- La cinquième aborde le suivi de l'avancement et le reporting
- La sixième démontre en quoi la planification Agile fonctionne
- Et enfin la dernière nous fait basculer de la théorie à la pratique avec un cas d'étude en reprenant tout les sujets abordés dans les parties précédentes
Cette dernière partie est bien évidemment très instructive, après l'avoir lu on se pose beaucoup moins de questions du genre "oui mais dans la vraie vie ça se passe comment ? et dans tel cas de figure je fais quoi ?"
|
