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 questions poser lors d’une revue « post mortem » de projet ?

Commencez par une réflexion personnelle et individuelle sur les leçons à retenir par chaque membre de l’équipe projet étendue: Équipe cœur, clients, utilisateurs, sponsors, parties prenantes…

Ce billet est la reprise d’un article de 2010 sur le sujet.

Bien que préférant la terminologie « session de leçons apprises » à « post mortem », j’ai trouvé de la valeur dans la liste suggérée par Michael Greer.

En particulier, les 2 premiers conseils de l’approche qui consistent à forcer une réflexion personnelle de chacun avant d’avoir une session commune. Je suis certain que procéder de la sorte est bien plus productif qu’un brainstorming sans préparation qui limite souvent les résultats à des banalités connues de tous et énoncées seulement par les plus extravertis du groupe.

Project Post Mortem Review Questions By Michael Greer

Vue d’ensemble

Il est critique pour des chefs de projet et membres de l’équipe de faire le point à la fin d’un projet afin de développer une liste de leçons apprises ne pas répéter les mêmes erreurs dans les projets futurs. Typiquement de telles revues sont appelés des revues de fin de  projet ou “post mortem”.

Je recommande une approche en deux étapes pour conduire ces sessions

1.      Préparez-vous: Circulez une liste de questions spécifiques au projet et donnez du temps aux membres de l’équipe pour y réfléchir et préparer individuellement leurs réponses.

2.      Tenez une réunion. Discutez des réponses fournies par l’équipe aux questions. Le résultat de cette réunion est souvent une liste de “Leçons Apprises”.

que comprendre de ces retours?L’avantage de la première étape, faite individuellement par des membres de l’équipe, est qu’elle permet aux personnes plus calmes, introverties ou plus analytiques, de développer leurs réponses sans être interrompues par les personnes plus extraverties et vocales. Celles-ci pourraient souvent dominer dans une réunion en face à face. De plus, cela donne à chacun le temps de créer des réponses plus posées.

Qu’inscrire dans cette liste de questions ?

Questions Générales

1.      Êtes-vous fiers de nos livrables (des produits réalisés par le projet) ? Si oui, qu’est-ce qui est si bien dans ceux-ci ? Si non, qu’est-ce qui est moins bon ?

2.      Quelle était la partie la plus irritante de votre projet ?

3.      Que feriez-vous différemment la prochaine fois pour éviter cette frustration ?

4.      Quelle a été la partie la plus gratifiante ou professionnellement satisfaisante du projet ?

5.      Lesquels de vos méthodes ou processus ont particulièrement bien fonctionné ?

6.      Lesquels de vos méthodes ou processus furent difficiles ou irritants à utiliser ?

introduire de l'innatendu7.      Si vous pouviez d’un coup de baguette magique changer quoi que ce soit du projet, que changeriez-vous ?

8.      Vos parties prenantes, management exécutif, clients et sponsor(s) ont-ils participé efficacement ? Sinon, comment pourriez-vous améliorer leur participation ?

Les questions suivantes sont spécifiques à chaque phase (celles-ci peuvent différer de projet en projet, selon le cycle de vie / la méthode).

Phase I : Besoin et Faisabilité

  • Nos analyses de besoins/marché ou études de faisabilité ont-elles oublier des livrables de projet que nous avons finalement dû construire ? Sinon, qu’avons-nous manqué et comment pouvons-nous être sûrs que nos analyses futures ne manqueront pas de tels items ?
  • Nos analyses de besoins/marché ou études de faisabilité ont-elles au contraire demandé des livrables inutiles ? S’il en est ainsi comment pouvons-nous être sûrs que nos analyses futures ne referont pas cette erreur ?
  • Comment pourrions-nous améliorer nos analyses de besoins/marché ou études de faisabilité ?

