Tag Archives: waterfall

Que signifie vraiment ‘en cascade’ (Waterfall) dans le management de projet ? Comment les gens utilisent-ils cette expression ?

28 Mai

Curieusement, l’auteur reste très dichotomique et ne considère pas dans ce billet une approche hybride entre les deux mondes adaptatif et prédictif mais son retour sur la genèse de la méthode Waterfall me parait intéressant à partager avec vous.

What Does ‘Waterfall’ Really Mean? How Do People Use That Word?

http://managedagile.com/waterfall-really-mean/ by Chuck Cobb

Y avez-vous jamais réfléchi ? Cette expression est souvent utilisée en comparaison de ‘Agile’ mais les gens savent-ils ce qu’ils font quand ils comparent ‘Agile’ à ‘en cascade’ ? Je pense que le mot ‘Waterfall’ est un des mots les plus abusés dans la langue anglaise (et le mot ‘Agile’ n’arrive pas loin derrière).

Quand les gens parlent de ‘Agile’ et ‘en cascade’, il semble qu’ils comparent deux méthodologies très spécifiques et bien définies qui sont les opposés binaires et mutuellement exclusifs l’un de l’autre. Cependant, quand vous fouillez dans ce que signifient vraiment les mots ‘Waterfall’ et ’Agile’, vous découvrez vite que c’est une comparaison très imprécise et prône à erreurs.

Que signifie vraiment ‘en cascade’ dans le management de projet ?

À proprement parler, le mot ‘ Waterfall ‘ a été à l’origine défini en 1970 par docteur Winston Royce dans son papier très célèbre :

Dr. Winston Royce’s 1970 Waterfall Paper

Il a décrit un modèle qui consiste en ordonnancer un projet en phases où les livrables d’une phase coulent dans la phase suivante et qui donne quelque chose comme ceci :

Il l’a appelé ‘en cascade’ parce que les résultats d’une phase s’écoulent naturellement dans la phase suivante comme l’eau dans une  ‘cascade’.

A quoi ressemblait la Vie avant ‘en cascade’ ?

Pour mieux comprendre, il est utile de voir à quoi ressemblait la vie avant ‘en cascade’ et quels problèmes cette méthode essayait de résoudre. Ce qui a précédé ‘en cascade’ était beaucoup d’efforts de développement mal organisés avec peu ou pas de structure, discipline et planification. Certains des problèmes principaux avec ces approches étaient :

  • Comme les projets grossissaient en termes de portée et de complexité avec de plus grands nombres de développeurs, il est vite devenu apparent qu’une approche plus planifiée et structurée était essentielle pour coordonner le travail de grosses équipes de développement
  • L’autre problème principal était une prévisibilité très limitée tant sur les dépenses que les délais des projets de développement informatique. Il y avait de fréquents en très importants dépassements de coûts et de délais et les commanditaires ont exigé un certain niveau de prévisibilité.

Pour ces raisons, quand l’approche ‘en cascade’ a été définie à l’origine, c’était une grande amélioration que de passer de pratiquement aucune méthodologie du tout à un processus très bien défini :

  • Un plan d’ensemble” pour coordonner le travail de multiples développeurs ainsi que l’intégration de leur travail avec d’autres ressources essentielles en dehors des immédiates équipes de développement
  • Un mécanisme pour gagner un certain niveau de contrôle de la portée du logiciel (de son contenu ou périmètre) pour obtenir plus de prévisibilité des dépenses et des délais.

Beaucoup de personnes plus jeunes n’apprécient pas aujourd’hui cette historique et critiquent juste la méthode ‘en cascade’ comme étant mauvaise sans comprendre les problèmes qu’elle a été créée pour adresser.

relisez ce billet sur les bénéfices de ‘en cascade’

Quels étaient certains des problèmes avec l’approche de originale ‘en cascade’ ?

Comme dans beaucoup de choses, il y a un effet de « balancier » et, quand l’approche a été initialement mise en œuvre, il y avait le sorte d’une sur-correction dans de nombreux cas. Le balancier est passé dans beaucoup de projets de presque aucun contrôle ni discipline à un contrôle très rigide et très rigoureux. La pratique commune quand le processus ‘en cascade’ a été défini à l’origine en 1970 était un processus de documentation très intensif et un sur-contrôle où vous ne pouviez pas quitter une phase tant que toute la documentation exigée pour prouver que tout le travail demandé pour cette phase avait été achevé, passé en revue et approuvé.

