Dans Agile, des exigences spécifiques documentées n’existent pas au départ. Spécifique se rapporte au livrable final. En Agile, les exigences sont capturées pendant le développement, pas documentées à l’avance.Cependant, le résultat final va typiquement au-delà du détail et de la spécificité d’exigences traditionnelles. Quand de grandes exigences ne sont pas spécifiques, elles sont typiquement décomposées en plusieurs histoires utilisateur en Agile, dont chacune fournit une fonctionnalité spécifique et peut être plus facilement produite.
Mesurable.
La construction et l’évaluation de chaque fonctionnalité se concentrent sur la mesure de l’efficacité. Un des bénéfices les plus significatifs d’Agile est que cette exécution et ces mesures de pertinence sont construites et mesurées durant le processus de développement. Avec une mentalité de prototypage, des fonctionnalités Agiles peuvent être évaluées par des utilisateurs avant leur mise en œuvre. Quand cela ne peut pas être fait directement, par exemple, quand un processus commercial totalement nouveau est créé, l’association développeur-utilisateur utilisée pour construire les fonctionnalités Agile réduit le risque de livrables ne réussissant pas à atteindre des objectifs business mesurables.
Atteignable
Le classement par taille de fonctionnalité et la priorisation assurent que la faisabilité est régulièrement évaluée. Les fonctionnalités sont examinées pour leur intégrité et capacité à être produites en un sprint. De plus grandes fonctionnalités sont décomposées en morceaux qui sont plus facilement créés, augmentant la faisabilité.
Quand les fonctionnalités ne peuvent pas être décomposées en parties gérables, c’est un signe qu’elles ne sont pas réalisables.
Les développeurs et les utilisateurs peuvent examiner ces fonctionnalités en temps réel pour déterminer à quel point elles sont critiques et explorer d’autres façons d’adresser le besoin business.
Réaliste
Une approche pratique de comment planifier et implémenter le changement
En Agile, les fonctionnalités sont développées et acceptées itérativement et en temps réel, par rapport à des semaines ou des mois après que les exigences soient documentées dans l’approche traditionnelle prédictive.
Agile se prête aux résultats réalistes et peut intégrer les derniers changements aux besoins business.
La nature d’Agile signifie que l’équipe entre plus profondément dans les fonctionnalités et leurs capacités, permettant aux utilisateurs de rendre les livrables plus faciles à utiliser. Les fonctionnalités présentent une plus grande intégrité et supportent de meilleurs processus business.
Temporel – contraint par le Temps
L’approche par sprints est idéale pour s’assurer que les contraintes de temps soient placées sur la création de fonctionnalités. De plus, il y a la valeur supplémentaire de pouvoir facilement changer les durées quand des priorités business changent. La re-priorisation et la planification de fonctionnalités avant chaque sprint fournissent un focus soutenu sur les périodes de développement. Bien que cette approche de gestion des délais ne soit pas parfaite, les fonctionnalités qui exigent plus de temps que prévu à développer sont réévaluées et reportées aux sprints suivants comme décidé au sein de l’équipe Agile.
QRP est partenaire de DantotsuPM, visitez leur site et leur blog
partagez ce billet avec vos amis, collègues et relations professionnelles
J’ai récemment visionné à nouveau ces 2 vidéos de Christian Hohmann sur les enquêtes Kano que je vous propose de découvrir avant de discuter de comment utiliser ce modèle pour le management d’un portefeuille de projets.
Reprenons les bases d’une enquête Kano
Un bref rappel à propos du modèle de Kano : comprendre les trois courbes
La spécificité des enquêtes Kano : interrogation positive et négative
La table de décodage d’une enquête Kano
Exemples, cas d’usage
et, pour communiquer graphiquement les résultats d’une enquête Kano
Votre portefeuille de projets et le modèle de Kano
Si vous managez et/ou contribuez à un portefeuille de projets, vous savez que certains projets vont être capables de changer totalement les règles du jeu pour votre entreprise ou votre secteur, certains ont déjà une forte visibilité, d’autres sont plutôt exploratoires…
Pourquoi ne pas essayer de les positionner sur le modèle de Kano Noriaki ci-dessous et voir ce que vous pouvez en apprendre ?
Les attributs d’un produit/service sont les supports des attentes des clients. Ils peuvent être classés en cinq catégories :
Obligatoires, indispensables (Must-Be)
Attractifs (attirantes)
Proportionnels ou linéaires (One-Dimensional)
Indifférents
A double tranchant (Reverse)
Sur la base de cette nomenclature, quatre zones (Indifférence, basique, performance, excitant) sont repérées sur le graphe ci-dessus qui comporte deux axes :
L’axe vertical représente le niveau de satisfaction : En bas, le moins satisfait (dissatisfied), En haut, le plus satisfait (satisfied)
L’axe horizontal représente la prise en compte des attentes : À gauche faible couverture (Need not fullfilled), à droite forte couverture (Need well fullfilled) »
Après avoir complété cet exercice et positionné tous vos projets sur le graphe…
Qu’en apprenez-vous ?
Devriez-vous changer la distribution de vos investissements en fonction de cette attractivité client ?
Les fonctionnalités de certains projets devraient-elles prendre en compte leurs positionnements Kano actuels pour les faire évoluer vers davantage d’attractivité client ?
Avez-vous des projets qui répondent un peu trop à des besoins déjà largement satisfaits ? Quels seront leurs éléments différenciant ?
J’aimerais beaucoup lire vos commentaires lorsque vous aurez réalisé cet exercice sur votre portefeuille de projets !
Planisware est partenaire DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
L’insensibilité à la taille de l’échantillon est un biais cognitif qui se produit lorsque les gens estiment la probabilité d’un résultat ou situation en se basant sur les résultats sur un échantillon sans égard à la taille ni à la représentativité de cet échantillon.
En quoi sommes-nous concernés dans nos projets ?
Tous vos clients ou prospects sont-ils identiques ?
Il arrive souvent que l’argument de « la voix du client » soit utilisé par vos parties prenantes pour justifier leurs choix ou les priorités qu’elles souhaitent voire satisfaites par votre projet. Et la voix du client est utile et doit être entendue. Parler avec les clients est important, mais ne basez pas vos suppositions sur les priorités des fonctionnalités de vos livrables sur seulement quelques entretiens. Plus l’échantillon est faible et plus la variation risque d’être grande.
Comment éviter le plus possible ce travers ?
Vous savez que le choix et la taille de l’échantillon sont primordiaux pour contrer le biais cognitif lié à notre insensibilité naturelle envers ces aspects. Efforcez-vous, avec l’équipe, de prendre en compte la taille et les caractéristiques de votre panel. Placez davantage d’efforts en amont sur les critères de sélection de l’échantillon. Travaillez avec de très nombreux clients et basez votre priorisation et vos décisions de produit sur des données factuelles plutôt que des suppositions ou des extrapolations basées sur les réponses d’une poignée de clients.
Ce biais peut-il nous être utile ?
Votre attention bienveillante à la qualité des échantillons choisis pour justifier les décisions de projet va rapidement infuser le projet, vos parties prenantes et vos équipes. Vous pourrez, après avoir enraciné les bonnes pratiques sur l’aspect quantitatif de ces échantillons, commencer à introduire l’aspect qualitatif. Par exemple, les clients choisis pour cette enquête terrain sont-ils bien représentatifs de la cible marketing visée ? Localisation, taille, usages, processus, secteurs économiques… Ne limitez pas vos enquêtes ou entretiens à des questionnaires à choix multiples, utilisez davantage de questions ouvertes pour que les répondants s’expriment pleinement.
Enfin, en utilisant des approches Agiles comme Scrum, validez les premiers livrables de vos itérations (ou sprints) avec vos clients pour avoir des retours concrets immédiats et infléchir ou corriger votre direction rapidement.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Pourquoi dépenser du temps à rédiger, planifier et évaluer une pile de courtes histoires quand vous pouvez écrire, planifier et évaluer une unique une grande histoire ?
J’ai souvent rencontré des équipes qui aiment les longues Histoires Utilisateur. Pourquoi dépenser du temps à rédiger, planifier et évaluer une pile de courtes histoires quand vous pouvez écrire, planifier et évaluer une unique une grande histoire ? Les histoires plus grosses signifient une meilleure efficacité, non ? Pas nécessairement.
Pourquoi des histoires plus courtes ?
Une petite de dose satisfaction à chaque histoire complétée
Focus : Des histoires courtes nous focalisent et nous aident à voir que la fin n’est pas trop éloignée. Il est fréquent de se sentir écrasé par les détails quand nous travaillons sur de longues histoires. De brèves histoires génèrent aussi une satisfaction de l’équipe plus élevée; les personnes reçoivent une petite dose de dopamine à chaque fois qu’elles finissent quelque chose.
Transparence : Des histoires courtes fournissent une transparence et une visibilité beaucoup plus claire des progrès dans le sprint pendant le Daily Stand-Up. Le réalisé est facile à suivre quand nous voyons une série de courtes histoires achevées; il est plus difficile d’évaluer et de visualiser le réel progrès sur une grande histoire chaque jour.
Relisez ce billet sur pourquoi Fibonacci
Prévisibilité : Des histoires courtes ont tendance à aboutir vélocité plus précise et juste, ce qui réduit la variabilité et améliore la prévisibilité. Des évaluations relatives de points d’histoire en utilisant la séquence de Fibonacci sont par définition de moins en moins précises pour de plus grandes histoires – voir “le cône d’incertitude”. Ainsi, une histoire 13 ou à 20 points est probablement beaucoup moins prévisible que plusieurs histoires à 2, 3, ou 5 points.
Flexibilité : Des histoires courtes fournissent . Elles fournissent davantage de flexibilité pour nous adapter comme nous apprenons. Quand les circonstances changent ou que certaines histoires deviennent sans utilité, il y a moins de perte dans la réorganisation ou l’élimination d’une courte histoire.
Relisez ce billet
Livraison : Des histoires courtes permettent aux équipes de test de commencer à évaluer plus tôt dans le sprint et de travailler sur de plus petites portions de code.
Risque Réduit : Des histoires volumineuses augmentent le risque que l’équipe ne livre rien à la fin du sprint qui soit 100 % fait (Done). La capacité de l’équipe ressemble à un entonnoir. Quand nous essayons de forcer un grand objet (de grandes histoires) à y passer, l’entonnoir se bouche. Par exemple, un développeur travaillant sur une grande histoire peut aussi être le seul avec le jeu de compétences nécessaires pour compléter une autre histoire critique.
Comment puis-je créer des histoires plus courtes ?
Vous trouverez des tas de bons articles sur la décomposition d’histoires d’utilisateur sur Google. Néanmoins, voici une poignée de questions que j’ai trouvé utiles pour déterminer comment créer des histoires plus courtes :
Vidéo explicative sur Pareto
S’il y a plusieurs résultats dans une unique histoire utilisateur, sont-ils tous nécessaires tout de suite ? Y-a-t-il un découpage 80/20 qui fournirait la majeure partie de la valeur ? Pouvez-vous développer ces 20 % dans une autre histoire différente ?
Avez-vous des règles métier multiples ou plusieurs personas dans l’histoire utilisateur ? Ces règles métier peuvent-elles être construites séparément, ou les différents personas traités dans des histoires séparées ? Des règles métier plus simples peuvent-elles suffire pour le moment pour faire marcher la solution ?
Est-ce que le parcours optimal peut être codé en premier sans toutes les exceptions ? Ces exceptions peuvent souvent être relogées dans des histoires complémentaires.
Y-a-t-il de multiples plates-formes ou plusieurs interfaces utilisateur associées à l’histoire utilisateur ? Pouvons-nous les développer une par une ?
Des opérations multiples sont-elles contenues dans l’histoire utilisateur c’est-à-dire Créer, mettre à jour, supprimer une donnée? Pouvons-nous développer une opération à la fois ?
Quels scénarios de test s’appliquent ? Certains scénarios sont-ils complexes et pas très critiques ? Une première itération plus simple peut-elle être développée pour valider le design ?
La plupart de la complexité de l’histoire vient-elle d’exigences non-fonctionnelles comme la sécurité ou la performance ? Si c’est le cas, l’histoire peut-elle être découpée pour d’abord faire le travail sur la fonctionnalité, puis modifiée plus tard pour satisfaire ces exigences non-fonctionnelles ?
Combien courte est « courte » ? Quelle est la bonne taille ?
Relisez ce billet sur la méthode INVEST
Ce sont des questions très subjectives et elles dépendent de plusieurs facteurs dont la capacité de l’équipe, la durée de sprint et autres. Un bon point de départ pour déterminer la taille idéale de l’histoire doit utiliser l’acronyme I.N.V.E.S.T. Si vous êtes peu familiers avec cette approche, cherchez simplement “agile invest” sur votre navigateur internet pour en apprendre davantage. Une histoire doit délivrer la valeur. Livrer une histoire qui a peu de bénéfices perceptibles juste pour la garder petite n’a probablement aucun sens. Au final, les histoires utilisateur plus courtes sont d’habitude meilleures que de plus longues. Mais, le bon sens s’applique pour vous assurer qu’une histoire utilisateur peut livrer une réelle valeur et peut aussi être achevé en un unique sprint.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Envoyer par email un jeu de documents pour exprimer un besoin ou une histoire utilisateur est rarement efficace.
En effet, de nombreux échanges seront nécessaires par ce média pour parvenir le plus souvent à une compréhension fragmentaire et incomplète du besoin. Les histoires d’utilisateurs Agile comme la description des besoins en méthode Waterfall sont plus efficaces en face à face. Le non verbal est très important et le cycle rapide de questions/réponses que permet l’interaction directe ne saurait être remplacé par l’écrit.
CSP est partenaire de DantotsuPM
Il s’agit donc de collaborer pour bien comprendre quel est le besoin, i.e. quel problème est à résoudre, plutôt que de se préoccuper du format de l’histoire utilisateur ou du document.
Idéalement, vous devez tous sortir de la séance de travail avec une représentation très claire de ce à quoi ressemblera le produit ou résultat du changement.
Si vous parvenez à identifier des éléments de mesure simples et fiables et à utiliser pour capturer la situation actuelle et la future souhaitée, vous aurez déjà franchi une étape clé.
partagez ce billet avec vos amis, collègues et relations professionnelles
La construction de produits formidables exige une compréhension profonde, emphatique de vos utilisateurs. De quoi ont-ils besoin ? Qu’est-ce qui les motive ? Quelle est leur expérience du produit ou processus spécifique ?
Dans ce billet, j’explique comment utiliser des Cartes d’Empathie et des interviews avec des utilisateurs pour construire cette compréhension.
À propos des Cartes d’Empathie
Les Cartes d’Empathie sont un outil simple et puissant pour construire une meilleure compréhension de vos utilisateurs. Il est pas étonnant qu’elles soient les basiques des UX-designers et généralement utilisées dans le Design Thinking. Le nom provient de “Empathie”, qui se réfère à la capacité de comprendre ce qu’une autre personne pense et ressent.
Vous pouvez créer une Carte d’Empathie commune à tous les utilisateurs, ou des cartes différentes pour de multiples segments ou utilisateurs individuels.
Dans tous les cas, les meilleures Cartes d’Empathie sont basées sur des données réelles. Pas sur des conjectures ou des suppositions que vous feriez dans votre équipe. Cela signifie qu’une bonne Carte d’Empathie exige de sortir de nos bureaux pour aller discuter avec de vrais utilisateurs en chair et en os.
Comment construire une Carte d’Empathie
Avec votre équipe (Scrum), identifiez des utilisateurs ou des clients que vous pouvez interviewer pendant 30 à 60 minutes. Si vous interviewez plusieurs personnes, essayez de trouver différents types d’utilisateurs. Incluez des utilisateurs insatisfaits chaque fois que possible. Leur perspective apporte souvent des vues qui vous questionneront.
CertYou est partenaire de DantotsuPM
Préparez l’interview avec votre équipe. Créez une liste de questions ouvertes qui vous aident à comprendre les utilisateurs. Bien que nous soyons au final intéressés par construire un bon produit, les Cartes d’Empathie ne sont pas destinées à évaluer seulement des idées de produit. Concentrez-vous sur l’utilisateur : Quel genre du travail fait-il ? Quels sont les défis auxquels il fait face dans son travail ? Qu’est-ce qui le frustre ? Qu’attendrait-il d’un nouveau produit ? La Carte d’Empathie affichée ci-dessus donne des idées des sortes de questions que vous pouvez poser.
Si c’est la première fois que vous allez interviewer des utilisateurs, il pourrait être avantageux de tester d’abord les interviews dans votre équipe. Pratiquez à tour de rôle en posant des questions ouvertes et en prenant des notes en même temps.
Interviewez les utilisateurs. Vous pouvez le faire avec l’équipe ou vous pouvez vous séparer en binômes. Assurez-vous que chacun dans l’équipe soit impliqué dans le processus. Prenez des notes pendant l’interview ou enregistrez-le (avec la permission de l’utilisateur, évidemment).
Quand vous avez fini de mener les interviews, réunissez votre équipe pour synthétiser l’information et en extraire les points clefs de compréhension des attentes. Utilisez de grands posters avec une Carte d’Empathie, capturez les compréhensions, les citations d’utilisateurs et leurs comportements sur des post-it et positionnez-les dans les secteurs correspondants sur la carte.
Quand vous avez fini de créer ces cartes, discutez-en en équipe. Que vous disent-elles ? Quelles compréhensions avez-nous recueillies ? Vous pouvez ou utiliser les cartes elles-mêmes comme point d’entrée à la génération d’idées ou vous pouvez poursuivre avec d’autres techniques (comme le brainstorming, la visualisation du parcours client, etc).
Comment faire une bonne utilisation des Cartes d’Empathie
Il n’est d’aucune utilité de construire une Carte d’Empathie que l’on ne regarde jamais. Les cartes d’empathie nous permettent de voir notre produit avec les yeux de nos utilisateurs. Cette perspective est facilement perdue au fil du temps, rendant d’autant plus important de garder les utilisateurs tangibles et visibles.
Ci-dessous, deux ou trois astuces :
Carte d’Empathie dans un cadre, par Paul Boag (Boagworld.com)
Les cartes d’Empathie peuvent facilement être métamorphosées en Personas. Un Persona est un utilisateur factice (ou parfois réel). Les Personas décrivent des caractéristiques majeures, des comportements et des attentes. Une façon de le faire est décrite ici.
Certaines équipes encadrent leurs Cartes d’Empathie et les placent quelque part bien en vues. J’ai une fois formé un groupe d’équipes chez ProRail à le faire. Ils ont aussi créé des Personas basés sur de vraies personnes et ont invité ces gens (de temps en temps) à suivre les Revues de Sprint.
En l’absence d’utilisateurs réels, les Personas et des Cartes d’Empathie sont utiles pendant la Planification ou les Revues de Sprint. Parce qu’ils rendent les utilisateurs tangibles et visibles, ils nous aident à regarder notre produit à travers leurs yeux. Comprendraient-ils cette nouvelle fonctionnalité ? L’aimeraient-ils ? Qu’est-ce qui pourrait être frustrant pour eux ?
Bonne chance dans la construction de vos Cartes d’Empathie!
Partagez ce que votre équipe a appris à travers ce processus lors de leur construction. Postez vos exemples de bonnes et vraies Cartes d’Empathie.
partagez ce billet avec vos amis, collègues et relations professionnelles
Quelqu’un qui a passé du temps dans le cycle de vie de développement de logiciel traditionnel peut certifier que le principe Agile d’accueillir des exigences changeantes peut s’avérer le plus difficile pour des organisations basculant vers Agile. Dans le cycle de vie traditionnel, changer les besoins génère de la frustration, de la colère, du désespoir et, dans certains cas, des frais d’avocats et des coûts additionnels.
CertYou est partenaire de DantotsuPM
Le mouvement Agile demande que les clients et les organisations de développement travaillent ensemble et embrassent le changement pour le plus grand bénéfice de l’utilisateur final. Ce niveau de transparence exige que les murs tombent entre clients et développeurs. Il nécessite aussi que le client reconnaisse l’impact que le changement aura sur le projet et le coût complémentaire du changement sur le budget de projet, ainsi qu’acquérir un meilleur niveau de compréhension du travail.
Le client et les développeurs atteignent une compréhension mutuelle
Dans une mauvaise mise en œuvre de Agile, les clients pensent qu’ils peuvent changer les exigences aussi souvent qu’ils le souhaitent et que le personnel de développement doit gérer ces changements. « Hé, vous avez dit que vous étiez Agiles, non ? »
Dans une bonne mise en œuvre, le client et le développement travaillent ensemble en étroite collaboration pour examiner et adapter le produit à chaque occasion possible. Comme le produit est revu fréquemment, le client et l’équipe maintiennent une compréhension partagée de l’état actuel du produit et de l’état actuel du marché. Quand le client change des exigences, le changement, son coût de mise en œuvre et son impact sur le projet dans son ensemble, sont mutuellement compris.
Jeff Sutherland utilise l’expression « Money for nothing and your change for free » (« l’Argent pour rien et votre changement gratuit ») quand il conseille des organisations sur la façon d’écrire des contrats Agiles (ndlt. Tiens, je ne savais pas que Jeff est fan de Dire Straits). En essence, on tient compte des deux côtés pour avoir une flexibilité maximale; l’équipe de développement tient compte d’exigences changeantes sans modifier le contrat ni charger des honoraires de modification et, en échange, le client consent à participer conjointement au processus Agile et au cycle de vie du développement de logiciel. Dans le cas où le client est satisfait avec moins de travail que prévu à l’origine, ils peuvent finir le contrat plus tôt, avec le paiement d’une partie prédéterminée du contrat restant.
Le changement est bon
La position est que le changement est bon. Il permet au client de satisfaire l’utilisateur final avec les fonctionnalités de plus forte valeur et de terminer le contrat au plus tôt. Il permet à l’entité de développement de recevoir la juste compensation pour livrer tôt et leur permet de se passer à l’opportunité suivante.
avec Ventura Asssociates, partenaire de DantotsuPM, recrutez les ressources critiques dont vous avez besoin pour vos projets
« Accueillir des changements dans les exigences, même tard dans le développement » ne signifie pas que le propriétaire de produit, le « Product Owner », est libre d’ajuster les critères d’acceptation après que le sprint ait commencé. Les processus Agiles qui exploitent le changement pour y gagner un avantage compétitif devraient être mis en œuvre avant l’exécution de sprint. De l’avis de tous, il existe un processus pour terminer un sprint plus tôt; cependant, c’est rare.
Les processus agiles facilitent l’élaboration progressive, la décomposition, le raffinement de l’arriéré de produit, une approche incrémentale et la planification de sprint; Ils exploitent pleinement le changement tout en protégeant l’équipe.
partagez ce billet avec vos amis, collègues et relations professionnelles
Commencez-vous immédiatement à planifier des tâches et mettre l’équipe en mouvement ?
Voici six choses que vous devriez vous efforcer de faire le plus tôt possible.
1. Validez le cas d’affaires
Comprenez et vérifiez le Business Case
Une des premières choses que vous devriez faire en tant que un chef de projet (PM) quand un nouveau projet vous est assigné est de découvrir pourquoi le projet est important et de valider qu’il a un bon cas d’affaires (« business case »). Comme PM vous n’êtes pas responsable du cas d’affaires, mais il est important que vous soyez familier avec son contenu et que vous y adhériez. Trop de projets sont commencés sans objectif, raisonnement ou bénéfice clairs et quand il se heurte plus tard à des problèmes, cela peut facilement se refléter négativement sur vous, le chef de projet. Ne laissez pas ceci se produire. Ayez une conversation avec les managers qui vous ont confié le projet et demandez-leur les raisons qui justifient le projet, à quoi ressemblera le succès une fois que le projet aura été achevé et comment voudraient-ils le mesurer. Comprendre pleinement le cas d’affaires vous rendra plus apte à prendre des décisions et diriger le projet dans la bonne direction.
2. Identifiez le comité de direction et le sponsor du projet
Identifiez précisément qui sont les décideurs
La chose suivante est de comprendre qui sont les décisionnaires sur le projet auxquels vous reportez. Idéalement il devrait y avoir une personne responsable – le sponsor – et qui accepte sa responsabilité. On me demande souvent si le PM et le sponsor peuvent être une même personne, et ce n’est pas un scénario idéal. Comme chef de projet, vous êtes responsable de livrer le projet selon les délais, coûts, qualité et bénéfices attendus par le sponsor. Si n’importe lequel de ces paramètres change, vous devez le remonter et chercher des conseils de la personne au-dessus de vous dans la hiérarchie du projet. Le sponsor aura normalement besoin de l’appui d’autres partenaires seniors dans l’organisation et ensemble ils forment le comité de direction. Assurez-vous que vous savez quels décideurs ont leur siège au comité de direction du projet et faites qu’ils se rencontrent sur une base régulière pour vous fournir des conseils managériaux et business sur votre projet.
3. Analyser les parties prenantes
listez et étudiez les parties prenantes
Il est très important que vous ne sautiez pas dans le projet et commenciez à planifier des tâches sans avoir une bonne compréhension de quelles sont les parties prenantes. Une partie prenante est une personne qui est impactée par le projet ou qui peut impacter le projet. Si vous n’identifiez pas toutes les parties prenantes au début, il y a un risque que des exigences fondamentales soient omises et que le projet ne puisse atteindre son but. Une autre raison pour laquelle vous devez prêter l’attention aux parties prenantes est que vous devez les gérer d’une telle façon qu’elles adhèrent au projet. Demandez-vous qui sont les influenceurs les plus importants et comment ils perçoivent le projet. Votre rôle est de garantir chaque personne adhère pleinement au projet en embarquant leurs réserves et en travaillant avec eux pour créer le meilleur résultat possible pour chacun.
4. Poser les règles du jeu
posez les règles de vie sur le projet
Sur de nombreux projets il n’est pas rare que les tâches ne soient pas toutes achevées dans les délais souhaités et que le travail ne soit pas fait de la façon espérée par le chef de projet. Le problème fondamental est que le PM a souvent un jeu d’attentes qui n’ont jamais été explicitement exposées ou discutées. Celles-ci ne touchent pas seulement à la qualité du travail, mais aussi au comment il sera fait. Avoir un jeu de règles que personne n’a eu au départ et qui n’a même pas été énoncé est une recette pour le conflit. La meilleure façon de créer une équipe de projet efficace et harmonieuse est pour l’équipe de produire en commun un jeu de règles qui adressent comment ils travailleront ensemble. Ce n’est pas au PM de dicter ces règles, mais à l’équipe principale (« core team ») de les définir. Une règle pourrait être que nous livrons toujours ce que nous promettons et que nous informons nos collègues dès que possible si nous ne sommes pas capables de tenir notre engagement. Une autre règle du jeu pourrait être que le PM tiendra toujours l’équipe informée de ce qui est décidé au niveau du comité de direction. Peu importent les règles tant qu’elles ont été collectivement consenties et fonctionnent pour chacun.
5. Recueillir les exigences
recueillez toutes les exigences
Il est probable que seules les exigences de haut niveau ou les objectifs ont été identifiés au moment où le projet vous est remis. C’est alors à vous et à l’équipe d’interviewer les parties prenantes pour découvrir dans le détail ce qu’elles exigent du projet. L’erreur que font beaucoup d’équipes consiste en ce qu’ils ne recueillent pas les exigences fondamentales suffisamment dans le détail et qu’ils ne sont pas explicites de ce qu’ils ne livreront pas. Cela peut aboutir à des malentendus, des désaccords et du travail à refaire. Alignez une série d’ateliers de recueil des exigences où vous décrivez l’état actuel et l’état futur souhaité et listez tous les changements qui seront nécessaires. Sur certains projets il n’est pas possible de définir toutes les exigences détaillées au départ car tout ne peut y être décidé à l’avance. Cependant, vous devez vraiment documenter toutes les fonctions fondamentales, mettre des priorités et comprendre à quoi ressemble un résultat réussi avant de commencer le travail. Créer des diagrammes de flux, des cas d’usage, des storyboards, des maquettes et des prototypes est une excellente façon de mettre en lumière les exigences plutôt que de les écrire dans un document textuel.
6. Créer le plan de haut niveau
visualisez les jalons de l’équipe vers le succès
Une autre activité qui doit être achevée avant que l’équipe ne s’engage sérieusement dans le travail est de créer collaborativement un planning des jalons marquants. Après avoir rassemblé la majorité des exigences vous êtes en bonne position pour identifier les 10-15 jalons les plus marquants et décider quand ils doivent être achevés. Il y a une énorme différence entre faire ce travail en isolation et engager l’équipe pour le réaliser ensemble. Quand vous engagez l’équipe et définissez le plan de haut niveau de manière collaborative, vous gagnez leur adhésion et d’une façon complètement différente. Après avoir identifié les événements marquants clefs, discutez de qui est responsable de chaque livrable et jalon et du plan détaillé qui va avec. Cette session de planification faite en collaboration devrait aussi comprendre une discussion sur les risques les plus importants, ce que vous allez faire pour les adresser et qui prend la propriété de chaque risque.
Méta Projets Management est partenaire de DantotsuPM
Quand vous prenez en charge un nouveau projet, ne commencez pas immédiatement à exécuter le travail. Vous devez d’abord au minimum comprendre si le projet a un cas d’affaires valable, qui sont le sponsor de projet et les parties prenantes, puis, aider l’équipe à définir un jeu commun de règles, recueillir toutes les exigences fondamentales et créer un plan à haut niveau des jalons majeurs auquel l’équipe toute entière adhère totalement.
partagez ce billet avec vos amis, collègues et relations professionnelles
Je me rends compte que le concept de Sprint Zéro est controversé. Et dans mes premiers temps en Agile, j’ai été étonné par l’importance accordée à ce sujet. Je pensais que nous aurions des sessions de transfert de connaissances au fil du travail, alors, pourquoi avoir un sprint séparé ? Mais plus tard j’ai compris l’importance du Sprint Zéro dans l’organisation où je travaille. Je ne prétendrai pas que toutes les équipes en ont besoin, mais voici pourquoi c’est utile pour nous.
Les questions abordées au Sprint Zéro s’appliquent à la release toute entière.
Nous pourrions l’appeler Sprint Initial, Itération Zéro, ou Sprint de démarrage.
Selon mon expérience, le Sprint Zéro est limité dans le temps à seulement une semaine.
Notre équipe passe en revue l’ensemble des items de la release et quel travail devrait être achevé dans chaque sprint. En passant en revue chaque article de sprint, l’équipe identifie les endroits pour lesquels nous ne connaissons pas suffisamment bien les exigences qu’elles soient matérielles, d’architecture, logicielles, ou techniques.
Après que l’équipe ait revu les épics (ndlt. groupe de User Stories pour fournir une valeur métier) et fonctions priorisés de l’arriéré de produit, nous devons les annoter et préparer les sessions de revue avec le product owner, le propriétaire de produit. Nous devons comprendre l’environnement et le code exigé pour les items de l’arriéré de produit, indépendamment de si le code sera simple ou complexe.
Comment décomposer les niveaux d’exigence Agile (précédent billet à relire)
La raison principale d’introduire un Sprint Zéro est que nous ne voulons pas inutilement prolonger le temps nécessaire aux sessions de revue ou de transfert de connaissance depuis le Sprint 1 jusqu’à la fin. Donc, nous prenons une semaine pour préparer notre équipe avant de démarrer sur des arriérés de sprint.
Grâce à Agile, on nous donne l’opportunité d’en apprendre beaucoup en peu de temps.
L’équipe avancera de façon calme, sans pression excessive.
CertYou est partenaire de DantotsuPM
Utilisez-vous un sprint 0 en début de release sur votre projet Agile? Pourquoi? Quels en sont pour vous les bénéfices et inconvénients ?
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Un défi usuel auquel sont confronté les équipes Scrum inexpérimentées est lié au découpage des « User Stories » (dans Scrum, les articles du Product Backlog) pour qu’elles soient suffisamment granulaires pour le développement. Le modèle INVEST est une bonne façon de tester si les « User Stories » sont bien écrites.
Microsoft est partenaire de DantotsuPM
I.N.V.E.S.T.
I – Indépendante
N– Négociable
V– de Valeur
E – Estimable
S – Suffisamment petite
T – Testable
Indépendante
Chaque « User Stories » doit être indépendante l’une de l’autre. Ceci empêche les chevauchements entre les items; de plus, cela permet à l’équipe de les implémenter dans n’importe quel ordre.
Négociable
Les détails du travail doivent être négociables, tant parmi les parties prenantes que l’équipe. Les besoins spécifiques et décisions de conception seront étoffés pendant le développement. Beaucoup de praticiens agiles recommandent d’écrire les « User Stories » sur une petite fiche – ceci est intentionnel pour qu’une quantité limitée de détails puisse être prescrite.
de Valeur
Chaque « User Stories »doit ajouter un valeur métier/business au produit, au client et/ou à l’expérience des utilisateurs.
Estimable
Une bonne « User Stories » peut être suffisamment bien comprise par l’équipe pour qu’ils puissent l’évaluer – pas précisément – mais qu’à un haut niveau ils en perçoivent la taille. Il est utile de comprendre l’effort relatif en comparaison d’autres « User Stories ».
Suffisamment petite
Une « User Story » n’est pas assez petite si l’équipe ne peut pas la faire faire dans un seul Sprint. Comme des grandes « User Stories » sont divisées en items plus petits, la clarté sur la taille et la mise en œuvre est plus grande, ce qui améliore la probabilité que l’équipe le réalisera en un Sprint.
Testable
Chaque « User Story » devrait être testable; ceci est une caractéristique commune de tout besoin bien écrit. Si l’équipe ne peut pas déterminer comment la « User Story » peut être testée, c’est une indication que la fonction désirée ou la valeur business désirée ne sont pas assez claires.
Découpage vertical ou horizontal
Il y a deux manières communes de découper des « User Stories » : verticalement ou horizontalement. La découpe horizontale divise l’article au niveau d’un composant architectural. Exemple : Interface Utilisateur, bases de données ou services back-end. Tandis que, une découpe verticale aboutit à un résultat logiciel démontrable qui ajoute de la valeur au business. Donc, on recommande de découper verticalement les « User Stories » afin de réduire les dépendances et améliorer la capacité de l’équipe à livrer un incrémentent de produit potentiellement utilisable à chaque sprint.
Des exemples de découpe de « User Stories »
Trop grosse User Story: « En tant que client, je peux payer ma commande pour recevoir les produits »
En tant que client, je peux payer ma commande pour recevoir les produits
Si la susdite histoire devait être divisée de façon verticale, elle pourrait se décomposer en fonction des façons de payer pour un client comme suit…
En tant que client, je peux faire un paiement par carte pour ma commande et collecter des points de récompense sur ma carte de crédit.
Et/ou
En tant que client, je peux faire un paiement PayPal pour ma commande pour que achever mon achat en toute sécurité sans partager les détails de ma carte de crédit avec un autre détaillant.
Le point clé de noter dans les « User Stories » verticalement décomposées comme ci-dessus consiste en ce que chaque « User Story »passe les tests INVEST mentionnés plus tôt et donc un Propriétaire de Produit (Product Owner) peut prioriser ces « User Stories » en fonction des besoins clients. Cependant, si une approche horizontale a été utilisée pour diviser la « User Story » (c’est-à-dire décomposition selon les couches et composants architecturaux) alors la mise en œuvre de tels besoins aboutira à une fonctionnalité utilisable Seulement quand tous les composants horizontaux seront finalement livrés et intégrés.
Découpage par flux de travail
revoir mon panier de courses
Une autre approche souvent utilisée sur les « User Stories » est de se concentrer sur les étapes individuelles qu’un utilisateur peut entreprendre pour atteindre son objectif final. C’est-à-dire une « User Story » qui décrit un long parcours ou « flux utilisateur » dans un système peut être décomposé selon les étapes qui en représentent les parties. En reprenant l’exemple précédent d’un client faisant un achat en ligne, la « User Story » peut être décomposée de la manière suivante :
Fournir mes informations bancaires
En tant que client, je peux passer en revue les articles que je veux mettre dans ma commande pour être confiant que je paye pour les bons articles.
En tant que client, je peux fournir mes informations bancaires pour ma commande pour recevoir les produits que j’ai achetés.
Recevoir une notification par SMS
En tant que client, je peux recevoir un avis de confirmation pour mon achat pour suivre et garder une trace de mon achat.
D’autres méthodes
Il y a de nombreuses autres méthodes qui peuvent être utilisées dans le découpage des grandes « User Stories » comme :
Visitez le blog Agilistic
par déroulement heureux / malheureux (ce qui se passe quand tout va bien versus quand il y a des exceptions, déviations ou autres problèmes)
par options d’interaction / par plate-forme
par types de données ou paramètres
par scénarios de test
par rôles
par ‘j’optimisemaintenant ‘ contre ‘ j’optimise plus tard ‘
par compatibilité de navigateur
la liste ci-dessus est détaillée (en anglais) dans ce billet: Blog.agilistic.nl.
Pourquoi le responsable de programme, chef de projet que je suis va passer une certification sur l’Analyse Métier et en l’occurrence PMI-PBA® : Professional in Business Analysis de PMI (Project Management Institute) ?
1. Mon parcours
Si j’ai fait de l’Analyse métier au début de ma carrière (à l’époque nous utilisions MERISE !), que ce soit en ayant le titre de chef de projet ou consultant et si mon poste actuel au sein de HSBC Private Bank Swiss SA est « Senior Business Analyste », la plupart de ma carrière dans la banque privée suisse se déroule à des postes de Responsable de Programmes, Chef de Projets, Responsable de Département IT…
Et, enfin et surtout, en tant que Responsable Européen des Releases : je précise « surtout » car ce poste occupé pendant deux ans m’a permis de constater de nombreux errements quant à la gestion des exigences, qu’elles soient fonctionnelles ou non fonctionnelles. Et cela coûte cher et ajoute des risques quand nous devons « sortir à la dernière minute » des livrables non acceptables par le client car mal ou pas complètement analysés.
Tout le monde connait cette illustration sarcastique du produit livré ne correspondant ni aux attentes du client ni à la réalité de ces besoins. Mais c’est si vrai ! Ce serait une des raisons pour laquelle l’Analyse Métier s’est professionnalisée.
C’est aussi une des raisons de l’émergence de l’agilité.
A ce propos, je me rappelle une anecdote de mon début de carrière, en 1988. Je travaillais sur la conception d’une nouvelle plateforme bancaire à Genève en utilisant MERISE au sein d’un gros projet : jeune analyste métier, je rédigeais des Spécifications Fonctionnelles Détaillées en étant contraint par les Spécifications Fonctionnelles Générales analysées précédemment par d’autres.
En discutant avec le métier je me suis aperçu que l’étape précédente avait été mal analysée et j’ai donc adapté mon analyse détaillée au besoin du métier. Je fus recadré par la Direction du Projet qui me demanda de respecter les contraintes de l’étape précédente même si cela allait à l’encontre de la satisfaction des besoins du métier ! Ma frustration est encore vivace !
2. Mon expérience de Release Manager Européen
Lors de ces deux années mon rôle fut de manager les livraisons coordonnées des différents projets livrés par les différents domaines du développement d’une banque privée genevoise dans un contexte européen.
Les livraisons étaient d’abord effectuées avec une fréquence trimestrielle, donc avec de nombreux livrables provenant de différentes équipes mais ayant des interdépendances.
Nous avons travaillé avec les acteurs de la gestion du changement, à savoir le métier, les architectes, la sécurité, le test et la production afin que l’entrée en release soit validée par ces acteurs pour éviter de découvrir quelques semaines avant la livraison des dysfonctionnements tels que :
le périmètre de la livraison est bien déterminé : fonctionnellement mais aussi géographiquement. Cela semble couler de source, mais pour des projets de petite taille (moins de 200 jours homme), j’ai constaté un manque de rigueur fatal à toute mise en production.
les architectes ont bien validé la solution.
la sécurité a été impliquée et que ses recommandations ont bien été mises en œuvre.
le support et la production ait pu donner leurs exigences non fonctionnelles à respecter avant toute mise en place.
Mais cela ne nous a pas empêché d’avoir à gérer des « sorties de release » suite à des analyses métier déficientes avec diverses origines :
Difficultés de l’analyse métier « à distance » par nos équipes offshores
Oubli d’interdépendances fonctionnelles ou géographiques
Normes de sécurité non respectées
Rejet par des utilisateurs non préparés (en termes de ressources et de formation)
Manque de stratégie globale de test sur des livrables différents mais interdépendants
3. L’Analyse Métier réussie, facteur clé de la réussite des projets
Une des raisons majeures des échecs dans les projets est la mauvaise définition des besoins :
Selon Carnegie, 25%-40% du budget des projets est utilisé par refaire à nouveau ce qui a déjà été fait … et que 70% – 85% de ces coûts de « re travail » sont dus à des erreurs dans la collecte des exigences métiers.
Selon le Gartner, 60 à 80% des échecs de projets peuvent être directement attribué à une mauvaise analyse des besoins ou exigences.
Il est donc important que le Responsable de Programmes, Chef de Projets, comprenne et maîtrise ce domaine, même s’il est sous-traité à des équipes d’Analystes Métier, afin de diriger au mieux cette activité primordiale de la gestion de projet et d’en gérer les risques.
Tout d’abord pour les mêmes motivations qui m’ont fait passer d’autres certifications :
Travailler sur des supports de cours en anglais et donc progresser dans ce domaine,
Réfléchir sur des concepts et outils que j’utilise au quotidien mais dont je peux utiliser l’amélioration,
Acquérir de nouveaux outils,
Rencontrer des personnes ayant les mêmes centre d’intérêts toutefois dans des domaines différents afin d’enrichir ma créativité.
Mais aussi :
Assurer une meilleure initiation des projets / programmes
Éviter d’avoir à retravailler des livrables du projet
Savoir déjouer les pièges de l’Analyse Métier à distance lorsqu’elle est déléguée à des partenaires éloignés comme en Inde, Chine ou Pologne, mais aussi quand une équipe centrale collecte des besoins pour différentes entités locales. Mon expérience m’a montré que les « Analyses Métier à distance » sont pleines de pièges à déjouer : autant anticiper !
Posséder une double compétence de plus en plus prisée pour des projets petits à moyens ou la réduction des coûts implique de savoir tout faire
S’assurer dès le début du projet que la collecte des exigences métier est intégrée dans un mécanisme de documentation des tests d’acceptation
Pour introduire de l’agilité, car le client a désormais le droit de changer d’avis … mais aussi car l’environnement incertain et instable requiert cette flexibilité accrue
Détails sur la certification PMI-PBA du PMI
Et enfin parce que l’analyse métier réussie est un facteur clé de succès du projet !
Je vous donne rendez-vous dans quelques semaines une fois la certification passée pour vous faire part de la rétrospective de mon expérience !
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
PMI recently launched a new practice guide on requirements management, which is available for free download for a limited time.
Requirements Management: A Practice Guide is a complementary document to the Project Management
Institute’s (PMI’s) foundational standards. This practice guide provides guidance for project and program managers
who are looking to further understand the components and importance of requirements management.
A Practice Guide is for your individual use only. It may not be shared, copied or otherwise distributed further without written permission from Project Management Institute. All rights reserved.
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous avez un portefeuille de projets. Certains projets changent totalement les règles du jeu. Certains sont sous les feux de la rampe. Certains sont plutôt exploratoires. Pourquoi ne pas essayer de les positionner sur le modèle de Kano Noriaki ci-dessus et voir ce que vous pouvez en apprendre ?
« Sur la base de cette nomenclature, quatre zones-fonctions (Indifférence, basique, performance, excitant) sont repérées sur le graphe ci-dessus (en anglais) qui comporte deux axes :
L’axe vertical représente le niveau de satisfaction : En bas, le moins satisfait (dissatisfied), En haut, le plus satisfait (satisfied)
L’axe horizontal représente la prise en compte des attentes : À gauche faible couverture (Need not fullfilled), à droite forte couverture (Need well fullfilled) »
Partenaire de DantotsuPM
Peut-être devriez-vous changer de votre pondération d’investissement. Peut-être êtes-vous incertains de la profondeur de fonctionnalités ou la qualité d’un projet et devrez le détailler davantage.
J’aimerais entendre vos commentaires lorsque vous aurez réalisé cet exercice…
partagez ce billet avec vos amis, collègues et relations professionnelles
Personal comment: While this report is interesting, I wish it would dive deeper next time into how the Agile principles can help address some situations where the fuzziness of the business requirements is high.
Learn more about the struggles faced by organizations and the way forward in the latest Pulse report.
The report identifie 2 key skills to develop !
partagez ce billet avec vos amis, collègues et relations professionnelles
Stephen Carver, conférencier à Cranfield, a dirigé un groupe de travail interactif sur le management des exigences de projet et il est parvenu à d’excellentes conclusions en pensant hors des chemins habituels ! Son analogie entre l’aviation et le management de projets et de programmes est particulièrement pertinente et je suis certain que vous saurez en faire bon usage.
Alors, vous entez-vous davantage pilote de ligne, de chasse ou plutôt contrôleur aérien envers les projets que vous managez ?
partagez ce billet avec vos amis, collègues et relations professionnelles
Cependant, le résultat final va typiquement au-delà du détail et de la spécificité d’exigences traditionnelles. Quand de grandes exigences ne sont pas spécifiques, elles sont typiquement décomposées en plusieurs histoires utilisateur en Agile, dont chacune fournit une fonctionnalité spécifique et peut être plus facilement produite.
Avec une mentalité de prototypage, des fonctionnalités Agiles peuvent être évaluées par des utilisateurs avant leur mise en œuvre. Quand cela ne peut pas être fait directement, par exemple, quand un processus commercial totalement nouveau est créé, l’association développeur-utilisateur utilisée pour construire les fonctionnalités Agile réduit le risque de livrables ne réussissant pas à atteindre des objectifs business mesurables.
Le classement par taille de fonctionnalité et la priorisation assurent que la faisabilité est régulièrement évaluée. Les fonctionnalités sont examinées pour leur intégrité et capacité à être produites en un sprint. De plus grandes fonctionnalités sont décomposées en morceaux qui sont plus facilement créés, augmentant la faisabilité.
Bien que cette approche de gestion des délais ne soit pas parfaite, les fonctionnalités qui exigent plus de temps que prévu à développer sont réévaluées et reportées aux sprints suivants comme décidé au sein de l’équipe Agile.
J’ai souvent rencontré des équipes qui aiment les longues
Transparence : Des histoires courtes fournissent une transparence et une visibilité beaucoup plus claire des progrès dans le sprint pendant le 
DantotsuPM.com 
