Rencontres sur le management de projets – 4 au 10 Juin

Que puis-je vous recommander en cette deuxième semaine du mois de juin ?

… des wébinaires et rencontres sur des thèmes variés du management de projet: EcoPMI, Gestion des ressources, la célèbre conférence virtuelle MS Project, pourquoi adopter AgilePM ?

Mardi 5

Nous sommes une communauté de chefs de projets de sociétés diverses et nous nous retrouvons régulièrement pour améliorer nos pratiques lors de conférences et de cercles de discussion. Nous souhaitons continuer à créer du lien entre nous, à échanger, à réseauter, à apprendre des autres. Bref à faire et vivre grandir la communauté des chefs de projets de Montpellier. Que vous soyez chef(fe) de projet aguerri(e) ou novice, n’hésitez pas à nous rejoindre pour échanger des bonnes pratiques professionnelles autour d’un verre dans un cadre sympathique à Montpellier de 18H30 à 20H30

Inscriptions sur le site du PMI France

Plusieurs chefs de projet vont nous faire partager leur expérience, leurs bonnes pratiques et difficultés: Quelles sont les solutions existantes pour répondre à cette problématique ? Quelles sont les organisations mises en place ?

AE, Architects for Business & ICT will provide us with a simple but challenging business game where collaboration and communication are key. It will be amusing for everybody!

Mercredi 6

The Hanford Double Shell Tank AY-102 Recovery Project successfully transferred nuclear waste into a double shell tank for safe storage with no safety issues, ahead of schedule, and US$8.7 million under budget. This project was the winner of the 2017 PMI Project of the Year Award. Learn about this award winning project’s challenges, best practices, and lessons learned in this webinar.

Méta Projets Management est partenaire de DantotsuPM
AgilePM Certification details

What the key elements of Agile Project Management are, and how these, using simple and non-IT examples, can increase chances of success whilst minimizing the level of risk.

Mercredi 6 et Jeudi 7

A 24-hour conference dedicated to Microsoft PPM including MS Project, Project Server and Project Online. This conference is completely focused on Microsoft® Project, Project Server and Project Online, with a lot of support from the Microsoft Project Community. So you get pure, unadulterated content about using the technology for your business problems.

Jeudi 7 à Samedi 9

Check the programme and register on line

Vendredi 8

Le webinaire en replay

Agile approaches continue to increase in popularity in the world of project management. A range of popular Agile methods have been employed to varying degrees by organizations to support their project management practices. But few of them offer a complete project management solution (e.g. covering the full project lifecycle, roles & responsibilities, etc).

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

IQar et SMPP confirment le partenariat avec le blog DantotsuPM pour la 5ème année consécutive !

Cette année se placera sous le signe des outils de la Maturité en Projets des organisations soucieuses d’améliorer leur système de pilotage des projets et du portefeuille.

La Gestion de Projets et Portefeuille By IQar, découvrez la plateforme de Maturité en Projets !

Nouveauté 2017/2018 : L’outil PPM d’IQar, SuiteProG : un pilotage pragmatique, simple d’accès et pédagogique !

Démonstration de l’outil
  • Plus de 1000 utilisateurs,
  • Une équipe Produit constituée pour un outil full SaaS : les consultants experts associés à notre une cellule R&D informatique développent les prochaines feuilles de route de SuiteProG
  • Une nouvelle version de SuiteProG présentée prochainement lors du Club Utilisateurs SuiteProG ! Première édition prévue en Juin 2018

Pour en savoir plus, demandez-nous une démonstration personnalisée de SuiteProG : cliquez ici.

 

Évaluez la maturité ’Projets’ de votre Organisation : Faites les tests !

En ligne, tests gratuits avec rapports complets d’audit !

www.testmaturite.com

www.profilprojet.com

SMPP est Partenaire de DantotsuPM

Et appuyez-vous sur le référentiel français SMPP, le métier et les conseils d’IQar pour décliner cette maturité en plan de progrès

IQar, auteur du référentiel français du système de management des portefeuilles de projets (SMPP), met à disposition des organisations, une plateforme d’information sur l’évaluation et le développement de la maturité en management des portefeuilles projets.

Partenaire de DantotsuPM

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

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

The Best Laid Plans often go awry

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

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

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

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

Livre sur Amazon

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

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

CertYou est partenaire de DantotsuPM

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

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

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

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

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

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

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

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

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

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

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

Participez à l’élaboration du Smart Assistant qui va révolutionner la manière dont vous collaborez !

les ateliers Entr’UP

Avec le mode projet, la hiérarchie s’estompe et les équipes doivent apprendre à collaborer efficacement pour aller au bout de leur mission.

85% des équipiers reconnaissent avoir été confrontés à plusieurs formes de conflits durant leurs projets

