4 façons d’améliorer votre processus d’estimation de projet

Le processus d’estimation de projet est le fléau de l’existence nombreux managers de projet. Mais c’est aussi et surtout l’opportunité d’avoir des conversations vraiment importantes sur le projet.

https://thedigitalprojectmanager.com/improve-project-estimation-process/ par Galen Low

Parlons estimations.

Le processus d’estimation de projet est le fléau de l’existence de nombreux managers de projet. Ce n’est pas seulement qu’il est sous haute pression, bousculé et souvent fait sur un coin de votre bureau. C’est aussi que vos efforts sont généralement ramenés à un compromis qui n’est presque jamais précis ou idéal.

Mais une chose que j’aime dans le processus d’estimation, c’est l’opportunité qu’il crée pour que des conversations vraiment importantes fassent surface.

Tout au long de ces conversations, vous imaginez le meilleur et craignez le pire. Vous faites des plans dont vous savez qu’ils changeront et résistez à prendre des engagements autour de choses que vous ne pouvez pas encore clairement voir. Vous examinez les projets passés et votre vision de l’avenir de l’entreprise.

En fait, je crois que chaque conversation sur l’estimation est une opportunité de parler de processus, de qualité, de vision et de valeurs.

Si vous avez trouvé que le processus de collecte et de revue des estimations est un peu épuisant et chronophage, essayez ces conseils pour rendre le processus plus gratifiant, moins mécanique et peut-être même un peu amusant.

#1 – Passez moins de temps à estimer seul et plus de temps à discuter des estimations

L’estimation des coûts signifie un certain temps passé tête baissée sur votre clavier, mais il ne sert à rien de créer une estimation parfaite si elle ne s’intègre pas au reste du contexte.

Enseignez à votre équipe de projet à poser des jalons qu’ils peuvent ensuite affiner par la discussion. Cela aidera tout le monde à avoir une vue d’ensemble et à mieux comprendre les métiers respectifs des membres de leur équipe.

#2 – Faites-en un processus créatif et ne mettez pas un pistolet sur la tempe de qui que ce soit

Manager l’ambiguïté est la pierre d’achoppement la plus courante pour les personnes à qui l’on demande de créer une estimation des coûts du projet. La deuxième pierre d’achoppement la plus courante est la peur de produire une estimation inexacte. Utilisez votre rôle de PM pour maintenir la conversation quelque part entre l’essentiel et l’idéal en documentant les hypothèses, en réitérant les contraintes et en posant des questions difficiles.

#3 – Éduquez vos clients et sponsors

Que ce soit à travers des faits concrets ou des métaphores comme la construction d’une maison ou la préparation d’un café, assurez-vous de ne pas survendre ce qu’est une estimation de projet.

Établissez des attentes selon lesquelles elle devra être affinée lorsqu’on en saura plus, qu’elle est sujet à changement et que le budget du projet devra être géré ensemble de manière proactive.

#4 – Ne présumez pas que vos données historiques sont un raccourci viable

passé, présent et avenir
Les performances passées sont utiles à connaitre mais elles ne prédisent pas l’avenir.

Vous pouvez consulter toutes les feuilles de temps de 5 derniers projets similaires, mais cela ne vous sera utile que si vous prévoyez d’utiliser exactement le même processus qu’un projet précédent et que vous avez également une compréhension claire des variables qui réduiront ou incrémenteront l’effort. Vous pouvez certainement augmenter la précision et réduire le temps passé à estimer, mais pas sans faire le travail de terrain à l’avance !

Ce dernier point est probablement le plus important parce que beaucoup d’entre vous pourraient se demander:

Quel est l’intérêt de rendre le processus d’estimation gratifiant si nos estimations sont toujours fausses ?

Eh bien, je dirais que les conversations autour de l’estimation mènent à des conversations sur les processus, qui mènent à des conversations sur les données.

Et cela conduit à une base de travail pour des estimations plus cohérentes et précises.

Visitez le site de notre partenaire Virage Group

Comment ré-estimez-vous les histoires utilisateurs inachevées lors d’un sprint avec l’approche Scrum ?

Lorsque le travail n’est pas terminé dans le sprint, que faites-vous ?

When Work Isn’t Finished In the Sprint, What Do You Do? par Joel Bancroft-Connors

https://resources.scrumalliance.org/Article/re-estimate-unfinished-stories?utm_campaign=practical-agility&utm_medium=dantotsuPM

Est-ce que vous ou votre équipe avez déjà dit :

« Nous n’avons pas terminé tout le travail de ce sprint. Nous allons découper l’histoire afin d’obtenir du crédit pour le travail que nous avons déjà réalisé. »

« C’est fait à 90%, il faut juste le tester. Passons de 13 points à 1 point pour le prochain sprint. »

« Wow, c’est bien plus que 5 points. Nous aurions dû en faire un item à 13 points. »

« Nous n’avons pas terminé ces quatre histoires, nous allons simplement les reporter au prochain sprint. »

« C’est fait, il faut juste le tester. Créons une nouvelle histoire juste pour ça et marquons celle-ci comme terminée. »

J’entends ces phrases et d’autres similaires tout le temps. L’estimation, dans des circonstances normales, est difficile. Ensuite, tenez compte de ce qu’il faut faire lorsque vos estimations étaient « fausses » et que cela devient carrément désordonné. Ces exemples sont les raisons et les scénarios les plus courants que j’entends lorsque les gens posent des questions sur la réestimation du travail.

Alors, comment ré-estimez-vous le travail inachevé ?

Réponse courte : Je ne le fais pas.

Je ne ré-estime jamais le travail qui n’est pas terminé. Il n’a pas répondu à la définition de Done et retourne dans le l’arriéré de produit (le « backlog produit ») où il pourra être pris en compte pour le prochain sprint.

