Comment bien décomposer le travail à réaliser dans son projet pour mieux le planifier ?

Practice Standard for Work Breakdown Structures

Les structures de répartition du travail (SRT) ou en anglais WBS (Work Breakdown Structures) sont un élément clé du processus de planification du projet, quelles que soient les industries, les organisations et les spécialités.

Livre sur AmazonLa SRT organise le périmètre total d’impact du projet et de sa réalisation en reflétant le travail précis et les livrables à produire. Ceci aide grandement les managers de projets à organiser la façon dont ils construisent et partagent l’échéancier, puis en font le suivi des projets. Ils et elles y intègrent les plans de management des risques pour les surmonter s’ils surviennent.
Le PMI® vient publier une mise à jour complète de ce recueil des meilleures pratiques « Practice Standard for Work Breakdown Structures (3rd Edition) » avec un focus spécifique sur les cycles de vie des projets Agile, itératifs, prédictifs comme incrémentaux.
Partenaire de DantotsuPM

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

Restez sur les rails en gardant à l’esprit les préceptes fondamentaux de Agile et les principes qui les sous-tendent.

Téléchargez gratuitement Le Manifeste Agile : 4 préceptes et 12 principes !

Imprimez-les, affichez-les au mur, faites-les suivre à vos équipes et surtout, appliquez-les !

Le Manifeste Agile a été écrit en février 2001 par 17 développeurs informatiques libres d’esprit. Il a donné naissance au mouvement Agile dans le développement de logiciels. Bien que chaque méthodologie Agile applique les préceptes et les principes à sa manière, ceux-ci leur servent de guide tout au long du processus de développement.

à télécharger en langue anglaise sur Agile Alliance.
Accédez à la vidéo de notre partenaire QRP International

Fournir des estimations n’est pas une tâche facile, supputer l’est davantage :-)

L’Art de l’estimation

Article original sur le blog expiriance.

PMGS est partenaire de DantotsuPM

Ce billet couvre rapidement l’une des techniques que les aspirants à la certification PMP® apprennent en étudiant le PMBoK® Guide.

Reconnaissons-le, fournir des estimations n’est jamais une tâche aisée. Faire des suppositions est bien plus facile.

En effet, l’estimation n’est pas seulement l’action concrète de calculer combien de temps une tâche va prendre. Il y a de nombreux éléments intangibles qui ne sont pas toujours pris en considération alors que ce sont eux qui feront ou déferont votre projet.

Comme les organisations pensent qu’une pression toujours plus élevée produit des résultats plus rapidement, le besoin de précision des estimations à grimpé en importance au point que la plupart d’entre elles ont développé des standards d’estimation basés sur des produits prédéfinis.

Par exemple, une société de construction a une estimation déjà prédéterminée de combien cela prend de construire une pièce de 4 mètres par 5. Un fabricant de meubles de bureau sait ce que cela demande de construire une chaise « Direction modèle Luxe » etc, etc. Ces sociétés font cela tout le temps en utilisant les mêmes outils et matériels, tous très tangibles.

Évaluer l’effort avec PERT

PERT est un des modèles les plus simples et les plus largement utilisés pour évaluer l’effort. Il permet de déterminer la meilleure estimation du temps requis (Te: Temps estimé) pour compléter une tâche, en assumant que tout se passe normalement. L’implication est que le temps prévu est le temps moyen que la tâche exigerait si elle était répétée un certain nombre de fois au cours d’une longue période de temps (comme pour la société de construction et le fabricant de meubles de bureau ci-dessus)

• le temps Optimiste (O) – le temps minimal requis accomplir une tâche, assumant tout se passe mieux que l’on s’y attende normalement

• le temps Pessimiste (P) – le temps maximal requis accomplir une tâche, assumant que tout tourne mal, mais excluant des catastrophes majeures

• le temps le Plus probable (M) – la meilleure estimation du temps requis accomplir une tâche, assumant que tout se passe normalement

