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
Dans la gestion de projet Agile, nous devons prioriser une liste de demandes pour la planification de version, d’itération et l’insertion de nouveaux besoins ou exigences. Mais il y a plusieurs techniques pour le faire.
Une des méthodes les plus populaires pour déterminer la priorité des demandes est l’approche dite « MoSCoW ». Cela signifie ‘ Must (Doit), Should (Devrait), Could (Pourrait), Won’t (ne fera pas). ‘ Le seul problème avec cette méthode est que d’habitude tout est un Must, ce qui ne permet pas une planification appropriée parce que les besoins ne sont pas nécessairement placés dans leur ordre de priorité.
Une autre méthode estle modèle de Kano, développé par le Professeur Noriaki Kano, qui s’efforce de satisfaire les exigences et de faire plaisir aux clients. Ce modèle dispose de quatre composants :
• Must haves (doit avoir) sont des éléments sans lesquels on ne peut livrer le produit.
• Dissatisfiers (générateurs d’insatisfaction) sont des choses que le produit ne doit pas inclure.
• Satisfiers (générateurs de satisfaction) incluent besoins pour lesquels plus vous en avez mieux le produit sera perçu. Comme un catalogue commercial dans lequel chaque fonctionnalité ajoute progressivement de la valeur.
• Delighters (générateurs de plaisir) amènent le produit plus loin que simplement répondre aux exigences vers l’augmentation de la satisfaction client et la recommandation par le client.
Plusieurs modèles de priorisation réunissent deux variables dans un tableau pondéré : fonctionnalités et clients. Chaque fonctionnalité est pondérée par sa valeur pour chaque client. La somme des poids multipliés par le score permet de voir quelles fonctionnalités sont en général les plus utiles pour un jeu de clients exigeants.
Quel que soit la technique utilisée, votre liste d’exigences de projet doit être triée de la plus grande à la plus faible valeur.
Quelles techniques utilisez-vous pour prioriser les besoins ?
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
1. PMI has selected PMI-Agile Certified Practitioner (PMI-ACP)SM as the name for the certification.
2. The PMI-ACP certification application is now open and available online at PMI.org.
Please note the following
As a reminder, the PMI-ACP examination will be not be available until Q3 2011.
During the application process, you can also pay the certification fee. After the certification fee is submitted, PMI will randomly select individuals for audit. If you are selected, you can use the time between your application submittal and when the examination is available to complete the audit process.
Don’t forget that PMI-ACP participants are eligible for a 20% rebate of the certification. Pilot candidates must pay the certification fee and take the pilot examination on/by 30 November 2011 to receive this 20% rebate. The rebate will be issued within 60 days of taking the examination via the payment method used to pay the certification fee.
As you prepare for the PMI-ACP certification process, please keep in mind the following examination study tips
Form a study group with colleagues or friends. (You can meet in person or virtually.)
To stay up-to-date on the PMI Agile Certification, please go to the Agile certification home page. If you have questions that cannot be answered by this information, please contact PMI Customer Care at customercare@pmi.org.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Voici une vidéo qui donne à réfléchir pour tous ceux qui sont actuellement chefs de projet dans le développement logiciel et qui commencent à adopter les méthodes et approches Agiles sur certains de leurs projets.
Lyssa Adkins nous confie quelques pensées radicalement opposées à ce que les chef de projet dans le modèle « en V » ou « en cascade » ont pu apprendre :
Se détacher du résultat, du livrable, pour se focaliser sur comment l’équipe travaille ensemble
Demander à l’équipe. Quelque soit le problème à résoudre, ne le faites pas vous-même et demander plutôt à l’équipe de le faire
Refléter vers l’équipe sans jugement de votre part ce que vous observez
Maîtriser votre communication orale et gestuelle (ok, pas vraiment nouveau…)
être confortable avec le silence pour laisser un espace d’expression à chacun dans l’équipe
être « déraisonnable », challenger le status quo et l’équipe ainsi que toute assomption
Laisser l’équipe apprendre de ses (petites) erreurs
être leur plus grand et plus fidèle fan
Au bout du compte, Lyssa mentionne que le coach Agile doit avoir 4 fonctions principales:
Bulldozer qui élimine tout ce qui entrave le progrès de l’équipe
Berger qui mène tout son « troupeau » au succès
Leader au service de l’équipe, facilitateur, supporter
Gardien de la qualité et de la performance
partagez ce billet avec vos amis, collègues et relations professionnelles
Le Project Management Institute a récemment annoncé son programme d’incorporer l’agilité dans son programme de management de projet. J’accueille ceci bien sûr avec plaisir et attends avec impatience que PMI change de son approche précédente à une approche agile. Le test en sera, bien sûr, le succès des projets qui adhèrent à ses principes. Dans le passé, le succès de leur approche prédictive a été moins de 50 % de projets (à l’heure, sur la date, avec la fonctionnalité souhaitée). La plupart des méthodes agiles ont un taux de réussite beaucoup plus élevé, y compris le succès à arrêter très tôt des projets à faible retour sur investissement. Nous observerons et verrons si ceux qui emploient l’approche agile du PMI bénéficient de tels succès, ou au moins d’une amélioration du seuil des 50% 1,2,3.
Dans le passé, PMI a embrassé l’approche prédictive, mécanique du management de projet. Cela a été d’abord soutenu par Frederick Taylor dans “Principles of Scientific Management”, qui était la base de la chaîne de montage des Ford Model T. C’est une approche pour une fabrication prévisible, en grand volume et bon marché. Ses bénéfices s’obtiennent en éliminant toute imprévisibilité de l’espace des problèmes à travers la standardisation et la répétition. La planification parfaite, la formation et la répétabilité sont les recettes. Planifiez et répétez ensuite à maintes reprises. La mesure de succès est le taux de rendement, qui est souvent très proche de 100 %. La productivité est optimisée par des processus parfaits, un « workflow » invariable et l’utilisation optimisée des ressources (les personnes ou les machines).
Des processus agiles, travaillent en revanche au développement de produits complexes, où il y a une certaine répétabilité, mais il y a davantage de développement nouveau que d’ancien. Les produits doivent être inventés à nouveau à chaque fois avec les changements des besoins, les techniques et les capacités et la créativité des personnes. Dans ces situations, nous avons constaté que la planification à flux tendu, avec inspection fréquente et adaptation est exigée. Les risques sont managés et la prévisibilité créée en limitant la période de temps entre les événements de planification et en assurant la transparence de tous les artefacts. Nous avons aussi trouvé que la productivité, la qualité et la créativité sont énormément accrues si les personnes réalisant le travail planifient aussi leur propre travail. Elles ne sont pas gérées comme des ressources, mais comme des personnes qui peuvent faire de leur mieux quand elles comprennent comment faire le travail par elles-mêmes. L’auto-organisation et la transversalité fonctionnelle sont essentielles au succès de ces équipes.
Nous avons constaté que le rôle du chef de projet est contre-productif dans un travail complexe et créatif. La ligne de pensée du chef de projet, comme représenté par le plan de projet, contraint la créativité et l’intelligence de tous sur le projet à celle du plan, plutôt que d’engager l’intelligence de chacun au mieux afin de résoudre les problèmes.
Dans Scrum, nous avons supprimé le chef de projet. Le Propriétaire de Produit, ou le client, fournissent la planification à flux tendu en disant à l’équipe de développement ce qui est nécessaire, aussi fréquemment que chaque mois. L’équipe de développement se gère, fournissant autant de ce que veut le propriétaire de produit en produit utilisable que possible. Le résultat est la haute productivité, la créativité et l’engagement des clients.
Nous avons remplacé le chef de projet par le Scrum Master, qui gère le processus et aide le projet et l’organisation à passer aux pratiques agiles.
Comment PMI va combler la différence profonde dans la philosophie, la pensée, le leadership et le management entre son approche prédictive traditionnelle et la nouvelle approche empirique agile sera fascinant à observer. Comment PMI remodèlera le rôle de chef de projet sera un exercice d’agilité en lui-même. Personnellement, je souhaite le meilleur aux gens de PMI. Ils ont certainement besoin d’un meilleur taux de réussites que 50% pour regagner la confiance de leurs clients.
1. Tiré de “The Rise and Fall of the Chaos Report Figures”, janvier/février 2010 IEEE Software, J. Laurenz Eveleens et Chris Verhoef, Vrije Universiteit Amsterdam.
32 % Réussi (À l’heure, Sur Budget, Entièrement Fonctionnel)
44 % Challengés (en retard, dépassement de budget, Et/ou Moins de Fonctionnalités que promis)
24 % Ont échoué (Annulé ou jamais utilisé)
3. En plus d’un taux de rendement bas (le taux de livraisons réussies), les statistiques indiquent aussi que plus de 60 % des fonctionnalités livrées ne seront que rarement ou jamais utilisées, une perte énorme de budget de support et de développement. Résultat de la non priorisation des besoins. http://en.wikipedia.org/wiki/Software_bloat, “Embonpoint Logiciel”.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous y découvrirez notamment que l’examen consistera en 100 questions dont la moitié sur les outils et techniques Agiles et la seconde partie sur les compétences et connaissances Agile.
Coté outils et techniques, les aspects suivants seront couverts: Communications, Estimations, Planification, Suivi et Amélioration continue, Analyse et Design, Qualité et Tests, Compétences relationnelles, Priorisation, Management des risques, mesures et indicateurs, anamyse de la valeur.
Les compétences et connaissances sont organisés en domaines qui sont eux mêmes triés par niveau d’importance sur les projets agiles.
La définition des « bonnes » estimations sur un projet est un savant mélange d’expérience, d’échanges entre experts, de comparaison par analogies, de calculs… Le Planning Poker est l’un des outils de la méthode Scrum qui permet à une équipe lors d’une réunion de planification de donner des estimations pour le développement d’une fonctionnalité.
Lors de la réunion, le product owner (directeur de produit), qui représente comme toujours le client, définit les priorités de développement des nouvelles fonctionnalités du produit logiciel. L’équipe projet doit donner des estimations d’efforts au product owner afin que celui-ci comprenne ce que va coûter chaque nouvelle fonctionnalité. Et c’est là qu’intervient le Planning Poker. Pour jouer au planning poker, l’équipe doit donc avoir la liste de fonctionnalités à livrer (le product backlog) et un jeu de cartes de planning poker.
Dans ce jeu de carte, au lieu de porter des valeurs entre le 2 et l’as, les cartes portent des valeurs qui sont plus pertinentes à l’évaluation de durée de tâches. Typiquement ces valeurs sont : 0, ½, 1, 2, 3, 5, 10, 20, 50, 100. Ces valeurs correspondent au nombre de jours qu’une fonctionnalité donnée prendrait à être développée.
La session de planning poker est habituellement facilitée par un modérateur qui est souvent le ScrumMaster ou bien le coach Agile de l’équipe, les participants sont donc le « product owner » et l’équipe de développement.
Quel est le processus ?
1. Le modérateur lit la description de l’histoire utilisateur (« user story ») ou fonctionnalité que l’équipe doit estimer. Le product owner peut fournir des clarifications sur la fonctionnalité. Chaque expert est doté d’un jeu de cartes.
2. Chaque expert choisit une carte dans son jeu qui correspond à son estimation initiale de l’effort de développement. Chaque expert pose sa carte à l’envers sur la table pour ne pas influencer les autres experts.
3. Quand toutes les évaluations sont sur la table, les cartes sont retournées.
4. S’il y a une palette très large entre les estimations, les experts qui ont suggéré les plus fortes et plus basses évaluations fournissent le raisonnement qui les a amené à ces valeurs.
5. Une fois que la discussion sur la palette d’estimations a été conduite, les étapes 2 à 4 sont répétées jusqu’à ce qu’un consensus soit atteint.
Quel est l’avantage principal ?
L’avantage principal du planning poker est d’encourager une discussion ouverte sur les estimations. Cela aide l’équipe à atteindre une proposition plus précise au lieu de compter sur l’avis d’un membre de l’équipe plus influent ou plus vocal que les autres. Cela permet aussi à l’équipe de bénéficier de l’expérience de tous les membres de l’équipe.
It holds an interesting high level comparison of the metrics and tools available for PMs to track progress and communicate on it: Gantt charts, WBS, Burn Down Charts… It also gives a few hints on how to interpret these as they are quite different from the metrics of waterfall approaches.
partagez ce billet avec vos amis, collègues et relations professionnelles
Apprenez comment la Certification Agile PMI peut vous y aider.
Agile est un sujet d’importance croissante dans le management de projet. Le marché dénote cette tendance comme les pratiquants en management de projet embrassent Agile comme une technique pour gérer avec succès des projets.
À cause de ces changements dans l’environnement de management de projet, PMI développe une certification Agile.
Les leaders qui utilisent des techniques Agiles dans le management de projet ont conseillé PMI sur la meilleure façon de proposer une certification Agile pour servir des membres de projet et les organisations pour lesquelles ils travaillent.
Agile est-il pour vous ?
PMI questionne régulièrement les chefs de projet pour mieux comprendre comment ils pratiquent le management de projet. Une statistique majeure qui est sortie de notre dernière enquête professionnelle est des pratiques standardisées de gestion de projet aboutissent à de meilleures performances de projet. Une des pratiques que PMI a surveillées depuis plusieurs dernières années est la croissance ininterrompue et de l’utilisation des pratiques Agiles dans le management de projet. Beaucoup de PMs ont ajouté Agile à leur « boîte à outils de management de projet » et l’utilisent comme une parmi de nombreuses de techniques de management de projets.
De plus, les organisations qui utilisent le management de projet pour servir leurs clients tant internes qu’externes voient de la valeur dans des méthodes Agiles pour livrer des projets à leurs clients plus rapidement. En conséquence, plus d’organisations et de bureaux de projet (PMOs) demandent à leurs chefs de projet d’appliquer des techniques Agiles. La recherche PMI a révélé que 68 % des organisations utilisant des pratiques Agiles verraient de la valeur dans une certification Agile pour des managers de projet. De plus, 63 % des recruteurs encourageraient leurs chefs de projet à passer une certification Agile.
Qu’est-ce que la Certification Agile de PMI ?
Les chefs de projet qui utilisent des pratiques Agiles dans leurs projets, ou dont les organisations adoptent Les approches Agile dans le management de projet sont de bons candidats à la Certification Agile PMI.
En obtenant la certification Agile, les chefs de projet peuvent :
Démontrer aux employeurs leur niveau de professionnalisme dans les pratiques Agiles de management de projet
Augmenter leur polyvalence professionnelle dans des outils et des techniques de management de projets
Démontrer qu’ils ont la capacité à mener des équipes de projet Agiles en possédant une certification qui est plus crédible que les offres basiques existantes de formations seules ou examens seuls
PMI sert la profession de management de projet en fournissant les chefs de projet avec une sélection d’outils de techniques — et Agile est l’un de ceux-ci. Par exemple, ceux qui ont la certification PMP® et travaillent dans une organisation qui utilise des techniques Agiles, trouveront dans la Certification Agile une base de connaissances applicable des principes et des concepts Agiles.
Apprenez-en davantage sur le pilote de Certification Agile
Le pilote de Certification Agile PMI est ouvert au public et à tout pratiquant du management de projet qui réunit les pré-requis d’admissibilité. PMI cherche actuellement des candidats pour ce pilote et ils pourront s’inscrire en ligne ou sur papier pour la certification à partir de mai 2011. L’examen de Certification Agile PMI débutera pendant le troisième trimestre de 2011. Pour en savoir davantage sur ce pilote, lisez le Document de FAQS (FOIRE AUX QUESTIONS) sur la Certification Agile.
Pour recevoir des nouvelles de ce Pilote de Certification Agile PMI, envoyez un message en anglais à AgilePilot@PMI.org
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
La dette technique et la dette de design sont des métaphores synonymes se référant aux conséquences finales d’une pauvre architecture logicielle et d’un développement logiciel à la va vite. La dette de code se réfère à la dette technique dans un code de programmation de logiciel.
Ward Cunningham a fait la comparaison entre la complexité technique et la dette dans un rapport de retour d’expérience 1992 :
La livraison du premier code ressemble au fait de s’endetter. Une petite dette accélère le développement tant est qu’elle soit remboursée promptement par une réécriture … Le danger se présente lorsque la dette n’est pas remboursée. Chaque minute passée sur du code pas tout à fait exact s’ajoute alors aux intérêts de cette dette. Des organisations entières d’ingénierie informatique peuvent parvenir à un blocage total sous le poids des dettes d’un développement non consolidé qu’il soit orienté objet ou pas.
Les développements réalisés en amont dans le projet peuvent augmenter le coût “du remboursement de la dette” à l’avenir. Une équipe devrait saisir les occasions, sur une base régulière de rembourser (ou régler) cette dette. Réservez un pourcentage de votre cycle de développement ou dédiez un cycle entier pour compléter ce travail. Si vous ne le faites pas, il reviendra vous hanter. Si votre bidouille de solution ne revient pas pour mordre l’équipe de développement, elle hantera probablement le « help desk », l’équipe de support, ou quelqu’un d’autre en aval.
Comme toute dette, vous vous trouvez devant l’obligation de la rembourser tôt ou tard. En tant qu’ancien Manager de Génie logiciel et maintenant que conseiller auprès de mes clients, j’ai vu (et vois) ce que la dette technique peut avoir comme impact sur la vélocité d’une équipe. Elle les prive de temps précieux, après coup. L’équipe de développement achète l’idée que faire les choses de la mauvaise manière, fait gagner du temps dans l’intérim et que cela justifie les risques et le coût total. C’est vraiment un processus de pensée à court terme. La dette technique ressemble à l’obtention d’un prêt d’usurier qui jetterait les dés pour décider de votre taux d’intérêt. Aussi, si vous n’êtes pas absolument obligés de prendre le risque, ne le faites pas.
Soyez honnête avec votre client, votre équipe et vous-même. Évaluez votre travail et tenez vos estimations. Ne laissez pas quelqu’un d’autre vous dire combien de temps il faudra pour livrer un travail de qualité. Si vous y êtes forcés, vous devrez juste délivrer moins de travail. Donc, ne prenez pas de dette en premier lieu.
Convaincre votre directeur financier (Chief Financial Officer: CFO) et autres cadres sup de votre société d’utiliser Scrum est en réalité très simple, dans la théorie. Essayez cette stratégie la prochaine fois vous devez aider des exécutifs à comprendre pourquoi Scrum est un processus important et utile pour le développement logiciel.
Selon mon expérience, les experts financiers et les directions sont très attentifs à savoir ce qui arrivera si de certaines situations se produisent et veulent souvent simuler des scénarios dans leur stratégie de management des risques.
La meilleure approche dans cette situation est d’exposer la valeur business que vous livrerez si le projet devait s’arrêter en cours d’exécution.
Il y a plusieurs raisons pour lesquelles des projets de développement de logiciel sont arrêtés avant leur date de fin :
sévères compressions budgétaires
changement de priorités de projet,
la société a été rachetée
le budget approuvé n’est pas suffisant pour couvrir le périmètre complet du projet
En justifiant au management pourquoi utiliser utiliser Scrum il y a quelques années, nous avons posé cette question à la direction : Et si le projet devait être arrêté à environ 60 % de son effort ou calendrier ?
Le projet W a un modèle de réalisation et une dépense typique par phase :
10 % du temps/effort concernent la préparation et la définition du projet
25 % du temps/effort sont passés sur une analyse minutieuse du livrable logiciel
40 % du temps/effort sont passés sur le développement et les tests de système
20 % du temps/effort concernent les tests d’intégration et de recette ainsi que les corrections de bogue
5 % du temps/effort sont requis pour mettre le logiciel en production et le lancer avec les clients.
Comme vous pouvez voir, si on ordonne à l’équipe d’arrêter le développement à 60 % du parcours dans ce processus nous serons en réalité en plein milieu de l’écriture de code et de l’exécution de quelques tests système. Dans ce scénario, « la valeur » que le projet W délivre à la société est en fait un tas de documents d’analyse et un morceau de logiciel non testé.
Maintenant jetons un coup d’œil au modèle de dépense du Projet S, fonctionnant en mode Scrum:
10 % du temps/effort concernent la préparation et la définition du projet
85 % du temps/effort sont passés à analyser, développer et tester des incréments de fonctionnalités qui sont livrés itérativement dans des « sprints » bihebdomadaires
5 % du temps est nécessaire pour clôturer correctement le projet
Si le Projet S doit s’arrêter à 60 % en temps ou en effort dépensé, l’équipe aura déjà complété une bonne quantité de sprints et délivré un certain logiciel utilisable. Dans ce scénario, le projet S délivre une valeur réelle et des fonctionnalités utilisables (probablement environ 40 % à 50 % du produit total) au client.
Dans l’entretien avec la direction, nous avons utilisé un graphique sur la valeur acquise pour mieux illustrer notre point. Il inclut les suppositions suivantes :
Le démarrage et la définition d’un projet / produit correspondent à 0 % de la valeur totale
La documentation d’analyse et de conception représente 15 % de la valeur totale
Le code source avec les tests unitaires système correspondent à 35 % de la valeur totale
Le logiciel complètement testé et packagé représente 50 % de la valeur totale
Notre directeur financier et les autres cadres supérieurs ont décidé de commencer à utiliser Scrum pour nos développements de nouveaux produits parce qu’ils croient fermement que, d’une perspective de management des risques de la société, il vaut mieux utiliser Scrum qu’un développement par phase.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
DantotsuPM.com 