Phase II : Plan de Projet

  • Quelle était la précision de nos estimations originales de la taille et de l’effort de notre projet ? Qu’avons-nous sous ou sur estimer ? (Considérez les livrables, l’effort de travail, les matériels requis, etc)
  • Comment pourrions-nous améliorer notre estimation de taille et d’effort pour qu’elle soit plus précise ?
  • Avons-nous assigné les bonnes personnes à tous les rôles du projet ? (Considérez les experts du sujet, les contributions techniques, le management, les revues et approbations et autres rôles clefs). Si ce n’est pas le cas, comment pouvons-nous nous assurer que nous obtiendrons la prochaine fois les bonnes personnes.
  • Décrivez des premiers signaux d’alarme de problèmes qui sont survenus plus tard dans le projet ? Comment aurions-nous dû réagir à ces signaux ? Comment pouvons-nous mieux remarquer ces premiers signaux dès leur apparition ?
  • Pourrions-nous avoir complété ce projet sans l’un ou plusieurs de nos fournisseurs/sous-traitants ? Si oui, comment ?
  • Est-ce que nos contraintes, limitations et prérequis étaient clairs pour tous les fournisseurs/sous-traitants depuis le début ? Sinon, comment pourrions-nous améliorer notre « Request for Proposal RFP » ou déclaration de besoin ?
  • Avons-nous rencontré des difficultés à négocier le contrat avec le vendeur ? Comment celles-ci auraient-elles pu être évitées ?
  • Avons-nous rencontré des difficultés par rapport à la paperasserie du fournisseur (bons de commande, contrats, etc) ou à bien le faire démarrer ? Comment celles-ci pourraient-elles être évitées ?
  • Listez des membres de l’équipe ou les parties prenantes qui manquaient au démarrage ou qui n’ont pas été impliqués assez tôt dans notre projet. Comment pouvons-nous éviter ces loupés à l’avenir ?
  • Tous les rôles et responsabilités d’équipe/partie prenante étaient-ils clairement décrits et communiqués ? Sinon, comment pourrions-nous les améliorer ?
  • Le cahier des charges des livrables, jalons et éléments/dates de planning spécifiques étaient-ils clairement communiqués ? Sinon, comment pourrions-nous nous améliorer ?

Phase III : Cahier des charges (les spécifications) des livrables

  • Livre sur Amazon

    Êtes-vous fiers de nos descriptions ou cahier des charges et spécifications de conception détaillées ? Sinon, comment pourrions-nous les améliorer à l’avenir ?

  • Tous les acteurs importants du projet ont-ils fourni un apport créatif dans la création des spécifications de conception ? Sinon, qui manquait et comment nous assurer la prochaine fois de leur participation ?
  • Ceux qui ont passé en revue les spécifications de conception ont-ils fourni un retour significatif dans les délais impartis ? Sinon, comment pourrions-nous améliorer leur participation et la qualité de leurs contributions ?
  • Comment pourrions-nous améliorer notre processus de travail pour créer les spécifications des livrables ?

[ Ajoutez ici vos propres questions spécifiques aux livrables de votre projet.]

Phase IV : Construction des Livrables

  • Est-ce que vous êtes fiers de nos livrables ? Sinon, comment pourrions-nous les améliorer ?
  • Tous les acteurs importants du projet ont-ils fourni un apport constructif dans la création des livrables ? Sinon, qui manquait et comment pouvons-nous nous assurer de leur participation la prochaine fois ?
  • Ceux qui ont revu les livrables ont-ils fourni un retour dans les temps et significatif ? Sinon, comment pourrions-nous améliorer leur participation et la qualité de leurs contributions ?
  • Comment pourrions-nous améliorer notre processus de travail de création des livrables ?

[ Insérez ici vos propres questions spécifiques aux livrables.]

Phase V : Test et Implémentation des livrables

Relisez ce billet
  • Les membres de notre équipe de test étaient-ils vraiment représentatifs de nos utilisateurs cibles ? Sinon, comment pourrions-nous obtenir une meilleure représentativité à l’avenir ?
  • Les équipements de test, le lieu, les matériels et les personnes au support ont-ils aidé à faire du test une représentation précise de comment les produits seront utilisés dans “le monde réel” ? Sinon, comment pourrions-nous nous améliorer dans ces domaines ?
  • Avons-nous obtenu un retour d’information au bon moment, de bonne qualité sur comment nous pourrions améliorer nos produits ? Sinon, comment pourrions-nous améliorer ce retour d’information dans l’avenir ?
  • Notre stratégie de mise en œuvre était-elle précise et efficace ? Comment pourrions-nous améliorer cette stratégie ?
  • Notre livraison des livrables à l’utilisateur/client/sponsor es-elle une transition souple et facile ? Sinon, comment pourrions-nous améliorer ce processus ?
En complément, relisez: « Une bonne vingtaine de questions à considérer pour vos sessions « Leçons apprises » de fin de projet« .

Quelles questions lors d’une revue post mortem de projet

http://www.pmhut.com/project-post-mortem-review-questions

Project Post Mortem Review Questions
By
Michael Greer

Vue d’ensemble

Il est important pour des chefs de projet et des membres de l’équipe de faire le point à la fin d’un projet et de développer une liste de leçons apprises pour qu’ils ne répètent pas leurs erreurs dans le projet suivant. Typiquement de telles revues sont appelés des revues de fin de  projet ou “post mortem.” Je recommande une approche en deux étapes pour conduire ces sessions :

1. D’abord, préparez-vous et circulez une liste de questions spécifiques au projet et donnez du temps aux membres de l’équipe pour y penser et préparer individuellement leurs réponses.

