Qu’est-ce que Agile Hybride en réalité ?

“Nous ne sommes pas encore Agile, mais nous utilisons une approche hybride” ???

What is Hybrid Agile, Anyway?

https://www.agilealliance.org/what-is-hybrid-agile-anyway/ par Becky Hartman, Mike Griffiths, Johanna Rothman, Jesse Fewell, Betsy Kauffman, Stéphane Matola et Horia Slusanschi

Maintenant que le mouvement Agile s’est étendu à de plus grandes organisations dans davantage d’industries, nous voyons énormément de variation. Accordé, nous utilisons une grande variété de structures, techniques et méthodes utilisées, de XP à Scrum à Kanban à la Livraison Continue. Cependant, récemment nous entendons de plus en plus parler d’approches « Hybrides ».

Peut-être avez-vous entendu un dirigeant dire : “Nous ne sommes pas encore Agile, mais nous utilisons une approche hybride”.

Ou peut-être vous avez entendu un consultant déclarer fièrement “À moins que vous ne fassiez beaucoup de prototypage, vous êtes seulement Agile Hybride”. Et ensuite, lors d’une rencontre vous entendez une autre personne dire, “Oh, nous ne sommes pas hybrides, nous utilisons une approche mélangée”.

A travers toutes ces discussions, ce que les gens veulent dire en réalité peut devenir assez confus. Ceux parmi nous qui travaillent sur le prochain Guide de Pratique Agile ont aussi entendu ces points de vue et nous ajoutons qu’une section au guide concentrée sur ce sujet. Voici certains des modèles initiaux que nous voyons…

« Itératif » par rapport à « Incrémental » par rapport à « Agile »

Les cycles de vie des projets suivent un continuum, de prévisionnel (« plan driven ») à  Agile. Pour nous aider à comprendre ce continuum, considérons deux des aspects clés de l’Agilité que sont “Livrer Tôt et Souvent” et “S’adapter au Changement”. Si nous devions les tracer sur un graphique bidimensionnel, nous obtiendrions quelque chose comme cela …

Sur le continuum d’approches, depuis prédictives (en bas à gauche) à Agiles (en haut à droite), il y a différents degrés de livraison (incrémentale) et  degrés de changement (itératif). Les techniques qui réalisent à la fois de forts niveaux de livraison et de hauts degrés d’adaptabilité sont appelées « Agiles ».

« Mélangé » (Blended) versus « Hybride »

Mais c’est juste trop simpliste. Dans le monde réel, nous n’utilisons pas juste une approche. Nous combinons presque toujours plusieurs techniques différentes. Pour nous aider à comprendre les différentes combinaisons, nous avons posé quelques définitions de travail.

Mélangé Agile (« Blended Agile ») est la combinaison de deux ou plus des méthodes établies, techniques, ou structures Agiles.

En ajoutant un peu de Kanban et des limites de travail en cours (« Work In Progress ») à vos Sprints Scrum, vous obtenez une approche « Mélangée ».  Ou peut-être voulez-vous « mélanger » un tableau de visualisation (« Information Radiator ») avec votre approche de livraison en continu. Pour beaucoup de praticiens Agiles, c’est facile à comprendre.

Nous combinons des techniques adaptatives-agressives connues pour être meilleurs dans ce que nous faisons :

Mélangé = Agile + Agile = Meilleur Agile

  • Mais en ce qui concerne le reste d’entre nous simples mortels ?
  • Et si nous ne sommes pas encore capables d’utiliser ces diverses techniques?
  • Et s’il y a contraintes ou demandes qui exigent que quelques éléments non-agiles se produisent ?

Et bien, dans ces cas, vous devriez considérer « l’Hybride »

L’Hybride Agile est la combinaison de méthodes Agiles avec d’autres techniques non-agiles.

Par exemple, un effort important pour détailler les exigences, suivi de sprints de livraison progressive serait une “Approche Hybride”. De même, le prototypage itératif fréquent d’un design, suivi d’une mise en œuvre prédictive avec un  plan simple serait “une Approche Hybride”.

Ici, l’idée est de prendre une approche non-Agile et d’y injecter quelques techniques Agiles pour aborder une question ou une opportunité spécifique:

L’hybride = non-Agile + Agile = quelque chose entre les 2 qui a du sens

Quand devrions-nous utiliser des approches Hybrides ?

Comme toute autre chose dans le monde, il y a une bonne et une mauvaise raison de faire quelque chose. Pour être clair, la mauvaise raison de mélanger des techniques est de vouloir faire comme les autres. “Utiliser des techniques Agiles” n’est pas le but. Le but est de livrer le bon résultat business en utilisant les bonnes techniques.

