Bonjour Didier,

Je vous remercie pour toute l'attention portée à mon cours d'initiation et à mon expertise.

Dans la mesure où la gestion empirique de projet favorise activement la transparence des communications et des informations, je vous conseille de commencer par signaler votre humeur en toute autonomie avant de la partager dans un calendrier Niko-Niko plus collaboratif.

Je reste à votre entière disposition pour plus de détails, si besoin.

Bonjour,

Ayant parcouru l'ensemble des questions-réponses ainsi que le cours, je voudrais avoir votre retour sur un point que je trouve un peu moins développer.

Ce dernier se base sur les possibilités d'application d'une méthode AGILE. Je précise mon fond de pensée; dans un environnement de travail type R&D avec beaucoup d'interlocuteurs ainsi qu'une équipe projet relativement conséquente (plus de 15), comment appliquer concrètement l'organisation AGILE.

J'ai quelques éléments de réponse, et je vous les présente afin de pouvoir orienter votre réponse si mon analyse est erronée.

1. La méthode AGILE est plutôt applicable sur des services de développements de produit, si l'on prend en compte ceux qui définissent le projet et ceux qui le réalisent.

2. (ce que je pense) On peut appliquer la méthode AGILE dans une équipe projet importante de R&D; tout en ayant des services de développements produits, marketing, etc en parallèle; et dans ce cas le client de l'équipe projet R&D sera par exemple le responsable du développement produit qui défini les attentes du client final.

Je vous remercie d'avance pour votre réponse qui, je pense, m'éclairera sur le sujet.

Salutations

Bonjour Antoine,

Je te remercie pour toute l'attention portée à l'un de mes trois cours dédiés au développement agile.

J'ai volontairement évité d'aborder l'application des processus et/ou modèle de gestion empirique dans d'autre contexte, cependant votre message me rassure quant à la très bonne compréhension et adaptation de ces ressources dans votre domaine d'activité ;-) C'est parfait !

Voir aussi les autres cours dans le parcours complet (Scrum Master) : https://openclassrooms.com/fr/paths/85-scrum-master

Bonne continuation

Bonjour Arnaud

Merci beaucoup pour ce cours très complet, qui aborde nombre de sujets intéressants et avec agilité

Je me permets de poser une question concernant la méthode MoSCoW, je ne crois pas avoir lu de détails sur ce point du cours dans le forum.

Je note que la méthode MoSCoW permet de prioriser les éléments de son Product Backlog, cependant je ne comprends pas bien le graphique présenté dans le cours. Notamment les cases situées dans les angles du graphique.

Le "Should Have" en haut à droite possède un critère de priorité de 2 et semble donc moins essentiel que plusieurs des "Must Have" en dessous qui possèdent un critère de 1.

Pourtant, ce "Should" répond à la double question : "Que pensez-vous du produit s'il contient bien la fonctionnalité ?" et "Que pensez-vous du produit s'il ne contient pas la fonctionnalité ?" par un "Cela me ferait plaisir" et "Cela me dérangerait".

Alors que l'un des "Must Have" notamment (critère de priorité 1) répond à cette double question par un "Je l'accepterai" et "Cela me ferait plaisir". Ce qui me semble moins prioritaire.

Je ne parviens malheureusement pas à m'expliquer cette nuance.
Merci beaucoup pour votre aide et toutes mes excuses si j'ai raté un élément pourtant évident.

A très bientôt j'espère !

Bonjour Jérémy, 

Je vous remercie pour toute l'attention portée à mon expertise en développement agile.

Le model de Kano fait en effet la différence entre les fonctionnalités obligatoires (les 3 cases "Must have"), les fonctionnalités attirantes (la case en coin "Should have), les fonctionnalités linéaires (les 3 autres cases "Should have"), les fonctionnalités indifférentes (les cases "Could have") et les fonctionnalités à double tranchant (les cases "Won't have") : https://fr.wikipedia.org/wiki/Mod%C3%A8le_de_Kano

Bonne continuation