2. Ensuite, tenez une réunion et discutez des réponses de l’équipe aux questions. Le résultat de cette discussion est souvent une liste “de Leçons Apprises.”

L’avantage de la première étape, faite individuellement par des membres de l’équipe, est qu’il permet aux personnes plus tranquilles, plus analytiques, de développer leurs réponses aux questions sans être interrompues par les personnes plus extraverties, vocales qui pourraient autrement dominer à la réunion en face à face. De plus, il permet à chacun le temps de créer des réponses plus réfléchies.

Donc, que mettre dans la liste de questions ? Voici certaines de mes favorites :

Questions Générales

1. Est-ce que vous êtes fiers de nos livrables (des produits réalisés par le projet) ? Si oui, qu’est-ce qui est si bien dans ceux-ci ? Si non, qu’est-ce qui est mauvais ?

2. Quelle était la partie la plus irritante de notre projet ?

3. Comment feriez-vous des choses différemment la prochaine fois pour éviter cette frustration ?

4. Quelle a été la partie la plus gratifiante ou professionnellement satisfaisante du projet ?

5. Lesquels de nos méthodes ou processus ont particulièrement bien fonctionné ?

6. Lesquels de nos méthodes ou processus furent difficiles ou irritant à utiliser ?

7. Si vous pourriez d’un coup de baguette magique changer quoi que ce soit du projet, que changeriez-vous ?

8. Nos parties prenantes, management exécutif, clients et sponsor(s) ont-ils participé efficacement ? Sinon, comment pourrions-nous améliorer leur participation ?

Les suivantes sont des questions spécifiques à chaque phase (celles-ci différeront de projet en projet, selon le cycle de vie / les phases).

Phase I : Déterminer Besoin et Faisabilité

· Nos analyses de besoins/marché ou étude de faisabilité ont-elles identifié tous les livrables de projet que nous avons finalement dû construire ? Sinon, qu’avons-nous manqué et comment pouvons-nous être sûrs que nos analyses futures ne manqueront pas de tels items ?

· Nos analyses de besoins/marché ou étude de faisabilité ont-elles identifié des livrables inutiles ? S’il en est ainsi comment pouvons-nous être sûrs que nos analyses futures ne referont pas cette erreur ?

· Comment pourrions-nous améliorer nos analyses de besoins/marché ou étude de faisabilité ?

Phase II : Créer le Plan de Projet

· Quelle était la précision de nos évaluations originales de la taille et de l’effort de notre projet ? Qu’avons-nous sous ou sur estimer ? (Considérez les livarbles, l’effort de travail, les matériels requis, etc)

· Comment pourrions-nous avoir amélioré notre estimation de taille et d’effort pour qu’elle soit plus précise ?

· Avons-nous assigné les bonnes personnes à tous les rôles du projet ? (Considérez les experts du sujet, les contributions techniques, le management, les revues et approbations et autres rôles clefs). Si ce n’est pas le cas, comment pouvons-nous nous assurer que nous obtiendrons la prochaine fois les bonnes personnes.

· Décrivez des premiers signaux d’alarme des problèmes qui sont arrivés plus tard dans le projet ? Comment devrions-nous avoir réagi à ces signaux ? Comment pouvons-nous nous assurer la prochaine fois de remarquer ces premiers signaux dès leur apparition ?

· Pourrions-nous avoir complété ce projet sans un ou plus de nos fournisseurs/sous-traitants ? Si oui, comment ?

· Est-ce que nos contraintes, limitations et prérequis étaient clairs pour tous les fournisseurs/sous-traitants depuis le début ? Sinon, comment pourrions-nous avoir amélioré notre « Request for Proposal RFP » ou déclaration de besoin ?

· Avons-nous rencontré des difficultés à négocier le contrat avec le vendeur ? Comment celles-ci pourraient-elles avoir été évitées ?

Avons-nous rencontré des difficultés par rapport à la paperasserie du fournisseur (bons de commande, contrats, etc) ou bien à faire démarrer le fournisseur ? Comment celles-ci pourraient-elles avoir été évitées ?

· Listez des membres de l’équipe ou les parties prenantes qui manquaient lors de la réunion de démarrage ou qui n’ont pas été impliqués assez tôt dans notre projet. Comment pouvons-nous éviter ces inadvertances à l’avenir ?

· Tous les rôles et responsabilités d’équipe/partie prenante étaient-ils clairement décrits et communiqués ? Sinon, comment pourrions-nous les améliorer ?

· Le cahier des charges de produits, les jalons et les éléments/dates de planning spécifiques étaient-ils clairement communiqués ? Sinon, comment pourrions-nous nous améliorer ?

