articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
Méthodes, retours d’expérience, bonnes pratiques
Un couple d’amis (merci Éric et Gwena !) m’a recommandé de voir cette courte vidéo sur la montée des réseaux sociaux. Attachez vos ceintures et ouvrez bien les oreilles car les statistiques d’usage défilent vite et sont parfois surprenantes.
Et si vous cherchez d’autres chiffres, en voici quelques uns.
http://www.projecttimes.com/robert-galen/agile-project-managementdriving-value-or-wheres-the-beef.html par Robert ‘Bob’ Galen
Il y a des années il y avait une merveilleuse publicité dont je me rappelle où une matrone nommée Clara Peller jugeait des hamburgers par la quantité de bœuf qu’elle y trouvait. Souvent elle était déçue dans sa recherche et, de frustration, criait « Où est le steak ? ». Wendy’s était la chaîne de restauration qui a inventé cette idée publicitaire et à ce jour la phrase est devenue une accroche pour délivrer de la valeur et répondre aux attentes des clients.
Je pense que Clara était sur quelque chose de vraiment important. Dans mon expérience, les business loupent souvent le « steak » quand ils essayent de délivrer de la valeur à leurs clients particulièrement dans le domaine du logiciel. Je ne sais pas exactement pourquoi. Parfois je pense que les développeurs sont trop distants de leurs clients. Ils peuvent rarement les toucher ou les observer. Ou comprendre leurs vrais défis. Donc ils font des suppositions quand on en vient à la priorisation des besoins puis jettent le logiciel « par-dessus le mur » pour un retour d’information.
Assez souvent ils sont sous pression pour livrer un maelström de fonctionnalités. Même si quasiment personne ne sait ce que sont les besoins clients, donc ils fournissent des solutions en ratissant large espérant atteindre les besoins. En croisant les doigts. Même si cela peut connaître certaines réussites, on aboutit aussi à la livraison de fonctionnalités de faible valeur qui diluent la concentration de l’équipe et augmentent les coûts de développement.
Ne serait-ce pas merveilleux si nous pouvions nous concentrer entièrement sur le « Steak » dans le développement d’application ? Dépenser la majorité de notre énergie, en nous concentrant sur la livraison de solutions à forte valeur et répondant aux plus forts besoins de nos clients. Éliminer le désordre de la déception et de l’ambiguïté et travailler simplement sur qui compte le plus ?
Même si cela ressemble à un conte de fées, les méthodes agiles aspirent justement à atteindre ce but. Mais il n’est pas facile de l’atteindre et le Chef de projet Agile efficace joue un rôle merveilleux dans cette quête. Dans ce billet, je veux partager quelques idées sur la façon de concentrer l’équipe sur la livraison de vraie valeur.
Un des premiers mécanismes qui pilotent la valeur est le « Backlog de Produit » – la liste priorisée des besoins qui pilote ce que les équipes agiles vont construire. Chaque équipe devrait être focalisée comme un laser sur la priorisation de leur « backlog » de 1 à N. Il ne peut pas y avoir trois ou quatre fonctionnalités de priorité 1, seulement une; puis une seule deuxième, une seule troisième, et cetera.
Croyez-moi, vos clients et parties prenantes voudront jouer indéfiniment avec les priorités. J’ai vu des cas où ils avaient fait des regroupements dans un tableur qui donnaient la priorité de chaque fonctionnalité, puis des sous-fonctionnalités de chacune d’entre elles également priorisées. Ils insisteront pour dire qu’ils ne peuvent pas décomposer davantage la valeur quand ils essaieront d’augmenter la priorité. Cette approche (1.a, 1.b..1.z) leur permet d’échapper à la vraie priorisation et à la sélection. Elle indique aussi leur incapacité innée à faire des choix difficiles quant à ce qui est réellement le plus important. Ne les laissez pas le faire!
Un backlog de produit efficace est toujours dans un ordre linéaire et priorisé. L’équipe délivrera toujours les fonctionnalités de priorité les plus hautes en premier. Ils travailleront d’abord sur celles-ci, les finiront en premier, et s’assureront que le client est bien engagé.
Et, puisque le client est l’arbitre final des priorités, il ne devrait pas vraiment se plaindre de cette approche. Il est vrai qu’historiquement nous leur avons permis de nous donner de longues listes de fonctionnalités sans faire cette distinction et ils sont devenus un peu paresseux.
Quand encouragée à prioriser, je n’ai jamais vu de partie prenante qui en soit incapable.
La priorisation peut aussi être pilotée par la valeur perçue, le changement, qui devrait être conduit. Une technique utilisée par beaucoup d’équipes agiles est la notion de Poker de valeur. C’est une variation de la populaire technique de Poker de Planification (Planning Poker) qui est utilisée pour l’évaluation de la taille d’une « User Story ». Mais au lieu de déterminer la taille des « User Stories » en points d’histoire, nous utilisons des Points de Valeur comme déterminant.
Dans ce cas vous utilisez un jeu de cartes étiquetées de 1-10, un étant la valeur la plus basse et dix la plus haute. Pour chaque « User Story » ou thème d’histoires vous demandez à un groupe mixte de clients et de parties prenantes ‘de voter’ sur la valeur de l’Histoire. Vous prenez une approche tournante et discutez ‘le pourquoi’ derrière la valeur la plus haute et la valeur la plus basse et vous laissez les membres de l’équipe exprimer leurs avis sur la nuance de valeur.
Une fois que la discussion est finie, vous faîtes un second vote et rediscutez jusqu’à ce que vous rétrécissiez la fourchette de valeurs autant que possible. Parfois vous atteignez un accord sur une valeur de l’ensemble de l’équipe. Parfois vous obtenez simplement une fourchette.
Vous pourriez même compartimenter les valeurs selon les différentes perspectives de l’équipe. Par exemple, les personnes de la qualité et des tests estiment une histoire particulière à cinq, tandis que la valeur des gens du métier cela la valorise à trois et les développeurs ou les gens de la technologie à un. Toutes leurs estimations fournissent des données importantes sur combien vous estimez transversalement la fonctionnalité.
Cette logique pourrait aussi être appliquée à de multiples parties prenantes. Par exemple, les parties prenantes Nord-Américaines pourraient estimer une fonctionnalité à six, tandis que les parties prenantes EMEA la jugent seulement à trois. Dans tous ces cas, discuter de la VALEUR comme d’un attribut distinct aide l’équipe dans la priorisation et dans la décision de combien de finition il faut apporter aux fonctionnalités individuelles.
Une variation vraiment efficace sur la technique de Poker de Valeur est de donner à chaque votant ou contributeur associé un montant de financement à dépenser pour leur vote. Alors, non seulement ils votent sur une valeur, mais ils doivent aussi investir une partie d’un montant fixe de dollars sur la fonctionnalité.
Très souvent de l’argent de Monopoly ou un équivalent amusant sont utilisés à cette fin. Disons que chacun possède 5,000 $ à dépenser sur leurs fonctionnalités pendant le Poker de priorisation. Dans un cas spécifique, une partie prenante vote neuf sur une caractéristique.
Pour souligner l’importance, ils déposent 1,500 $ sur la caractéristique soit environ 30% de leurs fonds disponibles. En fait, ils dépensent leurs fonds sur un total de seulement sept fonctionnalités. Pendant qu’ils continuent à prioriser les fonctionnalités ultérieures, ils ont clairement communiqué leurs avis sur la valeur. En fait, cette caractéristique à 1,500 $ finit en première priorité avec une valeur totale de 12,000 $ à travers l’équipe de vote entière soit 25% des fonds disponibles.
Aussi, voici une question intéressante. Si vous implémentez cette approche, que transmet Priorité n°1 par rapport à Priorité n°1 ET 25% de la valeur ? Selon moi, il y a une grande différence. Cette fonctionnalité représente une part beaucoup plus significative de la valeur et exige un soin particulier dans l’exécution. J’espère que vous voyez la différence.
Souvent dans les équipes agiles, des « User Stories » singulières n’ont pas la masse ou l’impact suffisant pour être estimées efficacement par le client. Plus tôt, j’ai parlé en termes de thème d’histoires. C’est une façon commune de grouper ensemble des histoires qui ont une valeur et de la signification en tant que groupe. Non seulement cela aide dans le développement des jeux de fonctionnalités significatives, mais si vous priorisez au niveau des thèmes, cela simplifie votre priorisation. Cela a aussi plus de signification du point de vue des clients.
Une variation sur ce thème est la Fonctionnalité Minimale Commercialisable (Minimal Marketable Feature : MMF). Ce concept est originaire de Kanban et de LEAN. Essentiellement, c’est comme un thème, mais il apporte les notions de faisabilité, possibilité de commercialisation et l’utilisation d’ensemble client.
Très souvent un MMF est plus grand qu’un thème. Cela pourrait être équivalent à une épopée d’histoires d’utilisateur et exiger que plusieurs sprints soient achevés. Cependant, une fois réalisé, l’équipe délivrera d’habitude physiquement le MMF au client, par exemple, le faisant passer dans l’environnement de production.
Suivi de ValeurUn des merveilleux ajouts à votre ensemble d’outils de Chef de projet Agile est de brûler complètement la valeur d’histoires, de thèmes, ou MMFs. Vous voudrez installer le graphique de « Burndown Chart » dans un emplacement bien visible qui mette en évidence la valeur livrée par l’équipe. Comme avec tout graphiques « Burndown » vous voudrez garder les yeux de chacun sur le progrès et interagir avec l’équipe sur le progrès et le flux.
Vous voudrez calculer la valeur totale pour une version ou un projet. Alors configurez votre « Burndown » sur une base itération-par-itération.
Si vous obtenez un comportement agile sain dans votre équipe, vous verrez que la valeur est livrée d’une façon chargée sur l’amont. Vous devriez aussi voir les fonctionnalités de forte valeur livrées très tôt. En fait, je m’attends habituellement à ce que des équipes factorisent la valeur dans la qualité globale et dans les stratégies de test.
Savoir conclureLes chefs de projet Agiles ne se soucient pas juste d’exécuter par cœur de tâches ou des « user stories ». Non! Au lieu de cela ils concentrent leurs équipes sur une vue nuancée et à multiples facettes et vers une exécution orientée client et pilotée par la valeur.
Non seulement espèrent-ils en premier délivrer de la valeur, mais ils espèrent aussi qu’en ce faisant, le client peut atteindre un niveau « assez bon » avec les incréments de produit livrés de façon incrémentale et permettre ainsi à l’équipe d’arrêter le projet plus tôt que prévu.
S’arrêter après la livraison des fonctionnalités et de la fonction qui leur importe vraiment le plus. En quelque sorte atteindre leur valeur et se déplacer ensuite vers le projet suivant de valeur la plus haute. C’est cette sorte de recherche de valeur qui peut vraiment faire qu’une équipe agile se détache de ses homologues traditionnelles et se déplace tellement plus rapidement.
Le modèle INVEST est décrit sur Wikipedia
| Letter | Meaning | Description |
|---|---|---|
| I | Independent | The user story should be self contained, in a way that there is no inherent dependency on another user story. |
| N | Negotiable | User stories, up until they are part of a Sprint, can always be changed and rewritten. |
| V | Valuable | A user story must deliver value to the end user. |
| E | Estimable | You must always be able to estimate the size of a user story. |
| S | Sized appropriately or Small | User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. |
| T | Testable | The user story or its related description must provide the necessary information to make test development possible. |
In a white paper available free of charge IBM proposes a Disciplined Agile Delivery (DAD) process to make the best use of existing Agile methodologies (Scrum, RUP, XP..) while scaling up and putting them in the context of a complete solution life-cycle.
I invite you to read the full introductory document. PMs will find there a terminology they recognize and can easily relate with rather than the sometimes hermetic one of Agile for new comers with its scrums, sprints, poker planning… Through inception, construction and transition phases, the authors position along the DAD Process the tasks to be done, of course in an Agile way and using many of the scrum and RUP techniques .
So, if you’re still Agile adverse, read this white paper, and you may well see some of these approaches like Scrum, XP, RUP in a new and brighter light.
En juillet 2011, Ken Schwaber et Jeff Sutherland ont édité une nouvelle version du Scrum Guide. Ce “Scrum Body of Kowledge” a l’air anodin, mais du point de vue de Pierre Neis, il annonce de profonds changements dans le “framework”.
Voici une traduction non-officielle que Pierre nous invite à découvrir.
Cornelius Fichtner, PMP, host of The Project Management Podcast™, reads out the Agile Manifesto for us and sheds light on each sentence based on his own very rich project management experience.
The Scrum Framework
Lyssa Adkins qui se présente comme une coach de Coach Agile (les ScrumMasters par exemple), montre dans cette vidéo comment expliquer Scrum à quiconque en reprenant dans un graphique les principes clés de cette approche. Lyssa est l’auteur du livre Coaching Agile Teams.
The Wedding Cake
Elle va plus loin avec cette démonstration de comment expliquer très simplement les différences et les bénéfices qu’il y a à adopter une approche Agile.
http://kenschwaber.wordpress.com/2011/05/03/empiricism-the-act-of-making-decisions-based-on-what-is/
Par Ken Schwaber
L’empirisme est l’acte de prendre des décisions basé sur ce qui est. Scrum est un processus empirique, parfois décrit comme “l’art du possible.” Par cela, je veux dire que nous faisons du mieux nous pouvons avec ce que nous avons.
Un Propriétaire de Produit (« Product Owner ») planifie une version (« release ») basée sur toutes les informations actuellement disponibles. Il ou elle définisse les objectifs, les fonctionnalités et les capacités qui délivreront ces buts ainsi que le coût probable et la date de livraison. À partir de ce moment-là, le travail du Propriétaire de Produit est d’évaluer ce qui est possible vu les capacités de l’Équipe et de prendre les meilleures décisions pour atteindre l’objectif souhaité. Étant donné la nature de la technologie, des marchés, des besoins et des personnes, des compromis sont faits. Parfois le but ne peut pas être atteint pour un prix raisonnable. Parfois le but sera atteint, mais d’une manière différente de ce que le Propriétaire de Produit pensait initialement. C’est l’empirisme en pleine action.
L’Équipe (de développeurs) sur l’Équipe Scrum fait de même. Elle rencontre le Propriétaire de Produit et évalue ce que le Propriétaire de Produit voit comme les choses les plus importantes à faire ensuite. Si réalisées, celles-ci dirigeront le produit émergent dans la meilleure direction vers le but désiré. L’équipe choisit autant de choses qu’elle croit pouvoir en faire pendant le prochain Sprint. Le coût de l’équipe et la longueur de Sprint est fixe. Seule la quantité d’items du « Product Backlog » choisie peut varier. Le Propriétaire de Produit et l’Équipe définissent souvent un objectif pour le Sprint. C’est un sous-ensemble des objectifs de la version (« release »).
Quand l’équipe choisit des items lors d’une réunion de Planification de Sprint, elle s’engage à le faire pendant le Sprint.
Une définition « s’engager » est : « Se lier moralement par une promesse : Il s’est engagé à payer ses dettes dans les huit jours. » selon le Larousse. (ndlt)
Cela correspond à ma compréhension du mot s’engager, qui est une promesse, un engagement à un plan d’action.
Cependant, beaucoup d’équipes Scrum utilisent le mot « s’engager » comme si c’était « une garantie ». C’est un reste des méthodes en cascade, où une évaluation était un contrat. Cependant, cela résonne toujours dans les têtes de propriétaires de produit et des développeurs. J’ai trouvé équipes après équipes qui estiment qu’elles doivent tout faire pour respecter leur engagement. La victime est habituellement la qualité.
Je me demande si nous devrions échanger le mot « s’engager » pour celui de “prédire” ?Ceci pourrait donner la même impression que la présentatrice météo essayant de nous fournir les meilleures informations possibles. Elle fait avec que l’on connaît et avec la science de la météorologie. Elle ne fournit pas de garantie, mais quelque chose que nous pouvons utiliser pour prendre des décisions. Les prévisions sont également utilisées par les organisations de ventes. Peut-être cette clarification nous aidera-t-elle à comprendre qu’ « un engagement » dans Scrum est une promesse de faire de notre mieux avec ce que nous avons.
Si Philip Diab (former PMI Chair Person) devait identifier un seul outil, méthode ou processus qu’il faut maîtriser parfaitement pour les chefs de projet, ce serait la structure de découpage du projet (WBS).
J’ai plusieurs fois abordé ce sujet critique de la construction du WBS en management de projet, notamment dans les billets: « conseils pratiques sur le WBS/practical tips on WBS »; « 20 erreurs courantes faites par les chefs de projet nouveaux ou inexpérimentés Par Harold Kerzner, Ph. D., PMP » et « Dix Choses à regarder lors d’une revue de planning (d’échéancier) de projet ».
Cornelius Fichtner nous fournit ici un éclairage personnel et insiste sur la règle des 100% qui est trop souvent oubliée.
un chef de projet devrait-il se soucier de Politique de Bureau ?La « politique politicienne » qui n’a pour intérêt que de servir quelques personnes qui en usent et en abusent est elle négative et c’est souvent dans ce sens que l’on se réfère à la « politique de bureau » qui ne sert que quelques individus dans l’entreprise à des fins personnelles.
La sensibilité aux cultures et à la communication inter cultures est un élément clé de réussite des chefs de projet qui travaillent à l’international. Je pense que cette petite vidéo amusante vous rappellera des souvenirs de situations similaires qui vous sont arrivées. Lesquelles ?
composer des équipes comme si les personnes importaientLes projets sont avant tout une affaire de personnes. Alors que cette affirmation semble tomber sous l’évidence, elle est souvent incroyablement oubliée. L’homo economicus a longtemps été discrédité et a prouvé être beaucoup moins rationnel que beaucoup de philosophes le voudraient. Les gens ne sont pas universellement interchangeables et on ne peut pas s’attendre à ce qu’ils se comportent dans les limites logiques et prévisibles de leur intérêt personnel étroit, mais nous continuons à faire comme si c’était le cas. Comment nous fonctionnons dans une équipe est critique. La raison même d’existence des équipes est que nous ne pouvons pas réussir tout seul; nous avons besoin d’un peu d’aide, nous avons besoin de l’expertise de spécialistes et nous avons besoin des gens pour soulever des montagnes. Cependant, mettez plusieurs personnes dans une même pièce et les défis de communication, de collaboration, de confusion et de conflit adviennent rapidement.
La spécialisation dans Scrum est un sujet chaud depuis de nombreuses années. Les questions sur la spécialisation arrivent quand j’explique aux gens que d’après la définition de Scrum, une équipe doit être cross-fonctionnelle. Je recommande aussi aux membres d’être à 100 % dédiés à une équipe (ne pas être membres de multiples équipes). La plupart des personnes qui sont nouvelles sur Scrum l’acceptent sans considérer les implications. Parfois quelqu’un demandera : « mais alors, que fera la personne des tests au début du Sprint ? »
La Vélocité est une mesure de productivité souvent utilisée dans le développement de logiciel, en particulier avec les méthodes Agile.
PMI a créé une nouvelle liste de questions/réponses sur les certificationsBonjour, je pense que vous trouverez cette page « Certifications FAQs » fort utile si vous vous posez des questions sur les certifications proposées par le Project Management Institute.
Le 4 janvier, ESI International, a révélé ses 10 Premières Tendances Mondiales de Management de projet pour 2011. Des thèmes clefs qui incluent construire l’influence du chef de projet, l’accélération d’un nouveau leadership et des compétences de communication et l’utilisation accrue d’approches d’étude informelles comme des médias sociaux et la formation résultant de l’expérience.
Selon cet article, des bonnes priorités aux salaires plus élevés, le management de projet et les PMOs reçoivent enfin plus qu’un intérêt de pure forme dans beaucoup de sociétés.
ordre du jour de la session de lancement du projetIl est à noter qu’il y a diverses réunions de lancement de projet. Celle à laquelle se réfère cet article est interne à l’équipe projet. Elle a pour objectif principal d’établir les normes, partager la même vision des livrables, comprendre les rôles et responsabilités de chacun, avec un clair focus sur le mode de communication que l’on souhaite utiliser entre membres de cette équipe.
J’ai bien aimé dans cet article les cinq compétences que McKinsey a identifié comme étant au cœur du leadership:
1. trouver et donner une signification dans le travail
2. convertir des émotions telles que le stress et la peur en opportunités
3. savoir tirer partie de ses connections et de sa communauté
4. agir face aux risques
5. soutenir l’énergie qui est la force vive du changement
La réflexion disant que toute personne maîtrisant au moins une de ses compétences double sa capacité à conduire le changement me semble un peu excessive et l’autosatisfaction de ceux qui posséderaient les 5 tout autant. Pourtant….
écrit par Neil Stolovitsky de Genius Inside
Agile fait beaucoup de bruit actuellement dans les milieux de développement de logiciels. La méthode a été créée par des développeurs pour des développeurs. Son origine remonte à 10 ans lorsqu’un groupe de développeurs ont mis en place l’Agile Manifesto dans une station de ski dans l’Utah. Ce manifeste visait à établir pour les projets de développement de logiciels un système plus inclusif, démocratique et efficace. Il en a résulté plusieurs méthodologies Agile dont notamment Crystal Clear, Scrum et Extreme Programming, toutes créées afin de mettre en place des équipes de projet autonomes qui placent la responsabilité dans les mains de chaque personne qui touche le projet.
Ceci est une toute nouvelle approche de gestion des équipes de projet. Les groupes de développement de logiciels doivent être très prudents lorsqu’ils déploient Agile dans leur organisation, car les équipes sont en général habituées à être surveillées et guidées tout au long du projet. En réalité, il y a de nombreux points à considérer avant d’implémenter Agile afin d’être sûr que les changements proposés par Agile soient positifs et non négatifs par rapport au processus existant. Voici les cinq points les plus importants pour vous aider à déterminer si la méthode Agile est la bonne pour vos développeurs:
Une culture trop différente est l’une des raisons principales à l’échec d’un environnement de travail de gestion de projet. Les environnements Agile sont autonomes, ils font face aux clients et sont démocratiques par nature. Tous les groupes de développement cherchant à adopter Agile doivent avant tout se demander si ces principes sont en accord avec la culture et les valeurs de la société ? S’ils sont en complète opposition, les chances de réussite sont minimes. La dernière chose à faire est de démarrer du mauvais pied!
La plupart des environnements de travail en management de projet réussissent simplement avec une bonne adhésion du leadership. Même si la culture de la société est adéquate, Agile nécessite une adhésion complète depuis la base dès le départ. Chaque personne a un rôle à jouer: des clients aux développeurs, étant donné que chaque personne a sa part de responsabilité avec Agile.
Est-ce que votre société est prête pour un changement? Étant donné qu’Agile requiert un changement d’envergure, il est primordial qu’une stratégie de gestion du changement soit en place afin de minimiser les risques et d’assurer une transition en douceur entre l’ancienne et la nouvelle manière de faire les choses.
La méthodologie Agile nécessite une compréhension complète de sa philosophie et de son environnement de travail dès le début. Cette méthodologie nécessite la participation de tous les membres de l’équipe, il est important que chacun connaisse l’ensemble du processus ainsi que sa propre contribution. Toute autre approche risque de faire échouer son implémentation.
La base de l’efficacité des projets Agile est l’effort concerté de mise en place d’un système qui permette une collaboration efficace entre les parties prenantes internes et externes. Vous devez vous non seulement vous demander s’il existe dans votre société une stratégie de communication efficace, mais surtout vous devez être sûr que vos clients seront prêts à s’investir lourdement dans le développement de leurs projets.
Pour en savoir plus au sujet de la méthodologie Agile, regardez ce bref (6′) et récent web cast (ci-dessous en anglais) et livre blanc (en anglais également).
http://www.allaboutagile.com/10-good-reasons-to-do-agile-development/
by Kelly Waters
Voici 10 bonnes raisons d’appliquer les principes et pratiques de développement agiles …
1. RevenusLa nature itérative du développement Agile implique que des fonctionnalités sont livrées de façon incrémentale, ce qui permet de commencer à encaisser des revenus pendant que le produit continue d’être développé.
La recherche suggère qu’environ 80 % de tous les leaders du marché ont été les premiers à commercialiser sur ce marché. En sus d’un revenu plus élevé grâce à une livraison progressive, la philosophie de développement Agile supporte aussi la notion de sorties en avant-première et de versions régulières et les versions « perpétuellement bêta ».
Un principe clé de développement Agile est que les tests sont intégrés tout au long du cycle de vie. Ce qui permet une inspection régulière d’un produit fonctionnel en cours de développement. Cela permet au propriétaire de produit (le « product owner ») de faire des ajustements si nécessaire et donne à l’équipe de produit la primeur de tout problème de qualité.
Les principes de développement Agile encouragent la participation active des utilisateurs tout au long du développement du produit dans une approche collaborative très coopérative. Cela fournit une excellente visibilité aux principales parties prenantes, à la fois sur l’avancement du projet et sur le produit lui-même, ce qui aide à son tour à s’assurer que les attentes sont gérées efficacement.
De petites versions progressives donnent de la visibilité au « product owner » et à l’équipe produit pendant le développement, permettent d’identifier les problèmes au plus tôt et facilitent la réponse à ceux-ci. La visibilité claire dans le développement Agile aide à s’assurer que les décisions nécessaires peuvent être prises le plus tôt possible, pendant qu’il reste du temps pour apporter une différence substantielle sur le résultat.
Dans des projets de développement traditionnels, nous écrivons de grandes spécifications au préalable et disons ensuite aux responsables business combien il est coûteux de changer quoi que ce soit, particulièrement quant le projet avance. Dans la crainte de dérive du contenu et de projet interminable, nous résistons aux changements et faisons passer les personnes par un comité de contrôle des changements pour les réduire au minimum vital. Les principes de développement Agile sont différents. Dans le développement Agile, le changement est accepté. En fait, on s’y attend. Parce qu’une chose certaine dans la vie est le changement. Au lieu de cela la durée est fixe et les exigences apparaissent et se développent comme le produit est développé. Bien sûr, pour que cela fonctionne, il est impératif d’avoir des parties prenantes impliquées qui comprennent ce concept et prennent les décisions de compromis nécessaires, négociant le contenu existant pour un nouveau.
La susdite approche de durées fixes et besoins en évolution permet d’avoir un budget fixe. Le contenu du produit et ses fonctionnalités sont variables, plutôt que le coût.
8. Satisfaction du client/business La participation active d’un représentant des utilisateurs et/ou un propriétaire de produit (« product owner »), la forte visibilité du produit et de l’avancement et la flexibilité de changer quand le changement est nécessaire, créent un bien meilleur engagement du business et la satisfaction du client. C’est un bénéfice important qui peut créer des relations de travail beaucoup plus positives et durables.
Par-dessus tous les autres points, la capacité des besoins de développement Agile à émerger et à évoluer et la capacité d’embrasser le changement (avec le compromis approprié), fait que l’équipe construit le bon produit. Il est trop commun dans des projets plus traditionnels de livrer un projet « réussi » coté informatique et de constater que le produit n’est pas ce à quoi on s’attendait, dont on avait besoin ou que l’on espérait. Dans le développement Agile, l’accent est mis absolument sur la construction du bon produit.
L’engagement actif, la coopération et la collaboration font des équipes de développement agiles un endroit beaucoup plus agréable pour la plupart des personnes. Au lieu de grandes spécifications, nous discutons des besoins dans des ateliers. Au lieu des longs rapports d’avancement, nous collaborons autour d’un tableau des tâches, discutant du progrès. Au lieu des longs plans de projet et des Comités de Gestion de Changement, nous discutons de ce qui est juste pour le produit et le projet et le L’équipe est autorisée à prendre des décisions. Dans mon expérience, cela donne une approche beaucoup plus utile pour chacun. À son tour, cela aide à créer des équipes fortement motivées, à haute performance qui sont fortement coopératives.
Mais il y a des implications. Il n’existe rien de tel qu’un déjeuner à l’œil ! Et il n’y a aucune baguette magique pour le développement logiciel. Désolé, non, cela n’existe pas 🙂 En échange de tous ces avantages, vous obtenez moins de prévisibilité, le logiciel et les personnes restent complexes, vous ne pouvez plus blâmer quelqu’un d’autre si les choses ne se passent pas bien et cela exige généralement beaucoup plus d’engagement et d’effort de chaque personne impliquée – c’est-à-dire que la collaboration est encore plus importante.
Néanmoins, les bénéfices du développement Agile sont vraiment irrésistibles.
Une brève explication des termes les plus fréquemment rencontrés dans le développement en mode Agile.
http://blogs.pmi.org/blog/voices_on_project_management/2011/04/prioritizing-agile-project-req.html
par Bill Krebs
Dans la gestion de projet Agile, nous devons prioriser une liste de demandes pour la planification de version, d’itération et l’insertion de nouveaux besoins ou exigences. Mais il y a plusieurs techniques pour le faire.
Une des méthodes les plus populaires pour déterminer la priorité des demandes est l’approche dite « MoSCoW ». Cela signifie ‘ Must (Doit), Should (Devrait), Could (Pourrait), Won’t (ne fera pas). ‘ Le seul problème avec cette méthode est que d’habitude tout est un Must, ce qui ne permet pas une planification appropriée parce que les besoins ne sont pas nécessairement placés dans leur ordre de priorité.
Une autre méthode est le modèle de Kano, développé par le Professeur Noriaki Kano, qui s’efforce de satisfaire les exigences et de faire plaisir aux clients. Ce modèle dispose de quatre composants :
• Must haves (doit avoir) sont des éléments sans lesquels on ne peut livrer le produit.
• Dissatisfiers (générateurs d’insatisfaction) sont des choses que le produit ne doit pas inclure.
• Satisfiers (générateurs de satisfaction) incluent besoins pour lesquels plus vous en avez mieux le produit sera perçu. Comme un catalogue commercial dans lequel chaque fonctionnalité ajoute progressivement de la valeur.
• Delighters (générateurs de plaisir) amènent le produit plus loin que simplement répondre aux exigences vers l’augmentation de la satisfaction client et la recommandation par le client.
Plusieurs modèles de priorisation réunissent deux variables dans un tableau pondéré : fonctionnalités et clients. Chaque fonctionnalité est pondérée par sa valeur pour chaque client. La somme des poids multipliés par le score permet de voir quelles fonctionnalités sont en général les plus utiles pour un jeu de clients exigeants.
Quel que soit la technique utilisée, votre liste d’exigences de projet doit être triée de la plus grande à la plus faible valeur.
Quelles techniques utilisez-vous pour prioriser les besoins ?
1. PMI has selected PMI-Agile Certified Practitioner (PMI-ACP)SM as the name for the certification.
2. The PMI-ACP certification application is now open and available online at PMI.org.
To stay up-to-date on the PMI Agile Certification, please go to the Agile certification home page. If you have questions that cannot be answered by this information, please contact PMI Customer Care at customercare@pmi.org.
Voici une vidéo qui donne à réfléchir pour tous ceux qui sont actuellement chefs de projet dans le développement logiciel et qui commencent à adopter les méthodes et approches Agiles sur certains de leurs projets.
Lyssa Adkins nous confie quelques pensées radicalement opposées à ce que les chef de projet dans le modèle « en V » ou « en cascade » ont pu apprendre :
Se détacher du résultat, du livrable, pour se focaliser sur comment l’équipe travaille ensembleAu bout du compte, Lyssa mentionne que le coach Agile doit avoir 4 fonctions principales:
Agility and PMIPosted in Scrum par Ken Schwaber
Le Project Management Institute a récemment annoncé son programme d’incorporer l’agilité dans son programme de management de projet. J’accueille ceci bien sûr avec plaisir et attends avec impatience que PMI change de son approche précédente à une approche agile. Le test en sera, bien sûr, le succès des projets qui adhèrent à ses principes. Dans le passé, le succès de leur approche prédictive a été moins de 50 % de projets (à l’heure, sur la date, avec la fonctionnalité souhaitée). La plupart des méthodes agiles ont un taux de réussite beaucoup plus élevé, y compris le succès à arrêter très tôt des projets à faible retour sur investissement. Nous observerons et verrons si ceux qui emploient l’approche agile du PMI bénéficient de tels succès, ou au moins d’une amélioration du seuil des 50% 1,2,3.
Dans le passé, PMI a embrassé l’approche prédictive, mécanique du management de projet. Cela a été d’abord soutenu par Frederick Taylor dans “Principles of Scientific Management”, qui était la base de la chaîne de montage des Ford Model T. C’est une approche pour une fabrication prévisible, en grand volume et bon marché. Ses bénéfices s’obtiennent en éliminant toute imprévisibilité de l’espace des problèmes à travers la standardisation et la répétition. La planification parfaite, la formation et la répétabilité sont les recettes. Planifiez et répétez ensuite à maintes reprises. La mesure de succès est le taux de rendement, qui est souvent très proche de 100 %. La productivité est optimisée par des processus parfaits, un « workflow » invariable et l’utilisation optimisée des ressources (les personnes ou les machines).
Des processus agiles, travaillent en revanche au développement de produits complexes, où il y a une certaine répétabilité, mais il y a davantage de développement nouveau que d’ancien. Les produits doivent être inventés à nouveau à chaque fois avec les changements des besoins, les techniques et les capacités et la créativité des personnes. Dans ces situations, nous avons constaté que la planification à flux tendu, avec inspection fréquente et adaptation est exigée. Les risques sont managés et la prévisibilité créée en limitant la période de temps entre les événements de planification et en assurant la transparence de tous les artefacts. Nous avons aussi trouvé que la productivité, la qualité et la créativité sont énormément accrues si les personnes réalisant le travail planifient aussi leur propre travail. Elles ne sont pas gérées comme des ressources, mais comme des personnes qui peuvent faire de leur mieux quand elles comprennent comment faire le travail par elles-mêmes. L’auto-organisation et la transversalité fonctionnelle sont essentielles au succès de ces équipes.
Nous avons constaté que le rôle du chef de projet est contre-productif dans un travail complexe et créatif. La ligne de pensée du chef de projet, comme représenté par le plan de projet, contraint la créativité et l’intelligence de tous sur le projet à celle du plan, plutôt que d’engager l’intelligence de chacun au mieux afin de résoudre les problèmes.
Dans Scrum, nous avons supprimé le chef de projet. Le Propriétaire de Produit, ou le client, fournissent la planification à flux tendu en disant à l’équipe de développement ce qui est nécessaire, aussi fréquemment que chaque mois. L’équipe de développement se gère, fournissant autant de ce que veut le propriétaire de produit en produit utilisable que possible. Le résultat est la haute productivité, la créativité et l’engagement des clients.
Nous avons remplacé le chef de projet par le Scrum Master, qui gère le processus et aide le projet et l’organisation à passer aux pratiques agiles.
Comment PMI va combler la différence profonde dans la philosophie, la pensée, le leadership et le management entre son approche prédictive traditionnelle et la nouvelle approche empirique agile sera fascinant à observer. Comment PMI remodèlera le rôle de chef de projet sera un exercice d’agilité en lui-même. Personnellement, je souhaite le meilleur aux gens de PMI. Ils ont certainement besoin d’un meilleur taux de réussites que 50% pour regagner la confiance de leurs clients.
1. Tiré de “The Rise and Fall of the Chaos Report Figures”, janvier/février 2010 IEEE Software, J. Laurenz Eveleens et Chris Verhoef, Vrije Universiteit Amsterdam.
2. 2009/2010 Standish Chaos Report, Standish Group, indique :
3. En plus d’un taux de rendement bas (le taux de livraisons réussies), les statistiques indiquent aussi que plus de 60 % des fonctionnalités livrées ne seront que rarement ou jamais utilisées, une perte énorme de budget de support et de développement. Résultat de la non priorisation des besoins. http://en.wikipedia.org/wiki/Software_bloat, “Embonpoint Logiciel”.
PMI a publié le document que vous obtiendrez en cliquant sur l’image ci-contre pour nous fournir davantage de détails sur la Certification Agile. Les inscriptions débutent en mai pour les premières sessions d’examen en Septembre.
Vous y découvrirez notamment que l’examen consistera en 100 questions dont la moitié sur les outils et techniques Agiles et la seconde partie sur les compétences et connaissances Agile.
Coté outils et techniques, les aspects suivants seront couverts: Communications, Estimations, Planification, Suivi et Amélioration continue, Analyse et Design, Qualité et Tests, Compétences relationnelles, Priorisation, Management des risques, mesures et indicateurs, anamyse de la valeur.
Les compétences et connaissances sont organisés en domaines qui sont eux mêmes triés par niveau d’importance sur les projets agiles.
PMI nous propose également quelques pointeurs vers des documents et publications utiles pour préparer cet examen.
Une page dédiée sur le site PMI contient de nombreuses réponses aux questions que vous vous posez peut-être sur Agile.
La définition des « bonnes » estimations sur un projet est un savant mélange d’expérience, d’échanges entre experts, de comparaison par analogies, de calculs… Le Planning Poker est l’un des outils de la méthode Scrum qui permet à une équipe lors d’une réunion de planification de donner des estimations pour le développement d’une fonctionnalité.
Lors de la réunion, le product owner (directeur de produit), qui représente comme toujours le client, définit les priorités de développement des nouvelles fonctionnalités du produit logiciel. L’équipe projet doit donner des estimations d’efforts au product owner afin que celui-ci comprenne ce que va coûter chaque nouvelle fonctionnalité. Et c’est là qu’intervient le Planning Poker. Pour jouer au planning poker, l’équipe doit donc avoir la liste de fonctionnalités à livrer (le product backlog) et un jeu de cartes de planning poker.
Dans ce jeu de carte, au lieu de porter des valeurs entre le 2 et l’as, les cartes portent des valeurs qui sont plus pertinentes à l’évaluation de durée de tâches. Typiquement ces valeurs sont : 0, ½, 1, 2, 3, 5, 10, 20, 50, 100. Ces valeurs correspondent au nombre de jours qu’une fonctionnalité donnée prendrait à être développée.
La session de planning poker est habituellement facilitée par un modérateur qui est souvent le ScrumMaster ou bien le coach Agile de l’équipe, les participants sont donc le « product owner » et l’équipe de développement.
1. Le modérateur lit la description de l’histoire utilisateur (« user story ») ou fonctionnalité que l’équipe doit estimer. Le product owner peut fournir des clarifications sur la fonctionnalité. Chaque expert est doté d’un jeu de cartes.
2. Chaque expert choisit une carte dans son jeu qui correspond à son estimation initiale de l’effort de développement. Chaque expert pose sa carte à l’envers sur la table pour ne pas influencer les autres experts.
3. Quand toutes les évaluations sont sur la table, les cartes sont retournées.
4. S’il y a une palette très large entre les estimations, les experts qui ont suggéré les plus fortes et plus basses évaluations fournissent le raisonnement qui les a amené à ces valeurs.
5. Une fois que la discussion sur la palette d’estimations a été conduite, les étapes 2 à 4 sont répétées jusqu’à ce qu’un consensus soit atteint.
L’avantage principal du planning poker est d’encourager une discussion ouverte sur les estimations. Cela aide l’équipe à atteindre une proposition plus précise au lieu de compter sur l’avis d’un membre de l’équipe plus influent ou plus vocal que les autres. Cela permet aussi à l’équipe de bénéficier de l’expérience de tous les membres de l’équipe.
Les cartes de planning poker peuvent être créées à partir de zéro. Ce lien vous permettra d’imprimer vos propres cartes de planning poker: http://www.sprintplanning.com/planningpoker_cards_1.gif et celui-ci de jouer en ligne: Http://www.planningpoker.com/
Voici une brève vidéo qui explique comment est née cette méthode.
Check out the document entitled « Metrics for Agile Projects: Finding the Right Tools for the Job » on the ESI Website.It holds an interesting high level comparison of the metrics and tools available for PMs to track progress and communicate on it: Gantt charts, WBS, Burn Down Charts… It also gives a few hints on how to interpret these as they are quite different from the metrics of waterfall approaches.
Apprenez comment la Certification Agile PMI peut vous y aider.
Agile est un sujet d’importance croissante dans le management de projet. Le marché dénote cette tendance comme les pratiquants en management de projet embrassent Agile comme une technique pour gérer avec succès des projets.
À cause de ces changements dans l’environnement de management de projet, PMI développe une certification Agile.
Les leaders qui utilisent des techniques Agiles dans le management de projet ont conseillé PMI sur la meilleure façon de proposer une certification Agile pour servir des membres de projet et les organisations pour lesquelles ils travaillent.
PMI questionne régulièrement les chefs de projet pour mieux comprendre comment ils pratiquent le management de projet. Une statistique majeure qui est sortie de notre dernière enquête professionnelle est des pratiques standardisées de gestion de projet aboutissent à de meilleures performances de projet. Une des pratiques que PMI a surveillées depuis plusieurs dernières années est la croissance ininterrompue et de l’utilisation des pratiques Agiles dans le management de projet. Beaucoup de PMs ont ajouté Agile à leur « boîte à outils de management de projet » et l’utilisent comme une parmi de nombreuses de techniques de management de projets.
De plus, les organisations qui utilisent le management de projet pour servir leurs clients tant internes qu’externes voient de la valeur dans des méthodes Agiles pour livrer des projets à leurs clients plus rapidement. En conséquence, plus d’organisations et de bureaux de projet (PMOs) demandent à leurs chefs de projet d’appliquer des techniques Agiles. La recherche PMI a révélé que 68 % des organisations utilisant des pratiques Agiles verraient de la valeur dans une certification Agile pour des managers de projet. De plus, 63 % des recruteurs encourageraient leurs chefs de projet à passer une certification Agile.
Les chefs de projet qui utilisent des pratiques Agiles dans leurs projets, ou dont les organisations adoptent Les approches Agile dans le management de projet sont de bons candidats à la Certification Agile PMI.
Lisez les conditions d’admissibilité
PMI sert la profession de management de projet en fournissant les chefs de projet avec une sélection d’outils de techniques — et Agile est l’un de ceux-ci. Par exemple, ceux qui ont la certification PMP® et travaillent dans une organisation qui utilise des techniques Agiles, trouveront dans la Certification Agile une base de connaissances applicable des principes et des concepts Agiles.
Le pilote de Certification Agile PMI est ouvert au public et à tout pratiquant du management de projet qui réunit les pré-requis d’admissibilité. PMI cherche actuellement des candidats pour ce pilote et ils pourront s’inscrire en ligne ou sur papier pour la certification à partir de mai 2011. L’examen de Certification Agile PMI débutera pendant le troisième trimestre de 2011. Pour en savoir davantage sur ce pilote, lisez le Document de FAQS (FOIRE AUX QUESTIONS) sur la Certification Agile.
Pour recevoir des nouvelles de ce Pilote de Certification Agile PMI, envoyez un message en anglais à AgilePilot@PMI.org
DantotsuPM.com 