L’estimation ne change pas parce que nous avons commencé ou que c’est plus difficile que nous le pensions, et nous n’obtenons aucun crédit pour un travail qui n’est pas « terminé ».

En tant que « sauveteur » chef de projet, j’aime beaucoup la simplicité de la définition de Fait (Done) (les mesures de qualité requises pour le produit). Comme le binaire n’est qu’une série de 1 et de 0, la définition de Done n’a que 2 états, « Done » et « Not Done ».

À la fin du sprint , nous examinons chaque élément du backlog produit et nous nous demandons : « Est-ce que cela répond à la définition de Done ? » Si la réponse est oui, elle va à la revue du sprint. Si la réponse est non, cela retourne dans l’arriéré de produits.

« Not Done » est également très précis : l’élément de l’arriéré de produit n’est pas utilisable et ne génère donc aucune valeur. Cela retourne dans l’arriéré de produits et je le traite comme si aucun travail n’avait été fait. C’est dans l’arriéré de produit et vous le traitez comme n’importe quel autre élément du backlog. Il a juste l’avantage de plus de « préparation ».

Pourquoi ne ré-estimez-vous pas ?

C’est une bonne question. Il y a un certain nombre de raisons de traiter un item « Not Done » comme n’importe quel autre élément de l’arriéré de produit.

Doit être utilisable

La première raison vient directement du Guide Scrum. « Afin de fournir de la valeur, l’incrément doit être utilisable. » Je ne divise pas une histoire juste pour obtenir un crédit partiel. Si j’avais pu le diviser en un travail plus petit et qu’il était encore utilisable, j’aurais déjà dû le faire en guise de préparation. Nous nous concentrons sur les résultats (la valeur) et non sur les livrables (le travail accompli).

Le code pourrit

J’ai appris cela d’un développeur expérimenté il y a des années. Même dans les environnements où la « production » ne change que tous les six mois, la base de code peut changer beaucoup en une semaine. Lorsque le travail a commencé sur la nouvelle interface de connexion, les environnements étaient à l’état X. À la fin du sprint, les environnements étaient à l’état Y et lorsque nous avons finalement terminé l’interface de connexion, deux sprints plus tard, les environnements étaient à l’état Z. J’ai vu du travail qui répondait à la définition de Done dans le sprint précédent planter le système construit parce qu’il n’a été déployé que quatre semaines plus tard. « Il faut juste le tester », est probablement tout en haut avec « qu’est-ce qui pourrait mal tourner? » dans les déclarations qui précèdent la catastrophe.

Ne prenez pas de raccourci

Ceci est étroitement lié à la pourriture du code. Si le travail n’est pas terminé dans le sprint, je ne le reprends pas dans le sprint suivant comme si rien n’avait changé. Je prends toutes les tâches (qui ne sont pas Done) et les ramène à « à faire » (To Do). Lorsque je reprends le travail, je valide à nouveau tout le travail. Non seulement le « code pourrit », mais vous avez peut-être appris quelque chose de nouveau, avez une nouvelle approche, quelqu’un d’autre a fait le travail. En revenant au tout début, vous vous assurez que rien n’a été manqué et que la qualité reste élevée.

Le tout s’équilibre

Cela entre en jeu à la fois avec un travail qui est « presque terminé » et un travail qui est « ouh la la ! C’est beaucoup plus gros que ce que nous pensions ». Vous allez reprendre un travail qui a été entrepris dans un sprint précédent et qui était à 1 point d’effort de finir, et vous allez également prendre un travail qui finira par nécessiter trois fois plus de travail que prévu, et à long terme, le tout s’équilibre. La loi des grands nombres nous dit essentiellement que, au fil du temps, le nombre d’éléments surestimés s’équilibrera avec le nombre de sous-estimés.

Ne le faites pas

Si cela n’a pas été fini dans le sprint, profitez-en pour examiner le travail à nouveau. Commencez par les critères d’acceptation. Sont-ils trop vagues ? Peut-on y répondre par oui ou non ? Regardez au-delà de cet élément de l’arriéré pour avoir une vue d’ensemble. L’équipe prend-elle trop de travail, cet élément dépendait-il d’un autre élément, y a-t-il une difficulté avec la définition de Done ?

Enfin, profitez-en pour poser la question suivante

Devrions-nous encore faire ce travail ?

Chaque sprint est une opportunité d’inspection et d’adaptation. Une partie consiste à examiner tout ce qui se trouve dans l’arriéré de produit et à vous demander si cela soutient toujours l’objectif du produit.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

La 3ème version de l’ouvrage de référence des Business Analystes est traduite en français.

Le BABOK V3 en Français est depuis peu disponible.

Le Guide du Business Analysis Body of Knowledge ® (Guide BABOK®, Guide du corpus de connaissances de l’analyse d’affaires) représente une norme reconnue à l’échelle mondiale pour la pratique d’analyse d’affaires.

Le Guide BABOK® décrit les domaines de connaissances de l’analyse d’affaires ainsi que les activités, les compétences fondamentales, les techniques et les perspectives sur la manière d’approcher l’analyse d’affaires.

Ouvrage sur Amazon
Association professionnelle internationale pour les Business Analystes (Chapitre de la Suisse romande - IIBA®)

Si la Business Analysis vous intéresse, découvrez la chaine YouTube de IIBA® Geneva

IIBA® Geneva, le chapitre suisse romand de l’International Institute of Business Analysis, organise un congrès annuel, des groupes d’étude du BABOK, des ateliers mensuels de business analyse et depuis peu une Chaîne YouTube IIBA Geneva 

Vous pouvez désormais trouver l’enregistrement de tous les ateliers sur cette chaîne YouTube.

Vous y trouverez également des enregistrements des conférences et des interviews avec des business analystes réalisés lors du congrès annuel.

Voici un exemple avec « Développer son Intelligence Emotionnelle » qui est particulièrement pertinent pour les managers de projets aussi bien que les business analysts.