Le logiciel Entr’UP Teams qui améliore la collaboration des équipes, leur cohésion et leur efficacité, à travers la maîtrise des interactions est utilisé par de nombreuses équipes. Entr’UP recrute pour participer à un atelier des chefs de projet, directeurs de projets qui vont évaluer les futures fonctionnalités de Smart Assistant, Entr’UP Teams.

En savoir plus sur les ateliers, vous inscrire à l’un d’eux en présentiel ou à distance et ce que vous y gagnerez.

18 Janvier – WEB&CAFÉ (30’ à 14 :00) – Retour d’expérience sur « Comment trouver l’outil PPM adapté à mon organisation ? »

La CAISSE D’ÉPARGNE Loire Centre prend le micro du premier Web&Café de l’année !!!

Sandrine BACHELLERIE

Bonjour, je m’appelle Sandrine BACHELLERIE.

Je suis Chef de Projet Organisation au sein du groupe CE Loire Centre. J’ai le plaisir de partager avec vous cette étape incontournable de la démarche de professionnalisation de sa gouvernance en Projets : Choisir son outil de gestion projets et le déployer !

Notre choix s’est porté sur SuiteProG, outil PPM conçu par les experts du cabinet IQar, et nous vous expliquerons pourquoi au cours de ce Web&Café !

Plus de 100 utilisateurs à former, une maturité en Projet débutante, des connaissances et pratiques en gestion de projets hétérogènes, bref l’aventure promettait d’être périlleuse !

Venez partager avec nous et poser toutes vos questions !

Inscriptions gratuites en ligne

Venez découvrir plus qu’un outil, une association pédagogique d’une méthodologie de management en portefeuille projet labélisée et une solution PPM 100% orienté pilotage projets !

Les outils de gestion du portefeuille de projet participent incontestablement à la maturité des organisations dans leur gouvernance Projets. Améliorer la gestion des demandes, des ressources, scorer pour arbitrer les projets à plus forte valeur ajoutée, piloter les portefeuilles de projets, tout ceci est rendu possible par ces outils PPM.

Que vous soyez Porteur, Sponsor ou Manager Projet, si vous souhaitez vous saisir du sujet Comment trouver l’outil PPM adapté à mon organisation et vous forger votre opinion sur les bénéfices de SuiteProG, cette session est pour vous !

« Pourquoi SuiteProG serait la solution PPM adaptée par rapport à mon besoin et la maturité en Projets de mon organisation ? »

Une question que nous poserons à notre invitée : Sandrine BACHELLERIE, Chef de Projets Organisation – CAISSE D’ÉPARGNE

Inscrivez-vous

Si vous souhaitez aller plus loin sur le sujet : Découvrez nos outils d’auto-diagnostic !

SMPP est Partenaire de DantotsuPM

Téléchargez gratuitement le référentiel francophone du management de portefeuille des projets, SMPP, www.smp2.org

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

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

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

Do you deliver dazzling demos?

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

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

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

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

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

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

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

CertYou est partenaire de DantotsuPM

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

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

Serhiy Kharytonov

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

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

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

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

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

Article original de Serhiy Kharytonov, SoftServe © 2009

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

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

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

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

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

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

Waterfall / « En cascade »

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

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

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

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

RUP (rational unified process)

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

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

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

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

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

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

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

Agile

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

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

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

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

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

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

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

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

CertYou est partenaire de DantotsuPM

Le meilleur de chaque monde

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

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

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

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

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

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

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

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

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

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

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

itérations et incréments

Que signifient les mots itératif et progressif ?

http://www.jrothman.com/mpd/agile/2016/11/iterations-and-increments/ par Johanna Rothman

Agile, c’est le développement itératif et progressif et la livraison fréquente avec un changement culturel vers la transparence.

Itératif signifie que nous prenons « un morceau à la fois » pour créer une fonction entière. Des approches itératives gèrent le risque technique. Nous apprenons du risque comme nous réitérons à travers le jeu entier des fonctionnalités.

Progressif signifie que nous livrons des portions de valeur. Les approches progressives managent le risque de planification, parce que nous délivrons un travail fini à chaque étape.

Book on Amazon

Agile fonctionne parce que nous manageons les risques techniques et ceux de planification. Nous réitérons sur un jeu de fonctionnalités, livrant de gros incréments de valeur. (Une raison pour livrer de la valeur souvent et que nous pouvons ainsi changer ce que l’équipe va faire ensuite).

Prenons l’exemple d’un jeu de fonctionnalités appelé: “l’établissement d’une connexion sécurisée”.

