Une belle journée passée au Agile Tour 2009 à Québec! Merci à tous les organisateurs.

C’était une journée où 14 conférences étaient présentées sur des sujets touchants les méthodologies de travail et de gestion de projet Agile. Il y en avait pour les amateurs de eXtreme Programming (XP) , Scrum, Lean, …

Et question de rendre à la communauté, je tiens à vous retranscrire ici certaines notes intéressantes que j’en ai retirées…

Tout commence par Agile Québec

La communauté Agile de Québec a démarré en 2005. J’en suis un membre assidu depuis le fondement. Lorsque j’habitais Québec, j’y étais à chaque rencontre. Maintenant à Drummondville, j’essaie de me présenter à la majorité des soirées, en partageant mon engouement pour la pratique Agile avec les employés de Nmedia Solutions et de Siga Informatique qui se joignent à l’occasion. Nous avons développé une belle relation avec ces derniers et j’ai d’ailleurs eu le plaisir de croiser Richard Messier, président de Siga, à la journée de Québec.

Et pour Agile Québec, il faut garder l’œil ouvert… Une nouvelle version de leur site web devrait être en ligne sous peu.

L’ouverture, présentation de l’Agile Tour

D’ordinaire, aux rencontres de soirs, nous sommes 25 à 40 participants. Mais là pour le Agile Tour 2009, nous étions 215 de présent. Les organisateurs ont même dû refuser des inscriptions.

L’événement qui en est à sa seconde année a commencé avec 7 villes en Europe pour un total de 800 participants. Pour cette année, il y a 18 villes qui participent, les organisateurs ayant étendus l’offre en Amérique.

Alors dans le désordre, voici certaines statistiques et points intéressant rapportés.

CGI

D’après Bernard Labelle de CGI, en 2009 :

• 93% des projets informatiques sont livrés en retard.
• 65% dépassent leurs prévisions budgétaires.

Pour ma part, je dirais donc que chez Nmedia Solutions, nous avons une excellente moyenne au bâton. Bravo à toute l’équipe !

David Beaumier, Elapse

D’après le Standish Group, dans le domaine informatique mondial voici ce que l’on observe :

• Dans la répartition des bugs, il y a présentement un ratio de 3 fois plus de troubles logicielles que de troubles matérielles. L’approche logicielle n’est pas aussi mature.
• Ces bugs causent 35% des pannes annuelles de systèmes.
• On estime que ces pannes causent pour 300 milliards en pertes annuellement.

D’après M.Beaumier

• Un développeur écrit en moyenne 35 à 40 lignes de codes par jour.
• Mettez-ça en lien avec le nombre de fois qu’il sera retouché ou relue par la suite et tout a beaucoup de sens.

Le présentateur mettait aussi beaucoup d’emphase sur le pair programming. Pour ma part, je n’ai jamais réussi à adhérer à 100% à ce principe. C’est comme le sel : Un peu c’est bien, mais trop c’est dangereux.

J’aime mieux généraliser ce concept en « team programming ». C’est le principe qui gouverne les interactions chez Nmedia. Plutôt que d’être constamment deux sur un ordinateur, chaque employé à son poste et travaille en solo. Mais s’il rencontre une embuche, il peut demander de l’aide à n’importe qui et l’on ne refuse jamais d’aider. Ainsi, une tache ne requiert pas systématiquement 200% du temps personne à accomplir. Le ratio de partage semble être de 1 ½ à 2 heures par jours.

Il a aussi présenté certains graphiques intéressant sur la dette technique.

Philippe Cantin, Ubisoft

Excellente présentation. Après le keynote, ce serait mon coup de cœur de la journée… Il avait 3 ½ ans de raffinement de son approche Agile dans une équipe multidisciplinaire d’environ 60 personnes. Lui, c’est le jeu vidéo avec plusieurs variétés d’artistes et des développeurs. Pour nous dans le Web & Windows Presentation Foundation (WPF), c’est similaire sur la plupart des projets où se côtoient intégrateurs et programmeurs.

En rafale :

• Ils ont implémenté leurs écrans de suivis de projets (Burn down chart). Il s sont mis-à-jour plusieurs fois par jour, avec un véritable écran d’ordinateur. C’est naturellement devenu un coin où les membres de l’équipe vont pour discuter.
• Après quelques itérations, les artistes ont été intégrés au back log, mais leur temps est géré en heures plutôt qu’en point.
• Pour découvrir l’ensemble des requis de projets, il n’y a rien comme les équipes de testeurs. Ils deviennent très pointilleux à expliciter chaque condition de phrases souvent large de sens qui provient d’un Product Owner.
• Maintenant que leurs évaluations se font en point et non plus en heures, leur univers a changé pour le mieux. Jamais qu’il ne retournerait aux méthodes par heures. La vélocité reste sensiblement constante avec la complexité subjective des différents modules.
• Le meilleur ratio pour l’équipe ? Viser un scrum master pour 8 membres max. Un scrum master de scrum masters pour 6 à 8 scrums masters.

Léo Lachance, Pyxis

L’agilité dans les projets d’envergure

• Pour éviter la dette technique, 15% à 20 % du budget d’un développement informatique devrait être conservée pour la gestion du changement.
• Contrairement à XP, les Product Owners ne devraient pas être trop près des développeurs, pour ne pas souffrir des « trippes de développeurs ». Question de rester en phase avec les besoins d’affaires.
• D’après lui, maintenant que nous avons d’aussi bons outils de développements et de refactorisation, il est maintenant plus sage pour deux équipes de faire deux fois la même chose et de refactoriser ensuite plutôt que d’investir à en faire une parfaite en commençant.

En conclusion ?

Bref, ce fût une journée très intéressante. De belles présentations, de belles discussions et toujours plaisant de retourner à Québec. Mais c’est définitivement la présentation de clôture de Mary Poppendieck qui m’a le plus amusée.

Mais ceci est une autre histoire qui sera comptée une autre fois !