Voici deux scénarios :

1. Hybride comme Adéquat en fonction du but

Pour les projets qui ont un profil de risque inférieur, utilise des approches prédictives pour minimiser les dépenses. Pour des projets de risque plus élevés, utilisez des techniques Itératives pour répéter des activités jusqu’à ce que les problèmes se révèlent et soient résolus. Pour des projets ayant besoin de livraisons agressives, des techniques Progressives livreront quelque chose plus tôt et assureront l’engagement du client. Finalement, pour naviguer dans des environnements complexes, des techniques Agiles peuvent avoir un fort coût initial aérien, mais pourraient le valoir pour les résultats d’ensemble. Chacune a sa propre force. Le mélange de celles-ci de la bonne façon peut mieux répondre à votre contexte que l’utilisation de seulement une d’entre elles.

2. Hybride comme Transition-vers-Agile

Beaucoup d’équipes ne sont pas capables de basculer vers les façons de travailler en mode Agile d’un jour à l’autre. Plus l’organisation est grande, plus ses composantes sont en mouvement, plus longtemps il faudra pour changer. Si vous avez vécu dans un monde prédictif depuis de nombreuses années, les méthodes Agiles paraitront très différentes. En conséquence, votre incursion initiale dans le monde Agile sera un amalgame peu ordonné des deux. C’est OK. Vous utilisez des techniques spécifiques pour vous déplacer dans la direction vers laquelle vous voulez aller.

Chaque projet a des besoins différents. Pour ceux qui se trouvent dans un environnement surtout prédictif, une approche hybride peut être une transition vers davantage d’adaptabilité et de livraisons. Pour ceux qui ont déjà adopté la livraison et l’adaptation agressives, incorporer quelques nouvelles techniques peut encore hausser votre challenge.

CertYou est partenaire de DantotsuPM

Ne déclarez pas simplement “Nous sommes Agiles”, la réalité est que vous utilisez déjà presque toujours une combinaison de techniques différentes. Au lieu de cela, une meilleure stratégie serait de vous poser et de réfléchir à quelles approches seraient les meilleures pour ce que vous voulez réaliser en fonction de là où vous êtes.

le rapport annuel de Version One sur l’état de Agile est disponible

The state of Agile Survey de Version One.

  1. Pas de surprise côté méthodes, SCRUM reste fortement majoritaire à plus de 50%, même si l’on commence à voir une percée des approches hybrides.
  2. En ce qui concerne l’agilité à l’échelle, rien de très nouveau. SAFe continue de dominer. Même s’il n’est utilisé que dans moins du tiers des cas, SAFe distance cette année plus largement ses compétiteurs comme Scrum of Scrums.
  3. Le point le plus positif selon moi du rapport est que les bénéfices attendus des projets Agiles sont au rendez-vous et dépassent même souvent les attentes des organisations.

Téléchargez gratuitement le rapport annuel de 16 pages

Merci à Florence Duverneuil pour le pointeur
CertYou est partenaire de DantotsuPM

Mai 2018 – articles les plus lus par les lecteurs du blog DantotsuPM

Management de projet hybride, nouveaux guides du PMI, outils Microsoft… mais aussi se comporter en adulte furent les billet qui retinrent votre attention en Mai 2018 et que vous aimerez peut-être relire ou découvrir en cette période estivale plus calme.

« une main de fer dans un gant de velours » avec les approches prédictives et Agile selon Christine Rieu, Sylvain Gautier et Marc Burlereaux

Cet article publié il y a plusieurs années et repris à l’occasion du forum des régions PMI France 2018 a connu un regain de succès. C’est très mérité car les auteurs, Christine Rieu, Sylvain Gautier et Marc Burlereaux, avaient pris le temps de partager avec nous leur expérience de l’agilité et premières idées pour adopter une approche plus hybride.

L’approche Agile dans les projets de développement de nouveaux produits permet d’assurer plus de souplesse dans la conception itérative, plus de légèreté dans la documentation et dans la formalisation, plus d’interactivité  et d’efficacité dans la conduite de réunions, et surtout plus d’implication du client tout au long du projet. En couplant une approche Lean à ces méthodes Agiles, nous supprimons en plus  toutes les étapes inutiles sans valeur ajoutée pour limiter les gaspillages et maximiser ainsi la valeur attendue du produit.

Une liste de 25 principes de comportement adulte par John Perry Barlow

