- le manifeste Agile, c'est la première étape. Le lire, le comprendre, l'imprimer sur du papier A3, l'afficher au mur, en discuter avec son équipe, avec d'autres collègues, avec ses managers les plus proches, puis un jour, se décider, quand on a atteint la maturité nécessaire, le signer. La signature du manifeste Agile est un sacré engagement, et cela vous change votre vie professionnelle de développeur. Plus rien n'est comme avant. La vision devient différente.
- le livre Agile Project Management with Scrum, de Ken Schwaber. Le lire. Le comprendre. Ce sont les bases de la méthode, d'un côté, mais aussi, de nombreuses histoires de projets de développement, sur les quels Ken est intervenu. A la fin de la lecture, on sait ce que c'est que la méthode Scrum. On sait aussi comment l'implémenter. On croit savoir. Mais cela ne suffit pas. C'est là tout le truc de Scrum. C'est très facile. Les concepts sont très simples. Les trois rôles : le responsable produit ou Product Owner, le Scrum Master, et l'équipe. La notion de Sprint : période de temps limité (15 jours, un mois, par exemple, mais pas plus) pendant laquelle l'équipe met tout en oeuvre pour développer les user stories sur lesquelles elle s'est engagée de manière collective. Les différentes réunions qui rythment les projets Scrum : les Scrums ou points quotidiens où chaque membre de l'équipe expose aux autres ce qu'il a fait la veille, ce qu'il fera aujourd'hui, et les éventuels obstacles qu'il a rencontré, charge au Scrum master de les régler. Les Sprint Reviews, lors desquels l'équipe exposent aux commanditaires, et toutes autres personnes de l'entreprise, d'ailleurs, les développements terminés lors du Sprint. Les Sprint Planning, pendant lesquels le responsable produit expose à l'équipe les user stories priorisées en attente. L'équipe estime et s'engage sur un certain nombre de user stories. Mais la vrai compréhension intervient petit à petit, dans la pratique de tous les jours.
- le livre Agile Estimating and Planning, de Mike Cohn. Le lire. Je conseille d'ailleurs de lire en même temps le livre de Ken et celui de Mike. Cet ouvrage de Mike Cohn se lit comme un roman. On apprend comment écrire une user story. Comment estimer de manière retlative une user story en user story point avec un planning poker. On comprend les différentes "peaux d'oignon" de la planification : la planification sur l'horizon de la journée lors du scrum quotidien, la planification sur l'horizon du sprint, puis les releases, puis la roadmap produit, et enfin la planification à horizon stratégique.
- le groupe de discussions du développement Scrum sur Yahoo, une mine d'or. Mike et Ken y participent régulièrement. Certain fil de discussion sont passionnant. AU début, l'oeil du débutant y fait un tri naturel. On ne comprend pas tout. Puis, petit à petit, à force d'avancée dans les projets, on s'aperçoit que d'autres, à travaers le monde, rencontrent les mêmes interrogation que soi-même, posent des questions que l'on se pose aussi, ou exposent comment eux, dans leur cas, ont résolu un problème de cette manière-là. Une source d'inspiration inépuisable.
- installer un framework de gestion de projet Scrum. Comme nous sommes en .net et que nous utilisons Team Foudation Server, j'avais deux options possibles : eScrum et Scrum for Team System de Cochango. J'ai choisi ce dernier, qui s'installe en 1 clic! Il faut en lire le Process Guidance, une ressource excellente de Scrum, avec quelques vidéos de Ken Schwaber.
- THE French Blog about Scrum tenu par Claude Aubry, consultant de son état (le Jeff Sutherland français?), qui a mis à disposition une remarquable documentation de la méthode au format EPF.
Après la lecture de toutes ces ressources, il faut plonger. Evangéliser son équipe. Evangéliser son boss. Evangéliser le boss de son boss. Evangéliser le boss du boss de son boss, par l'intermédiaire de son boss... Evangéliser ses partenaires transverses à l'intérieur de la structure. Expliquer, avec agilité. En effet, il faut savoir être agile dans son discours, quand on prône l'agilité!
Lire. Evangéliser. Puis pratiquer. C'est là où l'on s'aperçoit que l'on est loin d'avoir tout compris. Chaque jour se poser la question du pourquoi de ses erreurs. S'améliorer. Feedback permanent avec l'équipe.



Bravo !
Votre article est vrai ment excellent !
Rédigé par : poker gratuit | mardi 14 juillet 2009 à 07:25
Bonsoir,
avant d'aller dormir sur mes deux oreilles, je veux remercier monsieur fréderic DOILON pour ce magnifique blog.
chapeau bas pour ce passionnant tour d'horizon et ces précisions ( liens, forum...).
Je m'appelle willy HOUBEN, infirmier dans un centre d'hémodialyse. Je m'intéresse à un plan de soins infirmier informatisé. En deux mot: qui fait quoi quand comment et pourquoi sans redondance, ni écriture fastidieuse. Sujet passionnant pour qui veut s'intéresser à la communication dans le monde infirmier.Plus j'avance, plus je me noie dans les possibilités . Ce blog m'aidera certainement à me remettre en question, à encadrer l'équipe, plannifier le projet ...
Merci.
willy
Rédigé par : Willy HOUBEN | dimanche 15 mars 2009 à 18:23