Comment nous interagissons et travaillons ensemble est essentiel. Les personnes ne se soucient pas de ce que vous savez jusqu’à qu’elles sachent que vous vous souciez d’elles. Grâce à l’intelligence émotionnelle, nous construisons la confiance qui nous unit, devenons de meilleurs collaborateurs, des catalyseurs du changement et apprenons à mieux affronter l’adversité.

Abonnez-vous afin de suivre aisément IIBA® Geneva

FDF est partenaire de DantotsuPM

Si vous souhaitez devenir analyste business ou êtes déjà un Business Analyst, sachez que IIBA® France est en pleine évolution

Des nouveautés chez International Institute of Business Analysis™ (IIBA®) France, l’association professionnelle des business analystes ou analystes d’affaire.

L’examen de certification est désormais accessible en ligne

Bonne nouvelle en cette période de confinement, il est désormais possible de passer les examens de certification derrière son ordinateur. Seule contrainte, disposer d’une webcam pour permettre le contrôle à distance de l’identité du participant et de l’absence d’aide extérieure.

A noter que le passage des certifications continue de se faire en anglais.

Le BABOK v3 en Français !

Détails et vidéo

Si vous préférez le terme d’analyste d’affaire en lieu et place de son homologue anglo-saxon « Business Analyst« , vous attendiez avec impatience le BABOK V3 en version française. Ce dernier sera très prochainement disponible gratuitement pour les membres de IIBA sur le Bookstore.

Du nouveau sur LinkedIn

Page officielle IIBA France Chapter et groupe IIBA Francophone

Pourquoi devriez-vous prendre le temps d’écouter vos utilisateurs ?

Bien que les besoins des futurs utilisateurs soient parfois difficiles à accoucher et demandent du temps, leur bonne compréhension est la clé de la réussite du projet.

Si vous n’avez pas le temps de discuter d’un besoin utilisateur (ou d’une user story en mode Agile/Scrum), vous n’aurez probablement pas plus le temps de le réaliser.

CertYou est partenaire de DantotsuPM

Valeur élevée plutôt que faible prix ou coûts réduits… dans vos projets aussi !

Valeur élevée

High value

https://seths.blog/2018/09/high-value  par Seth Godin

… n’est pas la même chose que prix bas.

Le prix est évident. On peut le voir de loin. Mais la valeur est plus subtile. Elle doit souvent être vécue pour être comprise.

Le prix est le même pour chaque personne qui achète cet article. La valeur est différente pour chacune.

Le prix bas est le dernier refuge pour les spécialistes du marketing qui n’ont pas la patience ou les tripes de démontrer la valeur pour ceux qui ont ce besoin.


Voici un billet de Seth qui donne aussi à réfléchir pour les managers de projets

Faisons-nous clairement dans les projets la nécessaire distinction entre coûts faibles et valeur élevée ?

Réaliser le projet à bas coûts pour produire le livrable pas trop cher est plus facile que d’aller chercher les budgets et délais nécessaires pour construire le produit que les clients s’arracheront.

L’analyse de la valeur perçue par le client, la Business Analysis et le Design Thinking ne sont-ils pas justement de bons outils pour trouver ce qui réellement apporte de la valeur au client, à l’utilisateur, au sponsor et à toutes les parties prenantes ?

Le cas d’affaire ou business case ne cristallise-t-il pas cette proposition de valeur pour les clients et futurs utilisateurs ?

Tout ceci fait partie de la définition des bénéfices attendus du projet puis du management de la réalisation de ces bénéfices.

Enfin, nous questionnons-nous suffisamment sur le portefeuille de projets en lui-même: « Faisons-nous les bons projets ? »
Hexagon est partenaire de DantotsuPM

Certes il faut apprendre à dire NON, mais ce n’est pas toujours la meilleure approche dans le management de projet.

Négocier sur le séquencement des livrables est souvent préférable à dire non d’emblée à une nouvelle demande de changement.

Idem au niveau du portefeuille de projets

Est-ce le bon moment pour lancer un nouveau projet ? Devrions-nous renoncer à un projet ? Ou devrions-nous temporiser un peu et positionner ce projet dans le portefeuille de projets à venir ?

Hexagon est partenaire de DantotsuPM

Commençons bien l’année, faisons un peu de ménage dans notre « product backlog » !

Je ne sais pas pour vous, mais j’ai remarqué que nous indiquons rarement une date ou raison de péremption sur nos besoins utilisateurs et autres user stories…

Hors, il n’est pas si rare qu’après une certaine date, jalon projet ou événements internes ou externes, certains des besoins précédemment exprimés (et toujours en attente dans le product backlog) ne soient plus d’actualité.

Qu’en pensez-vous et comment traitez-vous ce problème ?

Est-ce en amont, en indiquant sur la user story une date ou les raisons pour lesquelles elle pourrait devenir inutile ?

Est-ce périodiquement lors de grands « ménages » saisonniers ?

Ou bien, serait-ce plutôt de manière opportuniste, lors par exemple d’un changement d’application de gestion du product backlog ? Ou d’arrivée d’un nouveau product owner, scrum master… ?

CertYou est partenaire de DantotsuPM

CertYou, spécialiste des certifications, renouvelle son partenariat avec DantotsuPM !

Olivier Boisne, responsable pédagogique, me confirmait récemment sa volonté de poursuivre notre partenariat pour une cinquième année !

CertYou est devenu le centre numéro 1 en volume en France pour la formation PMP® et propose régulièrement les formations PfMP® et PgMP® tellement difficiles à mettre en place !

Partenaire de DantotsuPM

Au niveau de la business analyse, la certification CBAP® de IIBA a le vent en poupe !

En dehors du management de projets, ITIL® continue d’être adopté par de plus en plus d’organisations et les professionnels passent de multiples certifications.