Quand il avait 30 ans, le fondateur de l’Electronic Frontier Foundation (et parfois parolier de Grateful Dead) a rédigé une liste de ce qu’il a appelé « les Principes de Comportement Adulte ». Lesquels 5 ou 6 éliriez-vous dans cette liste pour votre propre éthique ? J’aime beaucoup 2,3,4,5,6,7,8…

…impossible de choisir.

Microsoft Planner ou Microsoft Project: Lequel utiliser pour manager vos projets ?

À ce jour, vous êtes probablement déjà familiers de Microsoft Project. Sorti en 1990, Microsoft Project est devenu l’application par défaut pour les chefs de projets. Microsoft Planner est une solution de gestion de projet plus récente qui a été publiée en 2016 dans le cadre d’Office 365. Les deux applications nous laissent créer des plans, organiser et confier des tâches, partager des dossiers, communiquer avec des collègues et obtenir des mises à jour sur le progrès de notre équipe.
Alors, quelle solution devrions-nous utiliser ?le combiné « Guide PMBOK® + Guide pratique des méthodes Agiles » du Project Management Institute est disponible en français
Afin de soutenir l’éventail de plus en plus large des approches de réalisation de projets, PMI propose un PMBOK® Guide – Sixième édition accompagné du nouveau Guide de pratiques Agiles.

Gratuits pour les membres du PMI

En mode ‘Ciel, mon outil PPM !’, 6 points-clé à ne pas manquer pour réussir le choix de sa solution de pilotage des projets !

Quand le sujet de choisir son outil PPM devient un vrai casse-tête, que vous vous perdez devant la pléthore d’offres et que vous ne savez plus vraiment comment faire le bon choix…

Pas de panique, détendez-vous ! On vous dit tout !

SMPP 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 !

4 Avril – Rennes #PMI® – Hybrider = tirer le meilleur des méthodes de management de projet agiles et traditionnelles sans les opposer

Le Mardi 4 avril 2017 (9h – 17h30) à RENNES, la branche Atlantique du PMI-France vous présente la 3ème édition du Forum PMI-Atlantique, sur le thème :

Hybrider

Comment tirer le meilleur des méthodes de management de projet agiles et traditionnelles, si souvent opposées ?

Inscription

Témoignages, ateliers et échanges autour des meilleures pratiques et retours d’expérience en gestion de projet partagés par des intervenants professionnels et passionnés.

La participation à cet événement vous permettra de collecter 7 PDUs.

4 Conférences en plénière et 2 sessions ateliers

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

Enregistrer

Enregistrer

Enregistrer

Enregistrer

selon le CRASH report: nous sommes sur la bonne voie dans nos projets informatiques et technologiques

Cette  année encore, CAST software a analysé plus de 1850 applications pour mieux comprendre comment les pratiques de développement et de livraison impactent l’IT ainsi que la performance de l’organisation.

En analysant de plus près nos méthodes de développement, maturité des équipes et autres facteurs, le rapport CRASH nous confirme que nous sommes sur la bonne voie même s’il reste encore des choses à améliorer. Nos pratiques de développement et de livraison de nos projets informatiques et technologiques évoluent positivement !

Obtenez votre copie gratuite du rapport (en langue anglaise)

Voici quelques découvertes :

  • Le secteur public est le plus sûr
  • La taille des équipes de développement fait une différence
  • Le type de « sourcing » a peu d’influence sur la santé globale des logiciels
  • Les méthodes de développement hybrides ont de bons résultats

Vous pouvez télécharger le rapport complet ici.

Enregistrer

Enregistrer

Enregistrer

Vers l’hybridation : Waterfall + Agile = ? par Stéphane Derouin

Un monde en disruption… par Stéphane Derouin – Ancien Président et Fondateur du PMI France, Président de Pmgs.

  • Stéphane Derouin
    Stéphane Derouin

    Incertitude, risques et difficulté à gérer la transformation

  • Complexité, (a)synchronie et accélération des temps
  • Primauté de l’innovation
  • Déferlement du Digital qui « rebat les cartes »
  • Nouvelles générations, nouveaux entrants
  • Le Vertical ne répond plus ni aux besoins ni aux attentes : « Servant Leadership »
  • Montée de l’interdépendance, du collaboratif, « monde en réseau »

Waterfall ?

Mode déterministe et planifié – on connaît le périmètre du projet qui est placé sous la responsabilité d’un Project Manager.  Adapté lorsqu’il y un besoin important de contrôle des spécifications et de maîtrise du périmètre du projet