C’était un processus très pénible et qui avait un certain nombre de problèmes que même le Dr. Royce a reconnus en 1970 quand il a défini le processus. Certains des problèmes les plus sérieux étaient :

  • L’utilisateur final du logiciel ne voyait pas normalement aucun logiciel avant que tout le développement et les tests ne soient complets et à ce moment-là, il était très difficile, sinon impossible, d’apporter quelques changements significatifs.
  • L’accent sur le contrôle du contenu rendait le processus très inflexible et résistant aux changements qui pourraient être nécessaires pour répondre aux besoins des utilisateurs et des objectifs business dans un environnement incertain.

En conséquence, il y a eu beaucoup de situations où le projet peut avoir respecté le coût et les délais, mais échoué à fournir un niveau suffisant de valeur business.

Un autre problème principal était que le lourd accent sur la documentation exigée pour les revues et les approbations rendait le processus tout entier bureaucratique et pas très efficace côté coûts.

Comment ‘en cascade’ s’est-elle développée pour Résoudre Ces Problèmes ?

Avant que Agile ne se répande, beaucoup de variations sur le modèle original ‘en cascade’ et d’autres modèles plus itératifs ont été développées et utilisées pour créer une approche plus adaptative et résoudre certains de ces problèmes. Un exemple était le Processus Unifié Rationnel (Rational Unified Process RUP) dont les origines peuvent être retracées jusqu’en 1996 et 1997. RUP a proposé une approche de développement itérative pour résoudre certains des problèmes de l’approche ‘en cascade’. RUP et les variations de RUP comme Enterprise Unified Process (EUP) sont devenus très populaires à la fin des années 1990 et au début d’années 2000.

En conséquence, si vous regardez ce que les gens ont fait en pratique pendant les 15 à 20 dernières années, il y a eu prolifération d’une large gamme de beaucoup de modèles différents (dont certains ont une ressemblance très limitée au modèle original ‘ Waterfall ‘ défini en 1970). Les gens les caractérisent toujours tous de ‘en cascade’ comme si c’était une méthodologie spécifique, unique et bien définie appelée ‘en cascade’ et ce n’est pas vraiment le cas. De la façon dont le mot ‘Waterfall’ est utilisé en pratique, il se réfère en réalité à une large gamme de méthodologies différentes.

Quelle est une façon plus précise de décrire ‘Agile’ versus ‘En cascade’ ?

Le dénominateur commun de toutes les méthodologies que les gens appellent ‘en cascade’ est qu’ils soulignent un certain niveau de planification en amont et de contrôle pour essayer de réaliser la prévisibilité sur le contenu du projet, des dépenses et des échéances. C’est pourquoi, je pense que « dirigé par un plan » est une description plus précise et objective de ce que les gens veulent vraiment dire quand ils disent ‘en cascade’.

Le mot ‘Agile’ est aussi utilisé de manière floue. Nous savons tous que ‘Agile’ n’est pas une méthodologie spécifique bien que beaucoup de personnes assimilent ‘Agile’ avec Scrum :

  • Scrum n’est pas vraiment une méthodologie spécifique, c’est vraiment une structure destinée à être adaptable à une large gamme de situations
  • Agile n’est pas vraiment l’équivalent de Scrum. Il y a d’autres méthodologies Agile comme Kanban

Il est assez facile de voir que le mot ‘Agile’ est aussi utilisé très largement pour qualifier une méthodologie spécifique et bien définie quand ce n’est pas le cas. Le dénominateur commun des méthodologies que les gens appellent ‘Agile’ consiste en ce qu’elles sont flexibles et adaptatives et soulignent la créativité et l’innovation dans un environnement incertain plutôt que la planification et le contrôle pour une prévisibilité avec des niveaux moindres de certitude. C’est pourquoi, je préfère utiliser le mot « adaptatif » au lieu du mot ‘Agile’ lors de la comparaison avec ‘en cascade’ (dirigé par un plan).

Pourquoi comparer « Dirigé par un plan » et « Adaptatif » est-il plus précis et objectif ?

Voici pourquoi je préfère utiliser une comparaison entre « Adaptatif » et « Dirigé par un plan » plutôt que ‘Agile’ versus ‘en cascade’ :

