Tag Archives: planning

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 !

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 !

Mindview est Partenaire de DantotsuPM – Cliquez ici pour une démonstration et réalisez un essai 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 !

Mindview est Partenaire de DantotsuPM – Cliquez ici pour une démonstration et réalisez un essai 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

Mindview est Partenaire de DantotsuPM

Mindview est Partenaire de DantotsuPM

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

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

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

1 Sep

Splitting User Stories

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

Un défi usuel auquel sont confronté les équipes Scrum inexpérimentées est lié au découpage des « User Stories » (dans Scrum, les articles du Product Backlog) pour qu’elles soient suffisamment granulaires pour le développement. Le modèle INVEST est une bonne façon de tester si les « User Stories » sont bien écrites.

Microsoft est partenaire de DantotsuPM

Microsoft est partenaire de DantotsuPM

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

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

Indépendante

Chaque « User Stories » doit être indépendante l’une de l’autre. Ceci empêche les chevauchements entre les items; de plus, cela permet à l’équipe de les implémenter dans n’importe quel ordre.

Négociable

Les détails du travail doivent être négociables, tant parmi les parties prenantes que l’équipe. Les besoins spécifiques et décisions de conception seront étoffés pendant le développement. Beaucoup de praticiens agiles recommandent d’écrire les « User Stories » sur une petite fiche – ceci est intentionnel pour qu’une quantité limitée de détails puisse être prescrite.

de Valeur

Chaque « User Stories »doit ajouter un valeur métier/business au produit, au client et/ou à l’expérience des utilisateurs.

Estimable

Une bonne « User Stories » peut être suffisamment bien comprise par l’équipe pour qu’ils puissent l’évaluer – pas précisément – mais qu’à un haut niveau ils en perçoivent la taille. Il est utile de comprendre l’effort relatif en comparaison d’autres « User Stories ».

Suffisamment petite

Une « User Story » n’est pas assez petite si l’équipe ne peut pas la faire faire dans un seul Sprint. Comme des grandes « User Stories » sont divisées en items plus petits, la clarté sur la taille et la mise en œuvre est plus grande, ce qui améliore la probabilité que l’équipe le réalisera en un Sprint.

Testable

Chaque « User Story » devrait être testable; ceci est une caractéristique commune de tout besoin bien écrit. Si l’équipe ne peut pas déterminer comment la « User Story » peut être testée, c’est une indication que la fonction désirée ou la valeur business désirée ne sont pas assez claires.

Découpage vertical ou horizontal

Il y a deux manières communes de découper des « User Stories » : verticalement ou horizontalement. La découpe horizontale divise l’article au niveau d’un composant architectural. Exemple : Interface Utilisateur, bases de données ou services back-end. Tandis que, une découpe verticale aboutit à un résultat logiciel démontrable qui ajoute de la valeur au business. Donc, on recommande de découper verticalement les « User Stories » afin de réduire les dépendances et améliorer la capacité de l’équipe à livrer un incrémentent de produit potentiellement utilisable à chaque sprint.

Des exemples de découpe de « User Stories »

Trop grosse User Story: "En tant que client, je peux payer ma commande pour recevoir les produits"

Trop grosse User Story: « En tant que client, je peux payer ma commande pour recevoir les produits »

En tant que client, je peux payer ma commande pour recevoir les produits
Mindview est Partenaire de DantotsuPM

Mindview est Partenaire de DantotsuPM

Si la susdite histoire devait être divisée de façon verticale, elle pourrait se décomposer en fonction des façons de payer pour un client comme suit…

  • En tant que client, je peux faire un paiement par carte pour ma commande et collecter des points de récompense sur ma carte de crédit.

Et/ou

  • En tant que client, je peux faire un paiement PayPal pour ma commande pour que achever mon achat en toute sécurité sans partager les détails de ma carte de crédit avec un autre détaillant.

Le point clé de noter dans les « User Stories » verticalement décomposées comme ci-dessus consiste en ce que chaque « User Story »passe les tests INVEST mentionnés plus tôt et donc un Propriétaire de Produit (Product Owner) peut prioriser ces « User Stories » en fonction des besoins clients. Cependant, si une approche horizontale a été utilisée pour diviser la « User Story » (c’est-à-dire décomposition selon les couches et composants architecturaux) alors la mise en œuvre de tels besoins aboutira à une fonctionnalité utilisable Seulement quand tous les composants horizontaux seront finalement livrés et intégrés.

