La 19 mars dernier (oui, je suis à la bourre :) s’est tenu la 13ème édition du séminaire agile organisé par l’association SigmaT. Au programme, un peu de gestion de projet, les tests d’acceptation avec FitNesse et un retour d’expérience très intéressant sur la création de deux portails web pour l’administration belge.
Une bonne quarantaine de personnes avaient fait le déplacement à l’amphi U3 de l’université Paul Sabatier1 pour assister à ce treizième séminaire sur les méthodes agiles
Laurent Carbonnaux, le nouveau secrétaire commence par une rapide présentation de l’association SigmaT. Il en profite pour annoncer que l’association va continuer sur la lancée du début d’année et organiser régulièrement des ateliers. Au programme, théorie des contraintes, tdd, business value game, et surement d’autres. Suivez le blog de la sigmat pour en savoir plus (je les annoncerai également ici :).
#Refactorer son Project Manager, Hervé Desaunois Hervé commence par un petit rappel des rôles de Scrum par comparaison avec une équipe de rugby. Il associe au scrum master la place d’entraîneur2. Le scrum master est avant tout un facilitateur qui résout les problèmes. Cela est un contraste avec la notion de chef de projet : le SM ne dirige/impose pas, il protège, résout les conflits/problèmes et vit avec l’équipe.
Petit rappel du manifeste agile : l’humain avant les processus :
- il faut humaniser les relations entre les membres de l’équipe
- les équipes doivent être petites
- et dans la même pièce.
Après ces rappels, Hervé nous présente les résultats d’un questionnaire auquel ont répondu des chefs de projets reconvertis en scrum master au sein de sa société. Grosso modo, la conclusion est assez classique : l’importance de l’implication du client, le SM doit être à l’écoute de l’équipe, le CdP se rapproche plus du PO3, …
Les difficultés rencontrées sont liées à l’autonomie de l’équipe, l’estimation des tâches, la détermination de reste à faire et l’implication du client. Pour ce dernier point, ils ont introduit un role de proxy-client4 en la personne du chef de projet qui maitrise le budget, le planning et le fonctionnel5.
La voie du succès :
- équipe motivée et compétente
- un PO intégré à l’équipe
- faire des rétrospectives
- un bon scrum master
- pouvoir d’adaptation
- collaboration entre les membres de l’équipe.
Le succès s’obtient via :
- une pièce dédiée et sympa pour l’équipe
- l’intégration continue
- un radiateur pour le suivi des tâches et défauts
- un wiki.
Pour finir, Hervé a diffusé une petite vidéo de photos prises au court d’un projet agile israélien sur l’air de We are the Champion de Queen.
Pour être honnête, j’ai eu du mal à accrocher à cette présentation. Je l’ai trouvé très On va vous montrer la voie alors qu’il n’y avait que peu de choses neuves et même certaines entorses aux principes de bases… Je pense peut être que je ne suis pas le bon public pour ce type de discours probablement plus adapté à des managers/clients qui ne verront l’agilité que de loin.
#Automatisation des tests d’acceptation avec FitNesse, David Gayerie Les tests sont une des pratiques d’ingénierie indissociable des méthodes agiles. On parle ici de test d’acceptation. Les tests d’acceptation permettent la validation des users stories, ils en font même souvent6 partie intégrante de leur spécification. Le passage réguliers de ces tests est aussi le garant de la non-régression au cours des itérations.
FitNesse est un framework qui va permettre l’automatisation de ces tests. Il se présente sous la forme d’un wiki, vendu comme un bon format pour partager facilement l’information. Les tests sont décrits en utilisant une syntaxe particulière sous la forme précondition, action, résultat attendu. Concrètement, ces informations sont traduites par le moteur du wiki en nom de fonctions qui seront appelées pour préparer, effectuer et vérifier le test. David nous a montré ce fonctionnement sur une petite démo d’un système simple du jeu puissance 4. Pas de code en live, mais passage des tests et suite de tests. C’est déjà pas mal :)
FitNesse semble un outils intéressant. David indique pourtant quelques limitations : la documentation très touffue et mal organisée7, un fonctionnement centralisé (pb de gestion des env de dev), et des difficultés pour le test des interfaces graphiques (qui est un vrai pb récurrent à beaucoup de système de test).
Après, ces détails techniques, David a laissé la place à Xavier de Labouret qui utilise régulièrement FitNesse pour tester un soft en cours de développement mettant en jeu des infrastructure de télécommunications. Il revient un peu sur les enjeux des infrastructures de tests, leur nécessité et leur contraintes (prédictibilité, stabilité, …).
Au final, David nous a donné une présentation très vivante de cet outil. J’aurais tout de même aimé rentrer un peu plus dans les détails concrets de la programmation : où écrire le code, sous quelle forme, où s’exécutent les tests… Mais bon en 45 min, on ne peut pas tout faire :)
#Réalisation de deux portails web, Bruno Sbille Bruno Sbille nous vient de Belgique pour nous faire une présentation très fun sur un retour d’expérience de réalisation de portails web pour Bruxelles Mobilité, un organisme officiel de la ville de Bruxelles.
Bruno est arrivée sur ce projet pour la rédaction du cahier des charges initiales. Une fois fait, un chiffrage en temps et en finances montrait que le projet était incompatible avec le budget, les délais de l’appel d’offre publique(9 mois), les dates de livraisons8. Bruno a alors suggéré un fonctionnement en mode agile : cela permettait un engagement d’une mise en production partielle pour la date de livraison prévue, un budget mieux maitrisé et la possibiilité administrative d’avoir une procédure simplifié et plus rapide pour l’appel d’offre9.
Au final, le projet a démarrer au forfait par sprint. Il a été un franc succès. Au bout de 6 sprints, une démo officielle a été effectuée en présence du ministre de tutelle. La mise en prod a suivi dans la foulée. Le projet continue toujours.
Bruno présente alors des chiffres impressionnant. Le chiffrage de départ tablait sur 2,1 millions d’euros et 36 mois. Avec le passage en agilité, une mise en prod a pu être faite avec seulement 750 000 euros et 18mois de travail. Je pense tout de même que cela n’est pas à périmètre fonctionnel équivalent, beaucoup de choses devant être présente (mais pas forcemment utile) dans le cahier des charges initiales. Cela reste de chiffres très intéressant.
Bruno nous explique un peu sur la mise en place de scrum, scrum board et démos. C’est du classique, je m’attarde pas :)
La fin de sa présentation est très intéressante : On a appris quoi ?
- la communication : contact direct, le téléphone si on ne peut pas faire autrement, et le mail en dernier recours pour acter les choses.
- la confiance dans l’équipe, tout en lui offrant un cadre pour s’épanouir.
- la première expérience est importante. Il faut qu’elle soit bonne pour ne pas effrayer le client et frustrer l’équipe.
- cela conduit à une réelle satisfaction du client.
- les outils évoluent. L’équipe a peu utilisé le classique burndown, qui mal interprété par l’extérieur était source de pression.
- le backlog doit être organisé en user story.
- le feedback ! !
- le process évolue après l’avoir pratiquer pour le comprendre. L’équipe a abandonné le découpage en tâche au profit des US après s’en être servie 6 mois.
- le team building se travaille tout le temps et pas seulement en début de projet.
Au final une présentation très zen et plein d’humour avec de grandes leçons du terrain dedans comme je les aime.
Pour info, Bruno est à l’origine d’une vidéo très sympa sur la mise en place de scrum réalisée au cours de ce projet et dispo sur son blog
Et une mention spéciale pour le plus grand philosophe belge.
Le pot
Comme à l’accoutumée, un bon séminaire agile se termine par un pot10. Comme à l’accoutumée, il nous est offert par l’IUP ISI. C’est l’occasion de discuter, d’échanger, de partager avec les orateurs et le public présent. Cette fois, cela c’est même fini au restaurant avec les plus acharnés :) 11
Toutes les présentations sont disponible sur le site de la SigmaT.
-
merci à l’IUP ISI qui nous y héberge ↩
-
pour moi, l’entraîneur serait plutôt le coach agile… ↩
-
alors pourquoi on en fait des SM ? :) ↩
-
arg… ↩
-
arg… bis ↩
-
cela devraient même toujours être le cas :D ↩
-
pour l’avoir lu, je confirme… ↩
-
probablement fixé en fonction des élections :) ↩
-
j’imagine que c’est du qu’une somme inférieure à du être engagé initialement, avec des délais courts ↩
-
c’est d’ailleurs vrai pour tous les séminaires :) ↩
-
dont moi, bien sur :) ↩
Poursuivre la discussion
Envie de réagir à l'article ? Il suffit de me laisser un message via la page de contact, sur mastodon @avernois@piaille.fr ou un billet chez vous.
Vous pouvez aussi proposer des modifications via le source de cet article sur gitlab.