Phase III : Créer le Cahier des charges (les spécifications) des livrables

· Est-ce que vous êtes fiers de nos descriptions ou cahier des charges et spécifications de conception détaillées ? Sinon, comment pourrions-nous avoir les améliorer?

· Tous les acteurs importants de projet ont-ils fourni un apport créatif dans la création des spécifications de conception ? Sinon, qui manquait et comment pouvons-nous nous assurer la prochaine fois de leur participation ?

· Ceux qui ont passé en revue les spécifications de conception ont-ils fourni un retour dans les temps et significatif ? Sinon, comment pourrions-nous améliorer leur participation et la qualité de leurs contributions ?

· Comment pourrions-nous améliorer notre processus de travail pour créer les spécifications de livrables ?

[ Insérez ici vos propres questions spécifiques aux livrables.]

Phase IV : Créer les livrables

· Est-ce que vous êtes fiers de nos livrables ? Sinon, comment pourrions-nous améliorer ceux-ci ?

· Tous acteurs importants du projet ont-ils fourni un apport constructif dans la création des produits ? Sinon, qui manquait et comment pouvons-nous nous assurer de leur participation la prochaine fois ?

· Ceux qui ont passé en revue les livrables ont-ils fourni un retour dans les temps et significatif ? Sinon, comment pourrions-nous améliorer leur participation et la qualité de leurs contributions ?

· Comment pourrions-nous améliorer notre processus de travail de création des livrables ?

[ Insérez ici vos propres questions spécifiques aux livrables.]

Phase V : Test et implémentation des livrables

· Les membres de notre équipe de test étaient-ils vraiment représentatifs de nos utilisateurs cibles ? Sinon, comment pourrions-nous obtenir une meilleure représentativité à l’avenir ?

· Les équipements de test, le lieu, les matériels et les personnes au support ont-ils aidé à faire du test une représentation précise de commen

Quelles questions lors d’une revue post mortem de projet

http://www.pmhut.com/project-post-mortem-review-questions

Project Post Mortem Review Questions
By
Michael Greer

Vue d’ensemble

Il est important pour des chefs de projet et des membres de l’équipe de faire le point à la fin d’un projet et de développer une liste de leçons apprises pour qu’ils ne répètent pas leurs erreurs dans le projet suivant. Typiquement de telles revues sont appelés des revues de fin de  projet ou “post mortem.” Je recommande une approche en deux étapes pour conduire ces sessions :

1.      D’abord, préparez-vous et circulez une liste de questions spécifiques au projet et donnez du temps aux membres de l’équipe pour y penser et préparer individuellement leurs réponses.

2.      Ensuite, tenez une réunion et discutez des réponses de l’équipe aux questions. Le résultat de cette discussion est souvent une liste “de Leçons Apprises.”

L’avantage de la première étape, faite individuellement par des membres de l’équipe, est qu’il permet aux personnes plus tranquilles, plus analytiques, de développer leurs réponses aux questions sans être interrompues par les personnes plus extraverties, vocales qui pourraient autrement dominer à la réunion en face à face. De plus, il permet à chacun le temps de créer des réponses plus réfléchies.

Donc, que mettre dans la liste de questions ? Voici certaines de mes favorites :

Questions Générales

1.      Est-ce que vous êtes fiers de nos livrables (des produits réalisés par le projet) ? Si oui, qu’est-ce qui est si bien dans ceux-ci ? Si non, qu’est-ce qui est mauvais ?

2.      Quelle était la partie la plus irritante de notre projet ?

3.      Comment feriez-vous des choses différemment la prochaine fois pour éviter cette frustration ?

4.      Quelle a été la partie la plus gratifiante ou professionnellement satisfaisante du projet ?

5.      Lesquels de nos méthodes ou processus ont particulièrement bien fonctionné ?

6.      Lesquels de nos méthodes ou processus furent difficiles ou irritant à utiliser ?

7.      Si vous pourriez d’un coup de baguette magique changer quoi que ce soit du projet, que changeriez-vous ?

8.      Nos parties prenantes, management exécutif, clients et sponsor(s) ont-ils participé efficacement ? Sinon, comment pourrions-nous améliorer leur participation ?

Les suivantes sont des questions spécifiques à chaque phase (celles-ci différeront de projet en projet, selon le cycle de vie / les phases).

Phase I : Déterminer Besoin et Faisabilité

  • Nos analyses de besoins/marché ou étude de faisabilité ont-elles identifié tous les livrables de projet que nous avons finalement dû construire ? Sinon, qu’avons-nous manqué et comment pouvons-nous être sûrs que nos analyses futures ne manqueront pas de tels items ?
  • Nos analyses de besoins/marché ou étude de faisabilité ont-elles identifié des livrables inutiles ? S’il en est ainsi comment pouvons-nous être sûrs que nos analyses futures ne referont pas cette erreur ?
  • Comment pourrions-nous améliorer nos analyses de besoins/marché ou étude de faisabilité ?

