Archive | agile RSS feed for this section

Différences entre diverses langues dans l’expression d’un principe #Agile par Ian Raja Stokes

18 Juil

Voyons la différence en diverses langues dans l’expression du principe 4 parmi les 12 principes associés au manifeste agile !

« Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet »

Que je traduis en Anglais à titre de comparaison : “Business people and developers must work together daily throughout the project”

  • Français: « users or their representatives and developers »
  • Allemand: « specialists and developers »
  • Italien: « clients and developers »
  • Anglais: « business people and developers »
  • Espagnol: « business managers and developers »
  • Néerlandais: « business people and developers »
  • Suédois: « business people and developers »
  • Finlandais: « business representatives and software developers »
  • Turc: « owners of business processes and software »
  • Croate: “business people and development engineers”
  • Polonais: « business and development teams »
  • Russe: « developers and business »
  • Chinois: « business people and developers »
  • Japonais: « business people and developers »

Selon vous, ces différences sont-elles significatives dans la manière d’aborder l’agilité ?

Par rapport à mon expérience personnelle, je crois que la réponse est « oui ».

Relisez le billet de notre partenaire QRP International

Nous avons ainsi des versions différentes de l’agilité en fonction de la langue utilisée.

Le Manifeste Agile, ses 4 valeurs et 12 principes, par QRP International

12 Juil

Le Manifeste Agile, ses 4 valeurs et 12 principes, sont la conséquence de la frustration des entreprises dans les années 1990 sur le laps de temps entre l’expression des besoins de l’entreprise et la livraison technologique de la solution. Les besoins business et métier évoluent pendant cette période et le produit final ne répond jamais aux besoins du moment qui ont changé.

“Les individus et leurs interactions PLUS que les processus et les outils
Des logiciels opérationnels PLUS qu’une documentation exhaustive
La collaboration avec les clients PLUS que la négociation contractuelle
L’adaptation au changement PLUS que le suivi d’un plan.”

les 12 Principes Agile inclus dans l’Agile Manifesto décrivent une culture dans laquelle le changement est bien accueilli et le client est au centre du projet.

Selon une étude de 2017 réalisée par VersionOne « State of Agile Report », 94% des organisations font de l’agilité.

Mais qu’est réellement Agile et qu’est ce que la méthodologie Agile ?

Le mot “Agile” fait référence à un groupe de différentes méthodologies et de cadres de travail basés sur le développement itératif, la livraison incrémentale, la planification continue, l’apprentissage continu et les équipes pluridisciplinaires auto-organisées.

Ce groupe de méthodologies Agile et de cadres de travail ont en commun les 12 principes Agiles fondamentaux décrits dans le Manifeste Agile. Le principal avantage pour les organisations adoptant une méthodologie Agile est la capacité de « s’adapter au changement », de le valoriser et de l’apprécier à sa juste valeur.

Certaines méthodologies Agile se concentrent clairement sur la livraison et le développement de logiciels, d’autres sont plus axées sur les projets de toutes sortes et peuvent être utilisées comme des méthodes de gestion de projet.

Le webinaire en replay de notre partenaire QRP International

Agile : Signification et Définition

Agile est un « terme générique » pour plusieurs méthodologies de développement (de logiciels) itératives et incrémentales. Ce qui est important dans les méthodologies agiles, c’est qu’elles sont toutes axées sur l’habilitation des personnes à collaborer et à prendre des décisions ensemble. Rapidement et efficacement.

La gestion de projet Agile décrit une approche itérative de la planification et de l’orientation des processus de projet. Cependant, Agile est un état d’esprit. Il n’existe pas une unique approche de gestion de projet Agile qui fonctionne dans toutes les situations; le terme général « Agile » représente plutôt une variété de méthodes et de pratiques qui s’alignent sur les valeurs présentes dans le manifeste Agile. Agile consiste à créer une culture dans laquelle les équipes Agile coopèrent et collaborent pour générer de la valeur.