Découpage par flux de travail

revoir mon panier de courses

revoir mon panier de courses

Une autre approche souvent utilisée sur les « User Stories » est de se concentrer sur les étapes individuelles qu’un utilisateur peut entreprendre pour atteindre son objectif final. C’est-à-dire une « User Story » qui décrit un long parcours ou « flux utilisateur » dans un système peut être décomposé selon les étapes qui en représentent les parties. En reprenant l’exemple précédent d’un client faisant un achat en ligne, la « User Story » peut être décomposée de la manière suivante :

  • Fournir mes informations bancaires

    Fournir mes informations bancaires

    En tant que client, je peux passer en revue les articles que je veux mettre dans ma commande pour être confiant que je paye pour les bons articles.

  • En tant que client, je peux fournir mes informations bancaires pour ma commande pour recevoir les produits que j’ai achetés.
  • Recevoir une notification par SMS

    Recevoir une notification par SMS

    En tant que client, je peux recevoir un avis de confirmation pour mon achat pour suivre et garder une trace de mon achat.

D’autres méthodes

Il y a de nombreuses autres méthodes qui peuvent être utilisées dans le découpage des grandes « User Stories » comme :

Visitez le blog Agilistic

Visitez le blog Agilistic

  • par déroulement heureux / malheureux (ce qui se passe quand tout va bien versus quand il y a des exceptions, déviations ou autres problèmes)
  • par options d’interaction / par plate-forme
  • par types de données ou paramètres
  • par scénarios de test
  • par rôles
  • par ‘j’optimise maintenant ‘ contre ‘ j’optimise plus tard
  • par compatibilité de navigateur

la liste ci-dessus est détaillée (en anglais) dans ce billet: Blog.agilistic.nl.

Autres Ressources Utiles

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

L’approche classique du chef de projet autodidacte peut être dangereuse, voire préjudiciable, au succès du projet

31 Août
Jean-Baptiste Jourdant

Jean-Baptiste Jourdant

Dans un article intitulé « l’organigramme des tâches en management de projet » publié sur ce blog il y a déjà 5 ans, Jean-Baptiste Jourdant, consultant-formateur et Responsable du département Management de projet pour CSP Formation partait d’un constat simple :

L’approche classique du chef de projet autodidacte est de dire « quand on doit planifier, on planifie. Et quand on doit planifier, on le fait de façon détaillée, tant qu’à faire ! »

Hors, attaquer directement par la planification détaillée, c’est prendre le risque de se couper d’une réflexion structurelle sur la dynamique interne de son projet.

WBS 3D - OBSEn effet, le découpage va impliquer tout d’abord un regroupement de tâches a l’intérieur de lots. Ensuite cela va nécessiter pour chacun de ces lots un responsable auquel la réalisation sera déléguée: Objectif spécifique, moyens adaptés, contraintes (qualité, couts, délai)…

WBS 3D - ZBSEnfin, le choix de structuration de ces tâches va structurer le développement et le suivi du projet. Ces groupement par lots de tâches peuvent refléter une organisation du projet par métier (informatique, processus, opérations, commercial, marketing…), ou par région et pays dans ces régions pour le développement et déploiement de nouveaux produits par exemple, ou par cycle du projet : définir la stratégie, configurer, communiquer, implémenter, tester, former, …

Quelle que soit l’option choisie, elle n’est ni bonne ni mauvaise en soi.

CSP est partenaire de DantotsuPM

CSP est partenaire de DantotsuPM

Jean-Baptiste préconisait dans ce billet de respecter quelques précautions dans le choix de l’option :

WBS 3D - PBSÊTRE CHOISIE. Rien de pire qu’un découpage par défaut, par habitude, ou héritée par hasard d’un autre projet (qui pourrait être totalement différent).

• ÊTRE ALIGNÉE avec les enjeux du projet et les objectifs de la société.

• ÊTRE  ÉQUILIBRÉE et « COMPENSÉE ». En fonction du choix de découpage, le chef de projet devra probablement ajouter dans le management de son projet les composantes structurellement manquantes. Il doit par exemple mettre en place des processus, outils, réunions… pour garantir la cohérence métier ou technique si le choix de découpage est géographique. Ou, à l’inverse, veiller à impliquer les régions et pays si le découpage du projet est par métier.

