Tag Archives: scrum

fausses idées sur l’arriéré de produit (Product Backlog)

13 Fév

L’Arriéré de Produit n’est pas une liste géante d’histoires utilisateurs

Misconceptions about the Product Backlog

http://www.extremeuncertainty.com/misconceptions-product-backlog/  par leontranter

Il y a beaucoup de fausses idées sur l’Arriéré de Produit. En fait, je dirais que c’est probablement l’artefact le moins bien compris de Scrum. Et cela peut causer de gros problèmes, pas seulement pour votre produit et son planning, mais pour vos développeurs également. Étant un propriétaire de produit et manager cette chose est un travail difficile et il est facile se tromper. Cet article dissipera certaines des fausses idées sur l’arriéré de produit.

L’Arriéré de Produit n’est pas une liste géante d’histoires utilisateurs

Beaucoup de gens pense que l’arriéré de produit est essentiellement une grande liste d’histoires d’utilisateurs, classées de la plus haute à la plus faible priorité. Comme si vous aviez un grand tableau et chaque ligne dans le tableau était une histoire d’utilisateur, avec un identificateur, un nom et une description et c’est votre arriéré.

Cela semble agréable et simple, mais c’est un arriéré de produit épouvantable, pour nombre de raisons :

  • Les histoires ne sont reliées l’une à l’autre d’aucune façon significative
  • Il n’y a aucune dépendance entre les histoires
  • Les histoires sont non seulement sans rapport l’une avec l’autre mais elles ne sont liées à aucun horizon particulier ou version
  • Il n’y a aucune explication “de l’image plus grande” sur comment les histoires touchent au produit, ses fonctions et sa vision.

Un arriéré de produit est vraiment une feuille de route

Un bon arriéré de produit commence par une feuille de route, qui est une vue très de haut niveau de l’avenir du produit. Il y a évidemment beaucoup de choses que nous ne savons pas au commencement, mais un propriétaire de produit devrait commencer par une feuille de route et une vision de comment le produit pourrait se développer puis commencer à décomposer ce plan en des fonctionnalités ou des épopées et des versions ou des horizons.

roadmap to success...

Il s’agit d’une feuille de route

Cela vous permet de :

  • Rapprocher des histoires l’une de l’autre, via une fonction ou une épopée
  • Donner les dépendances entre histoires
  • Définir les fonctionnalités et épopées et quelle valeur elles fournissent et pourquoi vous les construisez.

Les fonctionnalités et épopées peuvent entrer dans l’arriéré. Et elles peuvent avoir leur propre description avec valeur, risque, bénéfices, dépendances et critères d’acceptation définis. Elles peuvent être évaluées et priorisées. Tout cela fournit “l’image plus grande”, la « big picture ». Si vous avez juste une liste d’histoires, comme quelqu’un l’a une fois dit, vous avez “un sac de feuilles, au lieu d’un arbre”.

Un arriéré de produit devrait être un arbre, pas un sac de feuilles

Donc vous voulez vraiment des histoires dans votre arriéré, mais vous voulez d’autres choses aussi. Et vous voulez que les histoires découlent de ces autres choses. Les histoires entrent en dernier, pas en premier.

arbre de la connaissanceAinsi, si vous voulez un arbre :

  • Débutez avec une vision de produit et une feuille de route
  • Décomposez-les en fonctionnalités et épopées
  • Dressez la carte des fonctionnalités et des épopées sur des horizons ou des versions
  • Décomposez -les alors en histoires d’utilisateur.

C’est un grand sujet et qui mérite beaucoup plus de couverture. Je recommanderais que vous lisiez User Story Mapping par Jeff Patton si vous voulez en savoir davantage.

Vous n’avez pas besoin d’évaluer toutes les histoires de l’arriéré

Certaines personnes pensent que vous devez avoir des évaluations sur tout dans l’arriéré, parce qu’autrement les items ne sont pas prêts à être travaillés. C’est-à-dire, ils ne respectent pas votre définition de « Prêts » (Ready). Et avoir quelques histoires prêtes à engager est bon, vous n’avez pas besoin que tout l’arriéré soit prêt à être entrepris. Le fait est que certaines des choses dans l’arriéré pourraient ne pas être travaillées avant une longue période de temps. Certaines d’entre elles pourraient ne jamais être développées. Et c’est OK.

Souvenez-vous, votre arriéré est fondamentalement superflu. Pour être plus spécifique, c’est le gâchis de type « Inventaire » en Lean. C’est une pile de choses qui restent là à attendre. Sans faire quoi que ce soit, sans allant où que soit, sans ajouter aucune valeur. Vous pouvez dépenser beaucoup de temps à construire, définir et évaluer un énorme arriéré de choses. Ou vous pouvez dépenser ce temps à faire en réalité du travail. C’est-à-dire à construire un logiciel.

Trouvez le bon équilibre

balance temps vs ressourcesIl existe un bon équilibre et le trouver n’est pas aisé. Si vous n’évaluez rien, vous ne savez pas combien de temps il faudra pour construire quoi que ce soit. Si vous évaluez tout, c’est beaucoup de travail. Je pense qu’il est bon d’utiliser un système « n+1 » ou « n+2”, où vous avez le prochain ou les 2 sprints suivants de travail bien défini et évalué et prêt à entreprendre. Ainsi, si vous entrez dans la planification de sprint, vous pouvez avoir une vue d’où vous allez vous rendre. Et si les choses changent et que vous décidez de prendre quelque chose d’autre dans l’arriéré qui est un peu plus loin, vous pouvez aussi le faire. Mais vous ne dépensez pas 90 % de votre temps en planification et estimations.

Mais comment faisons-nous la planification d’une version si nous n’avons pas évalué les histoires ?

Les gens se bloquent sur ce point, mais c’est très simple. Vous pouvez simplement utiliser des moyennes. Donc, vous avez les un ou deux sprints d’histoires évaluées et pour le reste de votre arriéré, vous pouvez juste utiliser des points d’histoire médians (pour cette équipe) pour chaque histoire. Si vous avez 50 points d’histoires dans vos deux sprints suivants, avec une moyenne de 6.2 points (ce ne sera probablement pas un nombre de Fibonacci). Vous avez 30 autres histoires dans votre arriéré. Donc votre taille d’arriéré de produit est de 186 (6.2 fois 30) plus 50 (vos sprints évalués) pour un total de 236. Vu ? Facile.

La vérité est, quelques histoires s’avéreront être plus grandes que la moyenne et certaines s’avéreront être plus petites et c’est OK. Parfois votre vitesse sera plus élevée, parfois plus lente et c’est OK. Si vous le pouvez, essayez de faire décomposer les histoires en tailles semblables, proches des 5 ou 8. Cela rend l’affaire plus simple et plus précise. Vous pouvez même faire des estimations approximatives pour des fonctionnalités où vous n’avez pas décomposer les histoires, avec des évaluations de niveau de fonctionnalité, ou en utilisant un nombre moyen d’histoires par fonctionnalité et en multipliant le tout.