pour identifier les besoins de vos clients, une pile de documentation n’est jamais aussi efficace qu’une bonne discussion collaborative.

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é.

Aimeriez-vous être davantage apprécié(e) dans votre organisation en tant que manager de projet ?

Le secret est d’apprendre à bien communiquer avec vos dirigeants.

Want To Be Valued as a Project Manager?  par Gina Abudi

regarder vers le basIl y a tant de managers de projet qui me disent qu’ils ne sont pas estimés même avec tout le bon travail qu’ils réalisent. Ils/Elles respectent les délais des projets, tiennent les budgets, prennent en charge des projets apparemment « impossibles » et gardent toujours le sourire.

Je leur réponds… …bien sûr que non !

On attend tout ceci de vous ! Et c’est très bien que vous puissiez le faire.

Vous voulez démontrer votre valeur de manager de projet ?

Apprenez à communiquer “vers le haut de l’échelle !

Le « Business Acumen » ou compréhension du business est un pré-requis si vous voulez que votre valeur soit reconnue par l’organisation. Définissons un peu le sens du business.

Selon Wikipedia, C’est un concept se rapportant à la connaissance et à la capacité d’une personne de prendre des décisions business rentables.

Pensez-y comme la capacité de voir le business depuis d’autres angles et perspectives. Pensez aux entrepreneurs que vous connaissez et qui réussissent. Ils/elles ont le sens des affaires. Ces leaders comprennent comment voir leur activité sous tous les angles, développer leur stratégie et la mettre en œuvre . C’est aussi ce dont vous devriez être capable en tant que manager de projet.

Pratiquement tous les managers de projet sont impliqué(e)s dans de nombreuses facettes du business simplement de par la nature transverse de leur rôle dans l’organisation. Alors en quoi tout cela a-t-il un rapport avec la communication avec les dirigeants ?

Les leaders de l’organisation connaissent le business de A à Z !

Vous avez besoin de faire de même !

Vous devriez connaître les réponses aux questions suivantes sur votre organisation :

  • résultatsQuels sont les produits et services principaux et quelle est la cible visée par ces produits et services ?
  • Quels sont les objectifs stratégiques à long terme de l’organisation ?
  • Qui sont les concurrents et comment votre organisation se compare à eux ?
  • Comment vos projets permettent-ils de supporter l’atteinte des objectifs de revenus de votre organisation ?
  • Votre industrie est-elle en croissance ou en stagnation ?
  • Quel est le potentiel de croissance de votre organisation ?

En sachant répondre à ces questions, vous êtes mieux placé(e) pour donner des conseils, suggérer des projets qui devraient être sélectionnés pour atteindre les objectifs organisationnels, devenir un conseiller auprès de l’équipe de direction.

Pensez à combien cela facilitera votre travail avec les parties prenantes et dans la motivation de l’équipe projet.

Qu’en pensez-vous ? Combien de ces réponses connaissez-vous ? Savez-vous comment aller chercher les réponses que vous ne connaissez pas encore ?

Mettez au point votre plan dès aujourd’hui sur comment vous développerez votre sens du business.

Prenez-en la ferme résolution et vous ferez un grand pas vers les rôles de direction et de leadership !

Avez-vous déjà entendu parler de la technique Agile dite des « Tres Amigos »

Three Amigos

https://www.agilealliance.org/glossary/three-amigos par Alliance Agile

Les trois amigos se réfèrent aux 3 perspectives de base pour examiner un incrément de travail avant, pendant et après le développement.

Les 3 perspectives

  1. The 3 Amigos is an Agile technique to balance between no collaboration between people with different perspectives and involving an entire team in discussing all the details of every increment of work.

    Business – Quel problème essayons-nous de résoudre ?

  2. Développement – Comment pourrions-nous construire une solution pour répondre à ce problème ?
  3. Test – Qu’est-ce qui pourrait possiblement se produire ?

Les gens qui tiennent ces différentes perspectives devraient collaborer pour définir que faire et convenir comment ils sauront quand cela sera réalisé correctement.  Le résultat final d’une telle collaboration aboutit à une description plus claire d’un incrément de travail souvent sous forme d’exemples, menant à une compréhension partagée pour l’équipe.

C’est aussi la bonne pratique pour les autres. Ils devraient eux aussi passer en revue depuis chacune de ces différentes perspectives les incréments du produit qui ont été mis en œuvre pour s’assurer qu’ils sont corrects.

Le concept des trois amigos a pour objectif de trouver un point d’équilibre entre aucune collaboration entre les personnes qui ont des perspectives différentes et impliquer toute l’équipe dans la discussion de tous les détails de chaque incrément de travail.

CertYou est partenaire de DantotsuPM

Une bonne compréhension mutuelle est à la base de tout projet réussi

Comprendre les parties prenantes du projet et leurs besoins, mais aussi, ceux du sponsor de projet, des donneurs d’ordre, des utilisateurs finaux et des membres de l’équipe projet.

Une meilleure compréhension des autres est à la base du projet qui se donne une chance de réussir.

Méta Projets Management est partenaire de DantotsuPM

apprendre à utiliser les cartes d’empathie permet de construire de meilleures solutions

Use Empathy Maps to build better software

https://blog.agilistic.nl/understand-your-users-with-an-empathy-map/ par Christiaan Verwijs

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.

Une recherche Google ramène beaucoup de modèles différents, mais je trouve celui ci-dessous le plus pratique et complet : http://www.eventmodelgeneration.com/empathymap/

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.
  • eye openerEn 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.

Quelles sont les alternatives au Agile Planning Poker de Scrum ?

Alternatives to Planning Poker

https://www.extremeuncertainty.com/alternatives-planning-poker/ de leontranter

Le Planning Poker est une façon commune de réaliser l’estimation des points d’histoire utilisateur. Il présente quelques avantages, mais aussi quelques problèmes.

 

 

 

 

 