Mindview est Partenaire de DantotsuPM

Mindview est Partenaire de DantotsuPM

Comment bien démarrer?

Jean-Baptiste propose que le chef de projet organise une réunion d’acteurs  ou d’experts et suive la démarche suivante:
  1. BRAINSTORMER : Lister toute tâche, activité, lot, thème nécessaire au projet.
  2. REGROUPER: Envisager au minimum 2 possibilités de regroupement des tâches pour avoir un choix.
  3. POSER LES AVANTAGES ET INCONVÉNIENTS de chacune de ces possibilités.
  4. CHOISIR UN DÉCOUPAGE et y incorporer les actions permettant d’incorporer les avantages de la solution non retenue.
  5. CRÉER LES LOTS, les sous-lots ou macro-tâches, puis nommer les responsables de ceux-ci.

Ensuite seulement il sera temps de penser à un planning…

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Saviez-vous que 3 des termes de PRINCE2 sont agiles ?

23 Août

En fait, beaucoup de termes de Prince2 sont en soi agiles et peuvent ajouter un niveau de flexibilité à la livraison de tout projet.

http://www.alctraining.com.au/4-prince2-terms-you-may-not-know-are-agile/ par ALC Group

Dans le monde de l’informatique, beaucoup de praticiens agiles croient que PRINCE2 n’est pas assez flexible pour les demandes business contemporaines. Cependant, pour ceux qui ont passé la formation PRINCE2, la plupart seront conscients que ceci est faux.

3 termes Agile Prince2En fait, beaucoup de termes de Prince2 sont en soi agiles et peuvent ajouter un niveau de flexibilité à la livraison de tout projet. Pour renforcer cette remarque, voici trois termes qui sont plus agiles que beaucoup ne le pensent.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Premier terme Agile – Initiation

A few videos to get started on Agile, Scrum and Kanban

A few videos to get started on Agile, Scrum and Kanban

Quand des projets PRINCE2 sont implémentés, ils comptent sur le cas d’affaires pour garantir qu’ils sont justifiables. Il y a aussi les plans qui décrivent ce qui arrivera, les contraintes budgétaires et les stratégies de livraison. Tous ces éléments sont identifiés et décidés pendant l’étape d’initiation.

Le cas d’affaires est l’espace parfait pour articuler une perspective agile et structurer les besoins de projets et planifiant d’incorporer en mode Agile des jeux de fonctionnalités et sorties de produit. Prenez par exemple le management du projet et de l’approche de livraison, les chefs de projet PRINCE2 peuvent tout à fait utiliser des approches agiles comme Scrum et Kanban.

De plus, les plans pourraient aussi être en « time boxing » plutôt que cascade, tandis que le financement pourrait être basé sur les releases plutôt que les étapes techniques traditionnelles liées à l’effort de livraison.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Mindview est Partenaire de DantotsuPM

Mindview est Partenaire de DantotsuPM

En implémentant ces approches dans l’étape d’initiation, le projet peut se concentrer sur la livraison de valeur, diminuant les délais de time-to-market et permettant aux utilisateurs finaux d’utiliser des composants de valeur dès que possible.

Second terme Agile – Work package (Lot de travail)

Une des idées fondamentales des approches Agiles est l’auto-organisation des équipes. Pour que ceci devienne une réalité, les équipes doivent être conscientes de leurs responsabilités et organisées selon des  frontières comprises et communicables.

Le lot de travail PRINCE2 n’écarte pas ces principes de base Agile et peut faciliter cette forme d’organisation. Par exemple, les lots de travail peuvent permettre aux praticiens agiles de communiquer aux parties prenantes leurs rôles, responsabilités et autorité. Ceci permettra aux équipes d’être certaines de ce qu’elles doivent faire pour construire et livrer des produits de valeur.

Troisième terme Agile – Tolérance

prioriser2Avec PRINCE2, le contrôle de la tolérance est sous la responsabilité du chef de projet. La tolérance se réfère à n’importe quelle variation des estimations acceptées lors du cas d’affaires par rapport aux délais, coûts, risques, bénéfices et contenu (périmètre). Si ces tolérances semblent en passe d’être excédées, il est de la responsabilité du chef de projet de remonter ceci au Conseil de Projet pour maintenir un contrôle formel des changements et obtenir une rapide prise de décision.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Les méthodologies agiles ont les mêmes approches, bien que sous l’apparence de mécanismes de priorisation. Par exemple, beaucoup de praticiens utiliseront MoSCoW pour ajuster le contenu de leur projet et rester les délais et budget alloués.