Souvenez-vous, l’estimation n’est pas porteuse de tant de valeur en premier lieu. N’y investissez pas trop de temps. Parce que les incertitudes sur les bénéfices sont plus fortes que les incertitudes sur les dépenses.

Vous ne devriez pas mettre chaque idée à laquelle vous pouvez penser dans l’arriéré

Certains propriétaires de produit se lâchent un peu trop quand ils passent sur Agile et disent “Super, je peux mettre tout ce que je veux ici ! Étonnant !”. Et passer les 20 jours suivants à bourrer l’arriéré de plein de particules et des pièces aléatoires, comme des gosses dans une confiserie.

Ce n’est pas une bonne pratique. Souvenez-vous, les articles dans l’arriéré sont une forme de gâchis. Vous voulez une feuille de route claire et une vision pour votre produit, pas une grande liste aléatoire de blanchisserie “de choses qui pourraient être sympas”. L’arriéré devrait refléter votre vision et stratégie pour le produit. Il devrait être capable de prendre en compte des changements, mais ne l’exagérez pas et surinvestissez pas. Concentrez-vous sur votre sprint actuel et paire suivante de sprints. Essayer de penser beaucoup plus loin que cela est de la pure spéculation et n’apporte pas de valeur.

CertYou est partenaire de DantotsuPM

Vous pouvez aussi totalement enlever des choses de l’arriéré

Des personnes pensent qu’une fois que quelque chose entre à l’arriéré, il ne peut jamais en ressortir. Ils pourraient penser “quel serait le point d’ôter quelque chose de l’arriéré ? C’est juste une idée, c’est juste un item de contenu potentiel. Nous pourrions ne jamais le construire, mais il n’y a aucun mal à le garder là”. Il y en a, c’est du superflu. Il introduit de la confusion embrouille les choses. De nouveau, l’arriéré n’est pas une liste de blanchisserie, c’est une feuille de route des fonctionnalités par version et qui reflète une vision et une stratégie de produit. Tenez-le fermement et propre et à jour. N’ayez peur de supprimer des choses. Si vous voulez vraiment y revenir plus tard, vous pourrez probablement la déterrer ou y bien réfléchir de nouveau (les choses peuvent avoir changé et reprendre le besoin pourrait ne pas être une mauvaise chose de toute façon).

Les développeurs devraient avoir voix au chapitre dans l’arriéré de produit

Certains pensent que l’arriéré de produit est exclusivement le domaine du propriétaire de produit. Et c’est partiellement vrai, mais pas tout à fait. Le propriétaire de produit dit ce qui y entre et dans quel ordre. Il est responsable de l’arriéré de produit. Et généralement, les développeurs s’occupent de l’arriéré de sprint, puisque c’est leur domaine. Ils construisent la portée qui entre dans le sprint. Mais un propriétaire de produit avisé parle toujours à l’équipe comme il construit et manage l’arriéré.

Les développeurs comprennent de domaine technique du produit. Ils comprennent ce sur quoi d’autres équipes travaillent et quelles nouvelles technologies arrivent (au minimum, ils le devraient). Ils comprennent les risques techniques et les dépendances dans le travail. Donc la discussion sur l’arriéré de produit avec eux est extrêmement importante.

La planification de sprint devrait être un environnement “sans aucune surprise”. Personne ne devrait lever la main en lisant un article de l’arriéré et dire “qu’est-ce diable que cela ? Je n’ai même aucune idée de ce que cela signifie ». La planification de sprint devrait être le choix final de quels articles de portée bien définis et compris de l’équipe prêts pour entrer dans le sprint.

J’espère que cet article effacera quelques fausses idées sur l’arriéré de produit! C’est un sujet important, difficile et il existe beaucoup de lectures que vous pouvez faire si vous êtes intéressés par ce sujet.

Le Guide Nexus : L’exosquelette de développement Scrum à grande échelle !

9 Fév

NexusTM Guide

https://www.scrum.org/resources/online-nexus-guide

Nexus est une structure pour développer et supporter des initiatives de développement de logiciel avec Scrum à grande échelle.  Il utilise Scrum comme sa composante de base.  Ce guide contient la définition de Nexus qui consiste en des rôles Nexus, des événements, des artefacts et les règles qui les lient ensemble.  Ken Schwaber et Scrum.org ont développé Nexus et ce guide qui a été traduit en français.

Nexus (n) : Unité de développement (dans « Scaled Professional Scrum »)

Nexus est une structure composée de rôles, événements, artefacts et techniques qui lient et tissent ensemble le travail de trois à neuf Équipes Scrum travaillant sur un même et unique Arriéré de Produit pour construire un Incrément Intégré qui atteint un objectif précis.

Contexte de Nexus

Récupérez gratuitement ce document disponible en français et de nombreuses autres langues.

Le développement logiciel est complexe. L’intégration de ce travail en une application logicielle qui fonctionne contient beaucoup d’artefacts et d’activités qui doivent être coordonnées pour créer un résultat « Fait ». Le travail doit être organisé, séquencé, les dépendances résolues et les résultats organisés. Le logiciel présente des difficultés complémentaires par rapport à d’autres produits puisqu’il n’est pas physiquement présent.

Beaucoup de développeurs de logiciels ont utilisé la structure Scrum pour travailler collectivement comme une équipe pour développer un Incrément de logiciel qui fonctionne. Cependant, si plus d’une Équipe Scrum travaille sur le même Arriéré de Produit et dans le même code source pour un produit, les difficultés surgissent. Si les développeurs ne sont pas dans une même équipe géographiquement colocalisée, comment communiqueront-ils quand ils font un travail qui peut impacter les autres ? S’ils travaillent dans des équipes différentes, comment intégreront-ils leurs livrables et évalueront-ils l’Incrément Intégré ?

Ces défis apparaissent dès que deux équipes sont en jeu et deviennent significativement plus difficiles avec trois ou davantage d’équipes.

Il y a de nombreuses dépendances qui surgissent dans le travail entre des équipes multiples qui collaborent pour créer un incrément complet et « Fait » dans chaque Sprint.

Ces dépendances sont liées aux :

  1. Exigences : La portée des exigences peut se chevaucher et la façon dans laquelle elles sont mises en œuvre peut aussi les impacter les unes les autres.  Cette connaissance devrait être prise en compte dans l’ordonnancement de l’Arriéré de Produit et le choix des exigences sur lesquelles travailler.
  2. Connaissances de domaine : Les personnes dans les équipes possèdent la connaissance de divers systèmes informatiques. Cette connaissance devrait être reportée sur la carte des équipes Scrum pour s’assurer de son adéquation et réduire au minimum les interruptions et passage de relais entre les équipes pendant un Sprint.
  3. Logiciels et artefacts de tests : Les exigences sont ou seront instanciées dans le code de logiciel et des jeux de test.