La formule pour calculer PERT est

Te = (O + 4M + P) / 6

J’utilise PERT tout le temps, c’est très précis et la méthode a prouvé sa valeur dans bien des situations.

Une société de développement de logiciel sur mesure, avec beaucoup d’éléments intangibles en fonction des pré-requis du client, a mis en œuvre une méthode d’évaluation basée sur huit catégories pour qualifier la complexité d’un projet de forte, moyenne ou faible.

Les points sont additionnés en fonction des réponses dans chacune des 8 catégories : 1 point pour faible, 2 points pour moyen et 3 points pour fort.

Le score total du projet détermine son facteur de complexité.

Celui-ci est alors utilisé pour fournir l’estimation initiale. Si le score total est de 8 à 12 points, c’est un projet de faible complexité, s’il est entre 13 et 18, c’est un projet de complexité moyenne et s’il est entre 19 et 24 c’est un projet de forte complexité.

Bien sûr, toutes les organisations de développement de logiciel ne peuvent pas suivre ce modèle même s’il peut être utilisé comme une base de départ.

Exemple :

Comme vous pouvez le constater, l’estimation reste un art.

Qu’en pensez-vous ? Quelle méthode utilisez-vous ?

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.

Gérez vos projets : Les clés pour réussir étape par étape par Thibault Pairis

Bonjour Thibault Pairis, pouvez-vous vous présenter ? Qui êtes-vous et quel est votre parcours ?

Ça va vous paraître étrange, mais ma formation initiale n’a rien à voir avec la gestion de projet ou le management. J’ai passé un master d’histoire (pour être précis : sur le thème du commerce entre les deux rives de la Manche au sein de l’Empire romain) qui m’a donné une rigueur de travail stricte. Mais sur le marché du travail, il n’y avait pas beaucoup de postes d’Indiana Jones de libres, du coup une fois mon master en poche, je me suis réorienté vers un master d’informatique en accéléré.

QRP est Partenaire de DantotsuPM

J’ai donc commencé l’informatique par la base, celle du développement. Ensuite, j’ai évolué dans la banque puis l’industrie : développeur, ingénieur, chef de projet, puis manager d’une équipe de développement en charge de projets internationaux. Je me suis formé de deux façons : par la formation continue (AgilePM et Prince2 principalement) et en lisant des livres de développement personnel.

Partenaire de DantotsuPM

Au cours de mes expériences professionnelles, j’ai rencontré beaucoup de problématiques de gestion de projet très diverses, sans y avoir forcément été sensibilisé durant mes études. J’arrive donc facilement à me mettre à la place du débutant face à ces problèmes, car je suis passé par là. Après 12 ans dans le domaine, je crée mon entreprise dans le conseil en gestion de projet.

Vous avez écrit un ouvrage intitulé « Gérez vos projets: Les clés pour réussir étape par étape ». Quelles sont les raisons qui vous ont poussé à rédiger ce livre ?

Deux observations m’ont conduit à ce projet de livre :
  1. Il n’y avait pas de livres destinés aux novices absolus en gestion de projet.
  2. Les livres de gestion de projet classiques sont souvent qualifiés d’arides par les débutants, parce qu’ils ne partent pas de zéro ou sont trop théoriques.

Partant de ce constat, j’ai voulu démystifier d’une part et rendre attrayante d’autre part la conduite d’un projet.

Le contenu du livre est façonné par ces objectifs :
  • J’ancre chaque présentation d’un concept par une anecdote historique sur un projet réel (il y en a 27 en tout)
  • Il y a beaucoup de schémas concrets pour expliquer des concepts abstraits : l’organisation en silos, l’effet tunnel, le concept d’itérations, etc.
  • Des exercices permettent de devenir acteur d’un projet : on apprend ainsi à définir les référentiels dans une PME d’outillage, modéliser les processus d’une agence de voyage ou gérer les conflits interpersonnels lors d’une réception de mariage !