Comme il n’existe PAS de solution universelle pour adopter ou mettre en œuvre une approche agile, il existe plusieurs types de méthodes Agiles (souvent appelées «cadres» ou « frameworks ») pour répondre aux besoins variés des différentes organisations et équipes.

Découvrez les principales méthodologies Agiles

Foire aux questions sur les Histoires d’Utilisateur (User Stories) #Scrum

4 Juil

Frequently Asked Questions About User Stories

https://www.scrumalliance.org/community/articles/2016/april/frequently-asked-questions-about-user-stories par Sandeep Paudel

Les membres des équipes Scrum, participants aux formations, collègues et parties prenantes diverses impliquées dans des projets de mise en œuvre Agiles/Scrum posent souvent les mêmes questions sur les histoires d’utilisateur (User Stories). Ci-dessous, une liste de questions et réponses que je partage avec vous. J’espère que ces informations seront utiles à quiconque veut en apprendre davantage sur les histoires d’utilisateur.

Q: Que sont les histoires d’utilisateur (User Stories) ?

Une histoire d’utilisateur est une brève description de tout besoin fonctionnel. Elle est écrite d’une perspective utilisateur pendant ou avant la priorisation de l’arriéré de produit (Product Backlog) ou une session de planification de Sprint (Sprint Planning). Une histoire peut inclure, mais n’est pas limitée à, une fonctionnalité avec ses caractéristiques et ses règles de gestion, des demandes d’amélioration, des corrections de bogue, l’installation d’infrastructure, ou une documentation technique. Les histoires d’utilisateur peuvent représenter presque n’importe quelle activité pendant le cycle de vie du développement logiciel.

Q: Comment les histoires d’utilisateur sont-elles apparues ?

Il n’y a aucune date spécifique ou événement rapportés sur l’origine des histoires d’utilisateur. Cependant, la littérature suggère que les histoires d’utilisateur ont évoluées pendant le processus de collecte et de mûrissement des besoins qui ont été à l’origine documentés sous forme de cas d’usage. Des « programmeurs extrêmes » à la fin des années 1990 ont rendu les histoires d’utilisateur populaires dans l’arène du développement logiciel. Des approches Agiles plus récentes, comme Scrum et Kanban, ont aidé à largement promouvoir l’usage massif les histoires d’utilisateur.

Q: Comment dois-je écrire  une histoire d’utilisateur ?

Le format le plus populaire pour écrire des histoires d’utilisateur dans beaucoup d’approches Agiles est comme suit :

En tant qu’utilisateur (du système), je veux faire (action) pour que (les bénéfices à avoir cette fonctionnalité).

Par exemple, « En tant qu’étudiant, je veux voir mes notes pour connaitre ma performance. »

Q: Qui est responsable d’écrire les histoires d’utilisateur ?

Il n’y a aucun rôle spécifique responsable d’écrire une histoire d’utilisateur. Toute personne impliquée dans le processus de développement logiciel, des parties prenantes du métier aux membres de l’équipe Agiles, peut écrire des histoires d’utilisateur. Cependant, beaucoup d’histoires sont écrites pendant la session de revue de l’arriéré de produit par les membres de l’équipe de développement, comme les programmeurs, testeurs et analystes, ainsi que le propriétaire de produit (Product Owner).

Q: Quelles sont les qualités d’une bonne histoire d’utilisateur ?

Une histoire d’utilisateur idéale devrait être courte, simple et sans équivoque. Beaucoup de partisans Agiles considèrent le modèle de Bill Wake INVEST comme une base pour une bonne histoire.

I.N.V.E.S.T. (Relisez le billet sur INVEST)

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

Q: Les histoires d’utilisateur exigent-elles une approbation ?

qui approuve une histoire utilisateur ?

Contrairement aux exigences opérationnelles ou aux documents dans des approches de développement logicielles traditionnelles, aucun processus formel n’existe pour approuver des besoins dans un environnement Agile. Et les histoires d’utilisateur ne sont pas les seules fonctionnalités, donc ce sont les membres de l’équipe Agile qui acceptent les histoires quand la plupart d’entre eux sont confiants sur la capacité à livrer cette histoire en une itération. Tous les doutes sur une histoire d’utilisateur sont clarifiés par le propriétaire de produit dans le cadre de Scrum.