C’est plus précis

« Dirigé par un plan » n’implique pas de méthodologie spécifique. C’est une caractéristique d’une large gamme de méthodologies ce qui je pense décrit plus exactement ce dont parlent les gens.

C’est plus objectif

Le mot ‘Waterfall’ associe des tas de connotations très négatives car il ramène au modèle original ‘Waterfall’ défini en 1970 et ce que les gens appellent ‘en cascade’ peut aujourd’hui avoir peu de ressemblance avec l’original de 1970. L’expression « Dirigé par un plan » ne traine aucun de ces bagages négatifs.

Quand les gens dans la communauté Agile comparent ‘Agile’ et ‘en cascade’, c’est d’habitude dans le contexte Agile est bon et ‘en cascade’ mauvais et ce n’est ni vraiment précis ni objectif. Dire « ‘Agile’ est meilleure que ‘en cascade’ » s’apparente à dire “une voiture est meilleure qu’un bateau”.

Les deux ont des avantages et des inconvénients selon l’environnement dans lequel vous évoluez:
  • Une approche ‘dirigée par un plan‘ donne à son meilleur dans les projets qui ont un faible niveau d’incertitude et exigent un fort niveau de prévisibilité
  • Une approche adaptative marche mieux dans les projets qui ont un niveau élevé d’incertitude et exigent un focus sur la créativité et l’innovation pour trouver une solution optimum plutôt qu’une orientation sur la planification et le contrôle pour atteindre la prévisibilité

En bref

livre sur Amazon

Je ne pense pas avoir la moindre chance de faire en sorte que les gens cessent d’utiliser la comparaison ‘Agile’ versus ‘en cascade’ qui est trop largement utilisée. Je l’utilise même moi-même parfois parce que c’est une façon commode et simple de décrire quelque chose qui est en réalité beaucoup plus complexe. J’espère juste que les gens comprennent combien c’est une simplification excessive et à quel point ce peut être imprécis et trompeur.

L’auteur de ce billet, Chuck Cobb est l’auteur du livre « The Project Manager’s Guide to Mastering Agile » et il  a développé un cours appelé “Learn the Truth About Agile Versus Waterfall” qui fournit plus de détail pour aider les gens à voir ces approches depuis une nouvelle perspective comme complémentaires l’une à l’autre plutôt que en compétition : Free Agile versus Waterfall course

N’hésitez pas à poster vos commentaires sur ce livre, ce cours et/ou ce billet…

Rencontres sur le management de projets – 11 au 17 Juin

21 Mai

Quelles rencontres sur le management de projet puis-je vous recommander en cette troisième semaine du mois de juin ?

Le forum national PMI des régions continue sont tour de France avec Marseille et Lille cette semaine !

Lyon nous propose aussi une session sur la bienveillance au travail et Paris-Saclay sur l’hybridation des méthodes Agile et prédictive.

N’oublions pas non plus que cette semaine est celle du wébinaire PMI sur les Talents en Management de projet, celle où Microsoft nous propose un webinaire sur l’intégration ERP/MS Project et de plus Scrum.org met le focus sur l’intégration de Scrum avec les ressources Humaines pour réellement ancrer les valeurs de l’agilité dans les organisations.

Lundi 11

La transformation des organisations est le partenaire du business de demain. 3 interventions: Pyramide DevOps & Équipe intégrée; Transformation Agile et Organisation en produits; Les limites du Time-to-market.

Chaque année, le réseau Anact-Aract organise une Semaine nationale dédiée à la Qualité de Vie au Travail. Pour ouvrir la semaine, nous aurons le privilège de recevoir Christine TAPERO, conférencière et coach, auteur du blog Educationpositive.com et dirigeante de Challenge Carrière & Famille. Elle abordera la conciliation vie professionnelle/ personnelle et nous transmettra les astuces pour un équilibre de vie plus harmonieux.

Mardi 12

La Neuroscience et l’Intelligence Artificielle au service des Projets. Un événement qui s’annonce PASSIONNANT ! le 12 juin 2018 à la Coque. La participation à cet événement vous permettra de collecter 7 PDUs.

  • Quelle place dans le management de projet pour IA & Neuroscience et quelles synergies pour mieux manager au XXIème siècle ?
  • Quelles sont les tendances en IA & Neuroscience qui vont impacter le métier de chef de projets ?
  • Comprendre son cerveau pour mieux gérer les autres 