En fonction des exigences, la connaissance des membres d’équipe, les artefacts de code et de test et leur alignement sur les équipes Scrum en présence peut permettre de réduire la dépendance entre ces équipes.

Quand le développement de logiciel utilise Scrum à grande échelle, ces dépendances entre les exigences, la connaissance de domaine et les artefacts de logiciel/test devraient diriger l’organisation d’équipe. Dans la mesure où ceci est réalisé, la productivité sera optimisée.

CertYou est partenaire de DantotsuPM

Rencontres sur le management de projet – 12 au 18 Février 2018

29 Jan

Les rendez-vous sur le management de projets et le leadership que je vous conseille cette semaine.

Mardi 13

Vous développez des logiciels ou concevez des systèmes complexes. Vous vous interrogez sur l’utilité d’une ingénierie des exigences dans un contexte agile et la manière de mettre en œuvre une démarche efficace et adaptée au contexte de l’agilité. Au cours de cette soirée animée par Stéphane Badreau, vous allez découvrir que l’ingénierie des exigences et l’agilité sont complémentaires et indissociables.

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

Mercredi 14

Many organizations want to « scale agile, » so that they can deliver more value in a given time frame. Ideally, a scaling initiative starts with one team using Scrum successfully. This team can act as a model for other teams. However, organizations tend to add more Scrum Teams hastily, and as a result, they overwhelm their ability to be agile because they tend to add more process and bureaucracy to manage those people. Agility scales successfully with a systematic, emergent, and managed initiative, and that starts with the teams. That is why Ken Schwaber the co-creator of Scrum and Scrum.org created the Nexus Framework. Nexus builds off of Scrum and is designed to enable multiple Scrum Teams to work together so that they can produce an integrated increment at least once every Sprint. It focuses on the key challenges of scaling agile delivery by encouraging transparency and a network among the teams.

Online guide

CertYou est partenaire de DantotsuPM

We all struggle with the concept of uncertainty, but it does not deter us from trying from planning the unplannable. This webinar will focus on developing project teams with the ability to share and collaborate turning ambiguity from a deficit to a vehicle that allows your assignee’s to produce added-value deliverables. We start this webinar by describing the current situation in how disjointed teams directly contribute to project failure. The effectiveness of a games model, through use of project-based simulation, is then characterized. The basis of this webinar is then illustrated through a number of situational real-life exercises performed. Lastly, we discuss the expectations of this approach, listing some of the lurking pitfalls of this method.

Jeudi 15

La direction Marketing de Thalès a choisi en 2015 la méthodologie mise au point par Strategyzer® pour définir la proposition de valeur des produits et solutions Thalès. Cette méthodologie dont le meilleur atout est la facilité d’accès permet de définir un cadre pour formaliser la valeur ajoutée tangible des offres en fonction du client cible. Dans la gestion de projet, cette méthodologie permet de mieux structurer les priorisations qui doivent être faite pour tenir le triangle scope / time / budget.

Méta Projets Management est partenaire de DantotsuPM

APMG est partenaire de DantotsuPM

“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.

Les meilleurs plans partent souvent à vau-l’eau: Plaidoyer en faveur de prises de décisions le plus tard possible.

24 Jan

Le développement de logiciel est un effort complexe dans lequel les suppositions et les décisions devraient être prises le plus tard possible.

The Best Laid Plans often go awry

https://www.scrum.org/resources/blog/best-laid-plans-often-go-awry par John Gillespie

Quand Henry Ford a conçu ses usines en 1913 pour construire la Modèle T, il a réduit le temps nécessaire pour assembler une voiture de plus de 12 heures à 2 heures 30 minutes.  Ce processus a permis la production d’une automobile à prix ciblé pour “le travailleur”.  Toutes les voitures avaient la même conception et toutes étaient peintes en noir.

Les designs préconfigurés fonctionnent quand les prévisions rencontrent les attentes (qui en 1913 aurait demandé une voiture rouge ?) et quand un spécialiste peut remettre son travail au suivant sans aucune perte de temps dans la transmission.

Quand une société est dans le business de produire des produits et des services innovants, ses plans reposent sur une ou plusieurs estimations et suppositions.   Ces évaluations ne sont rien de plus que des probabilités.  Baser un plan de projet sur des suppositions exige que votre système puisse manager les changements.

Livre sur Amazon

Marie Poppendieck a exposé dans Lean Software Development, An Agile Toolkit, “le simple fait mathématique ici au travail est que toute variation est toujours amplifiée comme elle déplace le long d’une chaîne d’événements connectés. Une petite variation dans une étape peut représenter une énorme variation cinq étapes plus loin”.  Donc la question reste entière quant à pourquoi les managers continuent à planifier des projets en se basant sur des suppositions séquentielles.

Pour comprendre comment un changement inattendu peut causer des retards significatifs en aval, visualisez une chaussée très occupée avec des voitures se déplaçant selon la limitation de vitesse.  Le trafic s’écoule régulièrement jusqu’à l’entrée d’un nouveau véhicule ou autre événement qui fasse qu’un conducteur actionne ses freins.  Le trafic sur la chaussée ralentit ou s’arrête alors pendant une brève période puis recommence à s’écouler de nouveau sans signe apparent de pourquoi il a ralenti en premier lieu.  L’exemple de cette route illustre comment, à moins que les systèmes ne soient conçus pour se concentrer sur le flux, ils ne fonctionneront pas efficacement à pleine capacité.  Parce que le développement de logiciel est un effort complexe dans lequel les suppositions et les décisions devraient être prises le plus tard possible.  Le fait de prendre des décisions au dernier moment possible permet à l’équipe Scrum de changer pour travailler sur les articles d’arriéré de produit de plus de valeur en fonction des données les plus récentes.

CertYou est partenaire de DantotsuPM

L’empilement de beaucoup de suppositions l’une après l’autre dans un plan de projet réduit significativement la probabilité d’un résultat positif.

Par exemple, considérez cinq tâches tout d’une probabilité de 90 % d’achèvement en une semaine: (0.9 * 0.9 * 0.9 * 0.9 * 0.9 = 0.59). Dans ce cas, nous avons cinq tâches sur lesquelles nous nous sentons confiants, mais le résultat cumulatif est que nous sommes à seulement 59 % de probabilité de finir ces cinq tâches en cinq semaines.  Je soutiendrais que basé sur mon expérience de professionnel en management de projet, il est aussi peu probable que cinq tâches séquentielles atteignent jamais chacune un niveau de confiance de 90 %.  Alors, êtes-vous encore étonné quand vous lisez Standish Group’s Chaos Report qui indique qu’approximativement 70 % de tous les projets des technologies de l’information échouent à atteindre leurs objectifs et sont significativement en retard et sur-dépensent ?