Q: Quels sont trois Cs des histoires d’utilisateur ?

En 2001, Ron Jeffries Proposé le concept de trois Cs : Carte (fiche), Conversation Et Confirmation, pour atteindre le consensus sur une histoire de la part des parties prenantes dans le cadre Agile.

  • La Carte d’histoire est écrite sur une fiche, qui est souvent un Post-it®.
  • La Conversation est une série de discussions entre l’équipe de développement et les parties prenantes internes et externes pour comprendre la complexité et la valeur de l’histoire.
  • La Confirmation doit s’assurer que la conversation tournant autour de l’histoire est parvenue à une conclusion.

Q: Quelles sont les différences entre un cas d’usage (Use Case) et une histoire d’utilisateur ?

Bien le cas d’usage et l’histoire d’utilisateur semblent semblables et que beaucoup de personnes les confondent comme une des façons de décrire des besoins, ils sont différents de bien des façons, comme suit :

Histoires d’utilisateur et tâches :

Les membres de l’équipe exécutent des tâches basées sur l’ensemble d’activités pour construire une fonctionnalité, comme exprimé dans l’histoire d’utilisateur. Par exemple, l’histoire d’utilisateur est: Comme un acheteur de mon futur domicile, je veux voir la liste de maisons dans mon voisinage pour que je puisse faire une liste des maisons candidates sélectionnées que je veux acheter.

Les tâches pour l’histoire pourraient être:

    • Codage, utilisation de la logique appropriée
    • Intégration d’APIs de recherche et de cartographie
    • Développement de scénarios de test
    • Intégration avec des sources de données
    • Finalisation de filtre de sélection

Les histoires d’utilisateur sont mesurées de manière relative avec des tailles comme S, M, L, XL, etc., ou en utilisant la séquence de Fibonacci : 1, 2, 3, 5, 8, 13 …, basée sur la complexité de développement des histoires. Les tâches sont toujours calculées en heures et sont basées sur le niveau d’effort que chaque membre doit fournir pour chacune des tâches.

CertYou est partenaire de DantotsuPM

Histoires d’utilisateur et épopées

Une épopée est un jeu de fonctionnalités qui ressemblent à une histoire au début, mais quand les membres de l’équipe commencent à l’analyser, ils constatent qu’elle pourrait être plus grande que précédemment envisagé. Donc ils doivent la décomposer en de multiples histoires. Une façon de différencier une épopée d’une histoire est en vérifiant qu’elle suit le modèle INVEST discuté plus tôt.

3 pratiques Agiles faciles que votre équipe peut commencer dès aujourd’hui

29 Juin

3 Easy Agile Practices Your Team Can Start Today http://projectbliss.net/agile-practices/ par Leigh Espy

Vous avez entendu vos amis chanter les louanges d’Agile. Vos copains chefs de projet deviennent des scrum masters. Vous entendez combien c’est formidable. Tous les gamins dans le coup le font et vous êtes un peu jaloux. Vous vous sentez exclu. Vous voulez voir l’objet de toute cette agitation.

Bonnes nouvelles ! Il existe des pratiques Agiles que vous pouvez utiliser même dans votre monde prédictif en cascade. Vous obtiendrez les bénéfices d’une communication accrue,  de la collaboration avec le client et de l’amélioration continue. Et vous aurez une opportunité de présenter quelques pratiques Agiles à votre équipe. Sans devoir vous coller à la transition de l’organisation toute entière vers Agile.

AVERTISSEMENT : que faire avant que vous n’adoptiez ces pratiques Agiles

N’adoptez pas de pratiques Agiles simplement pour suivre les foules.

Comprenez les bénéfices que vous tirerez à incorporer des pratiques Agiles. Vous économiserez du temps et de l’argent en obtenant des réactions des clients et en livrant le bon produit. Vous travaillerez plus intelligemment avec une communication accrue et transverse dans l’équipe et des pratiques de travail améliorées.

