Discussion :

[Nalonna]

Bonjour,

voilà je découvre cette méthode dans le sens où je la connaissais de nom, je m'étais renseignée sur le sujet etc. mais la mise en pratique s'avère bien plus compliquée que je ne le pensais.
Je suis nouvelle en tant que chef de projet, et comme tout junior je rame pas mal :p

J'ai un projet assez simple en web, sur lequel j'ai fait une grosse analyse, des specs fonctionnelles générales et des specs fonctionnelles détaillées.
Du coup, pour faire mes sprints, je suis partie du principe que mes SFG me permettaient de dresser une liste des features à réaliser, et que mes SFD étaient mes stories voir même j'éclatais certains stories en plusieurs pour encore plus découper mon projet (voir même parfois j'y anticipe un peu de conception technique mais tout en restant très macro....genre création DAO, création objet métiers, configuration application etc) et ainsi voir si on peut plus facilement organiser les sprints et la charge.

Or, après consultation avec mon client de l'organisation des sprints que j'avais préparé initialement pour une première mouture, il a pris l'initiative de refaire les stories, changer les noms, voir merger certains des miens pour un résultat quasi identique. Seul le but d'un sprint a changé, ce que je peux comprendre.

Ma question est donc la suivante : qui est censé faire les stories ? quelle est la participation du client dans la planification des sprints ? est ce à lui d'y définir/créer le contenu ou est il juste là pour définir des objectifs ?

De ce que j'avais cru comprendre, le client intervenait surtout pour définir le but des sprints, définir ce qu'on incluait ou non dans les sprints pour donner une sorte de priorité aux stories énumérés.

Je remercie par avance toute personne qui pourra m'éclairer sur le sujet.

[montesq]

Bonjour,

C'est le "Product Owner" (PO) qui est responsable du backlog (qui est constitué des user stories (US))
C'est lui qui ajoute/supprime les US et qui leur attribue un ordre de priorité. Bien sûr il peut être aidé, conseillé, sollicité pour ajouter de nouvelles US, mais c'est lui qui est l'unique décideur/arbitre de son backlog.

Lors de la planification d'un sprint, l'équipe parcourt les user stories par ordre de priorité décroissant et s'engage sur la quantité d'US qui seront livrées au cours de ce sprint. Ainsi, le PO peut souhaiter que les 15 premières US soient développées, mais l'équipe peut ne s'engager que sur les 10 premières. Le PO propose, l'équipe s'engage.

Bref, dans ton cas, ton client est clairement dans son rôle, à moins que ton rôle soit précisément celui du PO...


Pour en revenir à ta préparation, je ne sais pas si tous les livrables que tu as fournie étaient un pré-requis, mais dans Scrum, spécifications fonctionnelles générales et détaillées sont clairement peu souhaitables : les US doivent se suffire à elles-mêmes.
D'autre part, j'ai l'impression que ton découpage en US est proche d'un découpage en tâche : en isolant les différents développements par couche applicative, alors qu'au contraire, une US est une fonctionnalité à part entière qui doit fournir de la valeur ajouté au produit.
=> En conclusion, je crois que ta pratique est restée très "cycle en V". Si tu ne les as pas déjà lu, je te conseille http://henrik-kniberg.developpez.com/livre/scrum-xp/ ET/OU http://www.aubryconseil.com/pages/Livre-Scrum

[Nalonna]

Pour donner plus de précisions, voici comment se sont déroulés les évènements :

- "l'entité cliente" nous a fourni des specs qui comprennent specs fonctionnelles, contraintes techniques, maquettes des interfaces et même de la conception en détaillant certains traitements

- De là, on m'a demandé de chiffrer et de créer les features, stories et de planifier les sprints en fonction des ressources disponibles.
Du coup, j'ai fait un découpage qui est un mélange de user stories et de technical stories, car finalement d'un point de vue user il y a très peu de fonctionnalité, et encore moins visible/testable lors de livraison. Bcp de traitements sont des traitements masqués qui ne donnent pas forcément à un résultat validable (ou alors en loggant dans un fichier les données).

- J'ai donc défini mes sprints, et de là je pensais qu'on allait peut être redéfinir le but des sprints si ils voulaient qu'on place plutôt tel ou tel storie avant certains autres.
Au lieu de cela, le client s'est servi de ma 1ere mouture pour tout refaire sans que cela ne soit forcément très cohérent. Et bien entendu a totalement occulté la valeur des efforts des stories pour recréer les sprints.

Le tout pour un projet au forfait