Produit Viable Minimum (MVP)

Produit Viable Minimum (MVP)

La qualité suit une approche similaire. Prenez par exemple la fabrication d’une voiture. Une approche Agile se concentrerait sur le produit viable minimal – le moteur, le châssis et d’autres fonctions centrales, tandis que les fonctionnalités comme le système de climatisation et le toit ouvrant seront inclus seulement si le temps et les coûts le permettent. PRINCE2 peut faire de même. Il a déterminé les tâches requises et le budget alloué qui est accompagné du contenu. Ceci permet aux projets d’être changés en temps réel pour répondre à des éventualités du marché ou dans le périmètre du projet.

Pour beaucoup, PRINCE2 est toujours l’une des plus, sinon la plus, importante des méthodologies de management de projet disponibles.

Assister à un cours de formation PRINCE2 est une excellente façon de comprendre l’agilité inhérente à cette méthode. C’est aussi une bonne façon d’étendre vos perspectives de travail et d’améliorer votre capacité à livrer des projets rentables dans les temps, avec un focus client et des standards élevés.

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

une mauvaise migration de système ressemble à une passe ratée dans la surface de réparation !

18 Août

Le système est-il prêt ?

Article original en Anglais « Planning System Cutovers » par Dave Nielsen

Office Workers Clapping at Office PartyL’équipe a bossé dur et construit un système qui satisfait à toutes les exigences business. Elle l’a testé et a vérifié qu’il répond à tout le jeu de normes de qualité applicables et les membres de l’équipe l’ont livré dans les temps. Maintenant vous pouvez vous asseoir et vous féliciter de l’excellent travail que vous avez fait en manageant ce projet.

Eh bien, pas tout à fait … …votre travail n’est pas terminé tant que le nouveau système n’est pas en production et la responsabilité du support transférée aux opérations. Pour y parvenir, vous devez planifier la migration parfaite.

Avant la planification de la migration il y a quelques interrogations auxquelles on doit répondre, comme:
  • “Comment le système se comportera-t-il dans l’environnement de production ?”
  • “Comment le système se comportera-t-il dans l’environnement de production ?”
  • “Le nouveau système peut-il supporter tous les utilisateurs qui doivent l’utiliser ?”

Telles sont les questions auxquelles l’on devrait répondre avant d’être prêts pour une transition en production.

Abordons ces questions dans l’ordre.

“Comment le système se comportera-t-il dans l’environnement de production ?”

SMP Test maturiteLa réponse à la première question devrait être “il s’exécutera aussi bien qu’il le faisait dans l’environnement de test”. Vous pouvez répondre avec assurance à la question parce qu’un jeu complet de tests a été exécuté dans un environnement de test qui est en tout un double de l’environnement de production hormis la présence des utilisateurs. Cet environnement est parfois appelé l’environnement de pré-production.

Le serveur qui supporte le système devrait être un clone du serveur de production. Si le système s’exécute dans un environnement distribué, tant l’hôte que le client doivent être dupliqués sur un réseau qui est un double du réseau de production.

Mindmap est Partenaire de DantotsuPM

Mindview est Partenaire de DantotsuPM

Fréquemment nos systèmes nouveaux ou mis à jour doivent fonctionner dans un environnement qui comporte un système d’exploitation standard et du logiciel “sur étagère” supplémentaire (Off The Shelf). Les systèmes d’exploitation et le logiciel “sur étagère” dans l’environnement de pré-production devraient être le duplicata exact de ce qu’ils seront dans l’environnement de production et toutes les versions logicielles devraient être les mêmes.

Assurez-vous que toutes les corrections qui seront appliquées au système de production sont aussi appliquées à l’environnement de pré-production.

