Avez-vous jamais entendu ou prononcé l’une de ces expressions ?
Nous allons implémenter la méthodologie Scrum.
Nous appliquons un Scrum modifié.
Nos développeurs utilisent un processus Scrum.
Ces déclarations peuvent sembler inoffensives mais elles sont les indicateurs d’interprétation erronée potentielle de comment Scrum est le mieux utilisé. Scrum n’est pas un processus de développement complet (bien que presque quoi que ce soit qui a des étapes puisse être considéré comme un processus) et ce n’est pas une méthodologie. Scrum ne vous dit pas comment implémenter le logiciel. C’est une structure simple qui aidera un groupe qui développe des produits à comprendre ce qui ne fonctionne pas bien et comment y remédier.
Voici le diagramme du Modèle Scrum
La Structure de Scrum
Au début, les personnes et équipes implémentant Scrum se concentrent sur le processus sans comprendre pourquoi et comment réaliser chaque partie efficacement. Nous croyons que nous « ferons du Scrum » et en gagnerons tous les bénéfices, simplement :
En maintenant d’une liste de travail à faire (l’Arriéré de Produit)
En l’assignant à l’équipe pendant une réunion de Planification de Sprint
En réalisant ce travail pendant la durée du Sprint
Ce focus sur comment passer à travers les étapes peut être dangereux et irritant pour les individus, équipes et managers. Scrum n’est pas UNE SOLUTION MIRACLE! Aucun processus, pratiques, ou des techniques ne le sont. Au lieu de vous concentrer sur le processus, les pratiques et les techniques de Scrum, je suggère aux personnes, équipes et au management de se concentrer sur les enseignements qui peuvent être produits par une équipe faisant du Scrum et agir sur ceux-ci.
Scrum est un processus empirique de contrôle. L’idée est que vous planifiez et réalisez ensuite quelque chose, inspectez ce que vous avez fait et adaptez ensuite votre comportement pour vous améliorer. C’est une structure apprenante pour des équipes de développement de produits. On se réfère à ce cycle d’étude comme « inspecter et s’adapter ». Les 3 rôles de Scrum sont impliqués dans cet apprentissage : le Propriétaire de Produit, le ScrumMaster et les Développeurs (quand je dis Développeurs je veux dire toute personne dont on a besoin pour construire le produit, pas seulement des programmeurs).
Dans Scrum, Il y a 3 cycles spécifiques « Inspecter et Adapter » :
La rencontre Scrum Quotidienne (Daily Scrum) permet à l’équipe de se concentrer sur ses engagements pour le Sprint actuel et vérifier s’ils sont toujours en piste pour livrer par rapport à cet engagement. S’ils ne peuvent pas respecter l’engagement, alors on leur demande d’ajuster le Sprint, s’adaptant ainsi à la situation.
La réunion de Revue de Sprint (Sprint Review) permet aux clients de voir un incrément de produit potentiellement utilisable créé par l’Équipe et de leur fournir un retour d’information qui ajuste le contenu de l’Arriéré de Produit et les priorités. Nous inspectons le produit et nous nous adaptons à une nouvelle compréhension du produit.
La Rétrospective de Sprint permet à l’Équipe d’améliorer le processus qu’ils utilisent pour délivrer du logiciel à chaque Sprint. On s’attend à ce que l’équipe inspecte son processus honnêtement et à fond pour comprendre comment ils peuvent s’adapter pour que leur capacité collective de livraison soit améliorée dans le prochain Sprint.
Si vous lisez souvent mon blog, vous pourriez reconnaître ici un billet précédent appelé « Kaizen Mentalité » qui contient de bonnes informations sur la façon d’utiliser les leçons apprises et gérez les obstacles autour de celles-ci.
Partenaire de DantotsuPM
Scrum est plus un outil qu’une méthodologie.
Scrum rendra visible ce qui ne va pas aussi bien qu’il pourrait être. C’est alors aux personnes dans l’équipe et l’organisation e faire des changements pour s’améliorer. Avec chaque amélioration progressive, l’équipe de développement accomplira beaucoup plus efficacement son travail. Plutôt que de vous concentrer sur atteindre la perfection sur chaque étape dans la structure de Scrum, découvrez ce qui peut être amélioré dans votre processus de livraison et adaptez-le en conséquence. Si une partie de la structure de Scrum est difficile à faire ou semble être une perte de temps alors, au lieu d’éliminer cette partie, découvrez pourquoi c’est difficile ou gaspilleur dans son adoption. Il y a d’habitude un obstacle caché derrière ces difficultés et perceptions qui si il est éliminé permettra à l’équipe de développement de produits d’être plus efficace.
Scrum n’est pas une destination.
C’est plutôt un outil qu’une équipe de développement de produits utilise pour continuellement inspecter et adapter leur façon de délivrer pour la rendre plus effective. La destination devrait être votre business et vos objectifs d’efficacité d’équipe de développement. Comment pouvons-nous livrer davantage ? Comment pouvons-nous réduire le temps entre le commencement et la livraison du projet? Comment pouvons-nous délivrer plus souvent à plus bas coût pour stabiliser les sorties de produits ? Comment pouvons-nous réduire le risque dans notre processus de livraison de projet et dans notre portefeuille de projets ?
La destination devrait être substantielle et attractive. Scrum est seulement le véhicule pour vous aider à vous y rendre.
partagez ce billet avec vos amis, collègues et relations professionnelles
La méthode de gestion de projets PRINCE2 grandit en popularité dans le monde entier. Cependant, un nouveau challenger, Agile, est apparu. Nous commençons à entendre ici et là le débat « PRINCE2 ou Agile » ? C’est une question intéressante, mais souvent c’est une façon erronée de poser le problème.
En effet, lorsque vous commencez un projet de décoration d’intérieur, vous ne vous demandez pas si vous allez utiliser le marteau ou le tournevis ? Il est probable que vous aurez besoin des deux. Ce qui importe est de savoir quand utiliser quel outil et de savoir utiliser chaque outil correctement.
La même chose s’applique à PRINCE2 et Agile. Une organisation mature dispose des deux méthodes dans sa boîte à outils, et de manière habile utilisera l’outil approprié au bon moment.
Donc si nous avons besoin de PRINCE2 et Agile, comment comparer les deux outils ?
Tout d’abord comparons ce qui est comparable, le point de départ est donc de trouver l’Agile qui convient. En effet, Il y a beaucoup de variantes d’Agile, comme ces variantes légères que sont SCRUM et XP. Ces variantes légères ne sont pas des méthodes de gestion de projets de grande envergure, elles sont utilisées par les équipes afin de gérer des parties de projets, surtout la partie informatique. Un concurrent de poids à PRINCE2 est ATERN Agile (aussi connu sous le nom DSDM).
Partenaire de DantotsuPM
PRINCE2 et Agile-ATERN sont des méthodes de gestion de projets à part entière. Les deux sont des méthodes globales. Les deux sont des méthodes « clé en main » axées sur la rentabilité, le contrôle, la qualité, et ainsi de suite.
Laquelle choisir ?
PRINCE2 est le choix le plus approprié pour les projets basés sur les spécifications
ATERN Agile est le meilleur choix pour les projets de découverte
ATERN Agile est fantastique pour les projets avec des dates butoir serrées
Le type de projet va influencer le choix de votre méthode :
Basés sur les spécifications signifie que vous commencez avec un document écrit (et probablement avec un contrat) ;
Les projets de découverte eux ont seulement besoin des éléments essentiels pour démarrer ;
Les projets avec des fortes contraintes de délai doivent absolument être livrés à temps.
Mais il n’est pas toujours nécessaire de choisir entre l’une ou l’autre des méthodes. Puisqu’ATERN a intégré des idées de PRINCE2, alors vous pouvez aussi rendre PRINCE2 plus Agile.
Voici quelques façons de rendre un projet PRINCE2 plus Agile :
Utiliser votre première séquence pour construire un prototype avec des fonctionnalités limitées afin de simuler la vraie solution ;
Utiliser ensuite une séquence pilote avec un déploiement limité qui vise à développer quelque chose qui marche et est utilisable dans l’usage quotidien ;
Utiliser les « timebox » (zéro tolérance de temps pour une séquence, mais une haute tolérance de périmètre – si vous êtes en retard, réduisez le périmètre) ;
Débuter votre journée par des réunions debout (chef de projet plus les chefs d’équipe) ;
Utiliser le concept de « suffisamment de conception en amont » (EDUF : Enough Design Up Front) et non pas le concept de « Massive Conception en Amont » (BDUF : Big Design Up Front) en finalisant vos descriptions de produit à la limite de séquence (au lieu du DIP) ;
Pour un lot de travaux où vous avez besoin d’une approche de découverte, utilisez une méthode Agile légère comme XP ou SCRUM.
Tout comme la question n’est pas de savoir s’il faut utiliser le marteau ou le tournevis pour vos projets domestiques, le même raisonnement s’applique lorsqu’il s’agit de PRINCE2 ou d’Agile pour votre entreprise.
CONCLUSION
Tout comme vous avez besoin d’un marteau et d’un tournevis à la maison, vous pouvez avoir besoin de PRINCE2 et d’Agile au travail. Le mieux c’est donc d’avoir les deux outils. Si vous utilisez PRINCE2 aujourd’hui, vous devriez d’ores et déjà commencer à vous intéresser à ATERN.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Une de mes idées préférées dans la nouvelle vague de programmation est la notion de produit viable minimal. L’idée est que vous devriez spécifier et construire le plus petit noyau de votre idée principale, le livrer au monde et voir comment les gens lui réagissent, puis l’améliorer à partir de là.
Pour des outils de forage et autres, c’est parfaitement clair. Livrez-les, faites-les utiliser, améliorez-les. La définition « de minimal » est évidente.
Souvent, pour le logiciel que nous utilisons dans le grand public, cette définition mène à l’échec. Pourquoi ? Deux raisons :
1. Le marketing joue avec des règles différentes de l’ingénierie. Beaucoup de produits dépendent de la communauté, de l’adoption par une tribu, de la rumeur. Ces produits ne sont pas viables quand ils sont initialement lancés, précisément parce qu’ils n’ont pas encore été adoptés. « Est utilisé par mes alter ego » est un élément clé de ce qui fait qu’une chose comme un télécopieur soit considéré comme un produit viable et bien sûr, votre nouvel outil ne l’est pas.
Avec suffisamment de patience, de continuité et un enthousiasme cohérent, ces produits vont passer ce seuil. Mais si la mentalité est « voir ce qui marche et en faire davantage », vous vous retrouverez souvent à renoncer bien avant que cela ne se produise.
2. Il y a un pic d’énergie et d’attention et d’effort qui accompagne un lancement, même minimalement viable. S’il y a un délai dans l’adoption par la communauté, il serait facile de passer à la chose suivante (voir #1), au lancement suivant, à la vague suivante, par opposition à faire le travail terriblement difficile de poursuivre avec cette chose que vous avez déjà lancée.
Inhérent au processus de produit viable minimal est la grande et large base de personnes qui vous font confiance et qui seront impatients de vous écouter, d’essayer votre nouveau livrable et vous feront part de ce qu’elles pensent.
Et vous n’avez pas l’option de construire cette base une fois que le produit est prêt : c’est trop tard.
Pour en apprendre davantage sur le concept MVP Minimum Viable Product, regardez et écoutez Eric Vries, auteur du blog Startup Lessons Learned
partagez ce billet avec vos amis, collègues et relations professionnelles
Comment rédigez-vous un contrat au forfait sur une proposition Agile embryonnaire ? Ce n’est pas aussi difficile que certains le font paraître mais cela implique un vrai changement de mentalité et un exercice d’apprentissage pour tout un chacun. Clairement définir « fait » (« done »), évaluer des histoires et comprendre la vélocité sont clés à la réussite.
Ne limitez pas Agile
Si toute l’idée d’Agile est que vous ne pouvez pas prévoir l’avenir, alors comment pouvez-vous l’utiliser dans un Environnement de contrat de forfait où il est essentiel de préciser vos coûts, votre temps et votre contenu de projet ? Peut-être que la réponse est de regarder au-delà de relier Agile à des modèles de contrat mal adaptés et de proposer une nouvelle structure.
OK, donc la chose fondamentale que nous pouvons affirmer de tout ce que nous lisons sur Agile est le fait que les besoins ont vraiment tendance à être très brumeux. Au contraire, le modèle de contrat fixe exige d’un jeu détaillé, stable et précis de besoins, définissant clairement des limites et des pénalités si quelqu’un pose le pied à l’extérieur de celles-ci.
Le faire de façon professionnelle
article précédent sur assistons-nous à la fin des contrats « classiques »?
Comment diable deux animaux si différents peuvent-ils coexister dans le même environnement ? Il y a tant de débat sur comment ceci peut être fait que couvrir chaque idée, pensée ou sentiment nécessiterait des dizaines d’articles. Je pense que ma meilleure approche est de décrire mon expérience et comment je configure un Contrat Agile.
Au tout début d’aborder la question d’Agile et forfait, il était impératif de partir d’une structure logique et professionnelle pour le processus. Je voyais si souvent des présentations où la société a offert une approche de toute évidence biaisée et il n’y avait absolument aucune chance que le projet puisse commencer, encore moins être complété. Mon conseil à toute société travaillant dans le marché de contrat au forfait Agile est de passer du temps à définir votre évaluation, cadencement et l’approche de définition du contenu. Un travail bâclé se sent à un kilomètre.
Alors, comment approchons-nous une proposition de contrat au forfait ? La première chose que nous avons faite a été de regarder le processus Agile que nous avions entrepris et le découper en trois domaines distincts. Sur chacun de ces domaines, nous avons alors passé beaucoup de temps à définir et documenter clairement et précisément le quoi et le comment. Pour nous, cela nous a ouvert une structure complètement différente de notre organisation et a potentiellement ajouté de nouvelles sources de revenu.
Le temps et les coûts dans un contrat au forfait sont raisonnablement faciles à définir et pour Agile l’approche itérative a durée contrainte est très facile à définir. Ceci nous laisse donc seulement avec le problème du contenu/portée/périmètre. Comment pourrions-nous fixer les livrables sans étrangler la méthodologie Agile que nous suivons si fièrement ? Le problème était de changer le concept de contenu en un budget.
Définition de l’élément « contenu » du Contrat
La toute première étape était de collecter les besoins des utilisateurs sous forme d’un arriéré de produit en utilisant des histoires utilisateur pour détailler les attentes des clients. Nous utilisons alors cet arriéré de produit pour prioriser puis évaluer les fonctionnalités en utilisant des techniques d’estimation de groupe comme le « Planning Poker » et donner des valeurs sous forme de points d’histoire « Story Points ».
En allant plus loin dans ce processus nous passons 1 à 2 jours à définir :
« L’histoire utilisateur est une façon d’exprimer des besoins qui sont compréhensibles pour les deux clients et nous-mêmes. Les histoires utilisateur sont rapides à écrire et impliqueront tous les niveaux de la structure d’organisation concernée. Elles sont, plus important encore, orientées fonctionnalité, donc elles peuvent fournir une bonne vue du contenu réel d’un projet et nous pouvons les comparer l’une à l’autre en termes de taille, d’effort « , etc [1]
Pour l’estimation, nous avons tendance à utiliser des points d’histoire par opposition aux jours idéaux ( Je discute de ceux-ci dans mon article sur les Burndown Charts). Il est très important de vous assurer que vous avez une vue très claire de « fait » (« done ») et que vous avez une définition explicite et concrète qui forme le point de contrôle critique du projet agile. Sans une compréhension cohérente de « fait » il sera impossible d’évaluer précisément la vélocité. « C’est aussi une façon de construire la confiance avec le client en ayant un consensus commun quant au processus de projet et sur le critère d’acceptation de haut niveau. « [1]
Ici, nous pouvons maintenant inventer une valeur définissant notre budget de contenu avec des points d’histoire. C’est cette valeur qui est fixée dans le contrat et non Pas les histoires.
Alors, combien cela coûtera-t-il et combien de temps sera nécessaire ?
Avec notre contenu défini nous pouvons maintenant concentrer à établir le prix et la durée. Et, pour ce faire, nous devons regarder la Vélocité de l’Équipe, combien de points une équipe peut-elle réaliser pendant une itération ?
La vélocité de l’équipe est basée sur beaucoup de facteurs, pas seulement combien de travail qu’ils peuvent réaliser. Nos pratiques de travail définissent déjà notre stratégie de communication et nous savons donc combien de temps est passé en réunions planifiées avec l’équipe et le client. Il y a d’autres facteurs à considérer comme les vacances, le volume des tâches, etc. En bout de ligne la vélocité journalière sera un nombre qui est en partie basé sur l’expérience, mais contient pas mal de suppositions (par exemple : si nous sommes en l’hiver, nous pouvons être sûrs que quelqu’un aura la grippe).
Disons par exemple que nous avons calculé que l’équipe peut livrer 30 points d’histoire par itération de 2 semaines et a 240 points d’histoire à livrer (tel que défini dans le contrat). Nous avons maintenant une durée de livraison de 8 itérations nécessitant 16 semaines en tout. Avec 70 heures allouées à chaque itération, une équipe de 5 personnes et un taux horaire de 100 € par membre de l’équipe nous pouvons facilement calculer le prix à 280,000 €.
Donc, maintenant nous avons nos valeurs de contrat fixes :
Prix 280,000 €
Temps 16 Semaines
Contenu 200 points d’histoire
Ces valeurs font tout simplement partie de la procédure tarifaire du contrat et ils ont vraiment tendance à être les chiffres les plus difficiles à atteindre avec un niveau de confiance acceptable.
Ce que nous essayions de montrer ici est que la façon dont nous travaillons sur les projets Agile peut aussi se refléter dans l’environnement des négociations de contrat.
Qu’advient-il si..
… Le propriétaire de produit « product owner » (le client) veut ajouter une autre fonctionnalité ? Nous avons déjà travaillé étroitement avec le client, à définir l’arriéré de produit, évaluer les points d’histoire, donc il connaît la situation actuelle. En cas de demande de travail supplémentaire nous évaluons l’ajout, disons 10 points d’histoire dans ce cas et nous négocions pour soit supprimer 10 points de valeur d’histoire de fonctionnalités agréée soit ajouter une itération de plus. Maintenant que nous avons fixé les points pour le contenu nous pouvons permettre à des changements de se produire, en termes de points. Cela nous permet d’interchanger des besoins en chemin dans la limite de contenu définie. Si nous pouvons rester dans cette limite, nous pouvons aussi rester dans des prix et durée fixes.
… Le client se plaint du prix ? Nous clarifions avec nos équipes de vente que la seule négociation possible dans cette situation est le tarif horaire. Nous ne mettrons pas en péril le projet en essayant d’augmenter la vélocité. Vous ne pouvez pas changer les membres de votre équipe en super-héros en changeant des valeurs sur une feuille de papier.
Et Finalement
Une fois que vous faites signer le contrat et que le travail est en cours, il est impératif que vous managiez vos coûts. Dans mon article sur les Burndown Charts, je discute de comment ceux-ci peuvent être utilisés pour contrôler la vélocité de l’équip. Ils peuvent aussi être utilisés pour contrôler le changement de contenu et les coûts.
Un de mes secteurs de spécialisation est les Contrats au Forfait Agiles, et j’écris et présente sur le sujet régulièrement.
Maurice Saunier nous propose une brève enquête pour sa thèse dont le sujet est de montrer que l’agilité et la gestion de projet classique peuvent cohabiter et que cette cohabitation pourrait faire émerger un management de projet hybride et différent.
accéder au questionnaire
Qui peut répondre ?
==> ceux et celles qui ont pratiqué Agile sur leur vision de l’agilité et sur ce qui en fait la réussite ==> ceux et celles qui n’ont pas pratiqué Agile sur leur vision du management de projet actuel.
Maurice recoupera les réponses des deux communautés et analysera les liens potentiels entre ces deux communautés.
Une fois le sondage fini, il s’en servira pour sa thèse et produira un document annexe pour en commenter les résultats qu’il partagera avec les personnes qui auront répondu et laissé leurs coordonnées de courrier électronique.
Merci à Mahfoud Amiour , Directeur de projet indépendant, Expert Agile chez SOFTENIA Solutions, qui a récemment traduit en français la dernière version du guide Scrum de Ken Schwaber et Jeff Sutherland (Version Juillet 2011).
(Note de Michel: Je vous l’accorde, la traduction du titre n’est pas littérale, mais tellement plus valorisante et plus française ! )
Derek est heureux d’annoncer le lancement du projet de Guide Communautaire PMI-ACP. Chaque jour, il voit que du nouveau contenu y est ajouté. Il se demande si c’est ainsi que Jimmy Wales s’est senti dans les premiers jours de Wikipedia. La première mesure de succès est d’atteindre un contenu pour chaque page du Guide qui soit proche de la vision du Comité de pilotage ACP et ceci aussi rapidement que possible. La deuxième mesure de succès est d’atteindre le point de basculement, à partir duquel la communauté (et non plus l’équipe de support) maintient le guide. Souvenez-vous, les versions futures de l’examen ACP seront basées sur ce Guide.
Dirigée par Joseph Flahiff de Whitewater Projets et Derek Huether, l’équipe de Support d’ACP a démarré le processus de création du Guide Communautaire. Ils sont décidés et 100 % auto-organisés.
L’Arriéré
Pour livrer quelque chose de valeur à la communauté, Joseph et Derek se sont servis du wiki sur le site Web du PMI pour créer un Arriéré de Produit. Ils ont voulu la transparence pour que chacun sache ce sur quoi ils sont concentrés. Chaque domaine majeur de l’examen ACP a une page en attente d’édition. Si vous aviez un arriéré de produit traditionnel, les 10 domaines majeurs qui comprennent les « Tools & Techniques » de l’examen pourraient facilement être considérés comme des « Epics ». Chaque page de notre wiki pourrait être comparée à une Histoire d’Utilisateur. Nous n’estimons pas notre temps de travail. Nous le faisons tout simplement.
Itération 1
Ils ont fini l’Itération #1 le 10 mai 2012. Ils ont demandé à leur équipe de 15 membres des volontaires pour s’engager à travailler sur les 7 premières pages du premier domaine de contenu. À la fin de chaque itération, ils peuvent demander aux membres du comité de pilotage ACP de passer en revue ce qui a été fait. Il est important de rester concentrés, d’avoir des boucles de retour d’information courtes et de livrer quelque chose de valeur sur une base régulière.
Boire son propre champagne
Quand vous pensez à PMI, vous pensez probablement aux plans de projet, aux échéanciers et autres choses de ce genre. En tant qu’équipe auto-organisée et autogérée, ils ont décidé de ce qui est important pour accroître leurs chances de réussite. Bien qu’il doive y avoir une date prévisible d’achèvement, basée sur les éléments à délivrer actuellement définis et la longueur des itérations, ils sont prêts pour des changements. Ils pourraient avoir à retravailler certaines pages. Ils pourraient avoir des départs et arrivées dans l’équipe. Quoiqu’il en soit, ils peuvent garantir qu’ils livreront de la valeur sur une base régulière. Ils peuvent aussi garantir qu’il y a de la collaboration avec la communauté.
Rejoindre l’Équipe
Si vous êtes intéressés par la création ou la maintenance d’articles pour le Guide Communautaire, Adhérez à cette équipe! Si vous voulez travailler de manière indépendante, ils accueilleront vos contributions de valeur.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Il y a trois raisons. Deux font explicitement partie de Scrum. L’autre n’est pas mentionnée, mais est une des fondations de Scrum. Les explicites sont le retour d’information rapide et le renforcement de la vue réaliste. La troisième est la suppression des retards.
Retour d’information rapide
Vous voulez un retour d’information rapide. Attendre plus de 30 jours pour ce retour d’information ne vous donne pas assez rapidement ce retour d’information.
Quel genre de retour d’information ? Un retour d’information qui vous permette d’apprendre rapidement. Le retour d’information vient sous bien des formes. Il y a le temps entre la réception d’une demande jusqu’à sa livraison et le temps de commencer une histoire jusqu’à ce qu’elle soit complète. Mais vous n’avez pas à écrire tout le code pour découvrir que le client n’en veut pas. Au lieu de cela, vous voulez écrire un peu de code sur les histoires dont le client a une compréhension claire. Montrer une partie de la fonctionnalité à un client nous permet d’en apprendre davantage sur le reste de ce qu’ils veulent.
J’entends souvent « échouez vite » comme raison. Je préférerais personnellement apprenez vite. Si je dois échouer, je voudrais le faire rapidement. Mais mon objectif est d’apprendre pas d’échouer.
Renforcement de la vue réaliste
Avec « renforcement de la vue réaliste », je veux dire que seule la fin d’un sprint nous dira où nous en sommes de manière objective, non subjective. Si le test n’est pas fini, sprint n’est pas fini. La raison est probablement un obstacle dans notre processus. Sans dates rigides, fixes, il est facile de rationaliser pourquoi nous n’avons pas accompli ce que nous voulions. Des obstacles usuels sont que les clients peuvent ne pas vouloir vous parler, que les processus de développement sont peut-être inefficaces, que les évaluations et le développement du code sont trop éloignés. En ayant une période déterminée de temps dans laquelle votre travail doit être achevé avec le timeboxing du sprint, ces choses qui travaillent à votre encontre deviendront plus visibles et douloureuses. Ce sont dans les faits des obstacles à votre travail et au lieu de les éviter en rallongeant le sprint, vous devez en réalité raccourcir le sprint pour les mettre encore plus en évidence. Il sera aussi plus difficile de les ignorer : si vous n’avez pas testé votre code à la fin du sprint, ce sera évident et irréfutable.
Ces deux raisons ont en réalité tendance à inciter à des sprints encore plus courts que 30 jours. La plupart des équipes Scrum qui réussissent et que je connaisse utilisent des sprints d’une ou deux semaines. En fait, j’irais jusqu’à dire que des équipes avec des sprints de trois ou quatre semaines indiquent une tendance à ne pas être pas suffisamment engagées dans la résolution de leurs problèmes. Ceci n’est pas toujours vrai, mais c’est assez souvent le cas.
suppression des retards
La troisième raison, qui par beaucoup d’aspects est la plus grande, est d’éliminer les retards.
Depuis 2004, j’ai clamé que Scrum est une faible mise en œuvre des principes Lean. Je dis « faible » parce que Scrum ne se préoccupe pas de l’optimisation de la totalité du processus, Scrum se concentre sur l’équipe de développement et délaisse une grande partie de l’éducation et du management Lean. Mais un des principes clés de Lean est d’éliminer les retards afin que la valeur puisse peut être délivrée rapidement. Ceci est critique parce que chaque délai entre étapes de travail crée littéralement plus de travail.
Le timeboxing dans Scrum exige que les équipes complètent leur travail rapidement, et encourage aussi à élaguer. Ceci réduit les retards et évite donc de faire un travail qui ne devrait pas être nécessaire.
La combinaison du retour d’information rapide, du renforcement de la vue réaliste et de la suppression des retards nous permet d’avoir des boucles de retour d’information de plus en plus brèves jusqu’à ce que tous les frais généraux du sprint, les « overhead », dépassent la valeur qu’ils sont censés apporter. Pour la plupart des équipes ce sera une ou deux semaines. Quelques équipes découvriront qu’elles n’ont pas besoin de la discipline du timeboxing et l’abandonneront complètement et pour passer sur Kanban.
partagez ce billet avec vos amis, collègues et relations professionnelles
Scrum est une technique de » management de projet » de plus en plus populaire sur les projets de développement logiciels (et de temps en temps sur d’autres types de projets). L’article Wikipedia http://fr.wikipedia.org/wiki/Scrum_(méthode) peut être un bon point de départ pour en apprendre davantage sur ce sujet.
Le « Microsoft Project 2010 Scrum Solution Starter » est conçu pour fournir des conseils d’utilisation de Microsoft Project 2010 pour manager des projets Scrum, aspirant à aider les équipes Scrum à commencer à utiliser MS Project pour :
Manager un Arriéré de Produit
Manager un Arriéré de « Sprint »
Suivre la progression et générer des « Burndown charts »
Ce kit de démarrage se concentre sur le poste MS Project 2010 et sur l’expérience de l’équipe Scrum.
Scrum est une méthodologie itérative et incrémentale pour la conduite de projet souvent vue dans le développement logiciel agile. Bien que Scrum ait été destinée au management de projets de développement logiciels, il peut être utilisé pour des équipes de maintenance logicielles, ou comme une approche générale de management de projets/programmes.
Il y a 3 artefacts principaux dans Scrum :
Arriéré de produit : Un arriéré de produit est dynamique : des items peuvent être supprimés ou ajoutés à tout moment pendant le projet. Ce sont les items avec la priorité la plus forte qui sont complétés d’abord. Ces articles prioritaires sont progressivement raffinés alors que ceux de priorité inférieure sont intentionnellement laissés à une granularité plus élevée.
Arriéré de sprint : Un arriéré de sprint est un jeu négocié d’articles de l’arriéré de produit qu’une équipe s’engage à compléter pendant la durée fixée pour un sprint. Les articles de l’arriéré de sprint sont décomposés en tâches détaillées pour que les membres de l’équipe les réalisent. L’équipe travaille de manière collaborative pour compléter les items de l’arriéré de sprint, se rencontrant chaque jour (pendant un « Daily Scrum ») pour partager les problèmes et avancées et mettre à jour l’arriéré de sprint et le « Burn Down chart » en conséquence.
« Burn Down » : Le graphique « Burn Down » du sprint est affiché publiquement et montre le reste-à-faire dans l’arriéré de sprint. Mis à jour quotidiennement, il fournit une vue simplifiée du progrès du sprint. Cela fournit aussi une visualisation rapide pour référence.
Scénarios Supportés:
Un Scrum Master veut utiliser MS Project pour les basiques de l’exécution d’un sprint, y compris :
Collecter et suivre le progrès
Gérer l’Arriéré de Produit
Gérer l’Arriéré de Sprint (et planifier l’itération initiale)
Générer un « Burn Down Chart »
Exporter facilement des données de Scrum poules r envoyer par courrier électronique ou autre moyen
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous n’aimez pas le mot « Exigences » ? Ce n’est pas si clair, n’est-ce pas ? NON ! Avez-vous avez jamais entendu votre client dire « Je vous ai déjà donné mes exigence » et l’équipe répond alors « Nous n’avons pas reçu de besoins clairs ou détaillés ». L’autre face de ceci est quand l’équipe dit au client « Vous nous donnez trop de détails, ne nous dites pas où le bouton doit être placé sur l’écran, dites-nous seulement ce que vous voulez ». Pas étonnant nous ayons tant de problèmes liés aux exigences sur nos projets!
Pendant l’un de mes webinars PMI précédent, nous avons parlé de Agile Requirements – Breaking Down EPICs and Prioritizing. Je ferai un essai dans ce billet à récapituler les niveaux d’exigences Agile (et non Agile pour être honnête) et comment vous pouvez utiliser un processus à quatre étapes pour les rassembler.
D’abord, commençons par l’image ci-dessous. L’image montre 4 niveaux d’exigences et aussi sur la gauche les 4 étapes du processus pour réunir les exigences.
Visioning: C’est l’étape initiale de collecte des exigences. Le but est d’aider à identifier tous les Thèmes et quelques fonctionnalités désirées. Cet exercice commence à définir le périmètre de ce qui est attendu.
Brainstorm: Le but de cette étape est d’identifier toutes les fonctionnalités et histoires (« stories ») désirées. La clé est ici la Couverture d’abord, la Profondeur plus tard. Ainsi, au lieu de discuter les détails de chaque fonctionnalité et histoire, notre but principal est de TROUVER toutes les fonctionnalités et histoires.
Breakdown: Le But de cette étape est de décomposer et découper les histoires qui sont encore trop longues (des ÉPOPÉES) en de plus petits morceaux. Vous avez probablement déjà fait beaucoup de découpage pendant le brainstorming, mais comme vous revisitez votre arriéré, l’équipe se rendra compte que quelques histoires sont encore trop longues pour être complétées en une itération (d’habitude 1 à 4 semaines). Le découpage des histoires est un art et j’y dédierais un blog entier!
Deep Dive: C’est l’étape à laquelle veut sauter tout de suite! Oui, finalement parlons des détails. Ce qui sera sur l’écran, quelles sont les règles de gestion exactes et comment nous ferons pour les tester, ce à quoi ressemblera le processus détaillé, quelles sont les tâches que nous devons réaliser pour achever cette histoire. Sauter dans ce niveau de détail en amont pendant les phases initiales est une des raisons principales contribuant à la dérive de contenu plus tard pendant le projet.
Supposons que nous développons un système pour un site d’offre d’emploi en ligne OnStopJobs.com. Voici à un exemple de ce à quoi les exigences pourraient ressembler en se basant sur les niveaux ci-dessus :
1. Domaine Employeur- Thème
a. Gérez des Emplois- Fonctionnalité
1. En tant qu’employeur je veux afficher un job afin que d’autres puissent le trouver. Histoire
2. En tant qu’employeur je veux modifier une offre d’emploi pour la corriger. Histoire
3. En tant qu’employeur je veux une liste de mes offres d’emploi ouvertes pour les analyser. Histoire
4. En tant qu’employeur je veux pouvoir faire expirer une offre d’emploi pour que personne ne puisse y appliquer. Histoire
b. Gérez les Candidats
1. En tant qu’employeur je veux voir la liste de candidats récents pour pouvoir leur répondre.
2. En tant qu’employeur je veux voir la liste de candidats d’une offre d’emploi spécifique pour pouvoir les qualifier.
3. En tant qu’employeur je veux choisir les meilleurs candidats pour pouvoir les interviewer.
Vous devriez rassembler les niveaux ci-dessus (Thèmes, Fonctionnalités, Histoires) en amont quand vous planifiez de votre « Release », particulièrement si vous avez des projets traditionnels avec des dates de début et de fin. Nous passons d’habitude plus d’effort sur les histoires qui arrivent dans les quelques itérations suivantes ou la Release suivante.
Le Deep Dive est là où se trouve la différence principale entre Agile et En Cascade. Des équipes traditionnelles rassembleraient des informations très détaillées en amont pour TOUTES les histoires de l’arriéré, Alors qu’en Agile , les équipes rassembleront ces détails Juste à temps pour les histoires suivantes, soit une ou deux itérations avant que cette histoire soit à faire.
Voici à un exemple de ce à quoi les détails pourraient ressembler pour cette histoire choisie : « En tant qu’employeur je veux job afin que d’autres puissent le trouver «
Critères/tests d’acceptation (Comment saurons-nous quand nous aurons fini):
1. UAT1 – Vérifier que seul un utilisateur autorisé avec un compte d’employeur valable peut poster un travail pour le compte de cet employeur.
2. UAT2 – Vérifier qu’une offre d’emploi dupliquée ne peut pas être entrée.
3. UAT3 – Vérifier que la date de publication est plus tard que la date du jour.
4. UAT4 – Vérifier que la date d’expiration est en principe dans 90 jours.
5. UAT5 – Vérifier que les champs sur l’écran passent nos règles standards de format.
6. UAT6 – Vérifier que tous les champs requis sont saisis.
Les critères d’acceptation sont ‘les détails’ de l’histoire et on les considère comme des exigences primaires dans Agile. Nous les réunissons avant de débuter tout développement.
Exemples de Tâches (Le travail à faire pour avoir fini):
1.Créez des tables de base de données pour stocker les détails d’offre d’emploi.
2.Concevez et construisez l’écran pour l’offre d’emploi.
3.Développez la logique pour passer UAT1.
4.Documentez/enregistrez l’aide vidéo insérée dans la page d’offre d’emploi.
5.Exécutez le test d’acceptation utilisateur.
6.Déployez le code dans l’environnement de test.
7.…..autres.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
J’étais à une conférence il y a peu de temps parlant et partageant sur divers sujets agiles. Comme il arrive souvent, un jeune homme m’a arrêté afin de me poser quelques questions après ma présentation. Nous avons entamé une conversation agréable qui a finalement débordé jusqu’au corridor de l’hôtel.
Nous avons commencé à parler de la dynamique de sprint dans des équipes Scrum et je suis arrivé de mentionner que je coache souvent des équipes vers la déclaration de leurs sprints en tant que succès ou… (pause pour plus d’effet) échec. Que nous faisons ceci comme partie intégrante de la revue de Sprint avec les équipes, le Propriétaire de Produit étant le décisionnaire final en se basant sur selon que l’équipe a atteint les Objectifs de Sprint ou pas.
Il a été visiblement énervé par mon avis. Il a dit qu’ils (il travaillait dans une société bien connue d’Atlanta) n’avaient jamais échoué de sprint. Jamais! Ils ne pouvaient pas, ni n’utilisaient ce MOT dans leur culture. Je lui ai demandé catégoriquement : n’avez-vous jamais échoué un sprint ? Il a dit bien sûr qu’ils l’avaient. Plusieurs fois. Mais au lieu d’utiliser le terme échec, ils ont utilisé le terme ‘challenge’. De cette façon, les parties prenantes ne se feraient pas de fausse idée et ne mettraient pas en doute les compétences ou la motivation de l’équipe.
Nous avons tourné en rond pendant 10 à 15 minutes de plus dans notre discussion, mais nous n’avons jamais vraiment réglé nos différences. Nous avons simplement consenti à être en désaccord. Bien que ce ne soit pas un terriblement large abîme entre nous, je me rappelle distinctement revenir vers ma chambre en secouant la tête. Je n’avais tout simplement pas compris le grand cas fait de l’échec. De l’utilisation du mot. D’une équipe disant…nous avons échoué. Dans mon job de coach et dans mes « tâches journalières », j’ai pu diriger et développer nos idées pour que l’échec ne soit pas un gros mot. C’est-à-dire l’échec est bon. L’échec est ok. L’échec mène à l’amélioration. L’échec fait partie de la vie.
Aussi, dans ce billet, je veux discuter de l’échec depuis quelques perspectives différentes. La discussion n’est pas destinée à être complète. Au lieu de cela, je veux juste partager quelques pensées avec vous et vous faire réfléchir sur l’échec… sur comment vous le percevez dans votre organisation, quelle est votre tolérance à l’échec et reconsidérer vos réactions normales face à lui. Je pense que cela vous mènera aussi à considérer votre management de risque, parce que je pense que les deux sont inextricablement liés.
Coacher pour éviter l’échec
Dans son blog du 20 juin 2011, s’intitulant Coaching is Not Letting Your Teams Fail (Coacher c’est ne pas laisser vos équipes échouer), Giora Morein justifie que des coach agiles devraient amener ou guider leurs équipes loin de l’échec. Il donne l’analogie d’un Sherpa guidant des alpinistes. Et oui, dans l’exemple de l’alpinisme en montagne, je dois reconnaître que l’échec n’est probablement pas le résultat que nous voulons.
Cependant, dans les environnements qui ne mettent pas la vie en danger, je pense que je ne suis pas d’accord avec Giora. Je crois de tout cœur que l’échec peut en réalité être bon pour une équipe. Je pense aussi que le rôle du coach est d’aider une équipe à regarder sa performance de deux perspectives. La plus facile des deux est la perspective de succès. C’est la perspective où vous donnez un retour d’information positif à l’équipe; où vous leur dites qu’ils ont besoin de répéter les pratiques qui marchent pour eux. En fait, quelles pratiques ils doivent amplifier et faire « davantage » afin d’atteindre des résultats de plus en plus importants.
Ces conversations sont clairement plus faciles.
Mais en ce qui concerne la perspective d’échec ? Comme coach, fournissez-vous une critique constructive ? Montrez-vous à une équipe où ils ont trébuché ? Tant individuellement que comme une équipe ? Je pense que vous le devez. Mais certainement pas de façon malveillante ou maladroite. Je pense si vous coachez efficacement une équipe vous devez explorer leurs erreurs et faux pas avec la même passion et énergie que quand vous traitez leurs succès.
Et je ne pense pas que vous le faites tranquillement, en vous cachant derrière des portes et sans reconnaître de leurs challenges. Non. Je pense que vous l’approchez de façon totalement transparente et pratique. En établissant au départ que l’échec est apprécié et bien accueilli. Que depuis l’échec, vos équipes cherchent des possibilités d’amélioration et avancent rapidement vers l’atteinte de meilleurs résultats.
Exposition Agile
Dans des équipes agiles, il y a deux cérémonies clés qui sont concentrées sur les résultats réussis ou pas de l’équipe. Dans Scrum, c’est la Revue de Sprint (la démonstration) et la Rétrospective de Sprint (les leçons apprises). Typiquement la revue de sprint est exposée au monde, donc vous pourriez vouloir être prudents sur comment vous énoncez vos échecs – pour que les parties prenantes n’interprètent pas mal l’impact ou l’effort consenti par l’équipe. Néanmoins, je crois que vous devriez déclarer des sprints succès ou échecs pendant l’introduction à la revue d’équipes.
Dans Scrum, c’est le rôle des Propriétaires de Produit de déterminer cela. Et c’est relatif aux objectifs sur lesquels l’équipe s’est engagée au début du sprint. On espère que ces objectifs étaient assez flexibles pour permettre à l’équipe d’ajuster leur travail pour les atteindre avec créativité.
Par exemple, je pense qu’un très mauvais objectif de sprint est quelque chose autour de l’équipe livrant un nombre d’histoires utilisateur – ou autres indicateurs d’exécution par cœur. Je pense que cela mène à un en-sablage potentiel de la part de l’équipe pour atteindre un but numérique plutôt que de penser au vrai problème qu’ils essayent de résoudre. Au lieu de cela, je pense que de meilleurs buts tournent autour de la réalisation d’une sorte de démonstration d’un comportement qui résout un jeu spécifique de problèmes clients. Donc le succès est mesuré sur comment l’équipe a respecté l’esprit de l’objectif et combien ils ont appliqué les principes agiles dans leur exécution.
Par exemple, j’ai vu des équipes qui s’engagent sur 10 histoires utilisateur, mais qui avaient 3 jours de temps mort à la fin de leur sprint, rater leur sprint. Pour sûr, ils ont bien livré par rapport à leur engagement, mais leur engagement était faussé. Ils s’étaient protégés et avait surestimé. De plus, ils n’ont pas fait part de leur capacité supplémentaire disponible à leur Propriétaire de Produit ni demandé davantage de travail dans leur sprint. Au lieu de cela ils ont planifié d’avance ou « plaqué or » leurs produits.
J’ai aussi vu des équipes qui s’engagent sur 10 histoires, mais en livrent 7 et ont un sprint très réussi. En cela qu’ils travaillent dur dans la complexité et l’adversité. Ils sont incroyablement transparents et engagent leur Propriétaire de Produit à faire des ajustements quotidiens sur les priorités en fonction de leur actuelle compréhension de leur capacité. Et en tant qu’équipe, bien qu’ils n’aient pas livré la quantité prévue à l’origine, ce qu’ils ont vraiment livré est aligné sur leurs objectifs et respecte l’esprit et l’intention du Propriétaire de Produit.
Ces deux cas devraient être discutés pendant la rétrospective des équipes et les façons de s’améliorer discutées. Pas de petite façon et sans ignorer les premiers troubles du comportement de l’équipe. Non. Tout cela, le bon, le mauvais (erreurs et échecs) et idées d’amélioration significatives, sera discuté pour que l’équipe décide de quels points sont dignes de leur attention pour amélioration dans le sprint suivant.
Mais l’échec est-il apprécié ?
En continuant sur mon exemple de coaching précédent, je me souviens qu’il n’y a pas longtemps je parlais à un groupe de nos Scrum Masters dans mon « travail de jour » chez iContact. Si vous ne connaissez pas Scrum, le Scrum Master est le coach et le guide principal et la voix du leadership agile dans l’équipe Scrum agile. Il est aussi responsable d’entretenir des valeurs agiles clés dans l’équipe et e la performance générale des équipes. Ce que j’entends par cela est qu’il guide les équipes vers une performance qui s’améliore dans la durée. Posant continuellement des questions comme : son équipe s’améliore-t-elle dans sa performance globale ? Sa vitesse s’améliore-t-elle ? Sa qualité de travail s’améliore-t-elle ? La collaboration et le travail en équipe s’améliorent-ils ? Et, leur focus est-il sur l’amélioration de la valeur livrée pour le client ?
Donc mon point auprès des Scrum Masters était que j’estimais que nous n’avions pas échoué depuis quelque temps. J’ai défini l’échec dans ce cas comme un échec de sprint ou un incident dans lequel une équipe s’est essentiellement heurtée à un obstacle et a eu besoin de re-planifier ou revoir l’alignement son sprint.
Ils ont tous été d’accord avec moi que les choses s’étaient déroulées sans à-coups. Et j’ai reçu plus que quelques regards interrogateurs fixes quant à pourquoi c’était un problème. J’ai essayé d’être prudent dans ma réponse, mais ma préoccupation était qu’il se pourrait que nous la jouions un peu trop sûrs. Que nous devenions complaisants dans nos pratiques agiles et que nous ne nous challengions pas assez. Que nous ne tentions rien. Et ne courrions pas de risques.
J’ai expliqué que ces caractéristiques sont fondamentales pour la croissance et la progression d’équipes agiles. Et le fait que nous ne rencontrions pas d’échecs indique que nous avons atteint un plateau dans notre croissance et notre performance. J’ai estimé que c’était un problème…et pour lequel j’ai demandé s’ils pourraient obtenir davantage d’échecs des équipes.
Pouvez-vous imaginer le reste de cette discussion ?
Me voilà le Directeur de R&D dans une société qui réussit en train de parler à mon équipe de Scrum Masters et leur demander d’amener plus d’échecs, pour inciter leurs équipes à davantage de prise de risques et inspirer des objectifs plus agressifs. Le point que j’essaye de faire passer est que j’apprécie vraiment l’échec. Que j’ai appris à le voir comme un critère critique de succès et que son absence est un problème pour moi. Je me demande combien d’organisations et de leaders ont la même position.
La notion de « Chuter en avant »
Un de mes auteurs préférés est John C. Maxwell. Il est relativement bien connu comme un coach en leadership et un prolifique auteur avec plus de 50 livres sur divers sujets de leadership. Il a un fort contexte Chrétien dans sa vie et dans son écriture, mais si vous n’êtes pas aussi enclins, ne laissez pas cela vous rebuter. Il maîtrise pleinement l’art du leadership.
Il y a quelques années il a publié un livre : Failing Forward—Turning Mistakes Into Stepping Stones to Success. Dans celui-ci, il souligne l’échec comme un facteur de réelle transformation dans nos vies personnelles, professionnelles et en équipes. Mais il place soigneusement l’échec dans une position d’avancée. Au lieu de voir l’échec comme un état final négatif et nous en plaindre, nous devrions l’embrasser comme une expérience à portée pédagogique positive. Que nous nous « penchions en avant » en démultipliant les leçons apprises pour nous améliorer.
Je ne pense pas que Maxwell souffle simplement un nuage de fumée positive dans notre direction. L’histoire est clairement encombrée d’exemples de succès qui ont été inspirés, forgés et durcis par le feu de l’échec. Thomas Edison en est un exemple célèbre quand il a persévéré pour inventer l’ampoule électrique.
Dans mon coaching agile j’utilise de manière consistante la terminologie « chuter en avant » quand je discute des échecs d’équipes. Oui, je veux qu’une équipe soit honnête avec elle-même et reconnaisse qu’elle a échoué. Mais je veux aussi que ses membres embrassent leurs erreurs au lieu de devenir défensifs, blâmer d’autres personnes ou être dans le plein déni. Et je veux que leur position les fasse se « pencher vers l’avant ». Désireux d’essayer quelque chose de nouveau qui amènera des résultats différents. Sans avoir peur de l’échec.
Je constate qu’en utilisant cette terminologie, j’aide des équipes à comprendre la nature de l’échec et à se comporter convenablement. Mais au-delà de la terminologie, les leaderships de projet et fonctionnel doivent aussi pleinement supporter l’idée. CE qui signifie que l’équipe de direction toute entière doit supporter l’échec. Voilà…je l’ai dit.
En conclusion – Mais, je suis un peu étrange …
Tout ceci étant dit, je me demande si j’ai une vue étrange et largement minoritaire envers l’échec ? Je me demande si la bonne réponse doit en effet de le craindre, de nier son existence, de passer d’innombrables heures à essayer de le prévoir, de ne jamais le mentionner en public. Est-ce que de telles actions sont les bonnes réponses ?
À cette fin, je ferme ce billet avec une requête auprès de tous les lecteurs. J’ai préparé une brève enquête, que je voudrais vous proposer. Je sais, je sais, vous êtes occupés. Mais je pense vraiment que vos idées seront ici utiles. L’enquête est centrée sur la construction d’une vue sur l’acceptation organisationnelle, de groupe/équipe et individuelle de l’échec et du risque. J’essaye d’obtenir à une compréhension profonde de cette acceptation et aussi de ses causes racines. Même si je suis particulièrement intéressé par les équipes agiles, ne laissez pas votre manque d’expérience agile vous empêcher de répondre.
Suite au retour d’informations reçu par le programme pilote et le Comité de pilotage PMI-ACP, le Conseil de Gouvernance de Certification a approuvé 3 mises à jour aux critères d’éligibilité pour la certification Agile Certified Practitioner de PMI (PMI-ACP). Cette certification reconnaît la connaissance d’un praticien des principes agiles, des pratiques, des outils et des techniques à travers les méthodologies agiles.
Le tableau suivant détaille les mises à jour qui sont entrées en vigueur le 26 mars 2012. Les candidats à la certification PMI-ACP devront respecter les critères d’éligibilité suivants :
Expérience Générale en Management de Projet
2,000 Heures Travail Sur des Équipes Projet
Ces heures doivent être cumulées sur les 5 dernières années
Tout PMP® et PgMP® actif satisfera ce pré-requis
Expérience en Management de Projet Agile
1,500 heures de travail sur équipes projet agiles ou avec méthodologies agiles
Ces heures viennent en supplément des 2,000 heures exigées dans « Expérience Générale en Management de Projet »
Ces heures doivent être cumulées sur les derniers 2 3 ans
Formation de Management de projet AgileFormation aux Pratiques Agiles
21 Heures
Les heures doivent être gagnées dans des pratiques agiles de chef de projet
Partenaire de DantotsuPM
Le changement « de l’expérience en management de projet » pour « expérience projet » clarifie le type d’expérience exigée. Alors que la description déclare que la certification n’est pas limitée aux chefs de projet, « l’expérience en management de projet » créait un peu de confusion en impliquant que nous exigions de l’expérience à manager des projets plutôt qu’à travailler sur des équipes projet.
La recherche PMI Pulse of the Profession indique que beaucoup d’organisations n’ont pas encore implémenté largement les pratiques agiles. Donc, pour encourager autant ‘d’adopteurs précoces’ que possible à atteindre l’expérience exigée, PMI met à jour le critère d’éligibilité aux 3 dernières années au lieu de 2.
Pour commencer à répondre à toute question et commentaire sur la mise à jour des critères d’éligibilité, nous avons préparé une Foire aux Questions en Anglais FAQ qui peut être trouvée sur la page PMI-ACP de PMI.ORG.
Si vous avez des questions supplémentaires, envoyez les s’il vous plaît par courrier électronique à Customercare@pmi.org.
Et voici un rappel en vidéo de ce qu’est Scrum en seulement 7 minutes.
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.
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
Ce focus sur comment passer à travers les étapes peut être dangereux et irritant pour les individus, équipes et managers. Scrum n’est pas UNE SOLUTION MIRACLE! Aucun processus, pratiques, ou des techniques ne le sont. Au lieu de vous concentrer sur le processus, les pratiques et les techniques de Scrum, je suggère aux personnes, équipes et au management de se concentrer sur les enseignements qui peuvent être produits par une équipe faisant du Scrum et agir sur ceux-ci.
La rencontre Scrum Quotidienne (Daily Scrum) permet à l’équipe de se concentrer sur ses engagements pour le Sprint actuel et vérifier s’ils sont toujours en piste pour livrer par rapport à cet engagement. S’ils ne peuvent pas respecter l’engagement, alors on leur demande d’ajuster le Sprint, s’adaptant ainsi à la situation.
DantotsuPM.com 