Gestion de projet : de la description des tâches à la validation

Thèmes abordés

Gestion de projet, description des besoins, niveau de besoin, phase de recueil, formalisation des textes, priorisation, représentation matricielle, séquence de production, itération

Résumé du document

Une user Story n'est pas contrat :
- Elle peut être ajustée par le Métier comme par les personnes qui la réalisent
- Elle laisse aussi une marge de manoeuvre à l'implémentation ce qui génère 2 effets vertueux !

Les approches de type TDD (Test Driven Dev) ont montré leur utilité et leur efficacité. Au final, formuler les règles comme des cas de tests :
- Permet de fusionner 2 étapes du projet qui sont souvent consommatrices de temps (chacune)
- De mettre l'équipe dans une dynamique d'échange (les cas de test deviennent eux aussi I.N.V.E.S.T)
- De faciliter, l'automatisation des tests aussi - car « coder » la solution exprimée en US et « coder » les cas de tests, quelles différences ?

Extraits

[...] Est-ce que l'on fait mieux ? • De faire des choses simples et d'être focus 34 LA PRIORISATION PRIORISER = CHOISIR (ET RENONCER MAIS TOUT À LA FIN) Prioriser, pour « qualifier » ce qui rapporte (être dans les 3 premiers) Qu'est-ce qui crée le plus de valeur dans ce qui est demandé ? Quels coût, temps, moyens va t-il falloir débloquer pour arriver au résultat ? . [...]

[...] Capter, Formaliser et Partager – un processus très « organisé » . Il va falloir produire et donc « injecter » de la matière première dans notre « Usine de réalisation » ❶ Décrire un 1er niveau de besoin ❷ • Des exigences fonctionnelles • Des exigences techniques Identifier et Lister les détails ❸ Classer, Prioriser et Ordonnancer • Voire des exigences organisationnelles, réglementaires, etc . (tous types de catégories que vous jugerez utiles) De ce coté là, rien ne change - Si ce n'est peut-être la manière et le timing LA DESCRIPTION DES BESOINS – CAPTER, FORMALISER, PARTAGER DÉCRIRE UN 1ER NIVEAU DE BESOIN Les différentes techniques qui fonctionnent bien types d'approches proposés • Les processus L'approche par les processus • Le story MAP • Une WBS Le Story Mapping Mo nP Ces techniques peuvent être couplées, bien évidemment rod uit Attention, cependant à ne pas démultiplier les angles de vues Et pourquoi pas encore une WBS 3 LA DESCRIPTION DES BESOINS – CAPTER, FORMALISER, PARTAGER DÉCRIRE UN 1ER NIVEAU DE BESOIN La multiplication des angles de vue est intéressante, uniquement si chacune des vues apporte de l'information supplémentaire Petites parenthèses ( ) Sinon, cela ne fait que consommer de l'énergie, sans générer de valeur pour le projet 4 LA DESCRIPTION DES BESOINS – CAPTER, FORMALISER, PARTAGER La formalisation des besoins par les processus L'APPROCHE PAR LES PROCESSUS PRINCIPAUX INTÉRÊTS : • L'identification des acteurs et de leurs rôles • L'intégration du temps ou plus exactement des SLAs et des evts (dits déclencheurs) • Adaptée aux séquences très structurées Outillage simple ou très évolué Très normée (BPMN V2.0) Démarche d'entreprise parfois • Très normée si on le souhaite (macro, processus, tâches . [...]

[...] Des séquences de travail qui permettent de préparer, la suite de la réalisation Comme avant, oui mais . CYCLE 2 CYCLE N • Mais de façon continue • Et caler sur les rythmes de la « production » CYCLE L'IMPORTANCE LA DESCRIPTION DES BESOINS – CAPTER, FORMALISER, PARTAGER (DE LA FORMALISATION) TESTS DES QUESTION : Ecrire un cas de test, c'est (presque) écrire une règle de gestion ? VRAI FAUX Cas de Test « Je paie en sans contact avec ma carte mon achat de 18,30 €. [...]

[...] Bref, une fonctionnalité sur laquelle personne (interne, partenaire, etc . ) ne pourra s'engager et dont le résultat final risque d'être « à coté » (nouveau) carcan • Mais bien pour se faciliter la tâche pour la suite : • Dans le « delivery » • Pour le suivi 15 LA DESCRIPTION DES BESOINS – CAPTER, FORMALISER, PARTAGER « Idéalement, une User Story est réalisée complètement en une seule itération » IDENTIFIER ET LISTER LES DÉTAILS S'assurer que l'on respecte certaines règles • Non pas pour se mettre un Une User Story « Small » englobe : • Une notion de simplicité (inévitablement) • De périmètre (et de compétences nécessaires) • De timing aussi Il n'est pas facile de trouver le bon équilibre entre VALUABLE et SMALL, c'est vrai . [...]

[...] Au final, formuler les règles comme des cas de tests : • Permet de fusionner 2 étapes du projet qui sont souvent consommatrices de temps (chacune) • De mettre l'équipe dans une dynamique d'échange (les cas de test deviennent eux aussi I.N.V.E.S.T) • De faciliter, l'automatisation des tests aussi – car « coder » la solution exprimée en US et « coder » les cas de tests, quels différences ? L'IMPORTANCE (DE LA FORMALISATION) DES TESTS Les tests sont une finalité dans le processus de production MAIS l'expression de ces tests FAIT PARTIE DE LA DESCRIPTION de la solution 31 LA DESCRIPTION DES BESOINS – CAPTER, FORMALISER, PARTAGER CAHIER DES CHARGES, SPÉCIFICATIONS ? Encore des « formules mathématiques » . [...]