Discutez avec votre équipe et obtenez leur adhésion. Le changement sera un effort d’équipe et vous aurez besoin de leur collaboration et coopération. L’équipe entière doit être à bord. Vous ne pouvez pas réussir seul.

Partagez vos idées avec l’équipe sur pourquoi vous voulez le faire. Découvrez les idées et préoccupations de vos coéquipiers. Assurez-vous qu’ils sont ouverts à faire un essai. Vous devrez vous lancer avec leur appui, parce qu’ils font aussi partie du jeu.

Les 3 pratiques suggérées sont ici de bonnes démonstrations des valeurs Agiles que j’ai discutées dans A PM’s Guide to Agile Software Development

Voici 3 pratiques Agiles que vous pouvez déjà commencer à utiliser:

1. Standup Quotidien

Bénéfices : transparence et communication accrues dans l’équipe.

Votre équipe aura une plus grande compréhension de la progression et des défis. Le chef de projet peut « mener » si nécessaire, mais les équipes Agiles s’auto-organisent et peuvent le faire elles-mêmes si le chef de projet n’est pas là.

Comment le faire : c’est une réunion très courte (15 minutes ou moins) qui donne chaque jour une occasion à l’équipe de faire un point et partager l’information.

Chaque membre d’équipe répond brièvement à ces trois questions :
  1. Qu’avez-vous fait hier ?
  2. Sur quoi travaillez-vous aujourd’hui ?
  3. Y-a-t-il des obstacles vous empêchant de faire votre travail ?

Dans le Scrum traditionnel, le scrum master élimine les points de blocage, mais le chef de projet peut aussi le faire.

Avertissement : ce n’est pas une réunion de statut d’avancement de 30 minutes. Ce n’est pas une longue discussion sur les détails. Cela devrait plutôt être très court : 15 minutes ou moins. C’est un rendez-vous pour votre équipe chaque jour pour rester à niveau. Si l’équipe doit discuter de plus de détails, faites-le après le stand up.

Un de mes amis a suggéré à son chef qu’ils s’y essaient. Ils avaient des très longues réunions de statut de projet. Son patron a accepté et aimé l’idée. Mais au lieu que ce soient les membres de l’équipe qui aient une réunion quotidienne rapide, son chef la dirige. Pis encore, le stand up s’est métamorphosé en réunion de statut prolongée tous les jours : une situation pire qu’avant. Évitez la tentation de faire traîner le stand up. Tenez l’agenda et le rythme et gardez les longues conversations pour après le stand up.

2. La Rétrospective

Bénéfices : amélioration continue.

Votre équipe identifiera des façons de s’améliorer pendant le projet, plutôt que d’attendre jusqu’à ce que le projet soit fini. Vous y gagnerez les bénéfices d’améliorations continues tout au long du projet.

Comment le faire : à divers moments pendant le projet, l’équipe évalue son efficacité.

Livre sur Amazon

Il y a 3 questions clefs à poser :
  1. Qu’est-ce qui a fonctionné bien pour nous ?
  2. Qu’est-ce qui n’a pas bien marché ?
  3. Que pouvons-nous faire différemment pour nous améliorer ?

Choisissez divers moments pendant le projet pour mettre en œuvre cette pratique Agile. Une fois que vous avez fait l’exercice et identifié des choses que vous pouvez améliorer, choisissez-en une ou deux à cibler les premières. Incorporez ces changements et voyez comment ça va. Répétez ensuite ce processus pendant le projet.

Votre équipe peut incorporer des améliorations tandis que le projet est toujours en voie de réalisation, plutôt qu’attendre jusqu’à ce que le projet soit fini.

Notez : Il doit y avoir un environnement de confiance et de soutien entre les membres de l’équipe. Ne critiquez personne pour des suggestions faites. Ne blâmez pas de membres pour des fautes, mais identifiez plutôt des façons de vous améliorer. Soyez ouvert à considérer les challenges comme des opportunités.