Ceci n’empêche pas que vous devriez adorer les statistiques 🙂

La meilleure façon d’optimiser la livraison de valeur est de faire des tâches ajoutant une valeur visible pour les parties prenantes.  La documentation de chaque flux de valeur mettra en évidence l’avancée et les retards entre les transitions.  En évaluant quantitativement des activités du flux de valeur, le coût des retards devient aussi visible.  Cette visibilité aidera l’organisation à déterminer où la constitution d’équipes fonctionnelles transverses améliorera immédiatement les temps de réponse.

L’utilisation de Scrum pour rendre ces inefficacités visibles est seulement le premier pas.

Le leadership a-t-il le désir et l’engagement d’effectuer le changement ?  Craig Larman, l’auteur des Laws of Organizational Behavior, a observé que les organisations sont implicitement optimisées pour éviter de changer les positions de statu quo et les structures de pouvoir. Il a aussi noté que si vous voulez changer la culture d’une société, vous devrez changer la structure de votre organisation parce que la culture/comportement et la mentalité suivent les systèmes organisationnels et leur design.

Les organisations comme des sociétés d’assurance et banques ont typiquement les silos de spécialisation fortifiés autour des applications, technologies et fonctions.  Chacun de ces départements a développé des règles soigneusement travaillées et des procédures interdisant le changement.  Ces processus administratifs ont pour conséquence fortuite de perturber le flux de valeur qui va du concept à la livraison au client.

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

Marie Poppendieck a décrit cette situation Lean Software Development: An Agile Toolkit, “la règle établie pour résoudre un problème renforcera souvent le problème, créant une spirale vers le bas : Comme un problème empire, les managers appliquent encore plus agressivement la même politique qui cause le problème.”  La mise en place d’équipes fonctionnelles transverses qui ont toutes les compétences pour achever le travail sans avoir à traverser des silos fonctionnels aura un impact étonnamment positif sur la capacité des organisations d’améliorer la qualité et le temps nécessaire pour commercialiser.

Votre direction a-t-elle le courage et l’engagement d’entreprendre le dur labeur d’éliminer les processus et les procédures qui n’ajoutent pas de valeur ?

La plupart des sociétés considérant l’adoption de Scrum devront changer leurs structures organisationnelles pour soutenir des équipes fonctionnelles et transverses autonomes.  Si la structure organisationnelle ne change pas, les comportements ne vont pas probablement changer.  Si votre modèle business dépend de l’innovation, ce changement devrait être d’une priorité supérieure.

Réalisez-vous des démonstrations éblouissantes ?

15 Jan

Voici quelques-unes des choses à faire et ne pas faire pour accroître la valeur que votre équipe tirera des  démonstrations.

Do you deliver dazzling demos?

https://kbondale.wordpress.com/2017/01/08/dos-and-donts-for-delivering-demos/ par Kiron Bondale

Les démonstrations ou « showcase » comme elles sont parfois appelées, sont des cérémonies critiques quand elle sont menées efficacement car elles adressent des objectifs multiples du projet en un événement simple incluant :

  • démonstrationValider que ce que l’équipe a achevé jusqu’à présent est de valeur de la perspective de leur client et d’autres parties prenantes importantes
  • Aider l’équipe et les parties prenantes à changer ou développer leur compréhension de la solution souhaitée
  • Obtenir l’acceptation des parties de travail achevées dans les organisations où une telle signature est un préalable exigé pour mettre en œuvre le changement
  • Faciliter un rapport d’avancement transparent car les parties prenantes voient ce qui a été promis par l’équipe et ce qui a été livré
  • Fournir aux membres d’équipe des retours réguliers et une reconnaissance de leur travail , ce qui augmente les niveaux de satisfaction au travail et l’engagement

Mais les démonstrations peuvent (comme d’autres pratiques de management de projet) aboutir à un résultat pire que si elles avaient été omises.

Voici quelques-unes des choses à faire et ne pas faire pour accroître la valeur que votre équipe tirera des  démonstrations.

  • A faire : Envoyez les invitations pour la rencontre à l’avance et si vous suivez une cadence de sprint ou d’itération standard (par exemple toutes les deux ou trois semaines). Envoyez un jeu d’invitations récurrentes.
  • A ne pas faire : Les démonstrations le vendredi après-midi afin d’éviter d’avoir les parties prenantes absentes de corps ou d’esprit.
  • A faire : Partagez la richesse en vous assurant que chaque membre de l’équipe ait son opportunité de  présenter une démonstration.
  • A ne pas faire : S’en servir pour vous plaindre de l’équipe, des points de blocage ou ce qui aurait pu ou dû être fait différemment.
  • A faire : Fournissez objectivement le contexte sur le sprint ou résultats itératifs (par exemple le prévu versus le réalisé).
  • A ne pas faire : Présenter une démonstration sans avoir testé à l’avance ce que vous allez montrer.
  • A faire : Invitez les représentants du client et parties prenantes associées appropriées à vos démonstrations.
  • A ne pas faire : Submerger vos parties prenantes de contenu.
  • A faire : Enregistrez les présentations à l’avance ou, si vous vous sentez chanceux, pendant la démonstration elle-même pour le bénéfice de parties prenantes qui ne pourraient se libérer.
  • A ne pas faire : Prendre les retours négatifs personnellement.

Bien que cet article soit principalement destiné aux équipes qui utilisent une approche de développement Agile, il est également applicable aux projets traditionnels. Les démonstrations éblouissantes peuvent aider à maintenir l’attention, conserver l’appui de votre client et maintenir les membres de l’équipe concentrés sur délivrer de la valeur.

CertYou est partenaire de DantotsuPM

Certifications Agile et Scrum

12 Jan

Agile and Scrum Certification

http://www.growingagile.co.za/2013/01/agile-and-scrum-certification/  par Karen Greaves

Scrum Alliance

La Scrum Alliance était le premier organisme de Certification Scrum, fondée en 2002. Elle offre une gamme de Certifications Scrum, la plus populaire étant le Certified Scrum Master (CSM). Il y a actuellement plus de 400000 CSMs dans le monde. Le CSM est une certification de niveau d’entrée. Pour obtenir le CSM vous devez suivre une formation de 2 jours donnée par un Certified Scrum Trainer (CST) et réussir ensuite un test en ligne avec le livre ouvert. Pour trouver une formation proche de vous, allez sur le site  de la Scrum Alliance. Les tarifs des cours varient selon la région et le fournisseur. Si vous considérez cette certification, la meilleure approche est d’acquérir quelques mois d’expérience avant d’y aller. Ainsi, vous saurez quelles questions poser et les parties sont les plus difficiles pour vous.

