Beaucoup de personnes demandent si le PMI lancera un Corpus des connaissances Agile PMI. La réponse est « Non ». D’une part, il serait presque impossible de se mettre d’accord sur ce qui y entrerait, particulièrement en considérant le désaccord sur ce qui constitue une déclaration officielle sur les structures Agile elles-mêmes (par exemple. Scrum, XP, Kanban). D’autre part, nombreux sont ceux qui pensent qu’un standard officiel Agile serait trop restrictif et irait même à l’encontre de l’intention « adaptative et itérative » du mouvement Agile. Cependant, un Corpus des connaissances Agile PMI n’est pas la seule façon d’avancer. À la place, il y a deux projets passionnants en voie de réalisation qui promettent une nouvelle avancée des techniques Agiles dans la communauté PMI.
D’abord, la 5ème Édition du Guide PMBOK est en revue publique. Pour la première fois dans l’histoire du PMBOK, les termes « le développement progressif itératif » et « Agile » sont explicitement définis.
Deuxièmement, PMI collabore avec l’IEEE pour développer « l’Extension Logicielle au Guide de PMBOK » (the « Software Extension to the PMBOK Guide »). Comme pour les extensions aux domaines de la Construction et des organisations Gouvernementales réalisées auparavant, l’Extension Logicielle fournira des outils et des techniques pour implémenter le Guide de PMBOK dans un environnement spécifique au développement logiciel. Étant donné qu’Agile est devenu une approche dominante pour les projets logiciels, ce document donnera des détails sur les approches « itératives-incrémentales » et « Agiles » brièvement mentionnées dans le nouveau Guide PMBOK. Aussi, vers le troisième trimestre de cette année, PMI vous donnera l’occasion de soumettre votre propre retour d’information sur ce document. Pour plus d’informations, vous pouvez lire un billet de blog de Mike Griffiths qui est membre de ce comité: http://leadinganswers.typepad.com/leading_answers/2011/09/the-new-software-extension-to-the-pmbok-guide.html
Bien qu’il n’y aura pas de Corpus des connaissances Agile PMI officiel dans un avenir proche, ces deux projets fourniront beaucoup de valeur à ceux qui les attendent avec impatience.
Et n’oubliez pas que Agile tient davantage de la philosophie que de la méthode et peut donc être appliquée à bien d’autres domaines que le développement logiciel. Dans cette vidéo, Joe Justice applique les principes Agile qu’il a embrassés dans le développement logiciel à la construction automobile et crée ainsi une nouvelle voiture à la fois performante et efficiente en un temps record.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Lors d’une session organisée par Eurogiciel, un groupe d’une vingtaine de chefs de projet et développeurs ont pu mieux appréhender les méthodes Agile grâce à une approche ludique et fort éducative. Cette session de travail de 3 heures commença par une introduction des concepts Agile par Yves Schneider et Fabien Massol.
Les principes de base de Scrum :
Adaptatif vs. déterministe
Temps limité : création d’un planning détaillé impossible dans le temps imparti
Nécessité de démarrer l’activité au plus vite pour montrer un résultat
Planification limitée à l’itération en cours
Souplesse et stabilité
Le Product Owner peut changer le Contenu comme il le souhaite sauf celui de l’itération en cours
L’équipe a un objectif figé pour l’itération en cours
Inspection et adaptation
Augmente les chances d’atteindre l’objectif dans un environnement empirique
Amélioration continue en cours de projet
Itératif et timeboxé
Équipe autogérée
Transparence
Un rappel des rôles clés:
1. Le Product Owner
Définit les fonctionnalités du produit
Est responsable de l’ordonnancement des fonctionnalités du produit
S’assure que l’équipe va travailler sur les fonctionnalités à plus forte valeur ajoutée
Maintient le Product Backlog
2. Le Scrum Master
Est garant des règles de fonctionnement
Protège l’équipe des interférences extérieures
Est garant de la stabilité du sprint en cours
Supprime les obstacles
Conduit les réunions
Est responsable du « temps »
3. La Scrum Team
S’engage sur une itération
Définit les tâches et les assignations
Est auto-organisée et autogérée
Implémente les fonctionnalités
Petit rappel des réunions et des objets :
a. Sprint Planning Meeting
L’équipe clarifie les exigences des entrées prioritaires du Product Backlog
L’équipe sélectionne les entrées prioritaires du Product Backlog sur lesquelles elle s’engage pour le Sprint
L’équipe définit son Sprint Backlog (todo list du Sprint)
b. Sprint Review
L’équipe présente le résultat au Product Owner
Le Product Owner accepte ou pas le résultat
c. Sprint Rétrospective
Qu’est-ce qui s’est bien passé ?
Qu’est-ce qui peut être amélioré ?
d. Product backlog
Liste des fonctionnalités désirées
Ordonnancé
N’importe qui peut ajouter des entrées à tout instant
Chaque entrée doit avoir une valeur métier
e. Sprint backlog
Todo list du sprint
Créé par l’équipe
À partir des fonctionnalités définies comme les plus importantes par le Product Owner
f. Task board
Visible
Objectif du sprint
Contient les activités du sprint
Activités à réaliser, en cours, et faites
Points de blocage
Les dominos !
Puis commença la partie pratique pour les participants répartis en équipes de 5 personnes avec 1 Product Owner, 1 Scrum Master et 3 membres.
Sprint zéro
À partir de la priorisation par le product owner d’une série de figures à réaliser comportant des nombres variables de dominos et divers degrés de difficulté. Chaque figure (besoin du client) rapportera un certain nombre de points à l’équipe fonction de sa valeur pour le client. Le Scrum Master aida les membres de l’équipe à comprendre le Product Backlog avec le Product Owner. Puis vint la détermination de l’objectif collectif que l’équipe allait décider de se donner pour un premier sprint. Les membres de l’équipe Scrum sélectionnèrent certains items de la liste de besoins (le Product Backlog) qui seraient embarqués sur ce Sprint zéro. Puis, les 3 équipiers se répartirent le travail à réaliser et bossèrent pour une durée prédéterminée (celle du Sprint) afin d’atteindre les objectifs agréés : Analyse, construction/réalisation et tests devaient être compris et intégrés dans le cycle de temps imposé pour le Sprint. À la fin du Sprint se tint une rétrospective pour voir ce qui avait bien et moins bien fonctionné pui tests d’acceptation du livrable par le client !
Un nombre de points atteints pour ce Sprint pu alors être facilement calculé pour chaque équipe, mettant en évidence les écarts entre les ambitions de chacune et le réalisé.
Sprint 1
Puis, un deuxième Sprint fut organisé dans la foulée avec les mêmes équipes qui commençaient déjà à mieux appréhender la difficulté de réalisation des besoins exprimés. Besoins qui bien sûr avaient évolués depuis le Sprint zéro.
Un enseignement qui devint rapidement très visible pour les participants est que l’équipe avait non seulement gagné une meilleure appréciation de la difficulté technique, mais aussi des compétences de chacun des membres de l’équipe, de la vitesse d’exécution, des procédures de sécurité et de tests à mettre en place… Bien que novices dans la méthode, les bénéfices étaient évidents.
Et d’ailleurs nos résultats le prouvèrent lors de ce second Sprint où nous atteignirent parfaitement les objectifs que nous nous étions fixés tout en respectant les délais.
Et, enseignement supplémentaire de cette seconde rétrospective : notre vélocité ayant crû, nous aurions pu être plus agressifs. À envisager pour les sprints suivants…
…mais c’était déjà la fin de cette belle introduction pratique à Scrum.
Merci beaucoup aux coaches et membres d’Eurogiciel qui nous recevaient et à Muriel Janel, directrice de l’agence de Sophia Antipolis, pour son invitation et la qualité de cette session. Muriel répondra comme toujours à vos demandes d’information avec plaisir, en particulier si vous souhaitez bénéficier de l’expérience de ses équipes pour appréhender et développer votre agilité.
J’invite les autres participants à cette session ou autres exercices similaires à poster leurs commentaires à ce billet.
partagez ce billet avec vos amis, collègues et relations professionnelles
Scrum.org et Scrum Inc. ont annoncé en Octobre dernier un modèle formel pour modifier et étendre Scrum. Les créateurs de Scrum, Jeff Sutherland et Ken Schwaber, invitent les pratiquants du monde entier à contribuer à l’avenir de Scrum.
Scrum a été créé il y a plus de 15 ans et développé et adapté depuis. En se basant sur leurs expériences et de celles de la communauté Scrum, Jeff et Ken ont soigneusement codifié la structure dans le « Scrum Guide », qui documente les règles de base, les artefacts et les événements de Scrum.
Cette annonce marque une nouvelle ère dans l’évolution de Scrum en donnant un mécanisme à tous de fournir un retour d’information sur le Guide Scrum et un modèle pour proposer des extensions à la structure de base.
Le processus formel pour proposer et intégrer des changements dans Scrum est disponible en ligne sur Scrum.org. Pour en apprendre davantage sur Scrum ou soumettre votre propre contribution à Scrum, vous pouvez utiliser les liens suivants :
Lyssa Adkins est une chef de projet expérimentée, certifiée PMP, qui a mené des projets pendant 15 ans de manière « traditionnelle », basée sur les plans et l’exécution rigoureuse de ces plans avant de découvrir l’approche Agile.
Selon son expérience, certaines choses dans notre environnement de travail sont aussi immuables que la loi de la gravité dans notre environnement physique :
Les besoins des clients changent
Ce que l’équipe est capable de faire n’est connue que d’elle-même et cette capacité évolue avec le temps.
L’environnement du projet évolue de manière imprévisible.
Il est impossible de prendre des engagements pour une autre personne et de s’attendre raisonnablement à ce que cette personne les respecte.
Hors, le problème est que la méthode traditionnelle de conduite de projet par la planification lutte en permanence contre ces lois naturelles alors que l’approche pratique d’Agile s’en accommode et en fait même une partie intégrante de la méthode.
Alors, comment adapter certains des principes fondamentaux de l’approche par les plans de la plupart des chefs de projet pour qu’ils puissent utiliser la réalité au lieu de la combattre ?
partagez ce billet avec vos amis, collègues et relations professionnelles
Félicitations aux premiers PMI Agile Certified Practitioner (PMI-ACP) !
La Certification PMI-ACP a été lancée en mai et maintenant un premier contingent de plus de 500 professionnels détient la certification PMI-ACP après avoir réussi l’examen.
Ces personnes se sont inscrites et ont étudié pour obtenir la certification et ont passé et réussi l’examen. Elles sont maintenant les premières à devenir professionnellement certifiées et reconnues pour leur connaissance des principes agiles, des pratiques et des outils et des techniques à travers les méthodologies agiles. Elles proviennent de toutes les régions du monde.
Agile est une philosophie qui utilise des modèles organisationnels basés sur les personnes, la collaboration et des valeurs partagées. Elle utilise la planification récurrente; la livraison itérative et progressive; la réponse rapide et flexible aux changements; et une communication ouverte entre équipes, parties prenantes et clients.
L’utilisation d’Agile comme une approche au management de projets a augmenté radicalement dans les dernières années.
Gartner prévoit que vers la fin 2012, des méthodes de développement agiles seront utilisées sur 80 pour cent de tous les projets de développement logiciels.
La recherche du PMI a montré que l’utilisation d’Agile a triplé entre décembre 2008 et mai 2011.
La certification PMI-ACP reconnaît et valide votre connaissance des pratiques et des techniques agiles tout en démontrant votre compréhension de concepts généraux de management de projet.
Rafael Prikladnicki, PhD, PMI-ACP, PMP, Directeur Recherche et Développement et Professeur d’Informatique au Brésil, est dans le premier groupe à avoir réussi la certification. « À cause de mon engagement avec des approches agiles depuis 2002, j’ai décidé d’essayer le PMI-ACP, » a dit Dr Prikladnicki. « De plus, j’ai pensé qu’était important de contribuer au pilote de cette nouvelle certification ». Dr Prikladnick gère actuellement des projets de R&D et d’innovation dans son Université en utilisant des approches agiles. Il utilise aussi des approches agiles dans des projets de génie logiciel. « J’utilise des approches agiles pour superviser mes étudiants et doctorants » a-t-il dit. « Une thèse de maîtrise ou de doctorat sont de la recherche qui implique innovation, flexibilité, adaptation et incertitude. C’est pourquoi des approches agiles semblent tout à fait convenir pour gérer ces sortes de projets et mon expérience a été positive jusqu’ici ».
Edgar Green, PMI-ACP, PMP, un cadre supérieur dans l’informatique impliqué dans le développement logiciel pour le transport aérien, en Floride, est aussi dans ce premier groupe à avoir gagné la nouvelle certification. Il a dit qu’il a voulu la certification pour prouver sa compréhension des pratiques généralement admises et se différencier des autres chefs de projet. « Dans ce marché de l’emploi compétitif, ces certifications peuvent aider à sortir du lot« . Les employeurs ont confiance dans les détenteurs de certifications PMI car ils possédent des compétences, la connaissance et l’expérience qui contribue directement au succès des projets et des résultats business.
En réalisant une évaluation de Agile, l’autre jour, j’ai pris place dans une réunion de planification de sprint. Bien que nombreux soient projets Agile qui en aient au début de chaque sprint, obtiennent-ils le meilleur du temps et des efforts investis ? En tant que partie intégrante du service fourni à mon client, je lui fournirai une petite antisèche pour la planification de sprint. Ce sera à la fois un guide et un ordre du jour, pour les aider à rester concentrés.
Qu’est-ce que la planification de Sprint (d’itération) ?
Le but de la réunion de planification de sprint est pour que l’équipe s’accorde à compléter un ensemble d’articles de plus forte valeur du «product backlog» (l’arriéré de produit ou liste des articles demandés pour un produit). Cet accord définit le contenu du sprint et est basé sur la vélocité ou la capacité de l’équipe et la longueur du sprint qui est limité dans le temps.
Qui le fait ?
La planification de sprint est un effort collaboratif impliquant :
ScrumMaster – Facilite la réunion
Propriétaire de Produit (Product Owner) – Présente le détail des items du product backlog et leurs critères d’acceptation
Équipe Agile – Définit les tâches et l’effort nécessaire pour accomplir l’engagement
Avant que vous ne commenciez
Avant de commencer nous ne devons assurer que :
Les items dans le product backlog ont été estimés par l’équipe qui leur a assigné une valeur de points d’histoire relative
Le product backlog est trié pour refléter les priorités du Product Owner
Il y a une compréhension générale des critères d’acceptation pour ces items
Les Backlogs
Le product backlog peut adresser aussi bien une nouvelle fonction que des corrections à une fonctionnalité existante. Pour la planification de sprint, les items du product backlog doivent être assez petits pour être achevés dans le sprint et que l’on puisse vérifier qu’ils ont été implémentés correctement. Cette liste d’item du product backlog deviendra le sprint backlog.
Bien calibrer les items du backlog
Les items de product backlog trop grands pour être complétés dans un sprint doivent être divisés en morceaux plus petits. La meilleure façon de les diviser est de se baser sur leur valeur et non pas sur le processus.
Plan basé sur la capacité
Des équipes matures peuvent utiliser la vélocité pour déterminer sur quels items du product backlog s’engager pour le sprint. Des équipes récentes ne peuvent pas connaître leur vélocité ou celle-ci peut ne pas être suffisamment stable pour l’utiliser comme une base de calcul dans la planification du sprint. Une approche pour de nouvelles équipes est de prendre des engagements basés sur la capacité de l’équipe.
Détermination de la capacité
La capacité d’une équipe est tirée de trois mesures simples pour chaque membre de l’équipe :
Nombre d’heures idéales dans un jour ouvrable
Nombre de jours pendant le sprint où la personne sera disponible
Le pourcentage de temps que la personne dédiera à cette équipe
Les étapes de planification
Le Product Owner décrit l’item du product backlog de plus forte valeur
L’équipe détermine les tâches nécessaires de compléter cet item du product baclog
Les membres de l’équipe se portent volontaire pour être propriétaire de certaines tâches
Les propriétaires de tâche évaluent les heures dont ils ont idéalement besoin pour réaliser leur tâche
La planification continue tant que l’équipe peut s’engager à délivrer sans excéder sa capacité
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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 « backlog » priorisé !
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.
Valeur Pilotée par le client
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
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 Valeur
Un 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 conclure
Les 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.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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”.
« Scrum est en amélioration permanente, pourquoi cette version serait-elle différente des autres? »
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.
Microsoft est partenaire de DantotsuPM
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Plusieurs articles sur les compétences et attitudes ont également été appréciés par les lecteurs.
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 ?
Les 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 ? »
Bonjour, 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.
Il 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….
partagez ce billet avec vos amis, collègues et relations professionnelles
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:
1) Culture adéquate
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!
2) Adhésion
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.
3) Management du changement
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.
4) Formation
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.
5) Collaboration
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).
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Voici 10 bonnes raisons d’appliquer les principes et pratiques de développement agiles …
1. Revenus
La 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é.
2. Vitesse de commercialisation
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 ».
3. Qualité
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é.
4. Visibilité
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.
5. Management des risques
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.
6. Flexibilité / Agilité
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.
7. Contrôle des dépenses
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.
9. Le bon produit
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.
10. Plus agréable !
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.
Les implications d’embrasser des principes de développement Agile
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.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Beaucoup de personnes demandent si le PMI lancera un Corpus des connaissances Agile PMI. La réponse est « Non ». D’une part, il serait presque impossible de se mettre d’accord sur ce qui y entrerait, particulièrement en considérant le désaccord sur ce qui constitue une déclaration officielle sur les structures Agile elles-mêmes (par exemple. Scrum, XP, Kanban). D’autre part, nombreux sont ceux qui pensent qu’un standard officiel Agile serait trop restrictif et irait même à l’encontre de l’intention « adaptative et itérative » du mouvement Agile. Cependant, un Corpus des connaissances Agile PMI n’est pas la seule façon d’avancer. À la place, il y a deux projets passionnants en voie de réalisation qui promettent une nouvelle avancée des techniques Agiles dans la communauté PMI.
DantotsuPM.com 