3. Démonstrations de logiciel au client

Bénéfices : transparence et collaboration avec le client.

démonstrationLes clients bénéficient de voir le produit en l’état et en partageant leurs réactions. L’équipe obtient l’avantage de retours des client sur n’importe quels ajustements nécessaires.

Comment le faire : Démontrez un logiciel qui fonctionne au client à des points appropriés en cours de développement. N’attendez pas jusqu’à ce que tout ce soit prêt pour les tests d’acceptation de l’utilisateur final.

Ce n’est pas une présentation PowerPoint. Vous montrez le logiciel réel. Ne cherchez pas de tape à l’œil ni perfection. Votre but est de montrer au client comment le produit progresse et d’obtenir des réactions. Vous ne devez pas louer une énorme salle de conférences et faire des PowerPoint tapageur. Vous ne montrez pas de produit fini pour l’instant.

Gérez les attentes du client sur ce que vous montrez. Vous ne voulez pas les étonner s’ils s’attendaient à quelque chose d’autre. Assurez-vous qu’ils sont conscients que c’est un premier jet et pas le produit fini. Expliquez pourquoi vous le faites et ce que vous espérez y gagner.

CertYou est partenaire de DantotsuPM

C’est un Voyage

Adoptez un esprit de collaboration, de communication et d’amélioration continue. Faites-le avec respect pour tous vos membres d’équipe pendant que vous adoptez de nouvelles pratiques.

Soyez patient avec eux. Vous n’atteindrez pas tout de suite la perfection. Mais vous en bénéficierez et l’aimerez probablement, aussi.

Maintenant que nous avons vu ces 3 pratiques Agiles, vous pouvez probablement voir comment les utiliser même si vous ne vous lancez pas à fond dans Agile.

Il n’y a désormais plus aucune raison de vous sentir exclu. La prochaine fois que vos amis scrum masters parleront Agile, vous pourrez vous joindre à eux.

Dites-leur les façons dont votre équipe s’en sert pour s’améliorer et combien vos clients en sont heureux.

Et ces autres amis qui ne l’ont pas encore essayé ? Partager votre amitié en partageant cette information avec eux !

Que signifie vraiment “le Produit Viable Minimal” ou mVP de toute façon ?

20 Juin

Elon Musc donne du sens à une idée qui peut nous embrouiller.

Un extrait de l’excellent billet https://medium.freecodecamp.com/what-the-hell-does-minimum-viable-product-actually-mean-anyway-7d8f6a110f38 de Ravi Vadrevu

Un processus MVP simplifié en 3 étapes

J’ai pris des méthodologies complexes comme LEAN, Agile et Guerilla pour en distiller le process mVP en 3 étapes :

  1. Commencez avec un produit simple et unique résolvant un minuscule sous-ensemble d’un grand problème;
  2. Continuez à itérez, en résolvant constamment de plus grands problèmes connectés à la résolution du grand problème;
  3. Communiquez constamment la vision du grand problème qui sera résolu.

Utilisons l’évolution de l’éclairage pour illustrer comment cela fonctionne.

Source : Egg Lighting

Grand problème : l’Humanité a besoin d’un éclairage bon marché, efficace pendant l’obscurité

1er mVP : Feu. Les gens ont observé comment la foudre des cieux pouvait enflammer des forêts et créer le feu. Après expérimentation, en frottant des bouts de bois entre eux, ils ont créé leur propre feu. Problème résolu. Mais le feu n’est pas particulièrement portable.

2ème mVP : Lampes à pétrole, Bougies et Lanternes à Gaz. Maintenant les gens pouvaient emporter la lumière avec eux quand ils se déplaçaient. Problème résolu. Mais les bougies et des lanternes à gaz ne sont pas particulièrement éclairantes et la plus légère brise les éteint.

3ème mVP : Ampoules incandescentes. Les premières ampoules étaient alimentées par batterie et plus fiables qu’une bougie vacillante. Problème résolu. Mais comme les villes ont grandi en taille, la demande pour un éclairage plus répandu a grandi. Le réseau national n’avait pas encore été construit.

