Mon premier livre concernant l'Agilité. Très bonne introduction au Lean Software Development. Avec ce livre, on apprend, entre autre, à "dégraisser" Agile (Eliminate Waste). Livre très utile pour débuter ou pour perfecfectionner ses connaissances. Permet d'optimiser notre travail au quotidien.
À mon avis, une référence dans le monde Agile. Mélange de théorie et d'expérience pratique qui aide vraiment dans nos taches de planification et d'estimation
Livre qui résume les différentes méthodologies Agiles. Un bon livre d'introduction pour comprendre les différences entre les méthodologies.
Plusieurs formats de rétrospectives sont présenté dans ce livre. Il est très bien structuré et permet de retirer beaucoup d'informations pertinentes des équipes de travail, pendant les rétrospectives.
LE livre de référence pour comprendre ce qu'est le Test Driven Development
Livre de référence sur les User Story. Il m'a été très utile pour faire face à différentes situations lors de mes projets.
Approfondissement du Lean Software developement. Un "must" si vous avez aimé le premier livre "Lean Software Development : An Agile toolkit"
Livre très complet concernant Agile. Il est plus axé sur XP mais il touche à plusieurs aspect de l'Agilité. À mon avis, c'est un livre pour les gens de niveau intermédiaires à avancé.
Livre plus technique qui décrit les bonnes techniques de programmation. Tous les programmeurs devraient lirent ce livre!
Ce livre traite de différentes techniques pour entretenir une application existante. Très bon ouvrage portant sur le "IT Application Maintenance".
Wednesday, November 18, 2009 at 08:51PM Conférence de trois jours sur le Lean à Atlanta.
http://atlanta2010.leanssc.org/
Le Kanban sera un des sujets chauds lors de cette conférence juste a en juger par les conférenciers.
Wednesday, November 18, 2009 at 10:37AM Voici une checklist pour Scrum très intéressante. Un "one pager" qui résume bien Scrum.
http://www.crisp.se/scrum/checklist/scrum-checklist.pdf
Tuesday, November 17, 2009 at 09:35PM Très bon exemple de Kanban.
La "définition du done" inscrite directement dans la phase de dévelopement est une excellente idée à mon avis. Cela augmente la visibilité ce qui est une très bonne chose.
Tuesday, November 10, 2009 at 09:27PM Petite lecture intéressante...
Voici les valeurs XP (source : Wikipedia)
La communication
C'est le moyen fondamental pour éviter les problèmes. Les pratiques que préconise l'XP imposent une communication intense. Les tests, la programmation en binôme et le jeu du planning obligent les développeurs, les décideurs et les clients à communiquer. Si un manque apparait malgré tout, un coach se charge de l'identifier et de remettre ces personnes en contact.
La façon la plus simple d'arriver au résultat est la meilleure. Anticiper les extensions futures est une perte de temps. Une application simple sera plus facile à faire évoluer.
Le retour d'information est primordial pour le programmeur et le client. Les tests unitaires indiquent si le code fonctionne. Les tests fonctionnels donnent l'avancement du projet. Les livraisons fréquentes permettent de tester les fonctionnalités rapidement.
Certains changements demandent beaucoup de courage. Il faut parfois changer l'architecture d'un projet, jeter du code pour en produire un meilleur ou essayer une nouvelle technique. Le courage permet de sortir d'une situation inadaptée. C'est difficile, mais la simplicité, le feedback et la communication rendent ces tâches accessibles.
Cette valeur fut ajoutée dans la deuxième édition de Extreme Programming Explained de K. Beck.
Tuesday, November 3, 2009 at 09:25PM Technique d'estimation
Depuis le début de mon blog (19 juillet 2009), je ne fais qu'ajouter des liens afin de pouvoir facilement les retrouver comme référence. Ce soir, j'écris mon premier billet tiré de mon cru. Le sujet... les techniques d'estimations.
Selon moi, les estimés précis en heures sont un gaspillage (waste). Le fait de passer du temps pour faire un estimé n'ajoute pas de valeur à mon client. Un estimé aide à la planification, mais n'ajoute aucune valeur ajoutée. Ce n'est pas de la business value. Tout ce temps perdu pourrait être utilisé afin de programmer une nouvelle fonctionnalité.
L'estimé relatif est un bon compromis. Nous pouvons nous servir de cet estimé pour des fins de planification, mais celui-ci ne prend qu'une fraction du temps qu'un estimé précis.
Je connais trois types d'estimés relatifs :
- Story points/Planning Poker;
- Estimé T-Shirt;
- Wall Planning Poker.
Story point/Planning Poker
(www.mountaingoatsoftware.com)
Cette technique consiste d'attribuer une valeur numérique relative (suite de Fibonacci) en ce qui concerne l'effort à faire pour accomplir une tache.
Pour plus de détails, cette présentation est excellente : http://www.mountaingoatsoftware.com/system/presentation/file/106/Cohn_EstimatingPlanning.pdf
Selon mon expérience, il est important que tous les participants tournent leurs cartes simultanément afin de ne pas influencer les autres. Aussi, on ne doit pas dire à voix haute notre choix d'estimé, car, encore une fois, cela pourrait influencer le choix des autres participants.
Estimé T-Shirt
Très simple. Quatre grandeurs : Small (S), Medium (M) Large (L) et Extra Large (XL).
Valeur de base (étalon) : S = 10 Heures
Chaque valeur vaut le double : S = 10, M = 20, L = 40, XL = 80.
On peut ajouter XS = 5.
L'utilisation de la technique "Estimé T-Shirt" est très intéressante en contexte de maintenance applicative. Dans ce contexte, les demandes sont généralement de grandeur relativement petite. On essaie de briser les demandes de facon à ce que les grandeurs relatives tournent entre XS et M.
Wall Planning Poker
Technique intéressante pour estimer un projet dans un sprint 0. On divise le mur en 8 sections (5 et moins ,8,13,20,40,60, 120, 240). On demande, en paire de deux si possible, de placer des User Story dans les bonnes sections. Ensuite, il y a une validation par une autre paire.
Le Product Owner étant présent, beaucoup de discussion est générée par rapport au projet. La connaissance du projet augmente pour l'équipe de développement et la vision du PO se clarifie.