Scrum - Méthodes agiles

1. Le vendredi 3 novembre 2006 à 12:45, par Stéphane

Je comprend pourquoi la priorité et l'ordre de developpement sont forcement identiques..
Lors du Sprint Planning, il y a doit bien avoir concilliation entre le Product Owner (valeur métier) et l'equipe (contraintes techniques/architecturales) non?

2. Le samedi 4 novembre 2006 à 03:14, par Oaz - site

Un "pur" agiliste serait tenté de dire que l'architecture n'est jamais que le plus haut niveau de conception qui, dans une modèle parfait, va émerger de la réponse au changement (feedback->ajout fonctionnel->refactoring...) et que, donc, l'équipe n'a pas vraiment à négocier la prioritisation par rapport à des contraintes techniques puisque celles-ci peuvent être résolues a posteriori.
Mais y-a-t-il des personnes pour se risquer à faire systématiquement ce pari là ?

3. Le samedi 4 novembre 2006 à 03:20, par Oaz - site

En ce qui concerne la problématique des dépendances entre les exigences, je crois que le sujet déborde du cadre de la prioritisation.
Une question plus fondamentale me semble être : quel est le meilleur moyen pour exprimer des exigences ?
UP et certaines méthodes agiles (XP) se rejoignent d'ailleurs un peu sur ce point là. En XP, le problème ne se pose pas car les histoires utilisateur sont entièrement indépendantes. Les cas d'utilisation de UP s'orientent (dans une certaine mesure) dans cette même direction d'indépendance.

4. Le dimanche 5 novembre 2006 à 15:03, par Le Francoué

Ca me fait penser à une technique de prioritisation qui s'appelle 'requirement value analysis' utilisée dans les grands systèmes. On fait évaluer la valeur ajoutée des exigences par le client et en parallèle la complexité (mélange de risque et de cout) de réalisation (équipes technique).
Cela donne un facteur de priorité qui est utile lorsque le délai de mise sur le marché du produit (time to market) est prépondérant. On décide de réaliser les exigences qui apporteront le plus de valeur ajoutée dans un délai adéquat. En cas de problème ou de risque, on est à même de décider ce qui ne sera pas mis sur le marché pour la première version du produit.

5. Le mercredi 8 novembre 2006 à 06:25, par claude aubry

Lors de la réunion de planification du sprint, la discussion (conciliation) peut amener à ajuster les priorités. Mais je pense qu'il est préférable -quand c'est possible- de tenir compte des contraintes d'architecture avant de lancer les sprints, lors de la préparation de la release. Cela permet de ne faire que de ajustements limités à chaque début de sprint, lors des réunions de planification.

6. Le jeudi 9 novembre 2006 à 08:01, par claude aubry

Je ne crois pas que les histoires utilisateur puissent toujours être complètement indépendantes. Je reprends le cas d'un logiciel qui gère les changements (un bug tracker). Une demande de changement passe par de nombreux états. Si on ne veut pas avoir de dépendances entres des histoires (ajouter avant analyser), cela revient à ne faire qu'une seule histoire utilisateur pour toute la gestion de la demande de changement, ce qui donne une histoire trop grosse pour être finie en une itération.

7. Le vendredi 10 novembre 2006 à 21:27, par Oaz - site

Le problème avec l'exemple du bug tracker c'est de savoir si un cas d'utilisation 'soumettre un bug' seul apporte vraiment de la valeur au client ? En d'autres termes, le logiciel lui servirait-il à quelque chose si un scénario issu de ce cas d'utilisation était implémenté sans rien d'autre qui lui permette de visualiser les bugs saisis ?

Comme le dit Cockburn dans un de ses papiers sur les use cases alistair.cockburn.us/inde... : The level of greatest interest is the user goal, the goal of the primary actor trying to get work done. This corresponds to what might be called "user task", or "elementary business process". A user goal addresses the question: "Does your job performance depend on how many of these you do today?"