Phase II : Créer le Plan de Projet

  • Quelle était la précision de nos évaluations originales de la taille et de l’effort de notre projet ? Qu’avons-nous sous ou sur estimer ? (Considérez les livarbles, l’effort de travail, les matériels requis, etc)
  • Comment pourrions-nous avoir amélioré notre estimation de taille et d’effort pour qu’elle soit plus précise ?
  • Avons-nous assigné les bonnes personnes à tous les rôles du projet ? (Considérez les experts du sujet, les contributions techniques, le management, les revues et approbations et autres rôles clefs). Si ce n’est pas le cas, comment pouvons-nous nous assurer que nous obtiendrons la prochaine fois les bonnes personnes.
  • Décrivez des premiers signaux d’alarme des problèmes qui sont arrivés plus tard dans le projet ? Comment devrions-nous avoir réagi à ces signaux ? Comment pouvons-nous nous assurer la prochaine fois de remarquer ces premiers signaux dès leur apparition ?
  • Pourrions-nous avoir complété ce projet sans un ou plus de nos fournisseurs/sous-traitants ? Si oui, comment ?
  • Est-ce que nos contraintes, limitations et prérequis étaient clairs pour tous les fournisseurs/sous-traitants depuis le début ? Sinon, comment pourrions-nous avoir amélioré notre « Request for Proposal RFP » ou déclaration de besoin ?
  • Avons-nous rencontré des difficultés à négocier le contrat avec le vendeur ? Comment celles-ci pourraient-elles avoir été évitées ?

Avons-nous rencontré des difficultés par rapport à la paperasserie du fournisseur (bons de commande, contrats, etc) ou bien à faire démarrer le fournisseur ? Comment celles-ci pourraient-elles avoir été évitées ?

  • Listez des membres de l’équipe ou les parties prenantes qui manquaient lors de la réunion de démarrage ou qui n’ont pas été impliqués assez tôt dans notre projet. Comment pouvons-nous éviter ces inadvertances à l’avenir ?
  • Tous les rôles et responsabilités d’équipe/partie prenante étaient-ils clairement décrits et communiqués ? Sinon, comment pourrions-nous les améliorer ?
  • Le cahier des charges de produits, les jalons et les éléments/dates de planning spécifiques étaient-ils clairement communiqués ? Sinon, comment pourrions-nous nous améliorer ?

Phase III : Créer le Cahier des charges (les spécifications) des livrables

  • Est-ce que vous êtes fiers de nos descriptions ou cahier des charges et spécifications de conception détaillées ? Sinon, comment pourrions-nous avoir les améliorer?
  • Tous les acteurs importants de projet ont-ils fourni un apport créatif dans la création des spécifications de conception ? Sinon, qui manquait et comment pouvons-nous nous assurer la prochaine fois de leur participation ?
  • Ceux qui ont passé en revue les spécifications de conception ont-ils fourni un retour dans les temps et significatif ? Sinon, comment pourrions-nous améliorer leur participation et la qualité de leurs contributions ?
  • Comment pourrions-nous améliorer notre processus de travail pour créer les spécifications de livrables ?

[ Insérez ici vos propres questions spécifiques aux livrables.]

Phase IV : Créer les livrables

  • Est-ce que vous êtes fiers de nos livrables ? Sinon, comment pourrions-nous améliorer ceux-ci ?
  • Tous acteurs importants du projet ont-ils fourni un apport constructif dans la création des produits ? Sinon, qui manquait et comment pouvons-nous nous assurer de leur participation la prochaine fois ?
  • Ceux qui ont passé en revue les livrables ont-ils fourni un retour dans les temps et significatif ? Sinon, comment pourrions-nous améliorer leur participation et la qualité de leurs contributions ?
  • Comment pourrions-nous améliorer notre processus de travail de création des livrables ?

[ Insérez ici vos propres questions spécifiques aux livrables.]

Phase V : Test et implémentation des livrables

  • Les membres de notre équipe de test étaient-ils vraiment représentatifs de nos utilisateurs cibles ? Sinon, comment pourrions-nous obtenir une meilleure représentativité à l’avenir ?
  • Les équipements de test, le lieu, les matériels et les personnes au support ont-ils aidé à faire du test une représentation précise de comment les produits seront utilisés dans “le monde réel ?” Sinon, comment pourrions-nous nous améliorer dans ces domaines ?
  • Avons-nous obtenu un retour d’information opportun, de haute qualité sur comment nous pourrions améliorer nos produits ? Sinon, comment pourrions-nous améliorer ce retour d’information dans l’avenir ?
  • Notre stratégie de mise en œuvre était-elle précise et efficace ? Comment pourrions-nous améliorer cette stratégie ?
  • Notre remise en main des livrables à l’utilisateur/client/sponsor représente-t-elle une transition souple et facile ? Sinon, comment pourrions-nous améliorer ce processus ?