Méta Projets Management est partenaire de DantotsuPM

Bonheur au travail, Chief Happiness Officer, Bienveillance… On en parle tellement, qu’on en arrive à se demander si ces mots ne sont pas un peu trop jolis pour être honnêtes. Au-delà de l’effet générationnel, l’aspiration au bien-être au travail répond à une réalité économique certaine et mesurable. Véritable changement de culture, elle adresse les questions posées par un environnement professionnel toujours plus exigeant et souvent plus instable.

L’agilité est aujourd’hui présentée comme la clé de voûte pour le succès des projets dans de nombreuses entreprises. On constate néanmoins que la méthode traditionnelle (ou waterfall) persiste et est encore largement utilisée. Cette conférence vise au travers de retours d’expérience et d’illustrations concrètes à présenter une approche « entre deux » ou « hybride » pour bénéficier du meilleur des deux mondes au sein d’un projet. Il sera, entre autres, détaillé au travers d’illustrations et d’exemples les critères d’application de l’une ou de l’autre des méthodes dans un projet.

Les nouveaux projets arrivent n’importe quand… pas seulement lors de la planification annuelle; Nous avons plus de projets potentiels que de moyens; Les priorités sont bouleversées régulièrement; Nos ressources humaines sont sollicitées de multiples parts; Les nouveaux projets sont retardés; Les projets actuels se prolongent… Au secours !

An official premiere of the Spanish version of IPMA ICB4 standard. The presentation “ICB4 and IPMA’s Global Competency standards for Project Management” will be held by Jesús Martínez Almela, President of IPMA.

Mercredi 13

Scrum provides for unmatched collaboration, increasing resiliency to the complexity that often takes HR Initiatives off course and budget, too often unintentionally disengaging employees. This is a major shift for many HR teams – exploring ways that shift how they think about delivering value to their employees, business partners, and organizations. Leading change that truly makes a difference as serving leaders to the organizations they serve is the hallmark of a truly great HR organization.

CertYou est partenaire de DantotsuPM

How may you adapt your career to anticipate and stay viable in an environment of rapid technological change ?

Details on line

The PMI Talent & Technology Symposium 2018 is the fusion of two prior events, the Internet Systems & Technologies Symposium, and the Talent Management Conference. The new event will focus on the impact of rapidly changing technologies on the project management discipline and careers. Participants will better understand how emerging technologies affect their career and skills progression, as well as the evolving needs of hiring managers as they seek out top project management talent.

The PMO Conference is curated and designed for you, the PMO practitioner. Focused on portfolio, programme and project offices, this one day conference is all about learning more about your chosen profession. From a full programme of PMO expert speakers, a dedicated PMO exhibition full of PMO products and services and time to network with new PMO contacts or reconnect with friends and ex-colleagues, the day is 100% PMO focused.

SMPP est Partenaire de DantotsuPM

Jeudi 14

Le programme MIKADO lancé en 2011 par Société Générale Global Banking and Investor Solution est une initiative innovante dans le monde des banques d’investissement : c’était la toute première fois en Europe qu’une activité stratégique d’une banque d’investissement était outsourcé à une utility. Ce fut une initiative de grade ampleur impliquant le transfert de plusieurs centaines de salarié dans le monde et le déploiement d’un nouveau système informatique. Accenture, qui a créé la utility pour cette occasion, a depuis intégré 2 autres banques d’investissement sur la plateforme.

 

Vendredi 15

Hybridation, Agilité, Bienveillance, Intelligence artificielle & Neurosciences. Quelles sont les tendances et perspectives en intelligence artificielle ? De la gestion du portefeuille jusqu’à l’exécution et la gestion du projet, quelle serait la meilleure  approche (agile, prédictif ou une combinaison des deux) ? C’est ce que nous verrons avec les intervenants, à travers leurs travaux et leurs retours d’expérience. La participation à cet événement vous permettra de collecter 7 PDUs.

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

Rencontres sur le management de projets – 19 au 25 Mars

26 Fév

De très prometteurs rendez-vous sur le management de projets et le leadership à Paris, Grenoble, Zürich et sur le web depuis votre bureau ou maison ! Projets eLearning, approches hybrides et priorisation MoSCoW , PMOs, neurosciences: Il y en aura pour tous les centres d’intérêts.