4ème mVP : Électricité largement disponible. Pour transmettre l’électricité sur de longues distances, le courant alternatif et les transformateurs ont été développés. Des centrales électriques thermales ont été construites pour satisfaire la demande massive. Problème résolu. Mais comme la demande mondiale en électricité augmentait, des alternatives sont devenues nécessaires.

5ème mVP : Énergie solaire. Des ampoules de consommation en watts inférieures remplacent les ampoules incandescentes originales tandis que les panneaux solaires deviennent plus efficaces et meilleur marché à produire. Problème résolu. Mais les solutions solaires restent encore relativement chères et l’adoption trop faible pour être en position d’éteindre le réseau électrique.

6ème mVP : une Planète dont l’énergie provient seulement du soleil. Des batteries hautement efficaces peuvent être chargées par des panneaux solaires bon marché et omniprésents. À ce point il devient possible d’éliminer notre dépendance aux carburants fossiles. Nous n’y sommes pas encore tout à fait.

Méta Projets Management est partenaire de DantotsuPM

Elon Musk est un entrepreneur qui est exceptionnel dans son application du processus mVP en 3 étapes.

1. Commencez avec un produit simple résolvant un problème minuscule.

Il a lancé une voiture électrique en moins de 3 ans qui est devenue la voiture électrique la plus demandée au monde.

2. Continuez à itérer, en résolvant constamment des problèmes plus grands.

L’autonomie de la batterie continue de s’améliorer pour que les voitures aient davantage d’autonomie et améliore leurs performances: 100km/h en 2.28 secondes, la technologie de conduite sans chauffeur réduit les accidents, la seconde phase de Tesla introduit des bus et des camions électriques, la fusion de Tesla avec Solar City et l’achèvement de Gigafactory.

3. Communiquez constamment la vision du grand problème.

La vision suprême de Musk est une planète actionnée entièrement par le soleil et finalement habiter de multiples planètes. Il n’est pas le meilleur communicant du monde. Beaucoup de ses discours sont maladroits (il s’améliore avec le temps). Mais il a capturé l’attention du monde parce qu’il communique constamment sa vision, en livrant des mVPs tout au long de ce voyage.

Imaginez si Musk avait commencé à résoudre son grand problème en construisant d’abord la Gigafactory (avant Tesla et Solar City). Il pourrait avoir lancé un mVP qui produise 1 batterie par mois. Cette idée n’irait nulle part, parce qu’il ne nous aurait pas embarqué dans ce voyage depuis où nous nous trouvons maintenant vers où il voit que nous devons aller. Son mVP ne serait pas viable.

Les entrepreneurs font très souvent l’erreur de commencer par le grand problème. Ils livrent alors un mVP, mais le marché ne répond pas parce qu’ils ne nous ont pas embarqués sur le voyage exigé. Le résultat ? mVP non viable qui aboutit souvent à un flop.

Processus mVP en 3 étapes en pratique

Disons que vous ayez lancé votre produit. Une poignée de clients a signé pour votre première version. Votre outil de suivi vous dit qu’il y a des téléchargements. Mais vous remarquez aussi que l’engagement est très faible. Vos projections financières sont loin de l’utilisation que vous aviez prévue.

Contrairement à la croyance populaire, ce n’est pas un désastre.

La bonne nouvelle est que les gens adhèrent à une certaine partie de votre vision. C’est le premier pas dans la validation de votre marché. C’est à ce moment que le responsable de la stratégie produit doit sortir du bureau, parler aux clients et comprendre la situation :

  • Quelle est exactement la partie de votre vision qui a initialement capté leur attention ?
  • Qu’est-ce qui précisément rend votre produit difficile à utiliser pour atteindre la vision ?
  • Y a-t-il quelqu’un d’autre qui fait ceci mieux que vous? Que fait-il différemment ?
  • Le problème est-il que les clients veulent résoudre un problème différent de celui que vous adressez ?