Quelles questions lors d’une revue post mortem de projet

http://www.pmhut.com/project-post-mortem-review-questions

Project Post Mortem Review Questions
By
Michael Greer

Vue d’ensemble

Il est important pour des chefs de projet et des membres de l’équipe de faire le point à la fin d’un projet et de développer une liste de leçons apprises pour qu’ils ne répètent pas leurs erreurs dans le projet suivant. Typiquement de telles revues sont appelés des revues de fin de  projet ou “post mortem.” Je recommande une approche en deux étapes pour conduire ces sessions :

1.      D’abord, préparez-vous et circulez une liste de questions spécifiques au projet et donnez du temps aux membres de l’équipe pour y penser et préparer individuellement leurs réponses.

2.      Ensuite, tenez une réunion et discutez des réponses de l’équipe aux questions. Le résultat de cette discussion est souvent une liste “de Leçons Apprises.”

L’avantage de la première étape, faite individuellement par des membres de l’équipe, est qu’il permet aux personnes plus tranquilles, plus analytiques, de développer leurs réponses aux questions sans être interrompues par les personnes plus extraverties, vocales qui pourraient autrement dominer à la réunion en face à face. De plus, il permet à chacun le temps de créer des réponses plus réfléchies.

Donc, que mettre dans la liste de questions ? Voici certaines de mes favorites :

Questions Générales

1.      Est-ce que vous êtes fiers de nos livrables (des produits réalisés par le projet) ? Si oui, qu’est-ce qui est si bien dans ceux-ci ? Si non, qu’est-ce qui est mauvais ?

2.      Quelle était la partie la plus irritante de notre projet ?

3.      Comment feriez-vous des choses différemment la prochaine fois pour éviter cette frustration ?

4.      Quelle a été la partie la plus gratifiante ou professionnellement satisfaisante du projet ?

5.      Lesquels de nos méthodes ou processus ont particulièrement bien fonctionné ?

6.      Lesquels de nos méthodes ou processus furent difficiles ou irritant à utiliser ?

7.      Si vous pourriez d’un coup de baguette magique changer quoi que ce soit du projet, que changeriez-vous ?

8.      Nos parties prenantes, management exécutif, clients et sponsor(s) ont-ils participé efficacement ? Sinon, comment pourrions-nous améliorer leur participation ?

Les suivantes sont des questions spécifiques à chaque phase (celles-ci différeront de projet en projet, selon le cycle de vie / les phases).

Phase I : Déterminer Besoin et Faisabilité

  • Nos analyses de besoins/marché ou étude de faisabilité ont-elles identifié tous les livrables de projet que nous avons finalement dû construire ? Sinon, qu’avons-nous manqué et comment pouvons-nous être sûrs que nos analyses futures ne manqueront pas de tels items ?
  • Nos analyses de besoins/marché ou étude de faisabilité ont-elles identifié des livrables inutiles ? S’il en est ainsi comment pouvons-nous être sûrs que nos analyses futures ne referont pas cette erreur ?
  • Comment pourrions-nous améliorer nos analyses de besoins/marché ou étude de faisabilité ?

Phase II : Créer le Plan de Projet

  • Quelle était la précision de nos évaluations originales de la taille et de l’effort de notre projet ? Qu’avons-nous sous ou sur estimer ? (Considérez les livarbles, l’effort de travail, les matériels requis, etc)
  • Comment pourrions-nous avoir amélioré notre estimation de taille et d’effort pour qu’elle soit plus précise ?
  • Avons-nous assigné les bonnes personnes à tous les rôles du projet ? (Considérez les experts du sujet, les contributions techniques, le management, les revues et approbations et autres rôles clefs). Si ce n’est pas le cas, comment pouvons-nous nous assurer que nous obtiendrons la prochaine fois les bonnes personnes.
  • Décrivez des premiers signaux d’alarme des problèmes qui sont arrivés plus tard dans le projet ? Comment devrions-nous avoir réagi à ces signaux ? Comment pouvons-nous nous assurer la prochaine fois de remarquer ces premiers signaux dès leur apparition ?
  • Pourrions-nous avoir complété ce projet sans un ou plus de nos fournisseurs/sous-traitants ? Si oui, comment ?
  • Est-ce que nos contraintes, limitations et prérequis étaient clairs pour tous les fournisseurs/sous-traitants depuis le début ? Sinon, comment pourrions-nous avoir amélioré notre « Request for Proposal RFP » ou déclaration de besoin ?
  • Avons-nous rencontré des difficultés à négocier le contrat avec le vendeur ? Comment celles-ci pourraient-elles avoir été évitées ?

