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é !