La Scrum Alliance offre aussi une certification de niveau d’entrée pour des Propriétaires de Produit appelés le Certified Scrum Product Owner (CSPO). Un cours de 2 jours donné par un CST. Actuellement, il n’y a pas de test sur le CSPO.

Certified Scrum Product Owner offre un parcours de certification avec Certified Scrum Professional (CSP), Certified Scrum Coach (CSC), Certified Enterprise Coach (CEC), Certified Agile Leader (CAL) et Certified Scrum Trainer (CST) pour ceux avec plus d’expérience. Vous pouvez en découvrir davantage sur ces programmes sur le site de la Scrum Alliance.

Scrum.org

Ken Schwaber a quitté la Scrum Alliance et formé Scrum.org en 2009. Ils offrent maintenant des certifications Scrum. Vous pouvez passer la certification Scrum.org en ligne sans suivre de formation. La certification Scrum.org est appelée Professionnel au lieu de Certifié. PSM au lieu de CSM. Il y a des niveaux multiples sur chacune des certifications de Scrum.org, c’est-à-dire PSM I, II et III. Il y a actuellement plus de 75000 I PSM, 600 PSM II et 360 PSM III dans le monde. On considère le PSM comme l’équivalent du CSM.

Vous pouvez passer les évaluations sans suivre aucun cours, mais il y a un coût à prendre l’examen. Scrum.org offre aussi un Professional Scrum Product Owner (PSPO). Les prix des cours varient par région et formateur.

Project Management Institute (PMI-ACP)

Listée en dernier parce que ce n’est pas une certification spécifique à Scrum, il y a l’offre du PMI : le Praticien Certifié Agile (PMI-ACP). Actuellement il y a 17000 détenteurs de la certification PMP-ACP. C’est une offre agile semblable au PMP dans la gestion de projet traditionnelle. Elle exige la preuve tant d’expérience de gestion de projet traditionnelle que d’expérience agile et il faut réussir une évaluation dans un centre d’examen autorisé.

Pour tous les détails (en anglais)

Bien qu’il n’y ait aucun cours spécifique exigé, 21 heures de formation sont requises. Comme avec le PMP, il y a des cours préparatoires disponibles pour fournir les heures de formation nécessaires et couvrir le matériel que vous devez connaitre.

CertYou est partenaire de DantotsuPM

“PMI,” the PMI logo, “PMP,” “Project Management Institute” and “PMI-ACP” are registered marks of Project Management Institute, Inc.

Rencontres sur le management de projets – 22 au 28 Janvier 2018

8 Jan

Les rendez-vous sur le management de projets et le leadership que je vous conseille en cette quatrième semaine de Janvier :

Lundi 22

Mardi 23

Les organisations et les projets sont de plus en plus complexes. Et ces derniers impliquent de plus en plus de parties prenantes pouvant influencer positivement ou négativement le projet, il devient impératif pour le chargé de projet qui possède un pouvoir limité de savoir communiquer afin d’assurer l’atteinte des objectifs du projet. Il existe 4 façons distinctes de communiquer, d’apprendre et de prendre des décisions. Dans le cadre de cet atelier, vous obtiendrez votre profil de couleurs un outil efficace de communication en mode projet. Connaître son style de communication et celui des autres vous permettra d’optimiser efficacement vos réunions d’équipe de projet à coup sûr.

“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.

Agile Big Ticket Change: Agile for Big Ticket Change delivers large transformation programmes using agile at scale in an otherwise waterfall/traditional organisation. Agile Transformation: Agile Transformation is the scaled metamorphosis of an organisation to achieve enterprise-level agility – think Amazon or Google. Case study: Agile Transformation at a large Bank.

CertYou est partenaire de DantotsuPM

Neurosciences et formation, mieux connaître notre cerveau pour mieux apprendre. On a longtemps estimé que l’intelligence était acquise dès la naissance ou la petite enfance. Or, les recherches sur le cerveau prouvent le contraire. Chaque jour, le cerveau génère de nouveaux neurones et de multiples connexions pour apprendre encore et toujours. Encore faut-il utiliser les subtilités de notre cerveau à bon escient !

CSP est partenaire de DantotsuPM

How can we as Project Managers spot and develop the critical skills that projects in a digital age are increasingly demanding? Get prepared, we will pick your brains!

 Requiring nothing more than configuration changes to Microsoft Project and the Project Server, PPM can be used very successfully to manage Agile projects.

Mercredi 24

Organisé en partenariat avec l’Université de Rennes 1, le Forum PMI Atlantique 2018 se déroulera dans le cadre exceptionnel de la salle de spectacle « Le Diapason », espace de vie et de culture au cœur du Campus de Beaulieu à Rennes. « S’ouvrir à l’international » est le thème retenu pour cette journée qui sera composée de conférences, ateliers et moments de convivialité où l’on pourra débattre et partager autour de sujets tels que les enjeux multiculturels et générationnels, le management virtuel, les outils collaboratifs et d’autres encore que nous vous révèlerons très vite.

The Project Management profession is continuously evolving and increasingly leveraging business and technology innovations. Creating value out of data is one of the highest priorities in business across all industries and services in the private, public and third sectors alike. But what about the effective use of data in Project Management?

Jeudi 25

Agile Software Development is about mindsets and practices where solutions evolve through collaboration between self-organizing, cross-functional teams.
It requires significant transformation at company level for an efficient deployment to generate the expected benefits. It starts with the integration of the Agile principles within the project management processes, that will be detailed in the first part of this conference. In the second part, we will illustrate it with an example of Agile deployment in Amadeus, a key player in IT solution development in the region.

There are many views about the processes associated with highly successful program and portfolio management practices and how to apply these processes in actual business environments. This presentation will address the application and processes of program and portfolio management from a perspective that includes the project manager as well as the executive or strategic viewpoint.

SMPP est Partenaire de DantotsuPM – Référentiel gratuit téléchargeable.

Vendredi 26

The challenges of Today’s project managers, the issues facing the profession in the near future, and the specific skills a project manager must attain and continue to enhance to remain successful in this very challenging and demanding discipline. What are the specific skills required to achieve organizational goals, meet project objectives and continually add value from a client and supplier perspective with emphasis on business skills, interpersonal skills, leadership skills and project management competency? The gaps between project manager and executive management are identified and possible actions to close those gaps offered. And let’s not forget the importance of work life balance.

Présentation des principales évolutions de la nouvelle version du PMBOK :

    • L’alignement des projets aux objectifs stratégiques de l’organisation
    • Une nouvelle section dédiée au rôle du Project Manager
    • La relation entre le Project Manager et le Business Analyst
    • L’ouverture vers l’agilité
    • Les autres changements et tous les conseils pour mener à bien vos projets !