Avons-nous rencontré des difficultés par rapport à la paperasserie du fournisseur (bons de commande, contrats, etc) ou bien à faire démarrer le fournisseur ? Comment celles-ci pourraient-elles avoir été évitées ?

  • Listez des membres de l’équipe ou les parties prenantes qui manquaient lors de la réunion de démarrage ou qui n’ont pas été impliqués assez tôt dans notre projet. Comment pouvons-nous éviter ces inadvertances à l’avenir ?
  • Tous les rôles et responsabilités d’équipe/partie prenante étaient-ils clairement décrits et communiqués ? Sinon, comment pourrions-nous les améliorer ?
  • Le cahier des charges de produits, les jalons et les éléments/dates de planning spécifiques étaient-ils clairement communiqués ? Sinon, comment pourrions-nous nous améliorer ?

Phase III : Créer le Cahier des charges (les spécifications) des livrables

  • Est-ce que vous êtes fiers de nos descriptions ou cahier des charges et spécifications de conception détaillées ? Sinon, comment pourrions-nous avoir les améliorer?
  • Tous les acteurs importants de projet ont-ils fourni un apport créatif dans la création des spécifications de conception ? Sinon, qui manquait et comment pouvons-nous nous assurer la prochaine fois de leur participation ?
  • Ceux qui ont passé en revue les spécifications de conception ont-ils fourni un retour dans les temps et significatif ? Sinon, comment pourrions-nous améliorer leur participation et la qualité de leurs contributions ?
  • Comment pourrions-nous améliorer notre processus de travail pour créer les spécifications de livrables ?

[ Insérez ici vos propres questions spécifiques aux livrables.]

Phase IV : Créer les livrables

  • Est-ce que vous êtes fiers de nos livrables ? Sinon, comment pourrions-nous améliorer ceux-ci ?
  • Tous acteurs importants du projet ont-ils fourni un apport constructif dans la création des produits ? Sinon, qui manquait et comment pouvons-nous nous assurer de leur participation la prochaine fois ?
  • Ceux qui ont passé en revue les livrables ont-ils fourni un retour dans les temps et significatif ? Sinon, comment pourrions-nous améliorer leur participation et la qualité de leurs contributions ?
  • Comment pourrions-nous améliorer notre processus de travail de création des livrables ?

[ Insérez ici vos propres questions spécifiques aux livrables.]

Phase V : Test et implémentation des livrables

  • Les membres de notre équipe de test étaient-ils vraiment représentatifs de nos utilisateurs cibles ? Sinon, comment pourrions-nous obtenir une meilleure représentativité à l’avenir ?
  • Les équipements de test, le lieu, les matériels et les personnes au support ont-ils aidé à faire du test une représentation précise de comment les produits seront utilisés dans “le monde réel ?” Sinon, comment pourrions-nous nous améliorer dans ces domaines ?
  • Avons-nous obtenu un retour d’information opportun, de haute qualité sur comment nous pourrions améliorer nos produits ? Sinon, comment pourrions-nous améliorer ce retour d’information dans l’avenir ?
  • Notre stratégie de mise en œuvre était-elle précise et efficace ? Comment pourrions-nous améliorer cette stratégie ?
  • Notre remise en main des livrables à l’utilisateur/client/sponsor représente-t-elle une transition souple et facile ? Sinon, comment pourrions-nous améliorer ce processus ?

t les produits seront utilisés dans “le monde réel ?” Sinon, comment pourrions-nous nous améliorer dans ces domaines ?

· Avons-nous obtenu un retour d’information opportun, de haute qualité sur comment nous pourrions améliorer nos produits ? Sinon, comment pourrions-nous améliorer ce retour d’information dans l’avenir ?

· Notre stratégie de mise en œuvre était-elle précise et efficace ? Comment pourrions-nous améliorer cette stratégie ?

· Notre remise en main des livrables à l’utilisateur/client/sponsor représente-t-elle une transition souple et facile ? Sinon, comment pourrions-nous améliorer ce processus ?

Accueil bienveillant des changements dans les besoins exprimés

Le principe Agile d’accueillir des exigences changeantes avec bienveillance peut s’avérer le plus difficile à adopter !

Welcoming Changing Requirements

https://www.scrumalliance.org/community/articles/2017/may/welcoming-changing-requirements par Joseph Collins

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.

6 choses à faire au lancement du projet

Que faites-vous quand vous venez de prendre en charge un nouveau projet ?