Qu’est-ce que ce Planning Poker ?

Le Planning Poker est souvent utilisé dans des équipes Scrum (bien qu’il ne soit mentionné nulle part dans le guide Scrum selon la croyance populaire). Mike Cohn l’a popularisé dans son livre “Agile Estimating and Planning“. C’est une technique d’équipe pour collectivement estimer les points d’histoires d’utilisateur. (Pas sûr de ce que cela signifie ? Lisez le « guide to story point estimation »).

Si vous êtes déjà familiers du Planning Poker, n’hésitez pas à sauter directement plus bas “la planification d’alternatives au Planning Poker”. Sinon, continuez de lire pour une explication de comment cela fonctionne et pourquoi les gens l’utilisent.

CertYou est partenaire de DantotsuPM

Comment fonctionne-t-il ?

Disons que vous avez une équipe de sept ou huit personnes, qui ont environ une douzaine d’histoires d’utilisateur dans leur arriéré de produit qu’ils voudraient estimer. Pour le faire via le Planning Poker, chaque personne dans l’équipe aura une certaine méthode pour fournir un chiffre. C’est d’habitude via un sabot de cartes de poker, mais vous pourriez aussi utiliser une app sur votre téléphone. Les chiffres sont d’habitude des nombres de la suite de Fibonacci, une série où chaque nombre est la somme des deux nombres précédents. Donc cela donne 1, 2, 3, 5, 8, 13, 21, et cetera (on ne va d’habitude pas dépasser 21 parce que les histoires d’utilisateur ne devraient jamais être beaucoup plus grandes que d’autres).

L’équipe prend la première histoire de la liste et en discute un moment. Souvenez-vous, une histoire d’utilisateur est écrite comme une déclaration de problème. L’équipe réfléchit ensuite à combien de travail il faudrait pour répondre à cette déclaration de problème, c’est-à-dire mettre en œuvre une solution qui réalise le comportement décrit dans l’histoire.

Estimation de Planning Poker

Une fois que l’équipe est prête à estimer, chaque personne choisit un numéro de son jeu de cartes. Ils le font en silence. Puis, chaque personne révèle son évaluation en même temps.

La raison de procéder ainsi est que l’évaluation d’une personne ne devrait pas influencer l’évaluation d’une autre. Si chaque personne fournit son évaluation à son tour, la première personne pourrait choisir une grande (ou petite) estimation, qui pourrait faire changer d’avis d’autres personnes et ainsi biaiser leur évaluation. Le processus est destiné à permettre à chaque personne de fournir sa propre évaluation impartiale et honnête.

Bien sûr, les valeurs sont souvent différentes, ce qui signifie qu’une autre discussion démarre. Il y a parfois alors un autre round d’évaluation. Quelques puristes de Scrum insistent pour que l’équipe continue les rounds d’évaluation jusqu’à ce que chacun arrive au même nombre. Je pense que c’est de la folie et que cela encourage ce que le planning poker devrait empêcher : les gens « forçant » d’autres à être d’accord avec leur évaluation.

Je pense que cela devrait continuer jusqu’à ce qu’un consensus soit atteint, ce qui est d’habitude très clair (et PAS la même chose que la conformité, c’est-à-dire quand chacun a la même valeur). S’il y a une gamme d’évaluations consistant de 2, 2, 3, 3, 5, 5, l’estimation est de 3. Cela ne doit pas être une moyenne exacte, mais une médiane suffit. Et cela ne doit pas être mathématiquement précis. Les évaluations sont essentiellement des suppositions informées. Le processus d’évaluation n’est pas précis donc les évaluations ne le seront jamais et c’est ok.

Alors, pourquoi chercher des alternatives au Planning Poker?

Vous pourriez vous demander pourquoi vous voudriez des alternatives à le Planning Poker. Ce n’est pas un mauvais système, mais il a quelques problèmes.

Il est lent

Cela peut prendre une longue période de temps pour faire l’évaluation avec le Planning Poker. J’ai vu des sessions de deux ou trois heures et ce n’est pas amusant. Montrer ces cartes est au départ amusant mais cela devient usant vraiment rapidement. Tergiverser sur savoir si quelque chose vaut 2 ou 3 est ennuyeux et irritant et ce n’est pas une conversation de valeur.

Il distrait

La discussion sur quelle carte est bonne ou fausse peut distraire les gens d’une conversation de plus de valeur : la discussion de la solution. Particulièrement, pourquoi quelqu’un estime que quelque chose mérite 2 ou 3 par opposition à une autre valeur.

Il peut donner une fausse impression des estimations

Certaines personnes pensent que si vous faites ce jeu intelligemment, alors les évaluations elles-mêmes deviennent soudainement plus précises et donc de plus de valeur. C’est complètement faux. Le Planning Poker est une bonne façon d’atteindre un consensus sur des évaluations. Cela ne signifie pas qu’elles soient précises. Il est très possible pour un groupe de personnes d’être dans l’erreur à propos de quelque chose (particulièrement quelque chose de notoirement difficile à évaluer comme la complexité de développement de logiciel).

Les alternatives au Planning Poker

Il y a quelques alternatives que vous pouvez essayer si vous vous fatiguez du Planning Poker, ou pensez que cela pourrait être mieux.

Classement par taille de t-shirt

