« 2005-11 | Page d'accueil | 2006-02 »
16 décembre 2005
Outils de suivi collaboratif
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.
20:00 Lien permanent | Commentaires (0) | Envoyer cette note
(Mauvaises) Odeurs de Scrum
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.
19:45 Publié dans Scrum | Lien permanent | Commentaires (0) | Envoyer cette note | Tags : odeur, scrum, mêlée quotidienne
14 décembre 2005
Bilan de la première semaine
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!
19:05 Lien permanent | Commentaires (0) | Envoyer cette note
09 décembre 2005
Un question de rythme
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?
14:30 Publié dans Mêlée quotidienne | Lien permanent | Commentaires (0) | Envoyer cette note | Tags : rythme, scrum
05 décembre 2005
Notre premier Daily scrum
Ce matin, à 11h30 nous avons fait notre premier scrum, qui à duré 5 minutes. Tout le monde était là à l'heure, mais seul un développeur avait réellement débuté le travail. On a noté qu'on serait prêt à montrer le prototype au client dans l'après midi.
Comme le client n'était pas présent (on ne l'a pas encore invité), le scrummaster est aller régler la situation après le scrum. (Nous avons finalement conclus avec le représentant du client , qu'il serait présent, par téléphone, lors des daily scrums. Note il est sur le même étage que le client.) La présentation aura lieu cet après-midi avec le client et le développeur. L'expérience du scrummaster est que l'approche du daily scrum permet d'agir rapidement.
Le scrum master a rappelé que le reste à faire devait être mis à jour pour 11h00, ce qui n'avait pas été fait.
On n'a découvert, que la disponibilité d'un des développeurs n'est pas celle que l'on croyait. Lors du sprint planning nous avons estimé que la charge de travail était de 70 h + 50 h. Il semble que le premier développeur puisse être affecté à son 70h, mais que le second développeur pourrait ne pas pouvoir fournir le 50h. C'est donc un point à surveiller. A moins on le sait rapidement!
Durant la rencontre, une des points de suivi à virer en discussion technique. Nous avons demander aux personnes de continuer après le scrum, ce qu'ils ont fait. La discussion a même impliquer d'autres membres de l'organisation présentent dans la salle.
20:15 Publié dans Mêlée quotidienne | Lien permanent | Commentaires (0) | Envoyer cette note
03 décembre 2005
Notre premier "Scrum planning"
Hier nous avons passer la journée en planification de notre premier sprint. Comme il s'agissait d'une nouvelle équipe nous avons débuté par identifier les règles qui nous régirait. Nous avons décider dans le contexte que la durée du spint serait de 2 semaines en raison de la petite envergure du projet. Nous avons décider de faire le daily scrum à 11h30 et que chacun devra mettre le reste à faire sur les items du sprint backlog à 11h00.
Nous avons ensuite identifié les personnes impliquées de près où de loin avec le projet et déterminer leur rôles. Déjà cet exercice nous permet de voir que nous devrons rapidement les sensibiliser à notre façon de travailler et leur préciser nos attentes. Dans notre projet il y a:
- 2 développeurs
- 1 scrum master
- 1 DBA
- 1 Pilote (client)
- 1 représentant de l'unité DSI
- 3 personnes ressources
Il faut noter que nous avons identifié des personnes tout au long de la journée, à travers nos discussions.
Ensuite nous avons établi le product backlog à partir du dossier fonctionnel préparer lors d'une rencontre initial, il y a 2 mois, et de demandes suplémentaires relevée lors d'une rencontre de travail cette semaine. Seul un développeur était à cette rencontre avec le client. Cette discussion nous a permis de bien comprendre le contexte du projet. Malheureusement ni le client ni son représentant DSI n'était avec nous et nous avons dû faire des hypothèses sur plusieurs points (valeur, détails des fonctionnalités...). La photo suivante présente le product backlog qui totalise 30 points d'efforts.
Cette première phase de planification a débuter à 9h30 pour se terminer à 12h00. Le développeur principal devant s'absenter fréquemment (support d'implantation), nous avons pu avancé grâce à la présence dans la salle (sur un autre projet) de la personne qui avait fait l'estimé initial.
Après dîner nous avons travailler sur le sprint backlog. Nous avons estimé notre capacité à 36 points par sprint. Comme le projet fait 30 points, nous avons pris chaque item du product backlog et nous avons identifier les tâches et estimé les efforts en heures.
Cet exercice a été long à démarrer mais après une heure les choses allaient rondement. Beaucoup de questions sont ressorties et beaucoup d'échanges ont eut lieu, questionnant le contenu ou les statégies de solutions. Nous avons même découvert qu'une tâche était déjà complétée!
La photos montre le sprint backlog. Nous avons aussi vérifié si nos estimé en heures étaient comparable à notre estimation en point. C'était le cas.
21:35 Lien permanent | Commentaires (0) | Envoyer cette note | Tags : sprint planning, planification, tableau, suivi, sprint backlog