Posté par jc-Qualitystreet le 13 novembre 2009
Noel approche et les enfants le savent, du coup voilà à quoi j’ai eu droit le weekend dernier…
Mes enfants : « Papa … papa … pour Noel on fait le jeu des post it »
Moi : « D’accord les enfants mais cette fois on va faire un petit peu différemment … »
Car depuis ce billet « Des priorités pour le Père Noel », j’ai bien évidemment eu le temps d’améliorer le process 
, même si côté contraintes, c’est toujours plus ou moins la même chose :
- Le temps du Père Noel est compté
- Son traineau n’est pas extensible
- Les délais sont serrés
- La date de livraison ne peut pas bouger
- Le Père Noel a un grand nombre d’enfants à satisfaire
En outre, mes enfants, en bons Product Owner qu’ils sont, ont compris qu’ils ne pouvaient pas tout avoir (même s’ils en veulent toujours plus), et que le fait d’avoir été sage (ou non) pouvait « potentiellement » avoir un impact sur ce qu’ils allaient recevoir… d’où la nécessité pour eux de fixer des priorités !
SCRUM / XP depuis… la maison !
Ou comment nous fixons des priorités pour la lettre au Père Noel
Temps 1 (Optimisé) : Brainstorming et collecte des données
Lecture passionnée depuis quelques semaines, et recherche intensive dans plusieurs sources, interview du petit frère et découpage des cadeaux potentiels.
Temps 2 : Initialisation du (ou des) Backlog(s)
Les images sont découpées : une enveloppe pour chaque enfant. Je colle chaque image cadeau sur 1 post it. 1 cadeau par Post it.
Le backlog est alors initié.
Temps 3 : Priorisation du (ou des) Backlog(s)
Les post it sont posés sur le sol. J’ai demandé à mes enfants de les classer par ordre de préférence « à la file indienne » : en haut, ceux dont ils ont le plus envie, les plus importants pour eux …
…..
….
Temps 4 : Affichage du (ou des) Backlog(s)
Les post it sont priorisés sur le sol. Il nous restait à trouver un petit coin de mur ou de porte pour les mettre à la verticale (management visuel…). Un peu de patafix et le tour est joué.
Pour la grande (pas trés raisonnable):
Pour le petit frère (beaucoup plus raisonnable …):
BILAN: On a passé un bon moment et les enfants sont contents
Ma femme et moi nous chargeons de l’estimation en points-euros :)
Posté par jc-Qualitystreet le 11 août 2009
Le Story Map est l’un des éléments forts que j’ai retenus de ma dernière certification Product Owner, délivrée par Arlen Bankston (LithtSpeed).
Jeff Patton - Story Map - http://agileproductdesign.com
Intégré à un large radiateur d’informations, le User Story map est une dose supplémentaire d’UX (user Experience) dans votre projet Scrum, le complément idéal, voire indispensable de votre Backlog de produit.
Contrairement au Backlog de produit, le Story Map est multidimensionnel, plus visuel et plus collaboratif notamment au moment de sa construction.
Les règles sont simples:
- Le User Story map représente donc le backlog de produit
- Il est lié aux Personas, placés sur la gauche du Story Map
- Il se lit sur 2 axes:
- Horizontal, l’axe temporel - séquences d’action, que les ergonomes et les analystes apprécieront puisqu’il se fonde sur les analyses de l’activité et analyses métier
- Vertical, l’axe priorité, qui servira à définir quelles User Stories seront retenues sur la release ou sur le sprint
- Les grandes activités sont placée au dessus sur une ligne horizontale (les post it jaunes sur la photo qui suit), puis sont décomposées en User Stories (les post it bleus).
- Les User Stories sont affichées en colonne sous l’activité dont elles dépendent et classées par priorité. La User Story la plus nécessaire à la réalisation de son Activité est placée le plus haut, les autres suivront par ordre d’importance (on peut se réfèrer au modèle de Kano pour le déterminer). Une décomposition trés fine et le respect des critères INVEST pour les User Stories est plus que souhaitable
Jeff Patton - Story Map - http://agileproductdesign.com
Avec le Story Map, vous avez :
- Des user Stories enfin liées les unes aux autres (c’était une vraie lacune de la technique des User Stories jusqu’alors)
- L’association de toute une séquence d’actions et d’un Persona
- Un point d’entrée évident vers d’autres livrables Ux, type Storyboards…
- Une représentation concrète des flux et des séquences dans une approche très orientée Utilisateurs
- Une véritable aide à la priorisation qui met l’accent sur les fonctionnalités nécessaires à la réalisation d’une activité
Bref, un Backlog de produit plus performant, un découpage des sprint et des release plus aisé, et une meilleure appropriation des backlogs (souvent indigestes) par les équipes.
Le User Story Map fait enfin VIVRE le Backlog aux yeux de tous!
Posté par jc-Qualitystreet le 2 juillet 2007
… avant tout un outil de communication et un brin de documentation (juste ce qu’il faut pour rester Agile) visant à rendre compte de l’adéquation de ce qui est livré avec ce qui est attendu, voulu par le Client et les Utilisateurs finaux;
… un travail produit dans le cadre du Recueil & Expression, de la Spécification et de la Gestion du besoin, composantes principales de ce qu’on appelle « l’Ingénierie des exigences » (=« Requirements » );
… des exigences au cœur des projets, qu’elle soient fonctionnelles (ce que le système doit faire, constituant par exemple un backlog de produit agile) ou non fonctionnelles (qualité du produit, principalement les attributs issus de la norme ISO 9126), présentes au travers de ces trois activités essentielles.
… et de nouveaux champs d’intervention pour l’Ergonome Agile comme je le décris dans le précédent billet de cette série: Spécifications, Exigences et Cahier des charges: Qui ? Quand ?
Recueillir & Exprimer les besoins
L’objectif est de fournir une vision claire du système à concevoir, d’offrir la définition et les limites du système, les fonctionnalités clés, les autres exigences et contraintes. Définir puis partager la Vision du produit est donc cruciale.
La vision synthétique est un excellent point de départ :
POUR (public concerné par le produit)
QUI SOUHAITENT (formulation du besoin des cibles)
NOTRE PRODUIT EST (ce qu’est le produit)
QUI (le bénéfice majeur, l’utilité de la solution)
A LA DIFFERENCE DE (pratique actuelle, concurrence)
PERMET DE (éléments différentiateurs majeurs)
Elle peut se prolonger dans de petits docs. à la structure souvent similaire :
Plan d’un Cahier Des Charges de Site Web
Plan de Vision Document (Wiegers)
L’entretien et l’observation sont les sources d’informations principales mais d’autres techniques peuvent aussi être utilisées : questionnaires, focus group, observation, tests utilisateurs exploratoires, benchmarking, étude de l’existant, de la concurrence), présentation de maquettes…
Le savoir-faire de l’ergonome dans la conduite de chacune de ces techniques est un véritable atout, notamment pour trier et organiserclassifying the voice of the customer », selon Karl Wiegers ), discours qui peut prendre différentes formes : l’input des utilisateurs (« exigences Business, scénarios d’usage, règles de gestion, exigences fonctionnelles, attributs de qualité, contraintes, données, idées et solutions).
Ce premier tri nous servira à établir notre base d’exigences.
Spécifier les besoins
L’objectif est de détailler et de clarifier les besoins exprimés en analysant le fonctionnement du système de manière formelle et exploitable par les équipes de développement.
Même si ce n’est pas forcément leur objectif initial, les user stories et les éléments de conversation les accompagnant (conditions de satisfaction, exemple, wireframes…) constituent un moyen particulièrement efficace de spécifier le besoin de manière collaborative.
Les formats de spécification plus anciens se recoupent (IEEE, RUP, Volere …). Ils intègrent généralement en leur sein une partie Exigences fonctionnelles. Cette intégration qui se concrétise souvent sous forme de renvois vers d’autres formats ou document permet à cette documentation générale de rester synthétique, ouverte et abordable.
Exemple SRS Volere
Exemple SRS IEEE 830
« Use cases et user stories », livrables d’ergonomie, diagrammes divers et variés … sont dans tous les cas de précieuses techniques pour spécifier les besoins.
Sur le plan fonctionnel et opérationnel, l’utilisation de ces user stories ou la construction progressive de Cas d’utilisation (« use cases »), (Acteur -> But -> Déclencheur et scénario nominal -> Extensions), le tout combiné aux spécifications IHM (wireframes ), sont désormais des standards, et des avancées majeures dans une vision toujours plus utilisateur et toujours plus orientée BUT.
Il s’agit avant tout ici d’un travail d’Equipe même si les spécialistes de l’Experience Utilisateur, de l’Analyse et des Tests apportent une vraie plus value.
Gérer les exigences
Les objectifs de cette activité transversale sont de faciliter la reconnaissance et la compréhension du lien entre les exigences, de permettre leur priorisation, et surtout de tracer leur prise en charge dans le projet (tel composant est le fruit de tel UC ou User Story, lui même issu de tel besoin, le tout testé dans tel cas de test); en somme, la vie d’une exigence aussi bien en amont qu’en aval de sa spécification.
Exemple d’une base d’exigences (RequisitePro)
Des outils spécialisés (Doors, Caliber-RM, Requisite Pro…) existent. Au final, ils sont plus complexes que véritablement utiles, car c’est surtout la prise de conscience de l’importance de cette activité qui est cruciale.
La gestion doit s’opérer de manière continue très tôt dans le projet : la base d’exigences ou tout simplement le BACKLOG de PRODUIT qu’ils soient manuels ou automatisés vont servir de fil rouge au projet et de référence à l’ensemble des acteurs.
Lister & vérifier (selon ces huit critères : caractère correct, clair, sans ambiguïté, cohérent, complet, réaliste, pertinent, vérifiable et traçable), qualifier, valoriser et surtout prioriser, suivre les exigences sont des tâches inhérentes à cette activité : il s’agit d’une grosse part du travail de l’analyste ou plus globalement du Product Owner.
Retrouvez des références bibliographiques sur ces questions dans la rubrique “Quelques livres“.
Posté par jc-QualityStreet le 27 juin 2007
Plus j’interviens dans les projets de développement informatique (Logiciel, Application Web, Sites Internet, INTRANET, EXTRANET …), plus je m’aperçois du caractère essentiel mais complexe, de trois activités, qui bien menées, maximisent pourtant les chances de réussite des projets:
- Recueillir et exprimer le besoin (Expression des besoins, Cahier des Charges, Vision …)
- Spécifier le besoin (Dossier de spécification, SRS, Use cases, User stories …)
- Gèrer et tracer les exigences (Backlog de produit, Liste des exigences, manuelle à base d’attributs ou sur des outils dédiés)
Évidemment, l’intensité, la répartition de ces activités va varier selon la taille et la nature du projet (Applications mètier, Sites Internet…), selon le contexte (Projet interne, R&D, Client, Appel d’offres), mais toutes trois se doivent d’être présentes et définies sur vos projets de conception…. D’ailleurs, dans un prochain billet, je détaillerai davantage le Quoi, et vous proposerai une réflexion sur le Comment.
Sans détours et sans vous rappeler les rapports CHAOS du Standish Group, je vous affirmerai pourtant que:
- La capture est souvent incomplète, biaisée, mal maîtrisée.
- La spécification souvent confuse, inadéquate, incorrecte, incompréhensible pour ses destinataires.
- La gestion des exigences faite dans l’urgence voire absente, et de toute façon sous estimée.
Sans détours, j’ajouterai même que le recueil, la spécification et la gestion du besoin, nécessitent au final une véritable expertise, la maîtrise de diverses techniques souvent complémentaires (issues des Sciences Humaines), et pas mal de rigueur…
bref, moins de blabla, moins d’artisanat, plus de professionnalisme et de méthode.
QUI
Vaste débat… et potentiellement pas mal de dérives…
Dans un contexte agile, on parlerait de Product Owner. Plus largement, l’Analyste, le Consultant, le Client sont des acteurs récurrents … mais aussi l’Ergonome qui de par son savoir-faire, ses objectifs et sa démarche centrée utilisateur doit en effet être un acteur privilègié du recueil et de l’analyse du besoin. Souvenez-vous , un produit “ergonomique” est un produit utile (issu d’un besoin EXPRIME ou NON) et utilisable : la présence de l’ergonome à ce stade est donc plus que légitime.
QUAND
L’expression des besoins et autres Cahiers des charges (suffisamment ouverts) sont quant à eux le fruit de l’activité de recueil, et servent souvent de déclencheurs pour la suite des opérations en mode agile, itératif ou séquentiel.
Dans une perspective séquentielle (cascade ou V: le pire), l’enchaînement est simple et bien connu. Les disciplines d’ingenierie (Spécification, Conception, Developpement, Intégration, Test) vont se dérouler dans un ordre trés précis avec la nécessaire validation de l’étape précédente pour passer à la suivante.
Les écueils de cette démarche sont nombreux : feedbacks et retours en arrière non prévus, corrections difficiles, pas de pilotage par les risques, manque de visibilité… Dans ce cadre, la gestion des exigences sera au mieux menée de manière transversale, servant de fil rouge à l’ensemble des acteurs et au projet; toutefois la plupart du temps la gestion des exigences ne sera pas envisagée ou sera traitée dans l’urgence.
Non ce qui marche, c’est l’AGILITE avec une bonne dose d’analyse, de test et d’expérience utilisateur.
Dans une perspective agile donc (l’idéal)
… de type SCRUM, méthode Agile la plus populaire, le degré de formalisme sera diffèrent; le tout intégré à chaque Sprint. Un effort particulier sera fait en Sprint 0, l’ingenierie des exigences se jouera principalement au travers du Backlog de produit & User Stories dans une dynamique plus collaborative, toute aussi disciplinée mais moins formelle. Le backlog de produit servira donc de fil rouge
Dans une perspective seulement itérative
… de type Processus Unifié (”Unified Process”), le concept ou plutôt la discipline “Ingènierie des exigences” prend cette fois tout son sens puisque prévue, formalisée et cadrée, permanente et continue. Les acteurs chargés de ces activités vont donc suivre le projet du début à la fin, certes avec plus de spécification en 1ère partie du projet (80% des cas d’utilisation doivent être rédigés en fin d’Elaboration), et davantage de gestion des exigences dans la seconde partie.
A bientôt pour plus de détails sur le Quoi et une idée du Comment.
