Agile

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.

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.

Ce matin, on démarre la réalisation d'un projet (maintenance évolutive), après avoir fait l'offre il y plusieurs semaines. Ce petit mandat, d'une vingtaine de jours, sera réalisé par une seule personne en quatre semaines.

Quels pratiques pourraient m'aider dans ce projet? Je retiens trois points: a) participation du client, b) engagement du réalisateur et c) planification et suivi par priorité client.

A) Le chargé de projet va prendre contact avec le client pour lui annoncer le démarrage et la date de fin prévue. Comme le client veut ça avant la fin d'année et qu'on va être capable de le faire, on part sur une note positive. Suggérons au client de s'impliquer, au moins à chaque semaine, idéalement au jour le jour. Proposons lui, de lui montrer ce qui est réalisé au fur et à mesure. Ça donne de la visibilité à l'avancement et ça nous donne un feedback sur ce que l'on produit et sur notre façon d'interagir avec lui. On pourrait, par exemple, arranger une conférence téléphonique en fin de journée pour faire le tour des travaux réalisés.

B) L'estimation des efforts a été réalisée par une tierce personne. Demandons au réalisateur, s'il se sent à l'aise avec les estimés. Quand je donne un estimé, je me sens plus "engagé" envers le projet, que lorsque quelqu'un d'autre fait l'estimation pour moi.

C) Assurons-nous que le plan est organisé de sorte que les fonctions prioritaires, celles qui ont le plus de valeur pour le client, sont réalisées en premier. Découpons le plan de façon à pouvoir montrer quotidiennement (ou aux 2-3 jours max) une fonction désirée par le client, quelque chose qui serait déployable. Démontrons cette fonction afin d'obtenir les commentaires du client (ici, prend la forme d'une acceptation). A chaque semaine, réévaluons la situation (estimé du reste à faire, priorisation des travaux, façons de faire).

Au cours des deux dernières semaines, à travers l'évaluation de trois projets, j'ai remis à jour mon outil d'évaluation de contexte. A l'aide de quelques questions simples, l'outil positionne le contexte d'un projet sur un diagramme afin d'évaluer le niveau d'incertitude. On sait que plus l'incertitude est élevée (en rouge sur le diagramme), plus les approches agiles représente une stratégie efficace.