Lundi 19

De Valenciennes à Pau en passant par Lyon: ça bouge ! Retour sur trois expériences d’innovation managériale en cours dans la fonction publique: Le niveau de service d’une grande ville à la campagne; Des systèmes d’information et d’innovation agiles et plus coopératifs; Organisation en holacratie, une forme de management non hiérarchique mais très structurée qui se développe actuellement

Mardi 20

La transformation digitale (réalité virtuelle, réalité augmentée, les chatbots…) et l’Intelligence Artificielle sont au cœur de la stratégie de toute la communauté RH. Les solutions Cloud, la dématérialisation, le Big Data, les Objets Connectés et la gestion des compétences sont omniprésents. Le elearning, les Moocs, les serious games font l’objet de nombreux débats avec le développement de nouveaux outils digitaux pour une pédagogue innovante… ces technologies sont à prendre en considération dans tous vos projets.

CSP est partenaire de DantotsuPM

 

Gantt Charts are a fine mechanism for planning projects that have well bounded activities with a clean start and end point, and with understood dependencies and sequences. But in the non-linear, sometimes chaotic world of Product Development, Gantt Charts can be inadequate, cumbersome, or even misleadingly inaccurate. In the session, we will explore an alternative using mechanism of Agile product development – a Backlog of value to deliver with estimations of size (effort) and a reality-based Burndown that shows a plan with visible assumptions. Together these mechanism provide an effective way to plan, track, and replan a complex Product Development effort.

Avec sa maison solaire NeighborHub – que l’on peut traduire par cœur du voisinage – l’équipe suisse a fait le pari audacieux de proposer un concept différent, avec une maison au service de son quartier, plutôt qu’un pavillon conçu pour une famille. Un pari risqué mais gagné qui montre la capacité de la Suisse à maîtriser les questions liées aux modes de vie durables.

En quoi l’approche et les outils proposés par la PNL peuvent-ils être utiles dans le cadre des politiques de prévention des risques psycho-sociaux et d’amélioration de la qualité de vie au travail ? Quand et comment les utiliser ?

Is jouw organisatie op zoek naar meer agility (flexibiliteit/wendbaarheid)? Is de keuze voor een methode binnen de organisatie lastig? Wil je graag meer Agile werken binnen de organisatie, maar kom je op het gebied van methodieken niet verder dan het alom bekende Scrum? Of denk je wellicht dat Agile een hype is?

CertYou est partenaire de DantotsuPM

Mercredi 21

Cette demi-journée sera composée de conférences, ateliers et moments de convivialité où l’on pourra débattre et partager autour de sujets tels que les neurosciences et le management, le deep learning et d’autres encore…

An overview of the ‘Project in a Box Community Edition’ and how this supports documentation and processes of the Praxis Framework – the free framework for the management of projects, programmes and portfolios. You’ll also find out how the Project in a Box Planner tool provides planning, risk and issue management capability.

APMG International France

APMG International est partenaire de DantotsuPM

Jeudi 22

Details and registration on line

Keynote Presentation—The Simpsons: There’s No « I » in « Innovation » (oh wait, there’s actually two of them)…Lessons in Innovation from the Most Successful Show in TV History

    • Imagining the Future of PMOs by Mark Mullaly
    • Creative Thinking: Engaging Your Stakeholders, Improving Your Requirements by Teresa Lawrence
    • Hacking Agile for Digital Agencies by Dave Prior
    • The Conundrum: Your Project Ends, But Its Outcome Lives On by Rich Maltzman
    • PMI’s Pulse of the Profession 2018 by Melissa Buchanan and Tricia Cabrey

 

  • Zürich – PMI® Switzerland – MoSCoW Prioritisation

Andrew Craddock

MoSCoW Prioritisation is a practice that has been part of DSDM since its creation in 1994. It is now regularly used within Agile projects and has spread far beyond DSDM. As it has spread, however, the detail of how it should be used – the ‘rules’ around its use – have become diluted and twisted. With his talk on MoSCoW prioritisation Andrew Craddock, Innovation Director from the Agile Business Consortium, will take us back to basics explaining the rules, the real power of the technique and, through that, the ‘easy sell’ to business and project participants alike.

 

