Tag Archives: planning

6 Décembre – Strasbourg (#PMI®) – Mind Mapping : un outil pour simplifier la planification de vos projets et la création des WBS

4 Déc

Pôle Strasbourg, Mardi 6 décembre 2016 à 18h15

Cliquez ici pour une démonstration en ligne !

Cliquez ici pour une démonstration en ligne !

Nous avons tous expérimenté différents moyens de récolter les besoins de nos projets pour pouvoir ensuite les planifier: tableaux blancs, post-it, tableaux informatiques, etc.

Le PMI Strasbourg vous propose de (re)découvrir le Mind Mapping : une manière efficace de recueillir et d’organiser les besoins pour ensuite construire le WBS (Work Breakdown Structure), le diagramme de Gantt, la documentation projet…

La conférence sera animée par Marc Cantain, directeur des ventes chez Matchware, éditeur du logiciel MindView.

Notre conférencier vous présentera la théorie du Mind Mapping et comment ses principes peuvent être appliqués à des chefs de projet. Il partagera également avec vous les meilleures pratiques en matière de Mind Mapping et vous montrera comment son utilisation, couplée à l’outil informatique, simplifie le cycle de vie du projet, fait gagner du temps et améliore la communication d’un plan projet. Les avantages de cette méthode seront démontrés en interaction directe avec les participants au cours de la présentation.

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

Essayez Bubble Plan !

Essayez Bubble Plan !

Enregistrer

Que sont les « Story Points » ou Points d’Histoire en #Agile ?

23 Nov

Les « Story Points » sont  une évaluation de l’effort total qui sera exigé pour entièrement mettre en œuvre un article de l’arriéré de produit.

http://www.mountaingoatsoftware.com/blog/what-are-story-points par Mike Cohn

mesurer et comparerLes «Story Points» sont une unité de mesure pour exprimer une évaluation de l’effort total qui sera exigé pour entièrement mettre en œuvre un article de l’arriéré de produit (du « Product Backlog ») ou autre travail.

Quand nous évaluons avec des «Story Points», nous assignons une valeur de point à chaque article de l’arriéré de produit. Les valeurs brutes que nous assignons sont sans importance. Ce qui importe sont les valeurs relatives. Une histoire qui est assignée un 2 devrait représenter deux fois plus qu’une histoire qui est assignée 1. Elle devrait aussi être les deux-tiers d’une histoire qui est évaluée à 3 «Story Points».

Au lieu d’assigner 1, 2 et 3, cette équipe pourrait avoir assigné 100, 200 et 300. Ou 1 million, 2 millions et 3 millions. Ce sont les valeurs relatives qui importent, pas les chiffres isolés.

Qu’est-ce qui entre dans un « Story Point » ?

Parce que les «Story Points» représentent l’effort pour développer une histoire utilisateur, l’évaluation d’une équipe doit inclure tout ce qui peut affecter l’effort.

Cela pourrait inclure :
  • Le travail pour faire
  • N’importe quel risque ou incertitude dans la réalisation du travail
  • La complexité du travail

En évaluant avec des «Story Points», assurez-vous de considérer chacun de ces facteurs. Voyons comment chacun impacte l’évaluation d’effort donnée pour l’histoire en question.

Le travail pour faire

typingCertainement, s’il y a plus à faire pour réaliser quelque chose, l’évaluation d’effort devrait être plus importante. Considérez le cas simple de développer deux pages Web. La première page a seulement un champ et une étiquette demandant à entrer à un nom. La deuxième page a 100 champs qui attendent aussi à être simplement remplis d’un peu de texte.

La deuxième page n’est en rien plus complexe. Il n’y a aucune interaction entre les champs et chacun d’eux n’est rien de plus qu’un peu de texte. Il n’y a aucun risque additionnel sur la deuxième page. La seule différence entre ces deux pages est qu’il y a plus à faire pour la deuxième page.

On devrait donc donner plus de «Story Points» à la deuxième page. Cela ne mérite probablement pas 100 fois plus de points bien qu’il y ait 100 fois plus de champs. Il y a, après tout, des économies d’échelle et peut-être que le développement de la deuxième page est seulement 2, 3 ou 10 fois autant d’efforts que la première page.

Risque et incertitude

"Image courtesy of Stuart Miles / FreeDigitalPhotos.net"

« Image courtesy of Stuart Miles / FreeDigitalPhotos.net »

La quantité de risque et incertitude dans un article d’arriéré de produit devrait affecter l’estimation en «Story Points» donnée à l’article.

Si on demande à une équipe d’évaluer un article d’arriéré de produit et le demandant est peu clair sur ce qui sera nécessaire, cette incertitude devrait être reflétée dans l’évaluation.

Si l’exécution d’une fonction implique le changement d’un morceau particulier de code ancien, fragile et qui n’a aucun essai automatisé en place, ce risque devrait être reflété dans l’évaluation.

Complexité

On devrait aussi considérer la complexité lors d’une évaluation de «Story Points». Repensez à l’exemple précédent de développer une page Web avec 100 champs de texte insignifiants sans interactions entre eux.

Pensez maintenant à une autre page Web, elle aussi avec 100 champs. Mais certains sont des champs date avec des gadgets de calendrier qui s’affichent en surimpression. Certains sont des champs de texte formatés comme des numéros de téléphone ou des numéros de sécurité sociale. D’autres champs ont des validations comme avec des numéros de carte de crédit.

Fournir mes informations bancairesCet écran exige aussi des interactions entre des champs. Si l’utilisateur saisit une Carte Visa, on montre un champ CVV à trois chiffres. Mais si l’utilisateur saisit une carte d’American Express, on montre un champ CVV à quatre chiffres.

Bien qu’il y ait toujours 100 champs sur cet écran, ces champs sont plus difficiles à mettre en œuvre. Ils sont plus complexes. Ils prendront plus de temps. Il y a plus de chance que le développeur fasse une erreur et doive repasser dessus et la corriger.

Cette complexité complémentaire devrait être reflétée dans l’évaluation fournie.

Considérez tous les facteurs : Travail, Risque et Incertitude et Complexité

story-pointsIl peut sembler impossible de combiner ces trois facteurs en un chiffre et le fournir en tant qu’évaluation globale. C’est cependant possible parce que l’effort est le facteur d’unification. Les experts considèrent combien d’effort sera exigé pour réaliser le travail décrit dans un article d’arriéré de produit.

Les experts considèrent alors combien d’effort inclure pour prendre en compte le risque et l’incertitude inhérentes à l’article d’arriéré de produit. D’habitude, ceci est fait en considérant le risque d’apparition du problème et l’impact si le risque survient vraiment. Ainsi, par exemple, plus d’effort sera inclus dans l’évaluation pour un risque consommateur de temps qui va probablement arriver que pour un risque mineur et peu probable.

Les experts considèrent aussi la complexité du travail à faire. Le travail complexe exigera plus de réflexion, pourra exiger une expérimentation plus empirique, peut-être plus d’interactions avec le client, pourra prendre plus longtemps à valider et avoir besoin de plus de temps pour corriger des erreurs.

Ces trois facteurs doivent être combinés.

Cfinionsidérez tout dans la définition de fini (« done »)

Une évaluation de «Story Points» doit inclure tout ce qui est impliqué dans l’obtention d’un article d’arriéré de produit entièrement fini. Si la définition d’une équipe de « fini » inclut la création des tests automatisés pour valider l’histoire (et ce serait une bonne idée), l’effort de créer ces tests devrait bien sûr être inclus dans l’évaluation de «Story Points».

Les «Story Points» peuvent être un concept complexe à saisir.

Mais l’effort de bien comprendre que les «Story Points» représentent tout l’effort nécessité par le travail, la complexité du travail et tout risque ou incertitude dans le travail le vaut tout aussi pleinement.

Essayez Bubble Plan !

Essayez Bubble Plan !

Quels autres conseils prenez-vous en compte dans l’évaluation des « story points » ?

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

évaluation des fonctionnalités logicielles telles que perçues par les utilisateurs grâce aux points de fonction

31 Oct

Le Point de Fonction n’est pas la panacée en matière d’estimation logicielle mais il permet d’établir un référentiel compréhensible par tous !

Cet article a été écrit il y a déjà plus de 5 ans par Jean-Baptiste Jourdant, consultant-formateur et Responsable du département Management de projet pour CSP Formation et partenaire de DantotsuPM.

Le chef de projet informatique Maîtrise d’OEuvre (MOE) client : « Avec cette méthode d’évaluation des charges avec les points de fonction (PF), on croit que tout est résolu, mais le prestataire fait ce qu’il veut avec tous ces ajustements, et on n’est pas plus avancé. »

Le chef de projet SSII : « Depuis qu’ils nous demandent des cotations en PF, on n’a plus de marge de manœuvre. En plus, on ne maîtrise pas les coefficients de productivité, alors on s’engage les yeux fermés, et puis on est coincé. »

La théorie synthétisée

Les PF sont une méthode d’évaluation des fonctionnalités logicielles telles que perçues par les utilisateurs (finaux, administrateurs métiers) de l’application. A travers différents composants (groupes de données, transactions) l’application est cartographiée puis valorisée en nombre de PF.

Puis, à l’aide d’un coefficient de productivité (nombre de PF produits par homme-jour), on calcule la charge estimée du projet.

Intérêt

curiositéLe PF n’est certainement pas une panacée universelle. Toutefois, il permet d’établir un référentiel compréhensible par tous les interlocuteurs de la chaîne de production.

La Maîtrise d’OuvrAge (MOA) voit ses fonctionnalités (disséquées, certes),

la MOE client va disposer d’une base de comparaison entre ses différents projets (à manier avec précaution),

la MOE SSII va disposer d’une image fonctionnelle « anticipée » de ses composants techniques, et faire valoir directement les carences éventuelles.

Les éléments variables

Les différents éléments suivants sont évalués pour prendre en compte les spécificités.

  • PRODUIT : nouveauté logicielle, complexité du langage, progiciel, niveau d’ergonomie ou de sécurité demandée, réutilisation du code, …
  • PROJET : Organisation de l’équipe (plateau de développement unique ou éclatement de la réalisation (off-shore), niveau de compétences des acteurs, urgence planning, …
  • MODÈLE DE PRODUCTION : Répartition des activités entre le client et le prestataire (RTU-Réalisation & Tests unitaires, conceptions, tests d’intégration, pilotage, prise de risques, …)
Microsoft est partenaire de DantotsuPM

Microsoft est partenaire de DantotsuPM

Processus de calcul des charges

calculerEntre la fonctionnalité et les charges, le chef de projet passe par plusieurs étapes :

  1. Cartographie : Nombre de PF dits bruts
  2. Ajustements produits : Nombre de points de fonction ajustés
  3. Utilisation du ratio de productivité standard : Charge nominale
  4. Intégration des spécificités projet (périmètre RTU) : Charge brute
  5. Prise en compte du modèle de production : Charge nette

Exemple

1° Cartographie fonctionnelle =>100 PF Bruts

2° Ajustement produit (sécurité, techno), +20% =>120 PF Ajustés

3° Productivité nominale (REX), 2 PF/HJ =>Charge = 60 HJ

4° Efficacité projet (off-shore), 0,8 =>Charge brute = 75 HJ

5° Activités complémentaires (Conception, doc), +50% => 112,5 HJ

Un ou des ratios de productivité ?

Finalement, dans la méthode, pour passer à l’étape suivante, on utilise un ratio qui mesure la contribution de chaque catégorie.

Et pour une productivité nominale de 2 PF/HJ, on a en réalité entre les PF bruts et la charge nette, une productivité globale de 0,88PF/HJ : 100 PF / 112,5 HJ

CSP est partenaire de DantotsuPM

CSP est partenaire de DantotsuPM

Recommandations

  • CONTRAT : C’est votre contrat qui fait foi. Précisez le ratio de productivité sur lequel vous vous appuyez. Et attention aux engagements préliminaires quand vous ne disposez pas de références.
  • MARGE DE MANŒUVRE : Soyez clair entre clients et fournisseurs sur les éléments variables et cadrer leur influence.
  • CAPITALISATION : C’est le secret de la fiabilisation de vos ratios de productivité !
Essayez Bubble Plan !

Essayez Bubble Plan !

Enregistrer

Enregistrer

le redressement de projet nécessite des qualités et approches spécifiques chez le chef de projet

11 Oct

« Je ne crois pas que quelqu’un soit né sachant comment mener une équipe de projet vers le rétablissement et le succès », Rebecca Winston

J’avais publié ce billet il y a 6 ans et il me semble toujours autant d’actualité. Aussi me suis-je permis de le reprendre pour en améliorer la forme et clarifier certains messages clés.

Lessons from a Turn-Around PM billet de Rebecca Winston, JD, Past PMI Chair et PMI Fellow

magicCertaines des leçons que j’ai appliquées, je les ai apprises au prix d’un certain nombre de cicatrices et de l’observation d’autres de chefs de projet que j’ai rencontrés ou avec lesquels je suis en relation. Il n’y a aucune formule magique ni nec plus ultra; Seulement quelques leçons relativement simples qui démentent la difficulté avec laquelle elles sont mises en œuvre.

D’abord, je ne crois pas que quelqu’un soit né sachant comment mener une équipe de projet vers le rétablissement et le succès. Je ne suis pas ni n’ai rencontré non plus le chef de projet de redressement qui connaisse en fin de compte la réponse sur comment transformer un projet dysfonctionnel ou en échec. Cependant, j’ai appris de nombreuses leçons.

1. Croyez en vous.

business success self confidenceNotez bien que je n’ai pas dit croire que vous avez toutes les réponses parce que vous ne les avez pas. Mais vous devez croire sincèrement que vous pouvez faire le job. Si vous ne le croyez pas, qui devrait croire en vous, qui vous donnera une apparente confiance, un sens de la direction et un objectif ?

2. Ne dénigrez pas votre prédécesseur.

Vous faites face à plusieurs pièges si vous vous engagez dans la diffamation du chef de projet précédent. On ne sait jamais qui dans l’équipe peut être leur ami et peut répéter vos déclarations à l’ancien chef de projet. Certaines de ces déclarations peuvent être vraies, d’autres peuvent seulement refléter votre opinion et certaines peuvent s’avérer ne pas être correctes. Vous ne connaissez pas tous les problèmes auxquels s’est confronté le précédent chef de projet. Tout que vous avez sont vos impressions et observations, toutes deux vues par vos yeux et non pas les siens au moment où ils les exécutaient.

De plus, critiquer le chef de projet précédent devant ses pairs peut vous couper d’un précieux réseau. Vous pouvez avoir besoin des autres chefs de projet dans l’organisation pour tester vos idées, questionner la signification et la mise en œuvre de procédures internes, découvrir comment supprimer des points de blocage connus et autres sujets. Beaucoup de ces chefs de projet peuvent vivre dans la crainte d’être les prochains éliminés s’ils trébuchent sur leurs projets.

Oh et n’oubliez pas que la personne qui est votre manager peut avoir été le manager du précédent chef de projet. Il peut même l’avoir embauché. Critiquer le chef de projet précédent peut mettre en doute leur bon jugement.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

3. Soyez focalisé sur faire avancer le projet.

ProgressLa plupart des chefs de projet n’ont pas d’yeux derrière la tête. Les yeux servent à regarder, soit vers l’avant, soit derrière soi. Regarder derrière soi ne change pas le projet et peut vous empêcher de trouver les solutions nécessaires pour résoudre les problèmes. Cela peut aussi vous condamner à revivre dans les risques du passé.

Bien sûr, il faut comprendre ce qui s’est passé et les indicateurs précédents, mais rester dans ce mode ne permet pas à l’équipe d’avancer. En matière de leadership, l’équipe de projet va suivre le chef de projet qui avance sans faire de blocage sur le passé.

4. Croyez en l’équipe.

équipe projet/businessNe commencez pas par remplacer des membres de l’équipe par des personnes avec lesquelles vous vous sentez à l’aise. Assurez-vous de bien analyser votre équipe et de lui donner du temps. Les changements causent une mise en doute de l’équipe et les membres restants peuvent devenir moins productifs qu’ils ne l’étaient ou ne pourraient l’être.

Vous, en tant que chef de projet, devez comprendre que, alors que vous vous sentez à l’aise avec de certains individus, le défi d’accroître le pool des talents avec lesquels travailler est plus important. Ils apporteront de nouvelles idées, une perspicacité de projet, la compréhension des risques tant antérieurs que futurs. Certains peuvent avoir des connexions avec des sponsors, des clients, des fournisseurs et autres personnes nécessaires au succès du projet.

Essayez Bubble Plan !

Essayez Bubble Plan !

5. Ayez un plan.

successLa leçon 5 est quelque chose de familier pour la plupart des chefs de projet : avoir un plan. Le plan devrait avoir reçu les avis de l’équipe de projet comme tout plan de projet, mais il devrait être vendu comme le plan vers le succès. Une communication positive est exigée. Le martelage du manque de réussite ou de progrès passés ne réunira pas l’équipe autour de l’esprit de succès. Tant vous-même que l’équipe devez croire que le succès peut être atteint et qu’il le sera dans les paramètres donnés pour le projet.

6. Renégociez.

Vous êtes nouveau et avez de nouveaux besoins, peut-être quelques nouveaux prérequis, ou de nouvelles parties prenantes. N’ayez pas peur de soumettre des demandes de renégociation. Elles peuvent être conduites selon des styles différents, des besoins de communication différents, et avec une compréhension des leçons qui ont été apprises jusqu’à présent sur le projet.

Méta Projets Management est partenaire de DantotsuPM

Méta Projets Management est partenaire de DantotsuPM

7. Communiquez, communiquez et communiquez encore un peu plus !

bonhom-courrierPeut-on le répéter suffisamment ?

Voici une leçon du management de projet en général, mais qui devient encore plus nécessaire dans un projet de rétablissement.  Des parties prenantes diverses, incluant les membres de l’équipe, devront être rassurées. Elles devront recevoir plus d’informations au moins pendant quelque temps, une meilleure compréhension des risques et des stratégies de management et d’autres sujet sur lesquels elles peuvent vouloir fournir des informations. De temps en temps, on peut estimer que le chef de projet sur-communique. Ce besoin de sur-communication peut diminuer avec le temps et en fonction du temps restant pour terminer le projet.

8. Soyez créatif.

Le chef de projet de redressement ne peut pas toujours compter ce qu’il a fait dans le passé. Il devra créer de nouveaux rapports, délivrer ces rapports de nouvelles manières, construire un esprit d’équipe différent, utiliser de nouveaux canaux de communication, ou stimuler l’équipe à être plus créative et innovatrice. Parfois cela peut être aussi simple que de ne pas amener des croissants pour la réunion d’équipe, mais de fournir à la place un jambon-beurre au petit-déjeuner. Le bruit créé par un changement aussi simple peut mener à une conversation qui rende le nouveau chef de projet plus réel.

inciter-l-equipe-a-etre-plus-creative-et-innovatrice9. Restez en contact avec votre réseau.

networkBien sûr, cette recommandation s’applique à tout chef de projet, mais je l’ai trouvée encore plus importante en menant un projet de redressement.  Vous aurez besoin d’une caisse de résonance. Il y aura des jours sombres et énervants; des jours où vous sentirez que vous serez le prochain chef de projet à ne pas trouver le chemin vers l’objectif. Votre réseau personnel vous écoutera, vous encouragera et vous offrira peut-être des solutions que vous pourrez vous approprier et utiliser.

10. Ne pensez pas que ce projet sera comme le précédent.

De nouveau une leçon générale de management de projet, mais qui prend une nouvelle signification sur un projet à redresser.  Certains aspects peuvent être similaires, mais ces projets n’incluaient pas cette équipe projet, les risques qui ont été rencontrés et leurs impacts, ou les parties prenantes, pour n’en citer que quelques-uns. Déclarer que ce projet est comme un autre que vous avez récemment réalisé transmet à l’équipe un manque de singularité de leur projet et les fera se questionner sur pourquoi ils ont échoué. Hors, les faire se mettre en cause personnellement plus qu’ils ne le font déjà est contre productif.

de bons outilsIl y a ici beaucoup de leçons. Nombre d’entre vous en transportent déjà d’autres dans leurs bagages de PM. J’espère que certaines de celles mentionnées ici peuvent être ajoutées à votre boîte à outils.

De même qu’un chef de projet devrait toujours être en mode apprentissage, votre boîte à outils devrait être en enrichissement permanent.

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

13 Octobre – Webinar (APMG) – Take control of your projects!

7 Oct

Project Planning & Control: Take control of your projects!

There has been very little guidance for practicing and aspiring project planning and control professionals to gain understanding of best practice, and how to apply it, until now…

Partenaire de DantotsuPM

Partenaire de DantotsuPM

The “Planning, Scheduling, Monitoring and Control – The Practical Management of Time, Cost and Risk” guide – published in 2015 – was developed by the UK Association for Project Management’s Planning, Monitoring and Control Specific Interest Group (SIG).

apmg-project-planning-control

Details on this certification

The guide is written in plain English – so even if this is your first experience in the field of planning and controls you should feel comfortable reading, understanding and working towards success.

The guide is supported by APMG International’s Project Planning & Control™ training and certification scheme. This webinar will provide a detailed overview of the guide and supporting training & certification. With some first-hand examples, we will look at the history behind the guidance and the benefits to both the organisation and individual.

Details and registration

11 Octobre – Paris – tour d’horizon des usages actuels des Points de Fonction

26 Sep

Métrique informatique de l’année 2016 : LE POINT DE FONCTION

  • Est-ce un phénomène de mode ?
  • Un effet de la prolifération des technologies de développement ?
  • Une conséquence de l’agilité ?
  • Le point de Fonction est toujours la métrique
  • la plus pertinente pour mesurer l’efficacité des projets informatiques !

assemiL’ASSEMI, association scientifique et technique, ayant pour objet l’étude et la promotion des métriques informatiques, organise le mardi 11 octobre 2016, sa conférence annuelle sur le thème « Les Points de Fonction ». La méthode des points de fonction est devenue une norme incontournable pour maîtriser et piloter la performance des Systèmes d’Information. La méthode supporte, en outre, des modèles d’estimation des coûts de développement et de maintenance informatique et permet de comparer l’efficacité des projets à des référentiels d’entreprises plus étendus. La méthode, représentée au niveau international par l’IFPUG est utilisée par des centaines d’entreprises et d’administrations dans le monde.

assemi-points-de-fonction

détails et inscriptions

La conférence aura lieu dans les locaux de la Maison de l’Europe à Paris. Elle est ouverte à tous les responsables informatiques, architectes, urbanistes, responsables support aux équipes projet, chefs de projet, étudiants, ….; souhaitant mieux appréhender cette méthode et bénéficier des retours d’expérience de plusieurs acteurs majeurs Français. Cette journée sera l’occasion de rencontrer vos pairs et d’échanger sur vos attentes communes.

Mindview est Partenaire de DantotsuPM - Cliquez ici pour une démonstration en ligne !

Au cours de cette conférence en français qui se déroulera de 9h à 12h, 14h à 17h, un tour d’horizon des usages actuels des Points de Fonction sera présenté, des retours d’expérience clients de plusieurs secteurs d’activités seront exposés :

  • Renault
  • Société Générale
  • Ministère de l’Agriculture

PROGRAMME DÉTAILLÉ ET INSCRIPTION: cliquez ici

Enregistrer

Enregistrer

5 Octobre – Montpellier ( #PMI ®) – Simplifiez la création du WBS et la planification

22 Sep

Mindview est Partenaire de DantotsuPM - Cliquez ici pour une démonstration en ligne !

« Simplifiez la création du WBS et la planification – Technologie, Mind Mapping et comment ils travaillent ensemble. »

La conférence organisée par La Branche Languedoc-Roussillon du PMI France vous invite à assister à cette conférence animée par Marc Cantain, directeur des ventes à Matchware, éditeur du logiciel MindView.

Cet événement aura lieu le Mercredi 5 Octobre 2016 de 18h00 à 20h00 dans les locaux d’ORANGE à Montpellier. L’événement est gratuit et sera dispensé en Français. Orange, Bâtiment A – 245 rue de la Galera – 34000 Montpellier

Fatigué des Post-It et des sessions de tableau blanc?

Le Mind Mapping est une manière efficace de recueillir des besoins. Lorsque le Mind Mapping est couplé à l’outil informatique, il simplifie les processus, fait gagner du temps dans la génération des différents supports et améliore la communication.

Le Mind Mapping a toujours été présenté comme un outil d’organisation et de planification, un moyen efficace de développer, organiser, et présenter les multiples facettes du plan de projet. Principalement utilisé pour la construction de la WBS, les utilisations avancées de cette technique simplifient également le processus de la communication du plan de projet.

Ces utilisations seront démontrées par interaction avec le public au cours de cette présentation directe d’un outil incontestable, polyvalent et utile.

Comment vous inscrire ?

PMIFR Languedoc RoussillonMerci de suivre ce lien http://pmi-france.org/branches/languedoc-roussillon/conferences

Attention, toute personne non inscrite avant le vendredi 30 Septembre 14h00 ne pourra accéder au site. Il faudra vous munir d’une pièce d’identité et nous signaler si vous avez besoin d’une place de parking.

Pour les membres du PMI, vous pourrez réclamer 2 PDUs pour la participation à cette conférence.

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

Enregistrer

4 Octobre – Sophia Antipolis ( #PMI ®) – MindMapping par MindView

19 Sep

Cette session sera l’occasion de développer le concept de Mind Mapping et découvrir le programme de conférences de la Branche PMI Côte d’Azur pour la saison 2016-2017.

Mindview est Partenaire de DantotsuPM - Cliquez ici pour une démonstration en ligne !

Merci de venir nous rejoindre à partir de 18h pour démarrer la conférence à 18h30.

Kick-Off de la Saison 2016-2017

Cette présentation sera précédée d’une rétrospective de la saison passée ainsi qu’une introduction des initiatives en cours et des volontaires de la Branche.

Le MindMapping par MindView

Comprendre le concept de Mind Mapping par la démonstration avec l’outil spécialisé MindView.

Partir d’une idée à la construction du WBS, le diagramme de Gantt, la génération de la documentation projet, … venez découvrir cette approche, vous permettant de simplifier la gestion de votre projet.

Ce sujet sera développé par Marc Cantain, directeur des ventes à Matchware, éditeur du logiciel MindView.

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

Enregistrer

Enregistrer

Enregistrer

Enregistrer

les mythes d’Agile : « il n’y a aucune planification dans #Agile »

12 Sep

« Il n’y a aucune planification dans Agile, vous improvisez au fil de votre progression »

http://trainings24x7.com/2015/06/22/list-of-free-pmp-sample-questions-websites/ par Leontranter

Je vais aborder certains des mythes persistants sur le Développement logiciel Agile. Le premier et probablement le plus connu est : « il n’y a aucune planification dans Agile, vous improvisez au fil de votre progression ». Ceci n’est pas du tout vrai.

En fait, je vais aller plus loin et poser une affirmation audacieuse :

Beaucoup de projets agiles font plus de planification que des projets en mode Waterfall / Cascade.

En fait, ils peuvent même faire bien trop de planification. J’espère que les gens qui utilisent les méthodes en cascade toussent et recrachent leur café partout sur leur bureau en réponse à cette affirmation. Décomposons cet argument et expliquons pourquoi je dis ça.

Il ne s’agit pas de plans mais de planification

Une de mes citations favorites est celle de Dwight Eisenhower :

« Les plans ne sont rien. La planification est tout. »

protectionCeci est un élément essentiel à la compréhension du rôle que joue la planification dans le Développement Logiciel Agile. En « Waterfall », l’idée est que le chef de projet rédige un grand échéancier au début du projet. Souvenez-vous, le contenu est habituellement fixé dès le départ et vous pouvez produire votre Structure de Répartition de Travail dont vous tirez votre plan de ressources (qui fait le travail) et votre diagramme de Gantt (le séquencement dans lequel il est fait) pour livrer ce contenu. Et avec tout ceci, vous pouvez déterminer vos coûts, parce que ces ressources ont des coûts spécifiques.

Puis, tout le monde signe (Oui ,nous aimons tous les signatures, n’est-ce pas !) le grand plan de projet et il est accepté et bloqué. Puis tout le monde vient travailler, selon le grand plan que le chef de projet a produit. Et que fait le chef de projet maintenant ? Il se contente de surveiller, lisant des revues ? Bien sûr que non ! Son travail est de protéger le plan à tout prix.

Les gens continueront à essayer de déplacer des choses, d’ajouter du contenu, d’allonger les délais, de permuter la personne A pour la personne B, de retarder ceci, de supprimer cela, de remplacer cette technologie pour cette autre et le chef de projet doit donc passer beaucoup de temps à :

  • Essayer d’empêcher tout cela de se produire (parce que le plan est signé), vous vous souvenez ? Ce qui signifie nous ne pouvons pas le changer, OK ?) et
  • documenter les risques s’il ne peut pas empêcher l’événement, laisser les parties prenantes savoir la catastrophe épouvantable qui s’abattra bientôt sur le projet en raison de ces changements non planifiés.

Ceci ne semble-t-il pas être une situation amusante pour tout un chacun et plus encore pour le chef de projet ?

Pourquoi les projets entrent-ils dans une telle spirale ?

Les projets en cascade s’engagent sur un plan quand il n’y a encore aucune information

aveugleLes projets en cascade élaborent un grand plan très complexe au début du projet, quand il y a :

  • Peu ou pas d’informations sur le travail qui a besoin d’être fait
  • Peu ou pas d’informations sur le livrable/produit, ce à quoi il doit ressembler et son fonctionnement
  • Peu ou aucune informations sur les problèmes et risques externes (dépendances, concurrents, partenaires, etc.)

Pas étonnant qu’il y ait autant de changements demandés sur de tels projets : comme les informations commencent à arriver, beaucoup d’entre elles sont en conflit avec le plan, parce qu’il a été basé sur des informations incomplètes (c’est-à-dire il a été composé de conjectures, de suppositions et d’estimations).

Ceci m’amène à une autre de mes citations favorites, cette fois d’un général allemand d’il y a longtemps, Helmuth von Moltke:

« Aucun plan ne survit au contact avec l’ennemi. »

Ce qui peut donner dans notre contexte: aucun plan de projet ne survit au contact avec le projet. Et c’est très bien ainsi, parce que nous ferions mieux de ne pas essayer de tout planifier sur le projet dès le début.

Les projets agiles planifient à plusieurs reprises par petits morceaux

Les projets agiles (utilisant Scrum ou l’une de ses variantes) ne créent pas un grand plan au début, ils font beaucoup de petites activités de planification (à chaque sprint) qui produisent de petits plans (des plans de sprint).

Ainsi au début d’un sprint de deux semaines, vous définissez un plan pour les deux semaines suivantes : c’est appelé la planification de Sprint. À cette réunion, l’équipe sélectionne des articles du Sprint Backlog et discute de combien ils peuvent en compléter pendant ce Sprint et comment le travail sera fait. Plutôt que d’essayer de définir un plan pour un travail que l’on ne connaît pas ou ne comprend pas vraiment, l’équipe élabore un petit plan pour un petit lot de travail qui est :

  • Bien connu et compris (autrement ce ne sera pas un candidat à entrer dans le Sprint Backlog)
  • Pouvant être achevé en un sprint (qui est souvent de deux semaines).

Donc vous définissez un petit plan pour une petite quantité de travail, puis vous faites le travail, puis vous faites le plan suivant pour le travail suivant, et cetera, à plusieurs reprises, encore et encore.

Ceci résonne-t-il comme « aucune planification » pour moi ? Pas du tout. Vous commencerez probablement vite à en avoir assez de planifier en suivant cette approche.

Un si petit plan apporte-t-il vraiment de la valeur ?

Vous pourriez penser « mais c’est complètement bidon ce plan, il ne couvre que deux semaines. Le plan en cascade était grand et beau et le Gantt géant expose graphiquement tout ce tout le monde va faire pendant les six mois à venir ! ».

Bien sûr, mais deux points :

  1. Le plan est en grande partie artificiel puisque créé au début du projet, quand personne n’avait vraiment assez d’informations sur le projet (car nous découvrons des informations au fil de notre progression)
  2. Le plan a été créé presque entièrement par le chef de projet, qui ne fera en réalité presque aucun travail lors de la construction du livrable et pas du tout par l’équipe, qui fera presque tout le travail de production du livrable.

Une grande partie de la valeur réside  dans la Planification, pas dans le Plan.

Rappelez-vous la précédente citation de Eisenhower.

plans are nothingLes membres de l’équipe se réunissent régulièrement et discutent du travail, combien de ce travail ils pensent qu’ils peuvent faire, combien il restera à faire.

  • Ceci apportera-t-il plus de valeur que nous l’avions pensé à l’origine ou moins ?
  • Qu’est-ce qui se révèle être plus facile ou plus difficile que nous ne le pensions de prime abord ?

Ces conversations ont énormément de valeur et aident à guider les développeurs et le propriétaire de produit tout au long du voyage vers l’achèvement du produit ou du projet.

Question: Avez-vous constaté qu’Agile n’apporte pas assez ou bien au contraire trop de planification ?

Enregistrer

Enregistrer

Enregistrer

Enregistrer

22 September – Lyon #PMI ®- Comment gérer un projet dont le temps est l’axe prioritaire ?

6 Sep

Mindview est Partenaire de DantotsuPM

« Time Driven Project »: comment éviter les pièges de ce type de projet et améliorer ses performances ?

Plus de 80% des projets sont dirigés en priorité par les coûts. Alors que faire quand il s’agit un projet dont l’axe prioritaire est le temps ?

Au travers d’un projet concret qui a été géré par Pierre-Marie Linden, cette intervention sera l’occasion d’échanger sur les bonnes pratiques de gestion du temps dans un projet.

Enregistrer

Enregistrer

%d blogueurs aiment cette page :