Si votre nouveau système exige une mis à jour du système d’exploitation et/ou d’un logiciel auxiliaire assurez-vous que vous installerez les mêmes sur l’environnement de production que sur l’environnement de pré-production. Tester votre système nouveau ou mis à jour sur le même matériel et le logiciel que ceux sur lesquels il fonctionnera dans l’environnement de production est une partie critique des tests. Fréquemment le logiciel se comportera différemment selon la combinaison de matériel/OS sur laquelle il fonctionne. Le système peut fonctionner sur la nouvelle combinaison, mais se comporter différemment selon l’environnement; donc une série complète de tests devrait être utilisée pour tester dans l’environnement de pré-production.

“Comment le système se comportera-t-il dans l’environnement de production ?”

data hard diskLa plupart des systèmes exigent de nos jours que des informations soient stockées et récupérées. Cela peut être minimal, comme un jeu d’identifiants utilisateurs et de mots de passe pour la connexion d’utilisateurs, ou cela peut être l’exigence plus importante d’une grosse base de données relationnelle. Les données qui doivent être propagées depuis l’environnement de production précédent doivent être clairement identifiées et un plan de travail défini pour les capturer et les installer dans le nouveau système pendant la migration.

En attendant, les tests dans l’environnement de pré-production devraient être réalisés avec un jeu de données qui simule l’environnement de production aussi étroitement que possible. Les données devraient imiter la production dans les secteurs de la volumétrie et de la distribution. C’est d’habitude accompli dans les systèmes ayant une grosse base de données relationnelle en prenant une copie instantanée des données de production, la convertissant au nouveau format de données et la chargeant dans l’environnement de pré-production. Ce processus de conversion est critique à la migration.

Pendant la migration, le processus utiliser pour convertir et charger les données dans l’environnement de pré-productions sera répété pour transférer les données vers le nouvel environnement de production. Non seulement le processus doit être répétable, il doit être optimisé pour que le téléchargement, la conversion et le chargement se déroulent rapidement.

“Le nouveau système peut-il supporter tous les utilisateurs qui doivent l’utiliser ?”

fastVotre projet peut ou pas avoir délivré des améliorations de performance. S’il l’a fait, ces améliorations doivent être vérifiées dans l’environnement de pré-production. Si aucune amélioration de performance n’a été exigée, il devrait s’exécuter au moins aussi bien que la précédente version. Le test devrait inclure la mesure de la performance de fonctions fréquemment utilisées en temps de charge. Par exemple, si le nombre maximal d’utilisateurs que le système doit supporter est 1000, à quelle rapidité le 1000ème utilisateur est-il connecté ?

Des points de référence devraient être spécifiés dans les secteurs de la performance, de la charge et le test de stress devrait être exécuté dans l’environnement de pré-production et vérifier par rapport à ces points de référence.

C’est seulement quand tous les points de référence ont été atteints ou dépassés que vous êtes prêts pour la migration.

Les Utilisateurs sont-ils Prêts ?

Le système peut être prêt pour les utilisateurs mais est-ce que les utilisateurs sont prêts pour le système ? De nouveaux systèmes apportent les communications dans l'équipegénéralement de nouvelles fonctionnalités que la communauté métier doit utiliser pour satisfaire aux nouvelles demandes du marché, pour répondre à un besoin de réduire l’effort, pour améliorer les performances, etc.

Les utilisateurs doivent être préparés pour qu’ils puissent bénéficier du nouveau système aussitôt qu’il est activé. Toute nouvelle fonctionnalité demande généralement de former la communauté des utilisateurs, mais au-delà de cela, ils doivent savoir quand le nouveau système sera mis en œuvre. Passer au nouveau système sans notifier la communauté d’utilisateurs, même une communauté d’utilisateurs formés, aboutira à un déluge d’appels de support.

La migration exige souvent une fenêtre de temps pendant laquelle ni les nouveaux systèmes ni les vieux ne seront disponibles.

C’est particulièrement vrai des systèmes qui utilisent d’importants volumes de données. Les données doivent être gelées pour être récupérées du vieux système, converties et copiées vers le serveur du nouveau système. Les utilisateurs n’auront pas d’accès aux données pendant ce laps de temps et donc devraient être notifiés pour qu’ils puissent planifier en amont cette période d’inactivité. Migrer vers le nouveau système pendant les heures de travail normales sans notifier la communauté d’utilisateur déclenchera immanquablement un déluge d’appels de support et peut causer plus de dégâts si les délais ne sont pas respectés. Votre migration comprendra un bulletin avant la fermeture du vieux système mais votre communauté d’utilisateurs doit être informée bien en avance de ce bulletin dans votre processus de migration.