Au lieu des nombres (Fibonacci ou autres, vous pouvez utiliser des tailles de T-shirt. Petit, moyen, large, extra-large. Cela vous donne une plus petite gamme d’estimations possibles, ce qui signifie que vous obtiendrez moins de désaccords et moins de variance. Vous pourriez penser que les évaluations seront moins précises, mais je ne pense pas qu’elles le seront. Je constate que les tailles de t-shirt sont suffisantes. Vous aurez besoin de quelques références pour ces tailles; utilisez simplement des histoires ou des fonctions précédentes. (J’aime en réalité faire des évaluations de taille de t-shirt et aucune autre estimation  d’histoire). Vous pourriez aussi utiliser un jeu plus réduit de nombres (1, 5, 8, 20) ou autre chose pour remplacer les tailles de t-shirt. Mais j’aime le fait que des nombres ne soient pas utilisés. Cela clarifie le fait que ce ne sont pas des mesures et elles ne sont pas précises.

Pour l’estimation précise, vous pouvez utiliser la technique du planning poker, ou la Technique « Affinity Mapping ».

Affinity Mapping

Vous pourriez être familiers avec la technique « Affinity Mapping » car elle est utilisée dans les Rétrospectives de Sprint. C’est une technique pour grouper ensemble des articles semblables. Commencez par créer une série d' »étiquettes » ou de « piles » sur la table : celles-ci pourraient être numérotés selon Fibonacci, ou les tailles de t-shirt, ou des catégories, ou quoi que ce soit. Puis, vous déposez les histoires sur la table comme des cartes. Ensuite, l’équipe déplace collectivement les cartes dans les piles pour les représenter selon leur estimation.

Petite Vidéo de Vincent Drecq, auteur du livre en français « Pratiques de management de projets ». 

 

 

 

Classement silencieux par taille

C’est une technique intéressante, peu commune et peu connue. C’est une manière efficace d’évaluer un grand nombre d’histoires dans un espace de temps très court. Commencez par définir vos points de référence (nombres de Fibonacci, tailles de t-shirt, etc). Créez des piles sur la table selon la technique « Affinity Mapping ». Ensuite, chaque personne est aléatoirement assignée un jeu d’histoires à estimer (peut-être en distribuant les histoires comme si elles étaient des cartes à jouer). Puis, à tour de rôle, chaque personne évalue en silence en plaçant une carte sur une des piles. Alternativement, une personne peut déplacer une carte d’une pile à une autre, si elle est convaincue qu’une estimation est incorrecte.

Continuez à faire ceci jusqu’à ce que toutes les cartes soient estimées. Si une carte est déplacée deux fois, ôtez-la de la table – elle aura besoin d’une discussion séparée après la réunion car il y a un fort désaccord sur son estimation.

L’avantage de cette technique est qu’une équipe peut évaluer beaucoup d’histoires en un très court laps de temps. A utiliser si l’on vous demande d’évaluer 100 histoires (même si je pense que c’est le signe d’un plus gros problème car vous devriez seulement évaluer un ou deux sprints d’histoires Utilisateurs à l’avance). L’inconvénient est que vous sautez ce qui est souvent la partie de plus de valeur : la discussion autour des histoires.

Aucune évaluation

D’autres personnes prennent une position plus extrême. Ils pensent que nous devrions nous débarrasser totalement des estimations ! C’est un mouvement qui est souvent identifié par le  hashtag Twitter #NoEstimates. Il a été lancé il y a quelques années par quelqu’un appelé Woody Zuil et est principalement soutenu par un coach Agile nommé Vasco Duarte. Si vous voulez l’essayer, c’est facile : n’abandonnez pas seulement le Planning Poker, abandonnez aussi toute estimation. Vous pouvez alors faire deux ou trois choses :

  • Donnez une évaluation moyenne sur toutes les histoires (utilisez une moyenne historique, total ou roulant la moyenne des trois derniers sprints)
  • Oubliez les points d’histoire et utilisez juste le nombre d’histoires pour la planification
  • Oubliez le planning d’histoires et estimez par fonctionnalité, utilisant probablement des tailles de t-shirt / le nombre de sprints.

En ce qui me concerne, je tombe dans le dernier camp. Je ne pense pas que les évaluations d’histoire sont très forte valeur, bien que des évaluations de haut niveau de fonctionnalités soient utiles pour la planification de release (et j’ai constaté qu’elles sont souvent aussi ou plus précises qu’une somme d’évaluations de point d’histoire).

 

#NoEstimates est un sujet complexe et très controversé et qui mérite une discussion séparée.

Conclusion

Vous pouvez essayer ces techniques et voir ce qu’en pense l’équipe. Assurez-vous de les considérer comme des expériences et recueillez-en les données: L’équipe estime-t-elle que c’est mieux que le planning poker ? Les évaluations se sont-elles avérées de plus de valeur ?

Rappelez-vous que la chose qui a le plus de valeur dans une session d’estimation est d’habitude les conversations autour de la solution, pas les nombres estimés.

une approche pour comprendre et appréhender la complexité grâce au modèle Cynefin

Understanding Complexity

https://www.scrum.org/resources/blog/understanding-complexity par Erwin Van der Koogh

Une des choses les plus importantes à comprendre dans le monde du business (et dans la vie en général) est le concept de complexité. Tandis que nous utilisons les mots compliqué et complexe presque de manière interchangeable dans le parler quotidien, ils signifient en réalité des choses très différentes. Explorons mon modèle favori sur la complexité : Cynefin.

Il existe un certain nombre d’articles et vidéos d’introduction à Cynefin, y compris celle de Dave Snowden, mais certains ne sont pas toujours très accessibles.

Essayons de l’expliquer avec des jeux. Richard Shy a créé une visualisation étonnante de Cynefin dans un de mes cours.

Quatre domaines  Cynefin

Cynefin parle de quatre types différents de problèmes ou domaines. Évident, Compliqué, Complexe et Chaotique. Nous aborderons ces premiers et couvrirons à la fin le Désordre.

Cynefin est une façon d’appréhender de quel type est un problème est et propose une stratégie de haut niveau pour résoudre ces différents types de problèmes.

1. Évident

L’analogie de jeu pour Évident est le Tic-Tac-Toe, aussi appelé « morpion ». Comme dans le Tic-Tac-Toe, les problèmes Évidents ont un lien de cause à effet clair et prévisible.

La stratégie de haut niveau pour résoudre des problèmes Évidents est « Observer  – Catégoriser – Répondre ». Observer n’est rien de plus complexe dans ce cas que regarder la grille. Catégoriser les moyens que nous avons de réduire toutes les combinaisons possibles en sous-ensemble beaucoup plus petit, gérable. Et Répondre faire un déplacement. Tic-Tac-Toe a 255,168 parties possibles, mais nous avons besoin de connaitre seulement quelques règles pour jouer la meilleure partie possible. Prenez le pion de départ, il devrait être placé dans un angle, n’importe quel angle fera l’affaire.

Nous répondons aux problèmes Évidents en choisissant la Meilleure Pratique appropriée. 

Nous avons regardé toutes les options possibles et calculé la meilleure voie. Ils sont appelés « Best », parce qu’il y a toujours exactement une meilleure réponse.

Le problème évident avec les problèmes évidents est que peu d’entre ceux restent sans réponse. C’est la substance qui est facilement automatisée. Les ordinateurs sont extrêmement précieux pour ce type de travail.

2. Compliqué

Maintenant, le Tic-Tac-Toe (les Morpions) est un jeu très ennuyeux précisément parce que nous l’avons calculé. Après, les meilleures pratiques vous feront jouer un jeu parfait. Si les deux joueurs jouent un jeu parfait il est un dessiné.

Les échecs sont très différents. Et notre stratégie de haut niveau pour des problèmes Évidents ne nous aidera pas le jeu d’échecs. Quelques mouvements dans un jeu d’échecs et le conseil sont dans une position vous ne l’avez jamais vu dans auparavant. Et plus important encore une différence minuscule dans le conseil fait une différence massive dans le jeu.

Dans des problèmes compliqués le rapport entre la cause et l’effet est prévisible, mais (très durement prévoir. Des problèmes compliqués sont le domaine d’expert, qui est meilleur capable de prévoir ce qui va probablement arriver. Qui est exactement quels joueurs d’échecs supérieurs font. Ils doivent prévoir ce que les mouvements probables de leurs adversaires vont être. Les experts peuvent simultanément considérer des options plus possibles, mais le réduire aussi à un jeu plus petit des scénarios qui exigent plus d’analyse.

Donc la stratégie devient le Observer – Analyser – Répondre. Et parce que c’est la figure impossible de si un mouvement est le meilleur mouvement (sauf la défaite évidemment) il n’y a aucune pratique la meilleure dans le domaine compliqué.

Mais il y a de bonnes pratiques. Les pratiques que l’on considère utile dans de certains contextes. Dans des échecs un exemple est la valeur de vos pièces. Chaque morceau dans des échecs fait associer une valeur avec cela. Et vous voulez toujours la valeur totale de vos pièces pour être plus haut que vos adversaires. À moins que vous ne vouliez que, parce que vous vouliez sacrifier un morceau pour la position de conseil.

3. Complexe

Les problèmes complexes sont à nouveau complètement différents. Ce qui les met à part est que le rapport entre la cause et l’effet est seulement évident de manière rétrospective. La métaphore de jeu pour la complexité est le poker. À la différence des échecs, qui sont un jeu de prévision, le poker est le jeu de l’étude. Apprendre quelles cartes vos adversaires ont et comment leurs mains se mesurent à la vôtre. Et la stratégie de haut niveau des échecs ne fonctionne pas pour le poker.

Si vous jouez ma version favorite de poker, le Texas Hold’em, vous pouvez regarder vos propres cartes jusqu’à en perdre le souffle, mais la seule chose que vous allez apprendre est que vos adversaires n’ont pas exactement les mêmes cartes que vous. Donc Sentir – Analyser – Répondre est éliminé comme façon de traiter la complexité.

Ce dont nous avons besoin à la place est Investiguer –Sentir – Répondre. Une investigation est une expérience sans risque. Selon le résultat de cette expérience (Sentir) nous répondons en amplifiant les bonnes et/ou réduisant les mauvaises (Répondre).

De nouveau, prenant l’exemple du poker, l’investigation peut prendre la forme d’une mise. Si vous déposer une mise vous forcez des adversaires à y répondre, en se couchant, répondant ou surenchérissant. Cela peut vous donner de l’information sur leur main. Mais d’autres investigations peuvent être d’attirer l’attention des adversaires, sentir peut être seulement regarder leurs comportements.

Donc la chose la plus importante de la Complexité est qu’il n’y a aucune façon d’apprendre (et ainsi résoudre le problème) sans faire. Réfléchir ne va pas résoudre le problème. Dans les problèmes Complexes, nos pratiques se développent toujours en se basant sur ce que nous apprenons. Dans le poker, même si nous jouerions une partie avec exactement les mêmes joueurs et exactement les mêmes cartes exactes, la partie serait différente. Parce que nous avons appris des choses pas seulement sur le jeu, mais aussi sur nos adversaires.

4. Chaos

Le chaos arrive quand il n’y a aucun rapport entre la cause et l’effet ou qu’ils changent très rapidement. Dans ce cas il n’y a aucune raison de réaliser des investigations parce qu’aucune étude ne nous aidera à nous améliorer.

L’analogie de jeu est ici le jeu d’enfants. Quelqu’un qui a déjà joué avec des gosses sait que les règles changent continuellement. Et il n’y a aucune raison d’essayer d’apprendre les règles avant le départ du jeu. Vous devez entrer et jouer avec eux (Agir), tout en vous assurant de l’amusement (Sentir) et en changeant en conséquence (Répondre).

Mais le plus souvent nous terminons dans le Chaos à cause d’une petite crise. Quand cela arrive nous devons très rapidement stabiliser la situation et ressortir du Chaos. Cela arrive tout le temps dans le business, où nous nous reposons fréquemment sur des leaders héroïques et des équipes spéciales pour nous sortir des problèmes.

Les pratiques sont ici Nouvelles.

Désordre

Le désordre n’est pas un domaine séparé, mais signifie au lieu de cela que nous utilisons le jeu de stratégies avec lequel nous sommes à l’aise au lieu de celles appropriées au problème à résoudre.

Et la malheureuse réalité consiste en ce que la plupart des personnes passent ici la plus grande partie de leur temps.

Je ne plaisante ni n’exagère pas quand je dis que comprendre Cynefin a changé ma vie.

Chaque fois que je me trouve (ou les gens autour de moi) à passer trop de temps à réfléchir, mon premier instinct est de prendre du recul pour m’assurer que le problème à traiter est Compliqué. Quand les organisations continuent à insister sur les Meilleures Pratiques, je vérifie d’abord si le problème est à portée de main en fait Évident. S’il est Compliqué (ce qui est très probable), nous devrions regarder une myriade de bonnes pratiques et calculer quelles pratiques sont applicables dans quelles circonstances.

Mais la leçon la plus importante est que bon nombre de nos circonstances sont complexes. Et ainsi en soi imprévisibles. Et aucune quantité de réflexion ne va les résoudre.

CSP est partenaire de DantotsuPM

La toute première édition du #PMI® Guide to Business Analysis est disponible en version anglaise

La Business Analysis est une compétence clé dans les projets

le guide pour les Business Analysts

Le domaine de la Business Analysis s’est énormément développé sur les dernières années au point que nombreux sont celles et ceux qui le considèrent comme un élément prépondérant dans les projets et programmes.

Les analystes business permettent de produire des descriptions de meilleures qualités des attentes des clients ainsi que de toutes les autres parties prenantes du projet.

Ce standard a pour but de devenir une fondation sur laquelle poser vos pratiques actuelles et les faire évoluer et s’améliorer. Cette base se veut compatible avec les différents types et tailles d’organisations, de domaines industriels et commerciaux ou administratifs.

Une version PDF gratuite est téléchargeable en ligne par tous les membres du PMI.

Bonne lecture et n’hésitez pas à postez vos remarques et commentaires ci-dessous.

PMI is a registered mark of Project Management Institute, Inc.

vous ne trouverez jamais les bonnes réponses si vous posez les mauvaises questions !

You’ll Never Find the Right Answers If You’re Asking the Wrong Questions

http://www.johnmaxwell.com/blog/youll-never-find-the-right-answers-if-youre-asking-the-wrong-questions par John C. Maxwell.

“L’esprit non créatif peut discerner les mauvaises réponses, mais il faut un esprit créatif pour reconnaitre les mauvaises questions.”

Sir Antony Jay

Pendant la résolution de problèmes, il est très facile de tomber dans l’ornière de la pensée non créative. Nous pouvons nous concentrer tellement sur les réponses et les solutions que nous perdons de vue la question. Et si nous posons les mauvaises questions, nous terminerons souvent avec de mauvaises réponses.

A quel point votre pensée est-elle créative ? Quand vous êtes face à un problème, vous tournez-vous immédiatement vers les solutions infaillibles que vous utilisez depuis toujours ? Ou ouvrez-vous votre esprit à de nouvelles idées ?

Une bonne façon d’ouvrir votre esprit est de commencer à poser de bonnes questions, telles que celles-ci :

  • Pourquoi ceci doit-il être fait de cette façon ?
  • Quel est le problème racine ?
  • Quelles sont les questions sous-jacentes ?
  • Cela me rappelle-t-il quelque chose ou une autre situation ?
  • Quel est l’opposé ?
  • Quelle métaphore ou symbole aident à l’expliquer ?
  • Pourquoi est-ce important ?
  • Quelle est la façon la plus difficile ou la plus chère de le faire ?
  • Qui a une perspective différente ?
  • Qu’arrivera-t-il si nous ne le faisons pas du tout ?

Vous comprenez l’idée… et vous pouvez probablement trouver de meilleures questions par vous-même.

Le Physicien Tom Hirschfield a observé: « si vous ne demandez pas, ‘Pourquoi ceci ?’ assez souvent, quelqu’un demandera, ‘Pourquoi vous ?’ »

Si vous voulez penser avec créativité, vous devez poser de bonnes questions. Vous devez challenger le processus en place.

avec Ventura Asssociates, partenaire de DantotsuPM, recrutez les ressources critiques dont vous avez besoin pour vos projets

The AgileBA® Handbook

The Agile Business Analysis (AgileBA®) Handbook – published by DSDM Consortium – offers useful, practical and comprehensive guidance on the role of the business analyst working in an Agile way.

AgileBA HandbookIt also aims to give context to the business analyst role beyond the individual project, in relation to organisational mission and strategy, and to give additional depth and guidance for the business analyst role.

AgileBA highlights techniques that can help the Agile business analyst support the organization in the formulation and reviewing of its strategies. Even if the project-level Agile BA is not directly involved in defining the organization’s strategies, they need to understand the way strategy is formulated and the factors and forces which affect it. This will give them the perspective to ensure that the projects they are involved in have objectives that align with, and support, the organization’s strategic goals.

Business Analysis is crucial to the success and competitiveness of organizations in today’s rapidly-changing environment, enabling the timely delivery of high value, cost-effective solutions. As the project world continues to change, the BA role will continue to be an evolutionary role: embracing Agile is a significant part of this evolution.

The guidance is aimed at aspiring, new and existing Business Analysts, whether new to working in an agile environment or experienced in agile practices. It will also support project managers and product owners working with (or within) agile project teams and other practitioners looking to understand the value and role of business analysts on agile projects.

The handbook is also the official reference material for those undertaking accredited AgileBA training and Foundation & Practitioner level certification.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer