Agile

Comme nos clients, PCO et l'équipe sont dans des espaces localisés à chaque bout de la ville, nous cherchons un outil collaboratif qui nous permettrait de partager le plan du sprint et qui nous aiderait dans les rencontre de release planning et sprint planning.

Voici une brève évaluation de quelques uns des outils.

Sharepoint. En mode feuille de calcul c'est pas pire pour faire le product backlog et même assigner des itérations. Cependant pas facile de faire un lien entre release et sprint. Le webpart d'assignation est limité et on n'a aucune statisque (burndown, vélocité, capacité...). Pourrait être la plateforme de portail du projet.

Rallydev.com. Un peu complexe, mais supporte le drag-n-drop sur le web! Beau produit.

XPlanner. http://www.xplanner.org Simple et to the point. Graphiques et statistiques. A évaluer plus à fond.

XPcgi. http://xpcgi.sourceforge.net/ Simple, interface peu sophistiquée. Perl. A évaluer plus à fond.

XPWeb. http://xpweb.sf.net/ Interface buggy.

XTracker Twiki. http://twiki.org/cgi-bin/view/Plugins/XpTrackerPlugin Complexe.

XPSwiki. http://www.agilexp.org/xpswiki/ Semble simple, A évaluer plus à fond.

UserStory.NET. http://userstorynet.sourceforge.net/ Pas de doc ou de demo.

Story Server. http://storyserver.sourceforge.net/ Applet. Rudimentaire.

Iterate. http://www.diamond-sky.com/products/iterate/ J'aime la métaphore des cartes. Produit commercial, évaluation 30 jours.

VersionOne. http://www.versionone.net/ Commercil, Relativement simple, graphiques adapté à scrum. Plus facile d'approche que Rally.

Scope Manager. http://www.selectscopemanager.com/ Commercial. Peu de matériel pour évaluer simplement.

DevPlanner. http://www.devplanner.com. Commercial à 43$/user. peu de screenshots. Semble relativement complexe.

AgilePlan. http://www.agileplan.com/ Pas de réponse à cette adresse.

ScrumWorks, http://danube.com/scrumworks Commercial.

jot. http://www.jot.com A évaluer plus à fond.

Une odeur dans les approches agile est un symptome d'une situation à corriger. Il existe des "odeurs de code" (code smells) et Mike Cohn a publier des odeurs de Scrum, donc des symptomes que quelque chose cloche dans l'application du Scrum. Vous les trouverez ici.

Au début de cette seamine, j'ai fait un bilan de notre première semaine de sprint avec l'aide d'une tierce personne.

Au cours de cette itération, nous avons pu établir un contact régulier avec le proxy de notre client, ce qui nous a permis d'accélérer plusieurs interventions. On remarque que la présence ou au moins la participation active et quotidienne du client serait un autre facteur d'accélération. Naturellement, comme on n'avait pas prévenu le client, ce n'est pas évident de le mettre dans la loop à ce moment-çi. Dans les prochains projets, dès l'évaluation, le premier contact, on devrait expliquer à notre client notre démarche et nos attentes.

En révenant sur notre session de planification, que nous avons fait sans le client (ni sont proxy), on se rend compte comment on a peu de marge de manoeuvre, étant lié par l'offre et l'analyse préliminaire. D'une part l'envergure du projet est relativement fixe en terme de contenu, de date et de budget, alors que dans les faits il persiste une incertitude relativement importante sur plusieurs éléments. On assume donc un risque relativement élevé (mais, ici acceptable), même si l'évolution des besoins nous dégage une petite marge.

Le choix d'une longeur d'itération de deux (2) semaines, cadre bien avec le contexte du projet. On aurait pu aller sur un cycle plus court si on n'avait pas eut la période des vacances et si on avait été plus rodé. Il faudra se questionner sur les techniques d'intégration continue. Pour le moment on est pas là! Je pense à se qui serait possible avec Continuum, CruiseControl ou AntHill.

Le mode de communication avec le client pour répondre à des questions nous force à nous questionner sur ce qui constitu un élément à ajouter au backlog, par rapport à un changement normal à apporter dans le développement d'un écran. C'est certain que d'avoir le client en continu faciliterait cette problématique, car pour le moment on ne peut "négocier" avec lui, donc on assume le risque!

Hier, on en était à notre quatrième daily scrum, à l'heure prévue (11h30), il manquait un joueur. Que faire? Reporter le daily scrum à 13h30, alors que tous seraient présent? L'annuler, simplement (on se rencontre demain de toute façon)? Le tenir, avec des abscents? L'équipe penchait pour reporter en après-midi. Pas moi!

Plusieurs raisons me pousse à recommander la tenu à l'heure dite, ce sont: rythme, règles simples, planification, visibilité.

Les approches agiles ont des rythmes réguliers à diverses fréquences. Dans le cas de SCRUM, il y a le rythme quotidien, marqué par le daily scrum et le mensuel marqué par le début et la fin d'un itération. Si on brise le rythme, on risque de désynchroniser la machine. Le daily scrum à lieu à 11h30, comme la mort, c'est une des certitudes de la vie! Si on commence à les recéduler, à quel heure aura lieu celui de demain?

En Scrum, peu de règles encadrent nos processus, si on se permet de les briser à la première occasion, quel rigeur démontrons nous? Qu'est-ce qui nous garde du chaos? L'équipe s'est donné une règle en cas d'abscence physique, situation dans laquel la personne abscente participe par téléphone. Si la personne n'est pas disponible, elle n'est pas disponible, on s'en passe!

Le fait de planifier le daily scrum à heure fixe simplifie la planification, je sais d'avance que dans 12 jours, à 11h30, je suis en rencontre pour une dizaine de minute. Si j'ai un empêchement planifié, je peu planifier une façon de "participer" au scrum. Si c'est un empêchement imprévu, alors c'est imprévue, on vit avec!

Enfin, ça donne de la visibilité à l'abscence (et à la présence). C'est une bonne façon de voir la participation d'un individu (client ou réalisateur). Est-ce qu'il est souvent abscent? Quel en est la raison?