Ce livre mentionne de nombreux projets qui peuvent être qualifiés d’échecs, pourquoi ?

John Hancock Tower

On pèche toujours par excès de confiance. Par exemple, quand a été construite la John Hancock Tower à Boston, tout le monde ne parlait que de ses prouesses : Le plus haut immeuble, la plus grande surface vitrée, le plus discret en raison de sa teinte bleutée. Les ingénieurs qui l’ont conçue ne prévoyaient pas que ses vitres de 227 kilos allaient se détacher une par une pour aller s’écraser sur les trottoirs en contrebas, et pourtant c’est ce qui s’est passé !

Donner des exemples de projets classiques, comme construire un immeuble, qui se muent en cauchemars, ça donne une leçon d’humilité. On se rend compte que dans un projet, les ennuis guettent à chaque pas, et que ce n’est pas juste aller d’un point A vers un point B situé 10 mètres plus loin. Entre les deux, on découvre des virages (les changements de cahier des charges), des dénivelées (les difficultés techniques inattendues), des intersections (les choix fonctionnels à faire). On peut vite se perdre à faire du hors piste, avec les risques que cela représente pour l’entreprise et pour le manager en question.

Vous proposez aussi de nombreux exercices concrets et quizz que les lecteurs et lectrices pourront utiliser tout au long de la vie du projet. Pourquoi avez-vous choisi de mettre des exercices pratiques ?

D’expérience, on retient mieux les situations concrètes que les exemples théoriques. Si vous lisez la recette du soufflé au fromage, sans faire de soufflé au fromage immédiatement : Vous ne vous rappellerez pas bien toutes les étapes, leur ordre, les quantités d’ingrédients, etc. Le meilleur moyen pour bien réagir face à tous les cas de figure dans un projet, c’est de les avoir déjà vécus en s’immergeant dans la situation et en réfléchissant à ce que l’on ferait soi-même.

Tous les exercices sont ancrés dans la réalité avec des détails, comme MagiCompote qui produit des confitures ou Volcano qui installe des chauffages. Ce n’est pas anodin : c’est pour se rappeler facilement des problématiques et de leurs solutions. Regardez, vous vous rappelez que j’ai fait un master d’histoire car j’ai évoqué Indiana Jones au début de l’interview. C’est le principe que j’ai voulu appliquer tout au long de mon livre.

Blog de Thibault Pairis
Thibault Pairis