With hybrid project management approach… L’agilité est aujourd’hui présentée comme la clé de voûte du succès des projets dans de nombreuses entreprises. On constate néanmoins que la méthode traditionnelle (ou waterfall) persiste et reste encore largement utilisée. Voyons à travers des retours d’expérience et des illustrations concrètes une approche « entre deux » ou « hybride » pour bénéficier du meilleur des deux mondes au sein d’un projet. Quels pourraient être les critères d’application de l’une ou de l’autre des méthodes et techniques dans un projet ?

Méta Projets Management est partenaire de DantotsuPM

 

“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.

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

4 Jan

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 !

quels furent les billets DantotsuPM les plus lus en Juin 2017 ?

8 Août

les articles les plus lus sur DantotsuPM de Juin 2017

Ce mois-ci les billets appréciés des suiveurs du blog et autres visiteurs furent ceux liés à l’agilité, aux soft skills et à la qualité. Bonne relecture ou découverte !

15 vérités pas si évidentes sur les compétences relationnelles: les connaissez-vous? qu’ajouteriez-vous?

Les personnes non intuitives et de nombreux professionnels techniques disent que maitriser les aspects pas si évidents des interactions avec les personnes (« soft skills » ou compétences relationnelles) est un grand défi et souvent prise de tête.

certaines relations peuvent être particulièrement frustrantes !

Quelles vérités sur les compétences ces personnes doivent-elles apprendre et utiliser ?

« Peut-on se libérer de sa culture ? » (de waterfall vers l’agilité)

L’un des 2 sujets 2017 du bac S en philosophie: « Peut-on se libérer de sa culture ? » m’a immédiatement rappelé des discussions avec Claude Emond sur la culture Agile et plusieurs billets que nous avons ensemble publiés sur ce blog.

L’Aïkido Verbal est un moyen pacifique de gérer les attaques verbales, basé sur la philosophie de l’aïkido martial.

Pour aller plus loin, le livre sur Amazon

Cet art s’est inspiré de la pratique et de la philosophie de l’aïkido martial, et permet de diriger une agression verbale vers un résultat positif et équilibré. Comme dans l’art martial, l’assaillant et le défenseur sont dits « partenaires » et non « adversaires ». Il n’y a donc pas à proprement parler d’affrontement, ni vainqueur ni vaincu.

Connaissez-vous le nouveau Agile Practice Guide (en anglais) ?

PMI et Agile Alliance se sont mis au travail ensemble pour produire le Agile Practice Guide dans l’intention de forger une meilleure compréhension des pratiques agiles pour les chefs de projet.

la qualité est trop souvent considérée seulement à la fin des projets: les 14 points de Deming sont un guide pour l’obtenir systématiquement

Le livre sur Amazon

La qualité est mal comprise par trop de personnes qui n’y pensent que quand ils touchent au produit final. En réalité, c’est seulement au travers de processus de qualité centrés sur l’efficacité, l’innovation et l’amélioration continue qu’un produit de qualité est réalisé, et ces processus exigent une culture de management de qualité non seulement dans nos projets, mais aussi dans nos organisations.

Dans le chapitre 2 de son livre de 1986, « Out of the Crisis« , Edward Deming a présenté 14 prinipes dont il pense qu’ils peuvent rendre l’industrie plus compétitive grâce à un accroissement de la qualité.

Comment crever le double plafond de l’Agilité ?

Marc-Noël Fauvel

Billet original sur LinkedIn (republié avec l’autorisation de Marc-Noël Fauvel que je remercie)

L’agilité au niveau des équipes de développement a fait ses preuves depuis des années maintenant principalement grâce à SCRUM et XP.

Enregistrer

« Peut-on se libérer de sa culture ? » (de waterfall vers l’agilité)

16 Juin

L’un des 2 sujets 2017 du bac S en philosophie: « Peut-on se libérer de sa culture ? » m’a immédiatement rappelé des discussions avec Claude Emond sur la culture Agile et plusieurs billets que nous avons ensemble publiés sur ce blog.

Je vous invite donc aujourd’hui à les relire:

Enregistrer

Enregistrer

Enregistrer

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

21 Nov

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

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

6 Nov

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

Scrum… Vraiment

13 Avr

agile-on-the-beachScrum… Really