Le Plan de Migration

PM PlanLe travail qui peut être fait sans perturber l’environnement de production devrait être fait en avance de la migration. Des tâches comme des installations de matériel, des installations de base de données, des installations d’OS, des installations logicielles devraient toutes être faites en avance de la migration réelle. Le plan de migration doit identifier et prévoir toutes les activités qui doivent se produire au moment de la migration. Mettre en place de nouveaux systèmes qui remplacent des systèmes existants exigera typiquement que la migration se déroule pendant des heures creuses. Le temps nécessaire devrait être identifié dans votre plan. L’heure H marque le début de vos activités de migration. Le plan devrait inclure chaque activité à exécuter, son responsable principal et le temps alloué à cette tâche. L’identification d’un remplaçant au responsable principal vous donnera un niveau de sécurité supplémentaire .

La première tâche sera le bulletin notifiant la communauté d’utilisateurs que l’arrêt se produira à l’heure H. Vous pouvez vouloir publier plusieurs bulletins pour vous assurer que tous les utilisateurs reçoivent la notification (y compris les utilisateurs qui se connectent 30 minutes avant l’arrêt). La tâche suivante est la récupération de toutes les données de l’environnement de production. Le téléchargement, la conversion et le chargement de données devraient suivre la procédure définie pendant le test.

Il y a plusieurs façons d’approcher la migration.

Vous fournissez un nouvel environnement de production et mettez le vieux à la retraite, vous utilisez l’environnement de production existant et échangez l’environnement de production par celui de la pré-production.

L’approche que vous prenez déterminera vos étapes suivantes et sera influencée par combien d’argent l’organisation doit/peut dépenser sur le système et à quel point le système supporte une mission cruciale pour l’entreprise.

  • Fournir un nouvel environnement de production et mettre le vieux à la retraite ou échanger la pré-production et les environnements de production vous permettra d’exécuter des activités comme l’installation de matériel, les installations de base de données, les mises à jour logicielles, etc avant la migration.
  • La réutilisation de l’environnement de production existant exigera probablement que vous exécutiez ces activités pendant la migration.

Chaque activité devrait être vérifiée sur l’environnement de pré-production et mesurée pour qu’une durée raisonnable puisse être intégrée dans votre plan de migration. Puisque le but ici est de  limiter la durée d’indisponibilité, essayez de prévoir autant d’activités en parallèle que possible sans risquer l’échec. Une fois que l’environnement de production a été mis à jour vous pouvez charger les données converties.

L’étape suivante devrait être un test “de fumée” (smoke test) du nouveau système de production.

Le test devrait être assez minutieux pour assurer qu’aucune étape de migration n’a été manquée, mais rationalisé pour qu’il puisse être exécuté dans une durée relativement brève. Les connexions d’utilisateur sont toujours un bon candidat aux tests de fumée. N’importe quel travail qui est exécuté fréquemment par les utilisateurs en est un autre.

La dernière étape devra exécuter toute mise à jour de l’OS nécessaire pour rediriger les utilisateurs sur le nouveau système et notifier que le système est prêt.

Ce bulletin est aussi une occasion d’informer les utilisateurs de tous les changements du système, comme des numéros de version, de nouvelles fonctionnalités, etc. Rendez le nouveau numéro de version évident à trouver et dirigez des utilisateurs sur les documentations décrivant la mise à jour dans votre bulletin d’annonce. Arrangez-vous pour faire surveiller le nouveau système dès la migration. Puisque la plupart des migrations arrivent pendant les périodes d’utilisation non-maximale, la  surveillance devrait durer au moins jusqu’à ce que le système rencontre une situation d’utilisation maximale, par exemple le lundi matin.

NQI est Partenaire de DantotsuPM

NQI est Partenaire de DantotsuPM

Votre plan devrait toujours être testé sur l’environnement de pré-production pour vous assurer de sa complétude (c’est-à-dire toutes les activités nécessaires sont identifiées) et que les durées sont adéquates. Si l’équipe a des problèmes à réaliser une tâche à 10h00 un mardi où personne ne souffle sur leurs nuques, ils échoueront quand ils essaieront à minuit un samedi avec le le Vice Président des Opérations qui les observe.

Stratégie de Retour Arrière

L

