lundi 18 avril 2011

Scrum Day France - Les présentations sont en lignes !

Je n'ai malheureusement pas pu me rendre au Scrum Day France le 31 mars dernier. Mais bon nombre des présentations sont en lignes sur le site du French Scrum User Group. Merci au groupe et à Xavier Warzee !

J'avais commencé à regarder quelques présentations dès leurs mises en ligne. Voici quelques retours sur :
  • Automatisation des tests : le mythe du ROI avec Gilles Mantel
  • Lorsque quelque chose empêche SCRUM de fonctionner !, Alexandre Boutin
  • Le Product Owner « Proxy », Bertrand Dour

Automatisation des tests : le mythe du ROI avec Gilles Mantel


(Type : vidéo et diaporama en parallèle)

En début de présentation, Gilles rappelle les différents types de tests. J'y ai découvert les Tests fonctionnels exploratoires, non automatisables, mais sujet certainement d'avenir.

Ensuite, Gilles présente la formule du ROI (=Coût des tests manuels - coût des tests automatisés) en détaillant le contenu de chaque terme. La courbe présentée ensuite montre, sans surprise, un ROI positif au bout d'un certain nombre de cycles d'exécution, le point de début de rentabilité pouvant être atteint au bout de 2 à 3 ans (période d'investissement au bout de laquelle on ne gagne rien !). Pas motivant ...

Gilles met donc ensuite le doigt sur le fait que dans cette approche très mathématique et financière, on oublie bon nombre d'intérêts des tests automatisés comme par exemple :
  • la possibilité de lancer les tests plus souvent, y compris la nuit, sans nécessité de disponibilité de ressources humaines
  • des retours (feedbacks) plus rapides
  • le coût des anomalies
Gilles détaille ce dernier point avec des graphes très intéressants mettant en évidence que plus une anomalie est découverte tard, plus elle coûte chère, évidemment. Mais un critère supplémentaire très important est la phase à laquelle l'anomalie a été créée : plus une anomalie a été introduite tôt dans le process (par exemple architecture, design, ...), plus elle va coûter chère, le tout étant accentué si elle est découverte tard !

La suite de la présentation reste très théorique en se basant sur le modèle de gain d'une option d'achat. Mais cette approche m'a enfin permis de comprendre pourquoi, en contexte agile, j'ai souvent été moins motivé à mettre en place des tests sur le GUI (par exemple) : tout simplement parce que par expérience, il y avait peu d'anomalies dans cette partie des logiciels, donc un ROI pressenti moins intéressant !

Gilles présente également un graphe très intéressant, de Scott Ambler, qui a fait une projection des pratiques, agiles ou non, sur la courbe de coût d'une anomalie, excellent ! Avec là aussi une mise en évidence d'un ROI, pour l'automatisation des tests, moins intéressant en contexte agile.

Conclusion : commençons par passer à des pratiques agiles, et les tests, ça vaut le coup à bon escient.

Une présentation que j'ai beaucoup apprécié, à voir !



Lorsque quelque chose empêche SCRUM de fonctionner !, Alexandre Boutin

(Type : audio sur diaporama sous forme de video)

Après une introduction sur une première raison d'échec, Alex anime sa présentation sur base du serious game "Buy a feature" (cf Innovation Game), en proposant 12 raisons d'échec de Scrum à acheter par les participants, raisons basées sur des exemples concrets vécus.

Parmi les sessions présentées :
  • Une seule personne ! : cas d'une personne malhonnête et méchante, ayant beaucoup de pouvoir
  • Casting du PO : une situation où tout semble parfait sauf que le PO n'était pas le bon, plus gestionnaire que visionnaire (pas impliqué), et non maitre des aspects financiers
  • Contrat agile : j'en retiens trop de contractualisation, trop d'adaptations de Scrum, trop de difficultés liés aux distances, aux mélanges d'équipes agiles ou pas, ...
  • Mission impossible : avec la blague de Ken Schwaber qui conseille à un ami, ayant un projet impossible, d'opter pour ..... la méthode Waterfall ! Scrum mettrait "trop" vite en évidence l'aspect impossible du projet
  • Les Geeks : échec d'un projet à cause des geeks, excellent techniquement, qui se font plaisir, mais pas du tout ouvert sur le métier. Personnellement, je me considère comme geek, par l'aspect passion, ou du moins, je me sens proche des geeks. Et je les perçois plus comme une réserve d'énergie et d'innovations. Je ne partage donc pas le point de vue d'Alexandre. Mais je comprends bien la raison d'échec de ce projet, plus dû à des développeurs renfermés sur leur focus technique, sans intérêt pour le métier. Et cela m'amène une question : quel est le rôle du coach agile et/ou du ScrumMaster dans une telle situation, intéressant ...
  • Micro management : présence d'un manager hiérarchique trop présent sur l'équipe, avec des pratiques incompatibles avec Scrum (déplacement des post-its, affectation des tâches, suivi du consommé, ...) et donc un ScrumMaster avec un rôle très réduit. Bilan : passivité et désengagement de l'équipe, Scrum devient impossible !
  • Multiples PO : présence réelle de plusieurs PO avec une répartition officielle (documentée) des rôles de chacun, rôles très répartis, aboutissant à un auto-blocage dans les décisions

Un rappel important au passage : l'agilité, avant tout, c'est un état d'esprit !

Une présentation intéressante (même si j'ai des différences de points de vue sur les geeks et les ScrumMaster qu'il est bon de faire "ramer"), avec une forme agile à différents points de vue. Évidemment, Scrum, ça fonctionne "presque" tout le temps, et il est intéressant et enrichissant de se repencher sur les raisons d'échec pour les comprendre et les éviter à l'avenir. Ce que j'ai pas mal fait personnellement ces derniers temps.

La conclusion est importante,puisqu'en général, ce n'est pas la méthode qui ne marche pas, mais son application, les limites de l'organisation, et les personnes concernées.



Le Product Owner « Proxy », Bertrand Dour

(Type : audio sur diaporama sous forme de video)

Une présentation rapide suivant d'une longue séance de questions/réponses. Malheureusement, difficile d'entendre toutes les questions, mais les réponses restent intéressantes ...

Bertrand présente le contexte de la mise en place,  chez PMU, pour 3 métiers différents, d'une structure agile sur base de 2 équipes de 4-5 personnes (permet de répondre à 2 thématiques à chaque sprint), travaillant sur 1 seul product backlog multi-activités, avec la présence d'un Product Owner Proxy dont Bertrand rappelle l'intérêt :
  • Un interlocuteur unique
  • Une gestion des priorités consolidées
  • Une planification de release cohérente
Bertrand lisse les problèmes et solutions :
  • Expertise métier : mise en place d'implication forte des experts métiers, vocabulaire commun et granularité similaires entre les métiers
  • Gestion des priorités : 
    • vrais jetons de pocker pour les valeurs métier (Business values)
    • augmentation de la transversalité entre métiers : fédération et collaboration
    • créations d'événements : démos au PO et aux personnes avec qui le PO est en contact, ateliers (écritures d'histoire, gestion du backlog, ...)
Bertrand dresse ensuite un bilan sur la mise en place de ce Proxy PO, que je complète avec les questions/réponses :
  • Avantages : gestion du besoin consolidé et interlocuteur unique, échanges transversaux entre métiers (ouverture)
  • Difficultés : connaissance métier (atelier indispensables), légitimité du PO, complexité du processus, Proxy PO avec pouvoir d'arbitrage mais sans pouvoir de décision (obligation de consulter la hiérarchie)
Les questions/réponses ont également permis de couvrir d'autres points plus généralistes sur l'agilité et Scrum : open space, évangélisation de l'agiliité au sein de toute l'entreprise (pas facile, comme souvent), etc ...

Une conclusion intéressante : un PO Proxy ça marche, mais commencer par essayer d'améliorer d'abord l'organisation ...


Aucun commentaire:

Enregistrer un commentaire