Déjà en 2009, un article nous invitait à l’hybridation des méthodes de management de projets et prônait la complémentarité plutôt que l’opposition

4 Jan

Dans cet article, l’auteur a pris le parti de la complémentarité plutôt que de l’opposition entre les méthodes de développement traditionnelles et Agile.

Serhiy Kharytonov

Selon Serhiy Kharytonov, le choix entre les méthodes « en cascade », RUP (rational unified process) et agile, dépend à la fois de l’expérience de l’équipe, de la culture d’entreprise, du type de projet, de l’environnement, du mode de développement interne/externe, et prend en compte la dispersion géographique de l’équipe.

Une combinaison des trois méthodes selon les moments du cycle de développement pourrait être une bonne approche.

Cet article qui date pourtant de presque dix ans reste étonnamment actuel.

Utilisez vous d’autres critères de choix de votre approche de développement?

Waterfall, RUP et Agile : quelle est la bonne méthode de développement logiciel  pour vous?

Article original de Serhiy Kharytonov, SoftServe © 2009

Rationalisez la production avec les processus rapides et efficaces « en cascade », RUP et Agiles. Créez le bon mix de stratégies de développement logiciel afin de répondre aux besoins spécifiques de votre projet.

Malgré les signes de reprise dans l’économie, une réalité persiste dans le développement logiciel: La plupart des sociétés et clients ont besoin de leur logiciel pour hier avec les fonctionnalités les plus avancées au coût le plus faible possible.

Pour atteindre ces objectifs apparemment contradictoires, les développeurs cherchent à rationaliser la production avec des processus rapides et efficaces qui peuvent donner au client ce qu’il veut en un laps de temps le plus court possible.

Ces constantes et les échecs de développement passés ont mené à un changement dans le développement logiciel depuis des méthodes très structurées, séquentielles de développement logiciel souvent appelées le modèle Waterfall / « en cascade », vers des modèles plus itératifs et progressifs tels que « Rational Unified Process » et « Agile. »

Les partisans d’Agile sont nombreux et il peut parfois sembler que les processus de développement plus traditionnels sont tombés en défaveur, mais en réalité les trois modèles ont leurs avantages, leurs incovénients et leurs environnements de projet favoris.

Au bout du compte, la meilleure méthode ou le meilleur mix de méthodes pour vous dépend d’une compréhension minutieuse des trois processus et comment ils s’adaptent à votre projet logiciel, votre culture business et votre propre environnement de développement.

Waterfall / « En cascade »

La programmation « en cascade » est un processus fortement structuré qui compte fortement sur une planification initiale et un ensemble d’étapes séquentielles, prescrites qui découlent l’une de l’autre comme l’eau dans une une cascade. Chaque étape a typiquement sa propre équipe d’experts et jalons soigneusement préparés à l’avance et aucune étape ne peut commencer tant que l’étape précédente n’a pas été complétée. Le but est de recueillir tous vos besoins détaillés tôt dans le processus et de fournir une seule solution complète  avec des résultats qui sont fortement prévisibles. On appelle aussi souvent cette approche le cycle en « V ».

Typiquement les étapes dans le développement « en cascade » sont :
  1. Recueil des besoins et rédaction du cahier des charges
  2. Analyse fonctionnelle
  3. Développement du code
  4. Intégration
  5. Test et mise au point
  6. Installation
  7. Maintenance

Ceci peut marcher très bien pour des applications complexes, critiques à la mission de l’entreprise et qui s’intègrent avec de nombreux autres systèmes ou pour des organisations comme la NASA ou l’armée qui exigent les plus hauts niveaux de fiabilité.

Les détracteurs disent que le « Waterfall » demande simplement trop longtemps et manque de la flexibilité, ou de l’agilité, requise pour le marché logiciel actuel avec son environnement de développement en constant mouvement. Les projets qui suivent la méthode « en cascade » prennent typiquement des mois ou des années et quand ils sont finis, on découvre parfois que les besoins ont changé ou que les besoins originaux étaient incorrects depuis le départ. Le résultat peut alors être des corrections onéreuses explosant le budget initial.

RUP (rational unified process)

Comme la « cascade », le Rational Unified Process (RUP), produit par Rational Software et plus tard par IBM, est aussi un processus lourd, mais c’est une approche itérative qui prend en compte le besoin de répondre au changement et introduit de l’adaptabilité pendant le processus de développement.

Comme la « cascade », RUP a une série de phases et des jalons qui découlent l’un de l’autre :
  1. L’initiation, où la portée du projet, l’évaluation des dépenses, des risques, le business case, l’environnement et l’architecture sont identifiés.
  2. L’élaboration, où les besoins sont spécifiés en détail, l’architecture est validée, l’environnement de projet est détaillé et l’équipe de projet est configurée.
  3. La construction, où le logiciel est construit et testé et la documentation de support est produite.
  4. La transition, où le logiciel est testé au niveau système et utilisateur, corrigé et déployé.

RUP définit en détail les rôles et les activités de membres de l’équipe et compte à chaque étape sur la production de modèles visuels, qui sont les représentations graphiques riches de systèmes logiciels et des cas d’utilisation spécifiques plutôt que de grandes quantités de documentations requises pour chaque étape « Waterfall ». Tous les membres de l’équipe ont accès à la même grande base de connaissance de guides, modèles, outils et autres articles pour s’assurer qu’ils partagent les mêmes langages et perspectives sur le projet.

Alors que cela apparaît de prime abord similaire au développement « en cascade », la plus grande différence du RUP est son approche de développement itérative, qui construit le produit en plusieurs étapes basées sur des revues fréquentes avec les parties prenantes. Les premières itérations RUP sont surtout de la définition de besoin, de l’architecture et l’exploration de différentes idées, alors que les itérations ultérieures essayent d’assembler un produit complet. Chaque itération est un livrable exécutable et chaque phase RUP peut interagir avec les phases précédentes pour s’adapter au besoin.

Non seulement le processus RUP est itératif dans son ensemble mais RUP suppose aussi que chaque phase ait plusieurs itérations internes basées sur des retours utilisateurs.

RUP adresse bon nombre des critiques du développement « Waterfall » et c’est une bonne méthode pour des agences gouvernementales et institutions éducatives qui apprécient un cycle de développement de logiciel stable et répétable, ainsi que pour des organisations qui « offshore » les développements dans des pays comme l’Inde et la Chine, ou qui produisent des progiciels.

Les critiques disent que RUP n’est pourtant pas aussi rapide ni adaptable que d’autres méthodes, comme Agile et ne marche pas bien quand un délai de mise sur le marché rapide est crucial et là où l’on s’attend à des mises à jour fréquentes et des compléments rapides de fonctionnalités.

Agile