Personne ne veut avoir à s’identifier pour se connecter. Mais, les gens veulent avoir une forte sécurité pour leur paiement. Hors, l’établissement d’une connexion sûre peut être une façon d’arriver à garantir le paiement. Le thème, ou ce que j’appelle un jeu de fonctionnalités, est “l’établissement de la connexion sécurisée”. Un jeu de fonctionnalités, ce sont plusieurs fonctions reliées qui livrent un thème.

Si vous voulez réitérer sur le jeu de fonctionnalités, vous pourriez livrer ces incréments de valeur :
  1. L’utilisateur existant déjà peut se connecter.
  2. Les utilisateurs peuvent changer leur mot de passe.
  3. Ajouter le nouvel utilisateur comme utilisateur.
  4. Ajouter le nouvel utilisateur comme admin.
  5. Empêcher des utilisateurs indésirables de se connecter : bots, certaines adresses IP, ou un emplacement physique. (3 histoires séparées.)

Si vous mettez en œuvre la première histoire, vous pouvez utiliser un fichier à plat. Vous pouvez toujours utiliser un fichier à plat pour la deuxième histoire. Une fois que vous commencez à ajouter plus de 10 utilisateurs, vous pourriez vouloir passer à une sorte de base de données. Ce serait une autre histoire utilisateur. Ce n’est pas “Créer une base de données.” L’histoire serait “Explorer des options pour permettre d’ajouter 10, 100, 1000, 10000 utilisateurs à notre site et voir quelles sont les implications en matière de performance et de fiabilité.”

Remarquez « explorer » comme une partie de l’histoire. Cela pousserait à produire des options que l’équipe puisse discuter avec le Product Owner. Certaines options ont des implications à l’exécution.

Chaque fois l’équipe réitère sur le jeu de fonctionnalités, elle livre un incrément. Puisque beaucoup d’équipes utilisent des durées de temps fixes (timebox), elles utilisent « des itérations » comme leur timebox. (Si vous utilisez Scrum, vous utilisez des sprints.) Remarquez les mots “réitère sur le jeu de fonctionnalités.”

Dans des cycles de vie progressifs, comme la livraison par étapes, l’équipe finirait toutes les fonctionnalités dans un jeu de fonctionnalités donné. Les cycles de vie incrémentaux n’ont pas nécessairement à utiliser des timeboxes pour livrer leur développement progressif. Dans les cycles de vie itératifs, comme spiral ou RUP, l’équipe développerait des prototypes de fonctionnalités, ou même finirait partiellement des fonctionnalités, mais l’intégration finale et les tests n’arrivent qu’après que tout le développement itératif ait été fait.

Dans Agile, nous réitérons sur un jeu de fonctionnalités, livrant la valeur progressivement.

Si vous ne finissez pas vos histoires, vous êtes dans un cycle de vie itératif. Si vous ne limitez pas les fonctionnalités que vous finissez et ne les terminez pas « toutes », vous êtes dans un cycle de vie progressif.

Il n’y a pas de bonne façon de choisir un cycle de vie pour votre projet. Si vous voulez utiliser agile, vous réitérez sur un jeu de fonctionnalités sur un bref cycle de temps, livrant de gros incréments de valeur.

CertYou est partenaire de DantotsuPM

 

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

Une progression ordonnée qui reste séduisante et bénéfique sur les projets où il est possible de bien définir les exigences en amont.

The Benefits of Traditional, Waterfall Project Management

http://kellyprojectsolutions.com/benefits-traditional-waterfall-project-management  par Technology Advice

L’approche « en cascade » d’analyse et de conception des systèmes a été créée dans les années 1970 et a gagné la popularité à cause de sa progression logique, linéaire. Les tâches sont décomposées en cinq parties qui suivent une progression ordonnée : définition des exigences, conception, mise en œuvre, vérification et maintenance. Dans la phase de définition des exigences, les programmeurs et le client déterminent le périmètre du projet; dans la phase de conception, les programmeurs créent des designs ou maquettes basiques et complexes; dans la phase de mise en œuvre, les programmeurs testent le code source comme le programme est écrit; dans la phase de vérification, les programmeurs évaluent la conception et corrigent les erreurs; et dans la phase de maintenance, les programmeurs apportent les changements nécessaires pour assurer que le système continue de fonctionner correctement. Chaque phase doit être soigneusement planifiée à l’avance pour assurer le succès.

Aujourd’hui, beaucoup de business optent au lieu de cela pour la gestion de projet Agile. Les personnes qui utilisent cette méthode se concentrent sur la production de petites parties du projet dans chaque cycle de livraison, plutôt que la création d’un plan pour le projet entier.

Cependant, l’approche en cascade traditionnelle du management de projet a toujours plusieurs bénéfices clefs.

D’abord, les développeurs et clients discutent ce qui sera livré tôt dans le processus, ce qui rend la planification et les phases de livraison plus évidentes.