Vous souvenez-vous j’ai mentionné qu’un test de fumée et un contrôle sont les parties essentielles du plan ? Que se passe-t-il si le test de fumée échoue ou le contrôle révèle un degré inacceptable de dégradation de système pendant l’utilisation nominale ? La réponse est: un retour arrière.

Le retour arrière rétablit le système et les données précédents sur l’environnement de production et ressemble fortement à une autre migration.

La stratégie de retour arrière dépendra de l’approche de migration utilisée. L’environnement de production doit-il être changé pour revenir en arrière ? ou est-ce que ce sera simplement une question d’installation de l’ancienne base de données dans l’environnement de pré-production et de rediriger les utilisateurs sur celui-ci ?

La stratégie de retour arrière devrait être testée avec le plan de migration pour s’assurer qu’elle fonctionne.

Cela peut sembler beaucoup de travail, d’autant plus que vous devrez probablement ramener l’environnement de pré-production à son état d’avant la migration, mais cela mérite l’effort particulièrement sur des systèmes de mission cruciale.

Et pour finir

Le plan de migration, y compris la stratégie de retour arrière, devrait être passé en revue avec des experts des migrations précédentes et le groupe de support.

supportLes experts de migrations précédentes sont une source d’informations de valeur sur ce qui marche bien ou pas dans votre organisation. Les leçons apprises sont une autre source d’informations mais les auteurs de ces leçons sont d’encore plus de valeur.

Le groupe de support portera le contrecoup principal de n’importe quelles bévues dans la planification ou l’exécution de la migration. Il devrait se sentir confortable que le plan n’a pas loupé d’étapes et que son exécution leur livrera un système supportable quand il le recevra après la migration.

Le plan de migration sera un livrable clef à la réunion de revue de jalon, ou la réunion de pré-jalon, tenue pour déterminer que vous êtes prêts pour la migration.

Le plan de migration ne semblera pas être un livrable important dans le rush pour compléter le projet dans les temps mais l’attention aux détails de ce plan en avance de la migration vaudra bien tous vos efforts.

Ne pas prêter l’attention nécessaire à ce livrable critique gâchera tout le dur labeur de l’équipe pour atteindre ce point culminant.

Peu importe comment l’équipe a bien réussi pendant le reste du projet, on se souviendra seulement du désastre au moment de la migration bien longtemps après que tout ce bon travail soit oublié. Une mauvaise migration ressemble à  une passe ratée dans la surface de réparation. L’attaquant peut avoir gagné 150m en courant, mais on se souviendra seulement qu’il a coûté la victoire à son équipe en ratant la dernière passe décisive.

Enregistrer

Enregistrer

Enregistrer

connaissez-vous la règle des 18 mois et pourquoi des projets sont annulés pour de mauvaises raisons ?

30 Mai

Why Projects Are Cancelled For The Wrong Reasons

http://www.fatcat.com.au/news/home/Ask+an+Advisor/418_0.html

Un nombre élevé et disproportionné de projets sont annulés par le management à 18 mois.

Comme dans tout projet, il y a un flux et un reflux naturel. Un rythme naturel. Ce que je trouve intéressant est que le rythme semble s’installer dans ce que j’appelle la Règle des 18 Mois.

La règle des 18 Mois déclare que :

Loi_de_Moore

Loi de Moore

Un nombre disproportionné de projets est annulé par le management à 18 mois.

N’oublions pas que beaucoup de secteurs ont un rythme naturel, par exemple technologique. Le rythme technologique le plus célèbre est la Loi de Moore qui prévoit que la croissance dans le nombre de transistors par puce doublera tous les vingt-quatre mois. D’autres lois technologiques qui ont un rythme naturel incluent la Loi de Kryder pour le stockage sur disque (~12 mois) et la Loi d’Haitz pour la production de LED’s (~18 mois).

Pourquoi y-aurait-il une Règle de 18 Mois pour les projets ?

Y aurait-il une certaine loi naturelle dans le travail ? La réponse est simple : oui. La nature humaine.

En regardant en arrière tous les projets que j’ai managés dans ma carrière, le cycle de 18 mois d’annulation des projets revient à travers industries, contextes, technologies, tailles d’organisations et nationalités. La règle semble universelle. Pourquoi ?

Dix-huit est le nombre maximal de mois pendant lesquels le management peut souffrir. Cette douleur est la répétition des efforts de re-justification d’un projet dont on attend encore de voir les bénéfices.