C’est un processus systématique d’analyse et de compréhension du sens. C’est un processus scientifique qui se base sur des données et une métrique bien définie. Mais le processus est guidé par la vision de l’artiste qui imagine un futur meilleur plus enrichissant. Non seulement l’artiste voir l’avenir, mais il peut voir le chemin à parcourir pour atteindre cet avenir. Et il sait que les livraisons de mVPs sont comme des tremplins pour nous déplacer d’ici jusque là-bas.

C’est ma compréhension de ce que fait un Produit Viable Minimal qui est réellement Viable.

Quelle est la vôtre ?

The Agile Manifesto: 4 values and 12 Agile Principles by QRP International

12 Juin

The #AgileManifesto is the core of the Agile Movement.

It was written in February 2001 by software practitioners who found consensus around 4 values and 12 Agile principles.

The Agile Manifesto, its 4 values and 12 Agile Principles, were the consequences of industry frustration in the 1990s about the time lag between business requirements and the delivery of technology. Business and customer requisites changed during this lag time, and the final product did not meet the then current needs.

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

Individuals and interactions OVER processes and tools
Working software OVER comprehensive documentation
Customer collaboration OVER contract negotiation
Responding to change OVER following a plan

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

The 12 Agile Principles included in the Agile Manifesto describe a culture in which change is welcome, and the customer is the focus of the work.

Learn more at this link: https://lnkd.in/dQaPXQb

Le webinaire en replay de notre partenaire

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…

2 new Agile pages on the QRP Web site: Agile Manifesto and an overview of Agile Project Management

26 Mai

These two pages have been developed with the goal to be informative on Agile, as our partner QRP International saw that most of the search queries for Agile are still related to general topics like the Agile manifesto or the overview and comparisons of different agile methods.

QRP International est partenaire de DantotsuPM

Agile Manifesto, principles and methodology

The Agile Manifesto was written in February 2001 by software practitioners who found consensus around 4 values and 12 Agile principles. The Agile Manifesto is the core of the Agile Movement. The intention of Agile is to align development with business needs.

Overview of Agile Project Management

Agile Project Management describes an iterative approach to planning and guiding project processes. Nevertheless, Agile is a mindset. There is not one Agile Project Management approach that works for all situations; rather the general term “Agile” represents a variety of methods and practices.
Image

le combiné « Guide PMBOK® + Guide pratique des méthodes Agiles » du Project Management Institute est disponible en français

19 Mai

Livres sur Amazon

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.

Le PMBOK® guide – Sixième édition contient maintenant des informations détaillées sur Agile; tandis que le Guide de Pratique Agile, créé en partenariat avec Agile Alliance®, sert de passerelle pour connecter méthodes prédictives et agilité. Ensemble, ils constituent un outil puissant pour les managers de projets.

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

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

3 Mai

soyons WAGILE (W-aterfall + AGILE)

Je reprends un extrait de cet article publié il y a déjà plusieurs années à l’occasion du Forum 2018 des régions du PMI® France, en particulier avec une journée sur Hybridation et bienveillance dans les projets à Sophia Antipolis

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.

L’approche Agile semble donc être la panacée !

Mais ce n’est pas simple à réaliser et le chef de projet se posera de nombreuses questions :

  • Comment intégrer ces approches de manière réussie dans des contextes de gestion de projet mature qui sont plus traditionnels avec du développement logiciel en V ou en cascade ?
  • Comment est orchestrée la livraison en production de ces produits développés avec agilité et approche Lean  dans un processus de gestion des livraisons pour la mise en production qui lui apparaît souvent très rigide, et qui se doit de minimiser les risques liés au changement ?
  • Comment ces livraisons s’intègrent-elles dans la gestion des versions (release management), et notamment les procédures de tests (unitaire, intégration et réception des applications), la production de la documentation technique d’exploitation, de la documentation destinée aux utilisateurs et enfin la création des procédures d’installation et de déploiement ?
  • Comment éviter que ces méthodes ne soient qu’un alibi à des comportements laxistes et inefficaces, par exemple en supprimant toute documentation ?

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