Tandis que « Waterfall » et RUP penchent vers la prédictibilité, les buts principaux d’Agile sont la vitesse et l’adaptabilité. Il y a beaucoup de types différents de processus de développement Agile, dont XP et SCRUM, et tous s’efforcent de mettre une version du produit basique mais fonctionnelle entre les mains du client aussi vite que possible.

Ils font alors suivre cette version par des versions successives qui ajoutent et changent les fonctions nécessaires au fil du temps pour fournir un produit plus robuste. Chaque module successif est planifié, codé, testé et complété sur de courtes périodes de deux à quatre semaines. Bien que le processus Agile soit planifié d’avance comme en « Waterfall » et RUP, il fait passer les gens et la collaboration avant le processus lui-même.

Plutôt que de dépendre d’équipes composées de nombreux experts, le processus de développement Agile est typiquement entrepris par une seule, petite équipe, cross-fonctionnelle, censément auto-organisée, qui doit inclure un représentant client qui suit des réunions quotidiennes et s’assure que l’équipe travaille sur les choses dont le business a vraiment besoin. La constante collaboration en face à face est l’objectif, avec le représentant du client comme l’un des collaborateurs les plus importants. La documentation est dé-priorisée par rapport à l’approche « Waterfall » et même RUP pour sortir quelque chose aussi rapidement que possible.

Avec son approche modulaire, progressive, faite en collaboration, Agile est rapide et fortement adaptative au changement des besoins et réponses aux challenges amenés par la compétition, qui sont les raisons de tant de partisans.

Certaines sociétés sont fréquemment citées comme ayant utilisé la programmation Agile avec beaucoup de succès, avec des cycles de développement de 30 à 90 jours qui ont apporté une productivité spectaculaire et des avantages business par rapport aux 18 mois ou plus pris dans le passé pour produire un logiciel utilisable.

Mais même s’il est facile de tomber amoureux d’Agile, l’approche a aussi ses limitations et inconvénients. Son accent sur les réunions quotidiennes en physique et la collaboration rapprochée rend le processus difficile à adapter à l’externalisation des développements, à des situations où clients et développeurs sont géographiquement éloignés, ou aux clients qui n’ont tout simplement pas les compétences, les ressources ou le focus nécessaires.

Son accent sur la modularité, le développement progressif et l’adaptabilité ne convient pas aux clients qui veulent des contrats avec des évaluations fermes et définitives et des échéanciers fixes. Sa dépendance sur de petites équipes auto-organisées rend difficile l’adaptation aux grands projets logiciels avec de très nombreuses parties prenantes aux besoins  différents et néglige de prendre en compte le besoin de leadership pendant que les membres de l’équipe s’habituent à travailler ensemble.

De plus, le manque de documentation complète peut rendre la maintenance et les nouveaux développements difficiles quand les membres de l’équipe originale laissent leur place à d’autres. Cela peut mener à des modules aux fonctionnalités et interfaces inconsistantes. Finalement, plus qu’avec le « Waterfall » et RUP, le développement Agile dépend éminemment de la capacité à recruter des analystes fonctionnels très expérimentés qui savent comment travailler indépendamment et s’interfacer efficacement avec des utilisateurs métiers.

CertYou est partenaire de DantotsuPM

Le meilleur de chaque monde

Si Agile, RUP et des modèles « en cascade » ont chacun leurs inconvénients, lequel devriez-vous choisir ? De plus en plus, le secret des développements logiciels réussis est de comprendre les trois processus dans le détail et de sélectionner les parties de chacun qui conviennent le mieux à leurs livrables et environnements spécifiques. Donc, être agile dans l’approche même du choix du processus, en regardant sans cesse ce qui a été réalisé, en réévaluant et révisant le processus de développement jusqu’à ce qu’il s’adapte au mieux aux circonstances actuelles.

Par exemple, si vous développez du logiciel « Software as a Service » SaaS dans un marché fortement concurrentiel, vous ferez probablement le meilleur choix en penchant vers des méthodologies Agile. Le SaaS se prête particulièrement bien à Agile puisqu’il prévoit un accès constant au logiciel pour y ajouter ou en changer des caractéristiques. Dans un tel marché concurrentiel avec des besoins utilisateurs changeants, vous voudrez probablement être capables d’apporter rapidement des changements.

D’un autre coté, si vous produisez pour le médical, l’ingénierie, ou autres systèmes qui exigent un haut degré de design et de certitude, alors il semble logique de commencer par du »Waterfall ».

Si vous produisez un progiciel grand public « sur étagère », avec de nouvelles versions qui vont être des enrichissements des versions précédentes, votre processus devrait probablement pencher vers RUP, avec une attention particulière sur le recueil des besoins, la définition du périmètre et du contenu au tout début, ainsi que des standards de parcours et d’interface utilisateur.

Quel est le meilleur de chaque approche que vous puissiez utiliser sur votre projet ?

Les développeurs peuvent tout de même utiliser des techniques Agile pour présenter des prototypes fréquents et des modules successifs aux chefs de produit de la société pour s’assurer qu’ils sont sur la bonne voie. La fréquence et l’intensité de collaboration entre chefs de produit et développeurs dépendent vraiment de leur proximité et de la culture de la société (selon que ces équipes soient plus ou moins habituées à une telle collaboration). Quand la distance géographique est un problème, les outils de collaboration comme la conférence à plusieurs sur le web et la vidéo peuvent être d’une grande aide.

Ce même mélange de techniques peut être utilisé dans un environnement d’externalisation du développement en « offshore ». En fait, avec les différences de fuseaux horaires et de cultures, il est important d’intégrer autant d’étapes itératives et progressives et autant de contacts de suivi que possible pour votre projet.

Choisir de partir sur des équipes auto-organisées ou une approche plus directive (« top-down ») de management dépend aussi du niveau de compétence et d’expérience de vos développeurs. Beaucoup de projets peuvent exiger au départ un leadership qui va ajouter une certaine urgence, une direction et une gestion des risques du projet jusqu’à ce que les membres de l’équipe s’habituent à travailler ensemble. Alors le rôle de leadership peut être réduit selon les besoins lors des itérations suivantes.

Le bilan est qu’il n’y a probablement aucun processus parfait pour tous les projets et tous les environnements, ni même pour un seul.

C’est pourquoi les sociétés doivent intégrer fréquemment « les leçons apprises » pour évaluer et réviser le processus lui-même, qui peut se déplacer d’un bout à l’autre du spectre à différents moments dans le cycle de développement.

Bref, en choisissant entre Agile, RUP et « Waterfall », adaptez le processus à vos besoins, plutôt que de chercher à adapter votre projet au processus !

Les articles les plus sur DantotsuPM.com au mois d’Octobre 2017

20 Déc