Pour moi, un cas d'utilisation "soumettre un bug" ne passe pas le test parce que ce n'est pas un but en soi. Par contre "soumettre un ensemble de bugs et obtenir une liste de tous les bugs soumis" le passe car c'est un but, certes simplifié, que l'on peut avoir pour effectuer une revue de la qualité d'un produit -- revue pour laquelle on se sert de ce bug tracker.
Si un tel scénario ne tient pas dans une itération, on a effectivement un problème mais je ne crois pas que ce soit le cas, quel que soit l'environnement utilisé pour l'implémentation.

8. Le samedi 11 novembre 2006 à 00:56, par claude aubry

Tout d'abord je ne parle pas de cas d'utilisation. Ce que dit Cockburn, appelé aussi test "du chef" par Larman, s'applique aux cas d'utilisation. Les histoires utilisateur ne sont pas des cas d'utilisation.

Cependant une des qualités d'un bonne histoire est d'apporter de la valeur, aussi. Pour revenir à mon exemple, l'histoire utilisateur qui a pour titre "soumettre un bug" a comme condition de satisfaction (critères de test) quelque chose comme "le bug est ajouté à la liste des bugs déjà soumis". Vous avez pu penser, à tort, que l'histoire s'arrêtait avant. Cela montre bien que le titre de l'histoire ne suffit pas pour être compris, que la conversation fait partie de l'histoire et qu'il est utile, comme je l'ai dit dans un précédent billet, de définir les critères de test d'une histoire. Cela précisé, je crois que nous serons d'accord.

Pour revenir au début du débat portant sur la dépendance entre histoires d'utilisateur, mon propos est de dire qu'il y a une dépendance entre l'histoire "soumettre un bug" et l'histoire "analyser un bug soumis", ce qui implique naturellement que la première soit plus prioritaire que la seconde. Quelle valeur aurait "analyser" s'il n'y avait pas de bug soumis ?

9. Le dimanche 12 novembre 2006 à 22:35, par Oaz - site

'Quelle valeur aurait "analyser" s'il n'y avait pas de bug soumis ?'

J'ai envie de répondre par une pirouette : si une histoire n'a pas de valeur, pourquoi la proposer ?
C'est ce que je tente d'expliquer dans mon billet en rétrolien. Il est inutile de construire des dépendances entre les histoires pour gérer une planification. Si on se contente de proposer les histoires ayant le plus de valeur, cette planification se réalise automatiquement.

10. Le dimanche 12 novembre 2006 à 23:22, par claude aubry

Hello Oaz. Votre position est basée sur la définition des priorités en considérant la planification d'une seule itération, celle qui commence. Le billet que j'ai écrit -mais ce n'est peut-être pas très explicite- est une réflexion sur les critères de priorité pour planifier une release, c'est à dire plusieurs itérations, en tous cas au moins les 2-3 à venir. Dans ce cas, l'objectif est d'ordonner tous les items du backlog et les dépendances que j'évoquais sont utiles (leur construction n'est pas difficile et n'est faite qu'une fois)

Pas le temps de lire votre billet en rétrolien maintenant, il est trop long.

11. Le lundi 13 novembre 2006 à 23:07, par Oaz - site

Je suis tenté de demander "pourquoi planifier 2 itérations à l'avance ?"
Les enseignements que l'on va tirer de l'itération en cours ne sont même pas encore connus !

Ceci étant dit, il faut tout de même faire le choix des priorités pour l'itération à venir immédiatement. Et là, bien sûr, on a besoin d'une sorte de relation de dépendance.
Ce que j'essaie de mettre en évidence, c'est que je vois plus cette relation dirigée par la valeur ("Quelle histoire puis-je raconter et prioritiser qui va me permettre d'obtenir un système immédiatement confrontable à la réalité d'un modèle métier ?") que par des dépendances fonctionnelles ("Quelle histoire est réalisable sans avoir besoin de dérouler auparavant une autre histoire ?")

12. Le jeudi 16 novembre 2006 à 18:20, par claude aubry

Hello Oaz, merci pour les commentaires même si nous avons parfois un peu de mal à nous comprendre...

Pour continuer le débat, je ferai un nouveau billet sur les 2 niveaux de planification : à court terme, c'est un plan d'itération, mais il arrive, souvent d'après mon expérience, qu'on ait également besoin d'une planification à plus long terme, qu'on qualifie de plan projet ou, comme je l'ai repris de Mike Cohn, plan de release.