Pourquoi 18 mois et pas 12 ou 24 ?

monthsPensez à un projet donné. La plupart débutent en milieu d’année avec un financement et des ressources alloués à grand-peine par le management en se basant sur le mérite et les impacts et bénéfices potentiels. Quand le cycle budgétaire suivant arrive, le projet est bien lancé et le financement est presque assuré car le projet a démarré depuis moins d’une année et que personne ne s’attend à ce qu’il ait déjà un impact. Donc, les ressources sont maintenues en place et le projet continue de progresser.

Le deuxième cycle est une question totalement différente.

Quand le cycle budgétaire suivant survient, des questions s’ élèvent sur le projet :
  • Est-ce que ce projet est toujours aussi important ?
  • Y-aurait-il des projets plus importants que nous devrions financer au lieu de celui-là ?
  • Atteignons-nous les progrès escomptés ?
des budget limités, voire compressés...

il faut se battre pour chaque nouvelle année de financement !

Pourquoi ces questions ?

Parce que chacun dans la chaîne de management doit re-justifier le projet pour encore une autre année de financement. C’est ce deuxième tour qui cause toute l’angoisse. Le résultat est que le management arbitrera s’il faut se battre pour une autre année de financement ou laisser le projet mourir et éviter cette peine. Comme nous pouvons tous l’apprécier, éviter la douleur est une réaction humaine naturelle.

Si le management pouvait voir la valeur (quelque chose qui justifie la peine), approuver que le projet continue ne serait pas un problème. Là où la plupart des équipes de projet s’attirent des ennuis est qu’elles ne saisissent pas cette réaction d’évitement de douleur du management. Dans leurs esprits, le management devrait seulement obtenir les financements et avoir confiance en équipe.

Le résultat est qu’un grand pourcentage de projets sont tués à 18 mois parce que l’on n’a pas démontré leur valeur.

Attendez ! Dites-vous. Nous avions un accord que ce serait un projet sur plusieurs années et que les bénéfices ne viendraient qu’à la fin. Ceci ne prouve-t-il pas que la Règle des 18 Mois ne s’applique pas ? NON. Si vous croyez vraiment que vous pouvez éviter le problème en obtenant un accord au départ, alors vous ne comprenez pas la nature humaine. Au cas où votre projet passerait le jalon des 18 mois, la peine grandira avec chaque cycle ultérieur. Ce qui signifie que vous devrez démontrer une valeur et un impact toujours croissants pour pouvoir continuer. La douleur ne part pas avec le temps. En réalité, elle augmente.

Ce n’est pas la faute de la direction. C’est la faute de l’équipe de projet qui échoue à comprendre le désir du management d’éviter la douleur.

Comment une équipe évite-t-elle cette règle ?

règle des 18 moisSuivez les quelques étapes simples suivantes :

1) Comprendre le cycle de votre organisation (ou votre client) pour vous assurer que vous comprenez le timing. Quand les budgets et/ou les stratégies sont-ils bouclés chaque année ?

2) Définir votre portée de projet et de livrables pour être certains que ce que vous livrez a un impact/une valeur avant que la règle ne soit appliquée.

3) Pour les projets qui s’étendent au-delà de 18 mois, découpez-les et faites de chaque partie un projet distinct. Pourquoi ? Pour esquiver le problème d’évitement d’une peine qui s’intensifie avec le temps car chaque projet remet les compteurs à zéro.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Dans mon expérience, j’ai vu la règle des 18 mois appliquée à des projets qui auraient du être tués dès le départ et à d’autres qui n’auraient jamais dus être arrêtés.

Cette apparente prise de décision aléatoire du management peut être perturbante et démoralisante dans une organisation. Si vous êtes dans le management, regardez-vous dans le miroir et comprenez que la nature humaine joue un rôle dans votre prise de décision de tuer des projets. Aidez vos équipes à le comprendre.

Si vous menez un projet, utilisez ces stratégies de management de projet simples afin d’éviter ce que dans le passé vous aviez attribué à des caprices du management.

CSP est partenaire de DantotsuPM

CSP est partenaire de DantotsuPM

En comprenant la Règle des 18 Mois, vous pouvez vous assurer que vos projets auront l’impact que vous désirez.

Bonne chance !

%d blogueurs aiment cette page :