Backlog Reboot

Il est des projets où même si le backlog est maintenu avec le plus de rigueur possible, un certain vieillissement de celui-ci s’opère avec le temps. Il n’est pas le seul, je sais, je vous vois venir.

Un backlog se construit dès la genèse du produit, et vit au même rythme que le produit lui-même.

Au fil des sprints, lors des affinages de backlog (backlog refinement),  de nombreuses informations y sont ajoutées, modifiées, supprimées, etc, etc…

Tout comme le code, le backlog a donc besoin d’un peu de nettoyage.

En phase de transformation à l’Agilité, il est nécessaire de « rebooter » le backlog au bout de 5 à 7 sprints. Il est intéressant de voir que cela correspond aussi, mais en est-ce la cause, à la phase de stabilisation de la vélocité.

L’enjeu est :

-          Revisiter les user stories restantes à faire

-          Réévaluer si besoin

-          Re-prioriser si besoin

-          Nettoyer l’outil (Excel, IceScrum, ou autres ;-( )

-          Avec une vision plus globale que ce que l’on fait en fin de sprint.

Et comme toute bonne chose arrive à temps, c’est le printemps, donc demain c’est Backlog Reboot !

Projets à releases parallèles : le Burn-Lot

Je travaille actuellement sur un produit mêlant software (SW) et hardware (HW).

L’application des méthodes agiles ne se limite pour l’instant qu’à la partie SW, mais les contraintes H/W sont tout de même à prendre en compte.

Et notamment la nécessité de releases plus longues qu’il faut anticiper côté SW.

Cela entraîne une roadmap produit à releases parallèles. Pour simplifier le projet SW, je n’ai préconisé qu’une seule release SW à la fois.  Chaque release SW doit donc prendre en compte le développement de tout ou partie des releases produits. Dans ce cas, les burn-up et burn-down simples de produit ne sont pas suffisant pour évaluer la tenue des jalons.

Nous avons donc combiné dans une sorte de burn-up « croisé » d’un parking lot, les infos de la release SW et le cumul des restes à faire par release produit. Avec projection de ce qu'il faudrait sur chaque release en tant que vélocité envisagée.

Bon, ce n’est pas un vrai burn-up, puisqu’il ne cumule pas les points obtenus.

D’un côté nous avons une répartition de la production par type : user stories par release ainsi qu’un pool de bugs à corriger. Et de l’autre une projection de la vélocité attendue pour tenir des jalons.

Ce burn-lot apparaît en complément des burn-down et burn-up bien sûr.

Tout ça ne reste pas simple, mais nous donne un peu plus de visibilité !

Super Consultant

Mea culpa : Je suis désolé, mais Je ni la solution miracle, ni réponse à tout.

Chaque problème a sa solution. L’agilité me propose une boite à outils

Il faut voir l’agilité comme un méta-process outillé, il n’y a pas une solution toute faite, mais une liste de pratiques pouvant servir à corriger un ou l’autre des problèmes.

En bon mécano des projets, j’utilise la clé à molette, des écrous et des boulons, voire quelque fois même le marteau et la faucille (Social events).

Oui, je peux changer d’avis : Une solution est bonne à un moment donné, ne l’est peut être plus 2 semaines plus tard. Le contexte a pu changer, une autre solution existe ou même la première solution doit être adaptée.

L’agilité a été élaborée à partir d’expériences, dans d’autres contextes. Cela nous donne un canevas, un guide et chaque pratique peut être présentée comme une solution.  En tant que coach Agile, j’aide l’équipe à découvrir ses problèmes, identifier quelles pratiques peuvent servir à les résoudre. Mais c’est à l’équipe de les adapter à son contexte propre. Les cycles courts (sprints) permettent de prendre la solution tel quel, de l’appréhender, puis de l’adapter.

Agile embarque un mécanisme d’auto-critique. Il ne faut pas voir Agile comme un dogme. Il faut aussi le remettre en question, et c’est, entre autre, bien l’intérêt de la rétrospective.

Je rejoins le discours de Thierry sur la stewardsheap, et le « manager con »

Je ne suis pas Super Consultant.

RobotFramework EclipseLibrary for Java/SWT

Nouvelle version de la librairie EclipseLibrary pour Robotframework


Cette nouvelle version permet, entre autres corrections, de tester des applications Java utilisant SWT en lieu et place de Swing.
Elle reste basée sur l'outil SWTBot et reprend les mêmes mots clés que ceux des applications Eclipse/RCP.
Avec un lanceur spécifique pour application Java repris de la librairie SwingLibrary.
Le lanceur Eclipse a aussi été remanié pour mieux supporter les erreurs de démarrage d'Eclipse.

Toutes les infos sont là!