La réussite de tels projets passe par un compromis  d’usage entre l’agilité de l’approche globale de développement et la rigueur à conserver dans le processus de livraison. D’où le titre de notre communication: « une main de fer dans un gant de velours ».

Quelle que soit la  méthodologie choisie,  elle doit pouvoir s’inspirer des avantages des autres méthodes existantes.

Citons l’exemple de l’institut PMI® qui est l’autorité en matière de gestion de projets « traditionnelle » ; cet organisme  s’est naturellement  ouvert aux principes d’Agilité en créant récemment une nouvelle certification PMI-ACP® (Agile Certification Practitioner) et en intégrant l’Agilité et le Lean Management dans la gestion de projet plus traditionnelle.

Un aspect important à ajouter dans les méthodologies Agile est la gestion du risque: c’est un exemple de bonnes pratiques dérivant des méthodes traditionnelles qui doit être intégrée dans les approches agiles.

Nous terminons sur un rappel des quatre principes fondateurs du Manifeste pour le développement Agile de logiciels rédigé par Kent Beck et 16 autres signataires qui peuvent être suivis quelle que soit la méthodologie de management de projet employée.

« Ces expériences nous ont amenés à valoriser :

1.    Les individus et leurs interactions plus que les processus et les outils,

2.    Des logiciels opérationnels plus qu’une documentation exhaustive,

3.    La collaboration avec les clients plus que la négociation contractuelle,

4.    L’adaptation au changement plus que le suivi d’un plan.

Nous reconnaissons la valeur des seconds éléments mais privilégions les premiers ».

sans dénigrer les items du côté droit, on favorise ceux à gauche

La démarche Agile doit être envisagée plutôt comme une véritable philosophie de développement

Nous avons voulu rassembler des conseils très pratiques pour dérouler les étapes d’un projet de façon Agile, en nous inspirant de nos expériences sur des contextes projets très variés. Mais nous insistons sur l’importance de comprendre qu’une démarche, quelle qu’elle soit, n’est pas la panacée, si on se contente de l’utiliser comme une « boîte à outils avec check-list intégrée ». La démarche Agile doit être envisagée plutôt comme une véritable philosophie de développement, qui mise sur l’engagement des employés et leur participation. Il faut savoir prendre dans chaque méthode ce qui est « bon pour l’entreprise », sachant que chaque entreprise est unique et a ses propres spécificités de fonctionnement qui en font sa richesse. Face aux méthodes traditionnelles, les méthodes Agiles sont une révolution, mais elles peuvent aussi apporter leur part de lourdeur et de contrainte, selon l’usage que l’on en fait.

L’Agilité c’est bien mais la contrôler c’est mieux

–       L’approche SCRUM n’est pas la panacée, notamment si elle n’est pas accompagnée par le Management et la Maîtrise d’Ouvrage (MOA)

–       L’approche Lean de l’industrie ne peut être transposée dans tous les contextes

–       L’esprit AGILE est avant tout le moteur qui garantira le succès, du Senior Management aux gens de terrain

–       Il faut bien sélectionner les outils AGILEs convenant le mieux à l’entreprise

–       Un coaching pragmatique est un facteur clé de réussite

–       Le dogmatisme doit être jeté aux oubliettes

–       Et il faut contextualiser la démarche qui ne peut être standard pour tous les domaines (de l’industrie spatiale à Google, en passant par l’aéronautique, l’industrie automobile, le secteur bancaire…).

CertYou est partenaire de DantotsuPM

Et l’Agilité mal comprise et mal appliquée pourra causer encore plus de dommage que les méthodes traditionnelles.

Soyons WAGILE ! Contraction de WATERFALL (méthodes de développement traditionnelles) et AGILE … d’où « Agilité une main de fer dans un gant de velours ! »


Si ce sujet vous intéresse, ne manquez pas le Forum 2018 des régions du PMI® France: Hybridation et bienveillance dans les projets (7 PDUs)

Inscriptions en ligne

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

%d blogueurs aiment cette page :