http://www.scrumexpert.com/videos/scrum-really par Amy Thompson à Agile on the Beach 2015

Scrum est depuis longtemps la plus populaire des approches Agile pour développement logiciel.

Amy Thompson

Amy Thompson

Mais de quoi s’agit-il vraiment ? À quoi ressemble une grande équipe Scrum? Scrum est-elle réellement la collection d’approches flexible, libre d’esprit et que l’on pense pouvoir adapter pour convenir à tout ce qui marche pour nos efforts ? Dans nos tentatives d’être ‘Agile’, avons-nous oublié les avantages de la structure et de la discipline ? Adaptons-nous Scrum un peu trop pour nous convenir et quel en est l’impact ?

J’ai travaillé avec beaucoup d’équipes Scrum et Kanban, y compris celles qui utilisent de plus lourdes méthodologies Agile comme SAFe et RUP et celles qui fonctionnent indépendamment au sein d’une organisation en cascade (Waterfall). Cependant, chaque fois que je travaille dans un nouvel endroit, je vois les mêmes problèmes encore et encore qui empêchent les équipes d’atteindre leur potentiel à être extrêmement performantes. Idem quand je participe à des réunions et conférences Agiles et parle aux gens de comment ils ont essayé de ‘devenir Agile’, mais que cela ne semble pas fonctionner pour eux.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Récemment, j’ai vu une tendance croissante des professionnels Agile à en arriver à la conclusion qu’une approche plus évangéliste parviendra plus probablement à amener le succès aux Business et équipes.

L’adhésion du management est essentielle, cependant que je voudrais concentrer ma discussion (vidéo en anglais ci-dessous) sur pourquoi je crois que la discipline, la routine, la structure et une compréhension minutieuse du processus Scrum sont clés à une grande équipe Scrum. Et aussi, expliquer que ceci ne signifie pas que l’équipe est étranglée dans sa créativité, ni contrôlées par leurs environnements, c’est en réalité tout le contraire … (voici le pointeur vers la présentation en pdf)

Be WAGILE (Waterfall + AGILE) : « an Iron Fist in a Velvet Glove » by Marc Burlereaux, Christine Rieu and Sylvain Gautier

30 Sep

A French version of this post can be found here: soyons WAGILE (W-aterfall + AGILE) : « une main de fer dans un gant de velours »

Marc Burlereaux has presented an article written by Christine Rieu, Sylvain Gautier and himself about the pitfalls when introducing Agility at the Project Zone Congress 18,19 March 2013 in Frankfurt.

The Agile approach used for projects, or new product development, ensures a greater flexibility with iterative design, lighter documentation and formalization, more interactivity and efficiency in the conduct of meetings, and especially more customer involvement throughout the project (Pichler, 2010). By coupling a Lean approach to these Agile methods; we remove all unnecessary and ‘non-value added’ steps to minimize waste and to maximize the expected value of the product (Larman & Vodde, 2010). This seems to be the panacea!

But it is not straightforward to implement this type of approach and the Project Manager may be asked many questions:

questiono How will  these approaches be integrated successfully in mature Project Management organizations that are more familiar with traditional software V-Model (software development) or Waterfall Model?

o How will the Release Manager be in a position to facilitate the delivery of products developed with Agile and Lean approaches?  This is particularly relevant given his/her role is to keep adherence to rigid processes for minimizing the risks associated with change, which is often seen by the Agile Project Manager as an awful slowdown in the delivery process.

o How will these deliveries fit in the whole Release Management process, including testing procedures (unit, integration and acceptance testing of applications), the production of operating technical documentation, user guides, and the creation of installation and deployment procedures?

o How will you  avoid Agile being used as an excuse for lax and ineffective behaviours, such as removing documentation?

The success of such projects imposes a balance between a comprehensive Agile approach and a discipline warranty by the Release Management process. Hence the title of our paper, « An Iron Fist in a Velvet Glove. »

product backlogThis presentation is based on lessons learned gathered during project experiences combining Agility and Lean Management in various fields of industry and banking organizations. We explain our vision of the prerequisites for a project to be eligible for Agile methods. The thread of the presentation is to then illustrate our experiences with emphasis on Agile best practices that we have identified as key success factors. We have divided these keys points throughout the various phases of project development, with a particular emphasis on the early stages of scoping and preparation, and then the final stages of acceptance (technical and business) and finally the transition to production.