Six things you should do when kicking off a project, http://www.susannemadsen.co.uk/blog/six-things-you-should-do-when-kicking-off-a-project, par Susanne Madsen

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.

comment BIEN réaliser la collecte et la compréhension des besoins des clients de vos projets ?

Savoir créer et entretenir un momentum semble être la clé pour éviter les échecs de projet.

Cependant, tout projet exige de bonnes définitions des besoins.

Comment les obtenir alors quand nous souffrons d’un excès massif d’informations ou au contraire d’un manque de données ?

Quand nous ne possédons pas les nécessaires compétences de facilitation pour les extraire?

Quand nous n’exerçons nos compétences d’analyse qu’occasionnellement ?

Voici ce que cette intéressante vidéo en anglais de Keith Ellis se propose d’aborder.

Méta Projets Management est partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Enregistrer

12 Avril – Montréal – Atelier de spécialisation sur les scénarios utilisateurs

Le passage de l’idée au code se fait par l’entremise de scénarios utilisateurs (“user stories”) avec  Luc St-Laurent

Luc St Laurent

Comme ces scénarios deviennent le centre de la communication entre les utilisateurs et les développeurs, il est nécessaire de savoir les utiliser et de bien les écrire. L’atelier vise donc à aider les propriétaires de produits, les développeurs et les entraîneurs à mieux comprendre les scénarios usagers et, surtout, à les outiller afin d’améliorer la performance de leur scénarios.

Un événement organisé par Agile Montréal

CertYou est partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Pourquoi un Sprint Zéro avec Scrum et Agile ?

Le concept de Sprint Zéro est controversé !

Why Have Sprint Zero? par Sujatha Tokala

Sprint Zéro
Sprint Zéro

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)
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
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

comment découper vos « User Stories » #Agile (Histoires Utilisateur) avec la méthode INVEST

Splitting User Stories

http://www.agileadvice.com/2016/06/03/scrumxplean/splitting-user-stories/ par Faisal Ansari

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
Microsoft est partenaire de DantotsuPM

I.N.V.E.S.T.

  • IIndépendante
  • N– Négociable
  • V– de Valeur
  • EEstimable
  • SSuffisamment petite
  • TTestable

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:
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
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
    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
    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
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’optimise maintenant ‘ 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.

Autres Ressources Utiles

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

July 12 – Webinar (PMI®) – Rethink Requirements – The Natural Language Processing Approach

According to PMI’s Pulse of the Profession, “When projects do not meet their original goals and project objectives, inaccurate business analysis/requirements management is cited as the primary cause 47% of the time.”

And the increasing scale and complexity of projects is making it extremely difficult to assess and verify the project requirements. As a result – a huge amount of critical errors in project and systems development arise in the initial concept & design stages.

MPM est Partenaire de DantotsuPM
MPM est Partenaire de DantotsuPM

In this presentation and workshop, we will focus on how harnessing automated computational tools utilizing Natural Language Processing can help project managers ensure their requirements are consistently clear & are a joy to work with.

These project managers, business analysts, engineers and by extension their clients, will benefit in the earliest stages of a project to ensure poorly written requirements do not infiltrate later project stages leading to reduced stress, increased confidence and higher project success.

Campana & Schott est partenaire de DantotsuPM
Campana & Schott est partenaire de DantotsuPM

Registration

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

Enregistrer

June 7 – Webinar (PMI®) – Slashing Risks with User Experience Engineering (UX) Second Edition

Recent PMI Study calls Requirements Management a core competency for project and program success – and does so for a good reason.

User Experience47% of projects run into trouble due to incomplete or changing requirements & specifications, lack of user input or unrealistic expectations.

UX methods brought wild success to Apple, Google and other top players and it has been increasingly popular ever since.

But what most magazines don’t tell you is that it’s not just the Design part of UX that makes it so effective!

This is an expanded and updated version of popular session that ran on February 23, incorporating additional information based on your feedback.

Requirements Management is the single biggest risk for a majority of projects. According to PMI, 47% of initiatives that missed the mark did so because of requirements management. It’s truly is a core competency for project and program success.

Imagine your life without these risks. Little or no stakeholder management… Clarity around scope and direction… Stable, measurable requirements, completely aligned with business needs…

Design Thinking and UX brought wild success to Apple, Google and other top players and it has been increasingly popular ever since. But what most magazines don’t tell you is that it’s not just the Design part of UX that makes it so effective, it’s the new tools for Business Analysis.

Attend this webinar to learn about these extremely effective new Design Thinking tools and processes – for gaining accurate insights, discovering ‘missing’ requirements and hidden underlying problems.

Details and registration

Partenaire de DantotsuPM
Partenaire de DantotsuPM