Les « guest writers » sont à l’honneur, merci à eux !

  • 3 articles de Rose-Hélène Humeau figurent parmi les plus appréciés par les lecteurs et nous t’en remercions !
  • Olivier Raguideau qui nous intrigue avec son billet sur l’impact de la distance dans les projets.
  • Louis-Marie Resseguier et ses 5 bénéfices majeurs de Kanban nous ouvrent à de nouvelles approches.

Livre sur Amazon

les 4 accords toltèques: 4 règles de vie à appliquer dans vos projets

C’est l’histoire d’un livre devenu culte, publié en 1997 par Don Miguel Ruiz (The four agreements), qui s’est écoulé à plus de 4 millions d’exemplaires dans le monde.

identifiez les parties prenantes qui comptent dans votre projet avec le modèle Salience®

Client, Sponsor/Commanditaire, équipe… voici les parties prenantes pour lesquelles nous faisons un effort de communication et d’implication dans nos projets. Est-ce suffisant ?

PAS LE TEMPS… …VOUS ÊTES PRESSÉ ?

Il n’y a pas de temps à perdre… il faut boucler le projet, respecter les échéances, lire et répondre aux mails, finir le rapport…. Le temps file entre mes doigts et je courre après… Vous aussi ? Voici trois conseils que j’ai mis en œuvre pour reprendre le contrôle.

Quelles habitudes rendent les chefs de projets plus performants et plus efficaces

Lors de l’enquête auprès des lectrices et lecteurs du blog DantotsuPM, la capacité d’organisation personnelle des chefs de projet est remontée comme le plus fort contributeur à leur réussite. En numéro 3 : c’est plus une question d’attitude que de compétences qui est ressortie.

Méta Projets Management est partenaire de DantotsuPM

Olivier Raguideau

Quels sont les impacts de la distance sur le management de projet et les acteurs nomades ?

La mondialisation de l’économie oblige les entreprises à rechercher tous les facteurs d’efficience et obtenir un avantage concurrentiel dans un marché où la chrono compétition est de rigueur.

Connaissez-vous les 5 principaux bénéfices de la planification de projet avec l’outil Kanban ?

La méthode Kanban adaptée à la planification de projet présente en effet de réels atouts

SMPP est Partenaire de DantotsuPM – Référentiel gratuit téléchargeable !

Disponible sur Amazon en Anglais et sur PMI.ORG pour les certifiés en pdf gratuit

Pourquoi les PMPs devraient lire la 6ème édition du PMBOK Guide

Le Project Management Institute (PMI) a sorti la 6ème édition du PMBOK le 6 septembre dernier.

Certains chefs de projet certifiés peuvent être tentés d’y répondre par “eh bien, je suis heureux que l’obtention de la certification soit derrière moi.”

Cependant, je pense que les PMPs et les autres chefs de projet certifiés devraient lire cette 6ème édition. Pourquoi ?

alors que nombre d’entre nous adoptent l’agilité, n’oublions pas les bénéfices du management de projet traditionnel en cascade

Aujourd’hui, beaucoup de business optent au lieu de cela pour la gestion de projet Agile. Les personnes qui utilisent cette méthode se concentrent sur la production de petites parties du projet dans chaque cycle de livraison, plutôt que la création d’un plan pour le projet entier. Cependant, l’approche en cascade traditionnelle du management de projet a toujours plusieurs bénéfices clefs.

CertYou est partenaire de DantotsuPM

La possibilité de Peter

Le Docteur Laurence Peter a compris la promesse et le danger de la bureaucratie mieux que la plupart d’entre nous. Il y a cinquante ans, il a écrit, « les managers s’élèvent jusqu’à leur niveau d’incompétence ».

“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.

Les articles les plus sur DantotsuPM.com au mois d’Aout 2017

11 Déc

Ce fut en août dernier que parurent la toute dernière édition du PMBoK® Guide et le premier Agile Practice guide.

Sur DantotsuPM, vous avez particulièrement apprécié les billets sur les compétences douces mais aussi celles plus techniques comme Ishikawa et de Reporting ainsi que sur l’agilité avec les rétrospectives.

Disponible sur Amazon en Anglais et sur PMI.ORG pour les certifiés en pdf gratuit

PMBOK® Guide – la 6ème édition

Réalisé par de chefs de projets pour les chefs de projets !

Disponible en ligne dès le 6 septembre

Le Guide to the Project Management Body of Knowledge (PMBOK® Guide) – 6ème édition est la dernière évolution de cette ressource clé pour les chefs de projets.

Connaissez-vous le nouveau Agile Practice Guide (en anglais) ?

PMI et Agile Alliance se sont mis au travail ensemble pour produire le Agile Practice Guide dans l’intention de forger une meilleure compréhension des pratiques agiles pour les chefs de projet.

Utilisez ces 15 vérités pas si évidentes sur les compétences relationnelles

Beaucoup de professionnels techniques et non intuitifs me disent que maitriser les aspects pas si évidents des compétences interpersonnelles (des compétences douces ou compétences relationnelles) leur pose un grand défi, voire un réel casse-tête. Où trouver les vérités sur les compétences relationnelles à apprendre et utiliser ?

Les 3 petits cochons et les rétrospectives Agiles amusantes

Les trois petits cochons sont une activité de rétrospective amusante qui utilise l’histoire des 3 petits cochons pour favoriser une conversation sur les améliorations pour obtenir de plus solides structures.

MPM est partenaire de DantotsuPM

Faire un rapport de projet: simple et difficile à la fois !

En tant que chef de projet, vous voulez faire un rapport efficace sur le statut de projet en fournissant des informations suffisantes aux parties prenantes en réduisant aussi la quantité d’aller-retour sur ces communications nécessaires. Ceci signifie des informations complètes, détaillées fournies de façons qui conviennent avec les parties prenantes, mais marchent aussi pour vous comme chef de projet. Cela peut être un challenge !

Et si vous alliez à la pêche… …aux causes du problème !

Avez-vous des problèmes ? Des projets en retard sur l’échéancier ? Des temps de cycle de processus métier en augmentation? Ventes en baisse ? Les gens continuent de vivre dans des silos ?

Discutons d’un outil simple mais puissant pour résoudre les problèmes – le Diagramme en arête de poisson « Fishbone Diagram » (Le diagramme de cause et effet).

CertYou est partenaire de DantotsuPM

Le management de projet Agile ne s’applique pas seulement au logiciel et aux projets informatiques !

Il est compréhensible que cette idée fausse existe. Après tout, le concept entier d’Agile est né dans le secteur informatique et dans le domaine du développement de logiciel. Cependant, ce mythe (selon lequel Agile ne s’applique qu’aux projets IT) n’est pas vrai et c’est un mythe qui a besoin d’être éliminé une fois pour toutes.

“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.

%d blogueurs aiment cette page :