Exemples : projets de pont, d’autoroute, de centrale nucléaire

Partenaire de DantotsuPM
Partenaire de DantotsuPM et le calendrier 2017 est déjà disponible !

Agile ?

Mode incrémental et collaboratif. On ne connaît pas le périmètre du projet et il est animé par un Scrum Master. Innovation, R&D, rupture technologique. Adéquation avec les besoins mouvants du projet ou du client

Exemples : jeux vidéo, réseau social, projets digitaux

Les différences majeures entre Waterfall et Agile :

Waterfall
  • Emphase sur les processus
  • Priorisation fixée dans le plan de projet sur les livrables
  • Équipe projet avec un Project Manager
  • Client en périphérie – effet tunnel
  • Management centralisé
  • Management directif et contrôlant
Agile
  • Emphase sur les individus
  • Priorisation basée sur la « business value » et mise à jour régulièrement
  • Équipe projet restreinte auto-gérée avec un Scrum Master
  • Client au cœur du projet
  • Management décentralisé
  • Mode collaboratif et « Servant Leadership »

… Mais la partition reste encore à composer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

1 Décembre – Lyon ( #PMI ®) – Agile versus Waterfall, vers l’hybridation des méthodes de management de projet

Le PMI France, Pôle Lyonnais vous invite le 1er Décembre à Lyon

On entend beaucoup parler d’agilité qui signerait la fin des méthodes classiques de gestion de projet. Pour autant, bon nombre d’entreprises utilisent encore très largement une approche traditionnelle.

  • Que faut-il faire et quand faut-il le faire ?
  • Faut-il tout miser sur l’agile ou rester sur les méthodes traditionnelles qui ont fait leurs preuves ?
Image courtesy of stockimages at FreeDigitalPhotos.net
Image courtesy of stockimages at FreeDigitalPhotos.net

La solution est peut-être entre les deux : l’hybridation entre gestion de projet traditionnelle et méthodes agiles afin d’utiliser leurs forces respectives et limiter l’impact de leurs faiblesses.

Cette conférence a pour objectif de présenter les grands principes d’une approche hybride :

  • Quelles sont les différences entre gestion agile et traditionnelle ?
  • Pourquoi l’hybridation ?
  • Comment choisir ?
  • Comment la mettre en œuvre ?

Intervention de Stéphane Derouin – Ancien Président et Fondateur du PMI France, Président de PMGS.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Événement ouvert à tous et gratuit pour les membres du PMI et de l’IAE Lyon (€10 pour participer aux frais pour les autres).

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

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

La certification agile version PMI®, PMI-ACP®: Mon retour d’expérience, par Martial Bellec

La certification agile version PMI®,  PMI-ACP®: Mon retour d’expérience, par Martial Bellec PMP, PgMP, PMI-ACP, C2MPC

Martial Bellec
Martial Bellec

Hello,

Le 25 Octobre, j’ai passé avec succès la certification PMI-ACP®, en candidat libre, c’était ma première tentative.

Pourquoi ?

Ce qui m’a motivé au départ, c’est que PMI a opté, non pas pour créer une méthodologie agile de plus, mais pour favoriser l’acquisition d’une bonne connaissance générale des méthodologies et une connaissance approfondie du fameux « mindset agile ».

Pour la préparation, j’ai passé environ 50 heures entre le 19 août et le 25 octobre

Partenaire de DantotsuPM
Partenaire de DantotsuPM
Cours

J’ai suivi un cours Scrum de 3 jours mais je suis resté sur ma faim pour la certification car je connaissais déjà Scrum. Le bon point néanmoins est que cette formation ouvre droit aux 21 heures de formation nécessaires au dossier PMI.

Je n’ai pas suivi de cours de préparation PMI-ACP®, les dates étaient trop tardives par rapport à mon objectif de passer en 2 mois.

Dossier
Le livre sur AmazonConcernant le dossier d’éligibilité, étant déjà PMP®, cela a été facile à remplir en mentionnant mes 3 projets agiles au cours des 2 dernières années.

Comme je dirige un projet agile en même temps, j’étais toujours en interrogation entre la vraie vie et la théorie, c’est très efficace comme toujours !

 

Lectures
Révisions de dernière minute

J’ai passé le dimanche avant l’examen à faire des questions et à butiner toutes ces références qui se contredisent quelques fois…

L’examen

Il est moins important de bachoter que pour le PMP, car:

  • ACPPratiquement aucune question ne porte sur les définitions ou bonnes pratiques (les fameux ITTO « Inputs, Tools, Techniques and Outputs » du PMBOK Guide). Pour l’agile ça aurait pu être par exemple : dans une rétrospective, quel est l’agenda à suivre ? Data gathering, issues identification, prioritization and improvement plan. Mais rien de ça !
  • si vous voulez être testé sur vos connaissances des nombreux outils agiles : comment écrire un bon user story (INVEST), ou bien tenir votre backlog (DEEP), passez votre chemin ! Vous ne serez pas testé là-dessus non plus.

En revanche, pratiquement TOUTES les questions sont des questions situationnelles, ou les rôles sont (très habilement selon moi) intriqués.

Les situations décrivent n’importe qui concerné de près ou de loin par le projet agile
  • Agile 2Agile practitioner
  • Product owner
  • Sponsor
  • Stakeholder
  • Project manager, qui est, selon la question Scrum master ou relais avec les execs

Les « objets » agiles sont toujours les mêmes et assez basiques : product backlog, risk, priority, value, kanban, Ishikawa… attention cependant au risk-adjusted backlog.

Dans une situation particulière, cette personne concernée par le projet Agile doit choisir parmi 4 possibilités ce qui est le mieux à faire immédiatement.

entrepreneur globalComme tout est en anglais, chaque mot compte. Attention il faut avoir un bon niveau d’anglais, même si le vocabulaire est « globbish »… il faut savoir très rapidement en comprendre le sens.

Généralement, il reste 2 réponses entre lesquelles il est difficile de trancher mais en relisant patiemment, la bonne apparaît enfin et semble alors évidente.

J’ai répondu aux 120 questions en 2 heures 6. J’avais environ 30 questions marquées et j’ai pu également repasser en revue les 80 premières d’ici  la fin des 3 heures allouées.

Les facteurs clefs de succès

Selon moi, il faut très bien comprendre le Agile manifesto et l’agile mindset et l’avoir déjà pratiqué sur des projets difficiles est un plus.

Je me suis entraîné à un memory dump de 5 minutes (pour occuper utilement les 15 premières minutes de l’examen qui sont en fait une démonstration de l’interface utilisateur PROMETRIC):

  • writing notes learnmanifesto,
  • xp,
  • Kanban,
  • Scrum,
  • acronymes,
  • evm,
  • Dreyfus,
  • Shu ha ri,
  • lean principles

Mais ça a peu servi pendant l’examen, le seul avantage est que je vais désormais me servir de cette carte au quotidien !

En conclusion

Je recommande cette certification car elle complète très bien le PMP®. Elle est aussi plus exhaustive que la scrum alliance, car PMI a une approche GENERALISTE (très bonne culture agile et des méthodologies).

Je suis enfin intimement convaincu, dans un contexte client, que le chef de projet de demain devra fonctionner indifféremment en waterfall et/ou agile sans les opposer mais plutôt en comprenant finement les avantages et inconvénients des 2 dans la situation réelle.

Cette hybridation des méthodes est un vrai challenge pour notre profession et PMI-ACP® me semble être un incontournable sur cette route.

CertYou est partenaire de DantotsuPM
CertYou est partenaire de DantotsuPM

Note : PMI, PMP et PMI-ACP sont des marques déposées de Project Management Institute, Inc.

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

17 Novembre – Caen ( #PMI ®) – Gestion de projet, entre musique classique et jazz…

Le PMI France, Branche Atlantique vous invite le jeudi 17 novembre 2016 à Caen

classsical-musicOn entend beaucoup parler d’agilité qui signerait la fin des méthodes classiques de gestion de projet. Pour autant, bon nombre d’entreprises utilisent encore très largement une approche traditionnelle.

  • Que faut-il faire et quand faut-il le faire ?
  • Faut-il tout miser sur l’agile ou rester sur les méthodes traditionnelles qui ont fait leurs preuves ?

La solution est peut-être entre les deux : l’hybridation entre gestion de projet traditionnelle et méthodes agiles afin d’utiliser leurs forces respectives et limiter l’impact de leurs faiblesses.

Cette conférence a pour objectif de présenter les grands principes d’une approche hybride :

  • jazzQuelles sont les différences entre gestion agile et traditionnelle ?
  • Pourquoi l’hybridation ?
  • Comment choisir ?
  • Comment la mettre en œuvre ?

Intervention de Stéphane Derouin – Ancien Président et Fondateur du PMI France, Président de PMGS.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Événement ouvert à tous et gratuit.

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

Enregistrer

Enregistrer

Enregistrer

Enregistrer