The following anecdote illustrates that sometimes agile’s team are surprisingly facing rigidity:

Geeky Unsure WomanJack Duggal, a seasoned Program Manager with over 30 years of experience in project management, said at a conference organized by PMI (Project Management Institute) in Geneva in 2012: « You can sometimes blame rigidity in the application of agility. In a Scrum meeting, which assumes that you are standing, a person a little tired had expressed the need to sit down: this was refused, as matter of principle!  »

Whatever method is chosen, we should be able to get inspired by other approaches and benefit from best practices:

As an example, PMI, which is the authority in the management of « traditional » projects, has naturally opened the door to the principles of Agility by recently creating a new credential PMI-ACP (Agile Certified Practitioner) and integrating Agile and Lean Management into traditional project management. For example, the PMBOK 5th edition now takes into account Agile « Adaptive Life Cycles » with section 2.4.2.4 covering iterative and incremental methods.  These methods involve short iterations of 2 to 4 weeks with fixed time and resources (i.e. time boxing).An important aspect to add is the risk management: this is an example of good practice derived from traditional methods integrated into agile approaches.

Finally, we conclude by reminding the four principles issued by the Manifesto for Agile software development written by Kent Beck and 16 other signatories (K. Beck et al, 2001) which by the way could be followed regardless of the chosen project management methodology:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  1. Agile ManifestoIndividuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

That is, while there is value in the items on the right, we place more value to the items on the left.

The Agile approach should be considered rather as a philosophy of development

In this presentation, we wanted to give very practical advice to implement a successful agile approach, especially in organizations which will combine it with more traditional models. It is inspired by our experiences in various project contexts and emphasizes the importance of deeply understanding the benefits and implementation impacts of this new way (i.e.  not just use it as a « tool box with an integrated checklist »). The Agile approach should be considered rather as a philosophy of development, which focuses on employee involvement and commitment. One has to take in each method that is « good for business », knowing that every business is unique and has its own specific operational characteristics. Opposed to traditional methods, Agile methods are a revolution, but they can also bring their share of the burden and stress, depending on the implementation and the use.

human factorThe Agility is good but to control it is even better …

The Scrum approach is not a panacea, especially if it is not understood and supported by the Management and Business Analyst (MOA)

The Lean Approach coming from the industry may not be implemented in all contexts

The AGILE mindset is primarily the key success factor that will ensure a smooth Agile implementation

We must select the right AGILE tools best suited to the company

A pragmatic coaching is a key success factor

– The dogmatism must be forgotten

– And we must contextualize the process that could not be standard for all areas (from the space industry to Google, through aerospace, automotive, banking …).

Last but not least, misunderstood and badly launched / implemented Agility may cause more damage than traditional methods.

Let’s Be WAGILE! Contraction of WATERFALL (traditional methods of development) and AGILE … hence Agility: An Iron Fist in a Velvet Glove!

Christine RieuChristine RIEU, works as an Associate Professor in the Listic laboratory and has carried out research on Knowledge Management for the past 15 years.  Christine teaches Project Management at the IUT of Annecy where she also holds the position of Head of International Relationships.  .  Christine is also a founding member of “PMI Pôle des Pays de Savoie”, France Chapter.

Marc BurlereauxMarc BURLEREAUX, has more than 27 years of expertise in Project, Program and Portfolio Management with a proven track record in the field of Swiss Private Banking.  Marc is a Senior Volunteer at PMI, Director of “Pôle des Pays de Savoie” (part of the France Chapter) and also a member of the PgMP® & PMI-RMP® Credentials PRC (Panel Review Committee). Marc has been applying agile technics for the past 10 years, and more recently has spent two years as Head of European Release Management in a Swiss Private Bank.

Sylvain GautierSylvain GAUTIER, has more than 27 years of expertise in IT and started his career working as a consultant, and then as an architect, within the Software Industry (Computer Associates, Sybase).  Sylvain focused mainly on data design, DBA, and project management methodologies for major European projects before becoming Head of IT Operations for an important private bank in Geneva.  Sylvain is now a freelance consultant applying Agile, ITIL, Archimate and Service Design best practice to companies within the Banking and Insurance sector.

Bonus video : « Agile: An Introduction »

%d blogueurs aiment cette page :