Avec maintenant 10 ans de gestion de projet derrière lui, Thibault Pairis commence à être plus expérimenté… et à vouloir partager un peu de cette expérience autour de lui. Il a commencé un blog en 2017 (http://www.rocketprojet.com/) et, en parallèle, travaillé sur ce livre qui récapitule toutes les bonnes pratiques de la gestion de projet, en collaboration avec les éditions ENI.

 

Rapport sur les compétences essentielles de DevOps en entreprise

Si votre projet est exécuté en approche DevOps, cette étude très complète devrait vous intéresser.

En effet, cette étude offre une vue complète des compétences essentielles de la méthodologie DevOps et de la transformation numérique dans la communauté informatique mondiale.

rapport

© 2019 DevOps Institute. All Rights Reserved.

QRP est partenaire de DantotsuPM – Téléchargez gratuitement ce document.

 

Le transfert de connaissances change-t-il avec #Agile ?

Le transfert de connaissances est-il différent quand l’équipe utilise une approche Agile ?

Does knowledge transfer change with agile?

https://kbondale.wordpress.com/2018/07/01/does-knowledge-transfer-change-with-agile/ par Kiron Bondale

Nous l’avons tous vécu : une personne clé annonce son départ et une folle bousculade s’ensuit pour faire passer leurs connaissances au reste de l’équipe.

Mais ceci est-il différent quand l’équipe utilise une approche et un cycle de vie Agile ?

En surface, il pourrait sembler qu’il n’y a pas de différences significatives sur comment le faire, quel que soit la nature du travail ou de comment il est exécuté. Après tout, le transfert de connaissance est d’habitude la formation par un expert d’autres experts au moyen de sessions présentielles ou par une sorte de documentation persistante comme un wiki, une vidéo ou un enregistrement audio.

Bien que ceci soit vrai, il y a des caractéristiques et des pratiques spécifiques dans la livraison agile qui peuvent impacter ce transfert de connaissance.

Les approches traditionnelles comptent d’habitude sur des spécialistes individuels qui restent concentrés leur rôle et leur secteur d’expertise. Alors que l’approche Agile encourage le développement de généralistes qui développeront un jeu plus large de compétences et de connaissances. On s’attend aussi à des niveaux plus élevés de collaboration dans ce contexte, ce qui augmente la quantité d’exposition que chacun des membres d’équipe a des connaissances de chacun.

Bien que cela ne se traduise pas par une totale polyvalence des membres de l’équipe, il y a moins de probabilités que seulement un membre d’équipe possède l’information critique. Cela ne se produira pas en un jour. Il faudra beaucoup de semaines de travail ensemble ainsi que l’encouragement explicite des parties prenantes clés comme les managers fonctionnels pour que les spécialistes développent leurs compétences généralistes.

Un autre activateur est de moins travailler en solo : La programmation en paires (en binômes), les hackathons, la programmation de foule et toutes les pratiques utilisant ce principe. Bien que le but primaire de ces pratiques ne soit pas le transfert de connaissances mais plutôt la qualité et la vitesse, c’est un bénéfice collatéral de valeur.

Plutôt qu’avoir des experts qui partagent leurs connaissances de façon académique, démontrer comment leur connaissance peut être appliquée pour compléter des items de travail est plus efficace.

pile de papiersAlors que la livraison traditionnelle a eu tendance à souligner la documentation comme le moyen de transférer le travail entre des rôles, les approches agiles se concentrent sur un minimum suffisant. Tandis qu’une équipe nouvellement formée pourrait exiger plus de documentation pour faciliter le partage de compréhension, une équipe avec un plus long vécu pourrait livrer avec succès avec beaucoup moins de documentation.

Le défi refait surface quand un membre nouveau ou junior rejoint l’équipe car il peut y avoir un matériel de référence insuffisant pour permettre l’auto apprentissage.

Mais cela ne devrait pas causer de problèmes majeurs si quelqu’un sur l’équipe se porte volontaire pour s’appairer avec le nouveau venu pour l’aider remplir les cases vides.

Même si le besoin de connaissances partagées est présent dans tous les contextes, une approche de livraison agile efficace peut réduire la criticité du transfert explicite de connaissance.

CertYou est partenaire de DantotsuPM

Je suis très curieux de connaitre votre retour d’expérience sur vos projets Agiles ?

Xavier Koma nous propose une petite vidéo de 5 minutes de l’animation « Speedboat » pour faciliter une rétrospective de fin de sprint.

Le « Speedboat » (ou « Sailboat ») fait partie des « serious games » très utiles dans les ateliers de travail Agile de fin de Sprint.

Et il peut être utilisé sur tous les types de projets, Agile ou pas.

Cette technique d’animation permet de rappeler la cible du projet, de matérialiser les succès du Sprint, les atouts et les freins pour l’équipe sous la forme d’un dessin et d’une histoire qui invite facilement toute l’équipe au voyage en mer (parfois tumultueux).

En bonus, vous pouvez télécharger un petit kit à découper pour avoir les éléments rapidement sous la main lors de votre session avec l’équipe. Xavier reprend les bases très simples de la méthode puis détaille comment la dérouler lors d’un atelier avec votre équipe projet.

Relisez cet article précédent sur la technique.

Merci à Xavier Koma et visitez sa chaine sur YouTube !

CertYou est partenaire de DantotsuPM

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

Three Amigos

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

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

Les 3 perspectives

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

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

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

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

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

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

CertYou est partenaire de DantotsuPM

Le « Standard for Earned Value Management » du PMI® est disponible pour revue et commentaires, contribuez !

Obtenez votre copie du brouillon de « The Standard for Earned Value Management » et commentez-le

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

Rappel de ce qu’est « Earned Value Management »

Partenaire de DantotsuPM

Pourquoi utilisons-nous les nombres de la suite de Fibonacci pour estimer les histoires d’utilisateur / User Stories ?

Why Do We Use Fibonacci Numbers to Estimate User Stories?

https://www.scruminc.com/why-do-we-use-fibonacci-numbers-to-estimate-user-stories/ par Jeff Sutherland

Il y a fréquemment de grands débats sur l’utilisation de la suite de Fibonacci pour estimer des histoires d’utilisateur. L’estimation est au mieux un outil imparfait, mais un outil nécessaire pour planifier le travail.

L’estimation d’histoire d’utilisateur est basée sur la recherche du Ministère de la Défense américaine en 1948 qui a développé la technique Delphi. La technique a été classifiée jusqu’aux années 1960 (il y a des douzaines de papiers sur le sujet sur rand.org). Essentiellement, les chercheurs de Rand ont voulu éviter la pression vers la conformité de groupe qui menait typiquement à de mauvaises évaluations. Donc, ils ont décidé que les estimations devaient être faites dans le secret. Initialement, les évaluations seraient très éloignées parce que les gens auraient des perceptions différentes du problème donc ils les feraient parler des maximums et des minimums proposés après l’estimation en secret, puis estimer ensuite dans le secret de nouveau. Sur Rand Worldwide vous pouvez lire les papiers originaux qui démontrent de la convergence.

Les chercheurs de Rand ont alors étudié l’effet des choix de nombres parmi lesquels choisir et ont constaté qu’un ordre linéaire donnait de plus mauvaises évaluations qu’un jeu de nombres augmentant exponentiellement. Il y a quelques arguments mathématiques récents pour ceux qui sont intéressés. La question, si vous voulez la meilleure évaluation statistiquement prouvable, est alors quelle série d’augmentation exponentielle utiliser. La suite de Fibonacci est presque, mais pas tout à fait exponentielle et a l’avantage que c’est le modèle de croissance vu dans tous les systèmes organiques. Pourquoi la suite de Fibonacci se répète-t-elle dans la nature ? Donc, les gens sont très familiers avec elle et l’utilisent constamment dans le choix des tailles de vêtements. Par exemple, les tailles de T-Shirt suivent Fibonacci. Puisque quelques développeurs sont opposés aux nombres (un phénomène vraiment étrange pour ceux qui travaillent avec des ordinateurs), ils peuvent utiliser des tailles de T-Shirts et leurs évaluations sont facilement traduites en chiffres.

Microsoft a répété cette recherche ces dernières années et publié un papier primé par l’IEEE. En conséquence, Microsoft a abandonné les estimations horaires des projets. Voir le papier récompensé en 2011 par IEEE de Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan (2012) Scrum + Engineering Practices: Experiences of Three Microsoft Teams.

Donc la communauté Agile a convergé sur Fibonacci comme la suite de nombres à utiliser. Malheureusement, beaucoup d’équipes agiles ne l’utilisent pas correctement et essayent de faire chacun converger sur un nombre de Fibonacci, ce qui vous donne mathématiquement et par expérience de mauvaises évaluations à cause du biais de conformité au groupe. C’est exactement ce que les chercheurs de Rand ont cherché à éviter en inventant la Technique Delphi.

À maintes reprises, les chercheurs ont montré que les estimations en heures ont de très forts taux d’erreur. C’est vrai même si l’utilisateur est un expert. C’est l’outil qui est le problème. Si vous voulez pratiquer en vous basant sur les évidences, des évaluations de taille relatives livrent tout simplement une estimation beaucoup plus précise.

CertYou est partenaire de DantotsuPM