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é !
3 commentaires:
Si j'ai bien suivi, cela revient un peu à dire qu'il y a une équipe SW qui doit travailler sur plusieurs "produits" à la fois.
Ce ne sont pas vraiment des produits différents mais des releases du même produit qui ont besoin d'être développées incrémentalement en parallèle du fait de contraintes HW.
La question qui se pose dans ce genre de contexte, c'est : comment est distribuée la bande passante entre les divers "produits" ?
Pour revenir sur ton exemple :
- Qu'est ce qui fait qu'il y a plus de bleu que de rouge sur S2 et plus de rouge que de bleu sur S4 ?
- Pourquoi les proportions de jaune et de rouge sont identiques dans les sprints à venir ?
- Pourquoi le jaune ne démarre qu'au S5 ? (pas plus de 2 releases en parallèle ?)
Salut Olivier.
Ce sont bien des releases du même produit.
Le dessin utilisé ne représente pas la réalité (confidentialité oblige).
Il y a plus d'une release en parallèle en réalité.
La distribution de la bande passante, c'est justement ce que nous cherchions à avoir avec ce burn-lot :
. Jusqu'au sprint 3, il s'agit de ce qui a été produit.
. Sur le sprint 4, reste à faire de la release R1 en priorité
. puis complément par vélocité prévisionnelle de la release R2
. A partir du sprint 5, ce n'est que du prévisionnel pour R2 et R3. Les user stories R3 (jaune) n'ont été décrites qu'en sprint 3, et donc ne pouvaient démarrer plus tôt.
Pour évaluer la vélocité prévisionnelle, nous avons simplement divisé le total de points d'une release par le nombre de sprints restant à faire.
ça c'est simplement mathématique, nous vérifions bien sûr que la vélocité prévisionnelle totale d'un sprint n'est pas supérieure à la vélocité réelle de l'équipe, sinon... on descope!
idée intéressante
mais attn à la comparaison avec le parking lots.
si g bien compris, R1, R2 et R3 peuvent concerner les mêmes bouts de code mais dans des versions différentes alors que les parking lots représentent des éléments disjoints
Enregistrer un commentaire