Repository with sources and generator of https://larlet.fr/david/ https://larlet.fr/david/
選択できるのは25トピックまでです。 トピックは、先頭が英数字で、英数字とダッシュ('-')を使用した35文字以内のものにしてください。

index.md 3.8KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273
  1. title: Le rôle du Product Owner
  2. slug: role-product-owner
  3. date: 2013-02-07
  4. chapo: Les méthodologies agiles permettent de se remettre en question sans avoir rédigé un cahier des charges de plusieurs centaines de pages.
  5. *Quelques notes prises pendant la formation [agile](http://www.agilemanifesto.org/)/[SCRUM](https://fr.wikipedia.org/wiki/Scrum_%28m%C3%A9thode%29) donnée par Stéphane ce jour pour [scopyleft](http://scopyleft.fr).*
  6. ### Vision
  7. C'est l'objectif global du produit accessible à toute l'équipe et compréhensible par tout le monde, même et surtout une personne extérieure à l'équipe.
  8. Il est possible de détailler les rôles, la méthodologie ou la technologie dans ce document mais ce n'est pas capital, cela dépend du contexte du produit.
  9. Ce document est relativement bref — surtout au début — pour avoir un ordre d'idée :
  10. * produit (une page)
  11. * release (un paragraphe)
  12. * sprint (une phrase)
  13. **La maintenance du document de vision au cours de la vie du produit est très importante.**
  14. ### Réunions
  15. Il y a un cérémonial à respecter qui est représenté par 4 types de rencontres :
  16. * *Planification de sprint (2h)* : négociation du backlog avec l'équipe qui hérite symboliquement du produit ;
  17. * *Dailies (15min/jour)* : permet de garder le contact et d'annuler l'effet tunnel ; ce que l'équipe a fait, ce qu'elle va faire, les blocages rencontrés (à résoudre par le *Scrum Master*) ;
  18. * *Démo (1h)* : montrer le (totalement) fini, célébrer le travail de l'équipe et réaligner tout le monde, l'équipe rend le produit au *product owner* ;
  19. * *Rétrospective (1h)* : utile pour l'amélioration continue.
  20. **Le Product Owner doit être disponible tout au long de la vie du produit.**
  21. Il doit également tester les *stories* terminées pendant le *sprint* pour faire des retours à l'équipe et s'assurer que les tests d'acceptation sont bien respectés.
  22. ### Backlog
  23. Chronologie possible des différentes étapes :
  24. * Inventaire brut des stories
  25. * Priorisation des stories par valeur métier
  26. * Rédaction des stories eligibles + tests d'acceptation
  27. * Challenging des stories avec l'équipe
  28. * Estimation des stories par l'équipe
  29. * Re-priorisation possible du *backlog* par valeur+effort
  30. ### Stories
  31. Respecter l'acronyme [`INVEST`](https://en.wikipedia.org/wiki/INVEST_%28mnemonic%29) :
  32. * Indépendante
  33. * Négociable
  34. * Valeur
  35. * Estimable
  36. * Small
  37. * Testable
  38. L'objectif est de *maximiser la valeur* du projet en *minimisant les prédictions*.
  39. Une *user story* est un signal fonctionnel, elle n'est pas détaillée et doit rester flexible. Ce n'est ni une spécification, ni un *use-case*. Il est possible d'avoir des *mockups* mais ils sont gardés par la personne qui en a besoin.
  40. Encourager les échanges directs entre le *product owner* et l'équipe pour résoudre les points flous, en passant parfois par le *scrum master*.
  41. Schéma de rédaction (peut être simplifié avec l'habitude) :
  42. **En tant que {rôle}, je {action} pour apporter {valeur}.**
  43. Le curseur de détail des tests d'acceptation peut varier en fonction du besoin, des contraintes du client et de la qualification du *product owner*.
  44. Ne pas oublier la priorité et l'estimation pour compléter la *story*. Par exemple, la [méthode MoSCoW](https://fr.wikipedia.org/wiki/M%C3%A9thode_MoSCoW) (MUST, SHOULD, COULD, WON'T) permet de faciliter la priorisation des *stories*. C'est l'équipe de développement qui découpe les *stories* en tâches.
  45. L'après-midi a été l'occasion de mettre en pratique la méthodologie sur un sujet concret — celui du client — et d'apporter de la valeur au produit proposé, ce qui s'est soldé par une remise en question très précoce du projet. **Les méthodologies agiles permettent de se remettre en question sans avoir rédigé un cahier des charges de plusieurs centaines de pages.** Et commencé à le réaliser au prix fort.