26/03/2014

Oubliez les Epics

Je voudrais me pencher sur ce concept d'Epic

http://referentiel.institut-agile.fr/stories.html
http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

Un epic est une grosse story, qui n'est pas détaillée et n'est pas découpée en 'vraie' story, c'est à dire une story qui peut rentrer dans un sprint. L'intérêt de l'epic est donc de commencer un backlog avec des éléments assez gros pour que l'on sache jute de quoi on parle, mais sans que cela prenne trop de temps à détailler. C'est dans ce premier travail de constitution du backlog que l'équipe commence à construire son langage. Ce qui me gène par contre dans les epics, c'est quand cela devient systématique et que l'on commence à devoir rattacher une story à une epic et que cela devient de la comptabilité. Je pense que certains outils de gestion de backlog peuvent nous pousser à cette systématisation.

Ce qui fait le plus de sens pour moi aujourd'hui, c'est de n'avoir que des stories.

Lors d'un release planning, les stories en haut du backlog doivent commencer à ressembler à des story prêtes pour le sprint, qui respecte le Definition of Ready de l'équipe. Mais les story en bas du backlog ne sont constituées que d'un mot ou une courte phrase. Toutes les story sont chiffrées et le périmètre de la release est proposé. Ce périmètre peut changer mais cela permet de donner de la visibilité.

Lors d'un sprint planning, les stories doivent respecter le Définition of Ready, être INVEST et tenir dans un sprint. Cela est possible par un affinage progressif du backlog. Le product owner découpe et affine les story afin de les décrire à l'équipe. Cet affinage peut être fait par le product Owner seul, ou avec l'équipe lors d'un 'backlog refinement', ou encore pendant le planning game.

Afin de découper les stories, on peut utiliser différentes techniques. Le mieux est de trouver une sous-partie de la story qui a de la valeur. On aura recourt à un découpage technique si cette valeur métier ne peut-être obtenue sans l'ensemble de ses parties.

Pour se raccrocher à la terminologie utilisée précédemment, l'epic disparait lorsque son découpage en story est assez fin, et ce n'est pas la peine de le garder.

Le product owner peut ainsi maitriser son product backlog, son 'stock' de user story. Ce stock total doit avoir une taille de l'ordre d'une release. Le stock de story prêtes doit aussi avoir une taille de l'ordre de un sprint.

Cela fait partie de mes réflexions sur le 'faire juste à temps' au lieu de 'faire bien'.

Sources d'inspiration et références:
http://www.aubryconseil.com/post/Ma-presentation-sur-les-bacs
https://leanpub.com/agile-expression-de-besoins
http://referentiel.institut-agile.fr/invest.html
http://referentiel.institut-agile.fr/ready.html
http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

Et pour terminer, une video très bien faite qui présente le 'product backlog refinement meeting'.
http://scrummethodology.com/scrum-epics/








23/01/2014

MYCOM

J'ai rejoint l'éditeur de logiciel MYCOM après 5 ans en société de conseil (Norsys et Sfeir).

La société de service m'a permis de voir rapidement des contextes différents en me poussant à apprendre et à m'adapter rapidement. Pour moi, c'est un environnement qui pousse à la veille technologique et au partage avec des passionnés.

Mais je souhaitais avoir la possibilité de m'engager à plus long terme sur le développement d'un produit logiciel. Cela est plus en phase avec mes valeurs agiles, et c'est exactement ce que j'ai trouvé à MYCOM.

En deux mots, le métier de MYCOM est la gestion de la performance des équipements téléphone et réseau des opérateurs téléphonique.

Mais bien sur je reste artisan du SI.

25/05/2013

la Dette Technique - Agile France 2013




La Dette Technique

  • Un choix (la "vraie" dette technique)
  • De la négligence ou un manque de maturité de l'équipe
  • De l'entropie logicielle
La relation avec le product owner est primordiale dans ce contexte afin de lui proposer d'une part un qualité minimale, mais aussi une marge de manoeuvre afin de faire des choix permettant d'avoir une meilleur qualité ou un feedback plus rapide.


Comportements d'équipe
  • Endettement
  • Economie
  • Remboursement

La stratégie d'endettement c'est essayer de faire la bonne chose rapidement,
avec une implémentation simpliste et quelques entorses à des règles, pour ensuite rembourser.

20/04/2013

java-to-OS-notify & progress-maven-plugin

Je vous présente deux projets OpenSource que j'ai réalisé.
Ils sont tous les deux disponibles dans le repository Central maven.

java-to-OS-notify

Librairie de notification système.

Elle arrive à détecter les notifieurs disponibles et faire une notification avec l'un des systèmes suivants:


https://github.com/wokier/java-to-OS-notify

progress-maven-plugin

Ce plugin maven est basé sur le projet précédent.
Lors d'un build avec plusieurs modules, une notification donne l'avancement dans le réacteur, soit dans la console, soit avec une notification. Utile si le build est long. En fait, il est préférable d'accélérer le build, mais si vous avez tout fait et que votre build dure toujours plus de 5 min, voici un plugin pour vous.

https://github.com/wokier/progress-maven-plugin