Selon Techrepublic.com “l’accent sur les exigences et la conception avant l’écriture d’une seule ligne de code assure un gaspillage minimal de temps et d’effort et réduit le risque de dérapage de délais, ou d’attentes de client non atteintes.” Parce que les promoteurs et des clients discutent des objectifs finaux dans le détail, les deux parties ont une solide compréhension des attentes primaires et des résultats désirables. En conséquence, il est beaucoup plus facile de garantir que le projet est sur la bonne voie.

Ensuite, la méthode peut sauver du temps et de l’argent.
Livre sur Amazon

Les programmeurs développent seulement le code qui est en réalité nécessaire, ce qui sauve temps et effort pendant les étapes initiales. Les développeurs peuvent corriger n’importe quelles erreurs ou défauts tôt dans le processus, ce qui permet à la phase de mise en œuvre de se dérouler sans à-coup. Parce que l’objectif final est clairement défini dans les étapes de démarrage, toutes les parties comprennent les contraintes de temps et de finances du projet. Dans son livre paru en 1996 Rapid Development: Taming Wild Software Schedules Steve McConnell a évalué que “un défaut d’exigences qui reste non détecté jusqu’à la construction ou la maintenance coûte 50 à 200 fois autant pour le fixer qu’il n’aurait coûté au moment de la définition des exigences.” En conséquence, achever chaque cycle avant de passer au suivant garantie le succès au final.

Les travailleurs peuvent facilement déterminer combien de progrès ils font, car les attentes sont clairement définies avant que le projet ne commence.

Parce que le projet est clairement planifié du début à sa fin, les travailleurs peuvent rapidement mesurer leurs accomplissements et livrables. La méthode en cascade est idéale pour les équipes qui travaillent étroitement ensemble, puisqu’elle offre des tâches et des objectifs précis. Elle permet aussi aux développeurs de continuer à travailler sur le projet sans avoir besoin de la surveillance constante d’un manager.

Le logiciel peut être conçu en se basant sur une compréhension minutieuse des éléments à fournir.

Parce que la méthode traditionnelle entraîne une documentation minutieuse, les programmeurs peuvent garantir qu’ils répondent aux attentes des client avant que le projet ne soit achevé.

Enfin, les programmeurs peuvent facilement évaluer les résultats en fonction du résultat attendu.

Dans la phase de maintenance, les programmeurs et clients peuvent observer la solution pour déterminer si elle fonctionne correctement. S’il y a des problèmes, les programmeurs peuvent corriger les erreurs avant la remise du produit fini aux clients.

Microsoft est partenaire de DantotsuPM

Bien que moins flexible que la gestion Agile, la méthode en cascade fournit un plan clair de résultats attendus tant pour les programmeurs que pour les clients. Elle peut faire gagner du temps et de l’argent en offrant une stratégie bien définie. Ce n’est pas la méthode la plus populaire actuellement, mais c’est un système valable et qui peut être mis en œuvre avec presque n’importe quel logiciel de management de projet. Les sociétés et leurs clients devraient considérer les bénéfices de la méthode de management de projet en cascade traditionnelle.

Méta Projets Management est partenaire de DantotsuPM

Qu’en pensez-vous? Quelles sont vos expériences en la matière? Commentez ce billet.

Enregistrer

Enregistrer

24 Octobre – Bordeaux #PMI® – DevOps : l’art de maîtriser la vie de vos SI

DevOps : développeurs et opérationnels main dans la main pour produire de la valeur dans un environnement optimisé

Une rencontre PMI France Branche Aquitaine

DevOps est la concaténation des trois premières lettres du mot anglais Development (développement) et de l’abréviation usuelle Ops du mot anglais Operations (exploitation), deux fonctions de la gestion des systèmes informatiques qui ont souvent des objectifs différents.

Les entreprises vont de plus en plus loin dans la transformation numérique. La distinction entre l’équipe qui développe dite « Build » et celle qui exploite les systèmes informatiques dite « Run » créent des difficultés. L’objectif pour la première étant de développer au moindre coût les changements le plus vite possible. Quant à la seconde, elle s’attache à garantir la stabilité du système qu’elle exploite.

Afin de réconcilier ces deux sœurs, il est recommandé, entre autres, de faire des déploiements réguliers, effectuer des tests au plus tôt dans un environnement d’intégration continue – le tout dans un écosystème Agile.

Benoit Defrance qui est Practice Leader Agile & Devops chez SQLI, entreprise de services du numérique Spécialiste de la transformation digitale des entreprises, partagera avec vous son expérience sur l’agilité-DevOps et Continuous Delivery de valeur.

Inscriptions

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

Microsoft est partenaire de DantotsuPM