- 30.05.2016
Le point clé de cette étape initiale est de travailler deux définitions pour votre projet :
- La Definition of Ready, a quel moment un élément de spécification est prêt à être pris par l'équipe pour développer ce qui y est attaché;
- La Definition of Done, a quel moment l'équipe peut elle être sur que le développement est terminé.
WARNING: ~50% de la promo n'a pas de sprint actif dans Jira à 13h30 aujourd'hui. Ce n'est pas admissible.
C'est globalement pas mal, et franchement mieux qu'en Janvier. On voit une nette progression dans la promo, c'est agréable a constater.
Votre gros problème est souvent sur l'identité entre "action" et "bénéfice" dans une story: "en tant que schtroumpf, je veux danser en cercle autour d'un feu de camp afin de dancer en cercle autour d'un feu de camp". Si l'action est identique au bénéfice obtenu par l'exécution de l'action, c'est qu'il y a un problème ou dans l'action, ou dans le bénéfice espéré.
Certains ont utilisé une tache de type deliverable pour décrire les personas mis en jeu dans le projet. Bonne idée.
Vous gérez globalement mal votre risque, plus vous vous engagez sur des stories "grosses" à l'échelle d'une itération, plus vous prenez le risque de vous prendre un train en sortant du tunnel. La clé de votre capacité d'adaptation est votre capacité à découper le travail de manière verticale pour arriver à vous adapter.
Pensez aussi a utiliser les sous-tâches dans Jira, et à les attacher à vos stories. Les taches sont techniques par definition, et vous permettent de vous organiser en interne dans l'équipe. Les stories doivent vraiment garder une valeur métier et être exposable à l'extérieur.
Regardez aussi dans la vue "Epic" le poids associé à chaque epic dans votre projet. Certains projets sont très déséquilibrés: des épics avec une somme de story points a 300 cote a cote avec d'autres sommant à 45.
- attention a bien mettre en avant l'originalité de votre projet dès le premier sprint;
- les stories seront en fin de sprint validée ou invalidée (la decision est binaire) => rentrer dans une itération "peu" de stories de taille "plutot grosse" est un risque de ne rien valider vendredi.
- X (5): Excellent travail de spécification du produit
- A (4): Bonne spécification
- B (3): Spécification suffisante pour avancer, mais perfectible
- C (2): Insuffisant et/ou Incomplet
- D (1): Très insuffisant
- F (0): ø
La moyenne est à ~13/20 une fois ramenées sur 20.
(R)Appel: Depuis la réforme de la nouvelle accréditation CTI, le projet est une UE a part entière, non compensable ou rattrapable => avec le montage actuel de l'année, ne pas obtenir la moyenne en projet invalide votre année. Pour info, l'an dernier, deux projets n'ont pas passé la barre du 10.
Pour chaque groupe, j'ai aussi indiqué qui suivra le projet "prioritairement", même si nous restons interchangeable avec Anne-marie. 2 groupes sont utilisés pour nous harmoniser, et sont donc suivi par nous deux.
- Facilitation / suivi : Sébastien
93 story points dans le premier sprint, c'est ambitieux. Les epics ne sont pas toutes des verbes (Conservation de l'énergie, panneau de configuration), c'est dommage. Attention aux stories n'ayant pas de valeur pour votre projet, comme créer un utilisateur (on peut travailler avec des users en dur pour commencer). Bonne description des critères et des tests, même si certains tests restent trop vague ("je selectionne l'appli maquillage du mirroir" ... comment ?). Plusieurs epics attaquées en // dans le sprint #1, attention a la garantie de livraison et à la démonstration de valeur au final. Attention a la vision produit, le backlog est un peu court pour un produit complet.
==> Eval: A
- Facilitation / suivi : Anne-Marie
31,5 storypoints dans le sprint, attention à la taille de vos estimés, c'est peut être trop fin. Peu de vision produit au final, le backlog du produit est limité. 3 épics attaquées dans le premier sprint, mais une avec une seule story. Or c'est celle qui a l'air le plus en rapport avec le coeur du projet => on peut se poser la question de l'alignement de la vision du produit et de la planification mise en oeuvre. A la lecture des stories il n'est pas clair de voir la ≠ entre le "player" et l'éditeur de jeu, Utilisez des "Components" par exemple pour classifier. L'épic la plus cruciale du projet n'est pas un verbe.
==>> Eval: B
- Facilitation / suivi : Anne-Marie
Seulement 6 stories dans le premier sprint, c'est faible, et du coup risqué pour la validation de votre avancement vendredi en démo. Certaines de vos épics ont des noms étrange ("jouer / gagner / perdre"). Le bénéfice de vos stories laisse par moment a désirer: "Je veux pouvoir jouer au jeu depuis n'importe où tant qu'il y a une connexion internet (Wifi, 3g...) afin de pouvoir jouer au jeu sans entraves". Si votre action correspond à votre bénéfice, vous avez un point de vue trop technique. Bonne description des tests et des critères d'acceptation.
==>> Eval: B
- Facilitation / suivi : Anne-Marie
Seulement 6 stories dans le premier sprint pour un estimé de 115, c'est énorme. Vous avez classifié les épics avec des "Must", "Should" et "Might". C'est original, on s'attend plus classiquement à cette classification au niveau des stories. Il y a une grosse confusion entre Critère d'acceptation (la finalité) et Test d'acceptation (le moyen de mesurer la finalité). Typiquement vos tests ne sont pas écrit, et vos critères n'en sont pas vraiment: vous avez un hybride des deux. Du coup c'est trop vague ... A quel moment un système qui "chargera une configuration prédéfinie dans le système" est-il terminé ? Quand j'en charge une ? Quand je sais en charger plusieurs ?
==> Eval: C
- Facilitation / suivi : Sébastien
Seulement 6 stories pour le premier sprint, estimé à 109, c'est énorme et risqué. Vos epics ne sont pas des verbes mais des noms. Bonne description des critères d'acceptation et des tests. Bonne vision du produit global. C'est franchement très bien, mais le contenu du premier sprint est vraiment discutable. Que ferez vous si vous n'arrivez a rien valider vendredi ?
==>> Eval: A (vaudrait X sans la prise de risque sur le premier sprint).
- Facilitation / suivi : Sébastien
Le sprint #1 n'est pas lancé, ça vaudrait presque un downgrade de l'évaluation ...
8 Stories dans le premier sprint, avec un mélange d'estimation grosses (40!) et très petite (2). Le grand écart risque de faire (très) mal. Les tests d'acceptation ont disparus dans certaines stories, c'est dommage. Très gros travail de découpage des stories et de vision produit, c'est très bien. On a par contre l'impression que les épics ont été spécifiées en isolation, et que la cohérence produit risque de se diluer si vous ne maintenez pas la cohésion.
==>> Eval: A (vaudrait X avec une meilleure spec des tests d'acceptation).
- Facilitation / suivi : Anne-Marie
Pas super pratique d'avoir appelé vos épics #1, #2 -> #5 ... Vous attaquez les 5 d'un coup, avec un survol des 4 et 5, c'est discutable vis a vis d'un objectif de démonstration d'originalité en fin de semaine. 8 stories pour 170 points, c'est ambitieux et globalement vos estimés sont très gros. Gros travail de description des critères d'acceptation et des tests. Par contre les bénéfices des stories tombent souvent dans la facilité ("afin de trouver le voyage qui me correspond" ... c'est à dire ?)
==>> Eval: A
- Facilitation / suivi : Sébastien & Anne-Marie
Le sprint #1 n'est pas lancé, ça vaudrait presque un downgrade de l'évaluation ...
Les epics sont des "grosses taches techniques" et n'apportent pas de valeur métier, même en visant un dévelopeur comme client final. Votre projet est "un peu" spécifique dans le sens où il vise le dévelopement d'une API, mais cela ne doit pas empêcher de mettre en avant une valeur pour le métier du développeur. Par exemple, en mettant l'appli de démo comme une épic a part, vous êtes horizontal dans votre découpage par construction, plutot que vertical. Par nature, l'epic "dev de la démo" se construit au dessus des deux autres, et vous ne pouvez pas l'abandonner sans abandonner votre projet. Pas la peine de répeter dans la description les infos storypoints et business value stockées par ailleurs. Attention, vos critères sont des tests, et vous n'avez pas de critères d'acceptation du coup.
==>> Eval: C.
- Facilitation / suivi : Anne-Marie
Le sprint #1 n'est pas lancé, ça vaudrait presque un downgrade de l'évaluation ...
On va avoir un problème de branding sur le nom de l'appli si vous gardez M&M's :). Vos epics ne sont pas des verbes, mais des mises en situation. C'est "intéressant" (je ne sais pas si c'est une bonne où une mauvaise idée => a vous de voir). Le sprint #1 voit peut-être un peu court dans ce qui est réalisable en 5 jours. Gros travail de description des critères d'acceptation et des tests.
==> Eval: X
- Facilitation / suivi : Anne-Marie
Le sprint #1 n'est pas lancé, ça vaudrait presque un downgrade de l'évaluation ...
8 stories pour 155 points dans le premier sprint, c'est risqué. Vous attaquez 4 des 5 epics en même temps, pas sur que ce soit justifié au vue du projet, gardez bien en tête la démo de votre originalité pour vendredi. Très gros travail de spécification et de description des stories. Le backlog produit est un peu court, ça manque d'ambition et de vision pour aller plus loin. Vous estimez très gros, si vous êtes cohérent c'est bien, mais globalement ça risque d'être compliqué à planifier à cette échelle.
==>> Eval: A (vaudrait X sans la prise de risque sur le premier sprint).
- Facilitation / suivi : Anne-Marie
Le sprint #1 n'est pas lancé, ça vaudrait presque un downgrade de l'évaluation ...
Seulement 4 stories dans le premier sprint, c'est beaucoup trop risqué. Vous attaques 2 des 4 épics identifiés, avec un focus sur la génération qui correspond a voire proposition de valeur, c'est une bonne idée. Vos épics ne sont pas décrite d'un point de vue métier, juste utilisées comme "tag" pour classer vos stories. C'est dommage. Les critères et les tests sont OK, mais mériteraient plus de précisions pour être réellement utile au projet. La vision produit est OK, même si elle semble un peu courte pour la suite.
==> Eval: C
- Facilitation / suivi : Anne-Marie
Le sprint #1 n'est pas lancé, ça vaudrait presque un downgrade de l'évaluation ...
7 stories pour le premier sprint, et un gros estimé. C'est risqué. La proposition de valeur du projet est mise en danger par des choses très basique comme la création d'un login ("Le login doit respecter le format [a-zA-Z-_]{3,20}"), qui n'apportent rien au projet. Quitte a travailler sur la notion de compte dès le départ, autant aller vers ce qui fait l'originalité du projet, par exemple les préférences vestimentaires ou l'affichage de photos. Le fait de n'avoir que des personas "utilisateur" et "posteur" affaiblit la valeur métier des stories. Ne confondez pas "acteur" (au sens UML du terme, diagramme patates-et-bonhommes) et "persona". Un persona peut endosser plusieurs rôles, en fonction de son histoire personnelle. Bonne description des critères et des tests.
==> Eval: B (c'est plutôt entre B et C)
- Facilitation / suivi : Anne-Marie
Le sprint #1 n'est pas lancé, ça vaudrait presque un downgrade de l'évaluation ...
7 stories pour un estimé de 15 points, c'est assez risqué en terme de valeur. vous misez tout sur une seule épique, orientée sur l'originalité de votre projet, c'est une bonne idée vu votre contexte. Attention à ne pas perdre de vue les autres épiques par la suite, elles ont toutes de l'importance dans votre vision produit. Bonne description des stories, des critères et des tests. Dommage d'avoir mal dimensionné le premier sprint.
==>> Eval: A.
- Facilitation / suivi : Anne-Marie
Le sprint #1 n'est pas lancé, ça vaudrait presque un downgrade de l'évaluation ...
13 stories pour le premier sprint, verticale et interchangeable. Très bien. Dommage d'avoir intégré dans la première itération des choses qui ne sont pas liées à l'originalité de votre projet (e.g., 49, créer un compte). Vous attaquez majoritairement l'épic de création de playlist (pas un verbe by the way), et esquissez les autres pour les besoins de la démo, ok. Bonne description des critères d'acceptation et des tests. Il y a beaucoup d'épics, et pourtant votre backlog produit semble avoir une vision assez court terme.
==>> Eval: B
- Facilitation / suivi : Anne-Marie
Le sprint #1 n'est pas lancé, ça vaudrait presque un downgrade de l'évaluation ...
11 stories pour 136 story points, c'est ambitieux. Les epics sont axés sur la proposition de valeur du projet, et ne tombe pas dans le travers classique de rentrer dans le premier sprint des choses peu en rapport avec la thématique du projet. Vous attaquez par contre beaucoup d'épics ≠ en //, c'est discutable en terme de gestion du risque. Dans la description des stories, vous êtes peu clair sur le bénéfice métier associé à vos descriptions: "Je veux pouvoir récupérer ma liste de courses Afin de pouvoir de voir ou vérifier ma liste de courses" ... l'action égale le bénéfice, c'est très discutable. Vos tests d'acceptation sont globalement faible, et trop calqués sur les critères d'intégrations. Typiquement (story #19) :
- Critères d'acceptations: enregistrer sa liste de courses
- Tests d'acceptations: enregistrer la liste sur son compte
Le test doit être un moyen, le critère une fin.
==>> Eval: B (ça devrait être plutôt C d'un point de vue global, vous êtes "sauvés" par la très bonne planification du premier sprint)
- Facilitation / suivi : Sébastien & Anne-Marie
Le sprint #1 n'est pas lancé, ça vaudrait presque un downgrade de l'évaluation ...
6 stories , pour 72 story points, trop de risques. Les stories ne suivent pas le template "usuel", mais l'esprit global est là. Par contre on ne retrouve ni critères d'acceptation ni tests formellement définis dans la spécification. Il y a beaucoup d'epics, qui sont utilisées pour catégoriser a gros grains. Elles sont bien décrites, en tout cas mieux que les stories qui les composent. Vous attaquez 3 des 7 épics dans le premier sprint, c'est apparement justifié.
==>> Eval: C.