articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
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.
Publié par Équipe PCO DexterIT sur leur blog.
La fonctionnalité de nivellement automatique de ressources de MS Project peut, malgré sa puissance, entraîner sur votre plan des modifications dont il est difficile de comprendre les impacts, surtout lorsque le plan est complexe.
Voici une méthode qui vous permet de faire un nivellement manuel des ressources grâce aux vues « excel-like » d’utilisation.
La vue d’utilisation des ressources permet de visualiser les tâches affectées à chaque ressource. La partie de droite de votre écran présente un tableur dont on peut changer l’échelle (jour, semaine, mois) pour changer la valeur du travail.
lire les détails sur le blog dexerit
Vincent Capitaine, Consultant Senior – Management de projet et de portefeuille – MCTS, MCITP & Microsoft Project MVP, nous propose sur son blog un article sur la gestion des tâches critiques et des chemins critiques dans Microsoft Project.
Vous y apprendrez, si (comme moi-même) vous ne le saviez pas encore, qu’ il est possible dans l’outil d’afficher le chemin critique de chaque sous-projet et non seulement le chemin critique global grâce à l’option « Calculer les chemins critiques multiples ».
Ou encore de mettre en place votre propre définition de ce qu’est une tâche critique en fonction par exemple de la marge disponible sur une tâche. L’option « Tâches critiques si la marge est inférieure ou égale à x jours » permet en effet de considérer comme critiques des tâches qui ont une marge libre inférieure au nombre de jours que vous fixez (0 jour est le défaut).
Au sein du bureau de PMI France-Sud, nous avons souvent discuté de comment amener les jeunes à s’intéresser plus tôt au management de projet et en comprendre l’intérêt dès leur parcours étudiant. Nathalie Hesters de Microsoft nous propose un jeu qui saura motiver vos ados. A la clef, la possibilité pour eux de gagner un séjour de rêve !
Par équipe de 2 à 3, le principe du jeu consiste à mettre en pratique les concepts de management de projet entre le 24 octobre et le 2 décembre 2011 en utilisant Microsoft Project 2010 (téléchargeable gratuitement par les participants, cf lien en bas de l’article).
Le principe est simple : manager au mieux son budget, ses ressources et gérer le temps pour construire des hôtels et marinas sur une île artificielle et en obtenir la meilleure rentabilité.
Les 5 premières équipes viendront présenter leur stratégie dans les bureaux de Microsoft France, face à un jury de professionnels. Pour en savoir plus sur le concours, cliquez ici ou sur Facebook ou bien sur l’image ci-dessous.
A gagner – un séjour au choix : Ibiza, Djerba, Grèce pour la meilleure équipe et un lot pour chacun des membres des 9 équipes suivantes !
Un billet de Estelle Groult que j’ai eu le plaisir de rencontrer à l’anniversaire des 10 ans de PMGS.
Estelle est consultante certifiée PRINCE2® Practitioner et PMP®, formatrice accréditée PRINCE2®. Estelle a une dizaine d’années d’expérience ( dont sept passées aux États-Unis et à Londres) en management de projets organisationnels et assistance à maîtrise d’ouvrage (MOA) en gestion financière. Estelle intervient sur des missions d’accompagnement en management de projet, assistance à MOA, optimisation de structures PMO, ainsi que formation aux techniques de management de projet (fondamentaux du management de projet et des approches PMP® et PRINCE2®, préparation aux examens PMP®, CAPM®, et PRINCE2®). http://estellegroult.net
En début d’année il m’a été proposé de contribuer à une étude menée par allPM.com sur les meilleurs standards en management de projet. Connaissant bien le PMBoK® et PRINCE2® pour les avoir appliqués à mes projets, j’ai concentré mon analyse sur ces deux approches en donnant des exemples basés sur mon expérience.
Après la plupart des formations que je donne, on me pose très souvent la question sur la meilleure méthode à adopter en management de projet. Il n’est pas évident de répondre de manière directe à cette question ; les deux standards les plus reconnus (le PMBoK® et PRINCE2®) proposent ce qu’on appelle de bonnes pratiques pour réussir un projet, mais ils présentent dans leur approche quelques différences qui me semblent intéressantes.
Je passe sur les différences dans la façon de planifier un projet (décomposition par produit dans PRINCE2® vs. décomposition du travail dans le PMBoK®) car à mon sens ce sont les plus connues.
PRINCE2® ne couvre pas, ou très peu, certains domaines de connaissances comme le leadership et les compétences en management d’équipe. Ces sujets sont par contre détaillés dans le PMBoK®; Comment gérer des équipes multiculturelles? Comment résoudre les conflits au sein de l’équipe projet ou entre les parties prenantes? Le PMBOK® consacre également un domaine de connaissances à la gestion des achats et de la sous-traitance indispensables au bon fonctionnement des projets. Comment planifier les achats? Comment sélectionner les fournisseurs? Comment gérer les contrats et les ressources externes?
La méthode PRINCE2® est définie autour de sept principes à commencer par la justification du projet (en d’autres termes l’élaboration d’un business case ou cas d’affaire). Le business case détermine les résultats et bénéfices attendus. Tout au long du cycle de vie du projet, le business case est régulièrement revu, et l’approche PRINCE2® incite le chef de projet à s’assurer que les bénéfices se réalisent au cours du projet ou une fois le projet terminé (revue des bénéfices post-projet).
Le management par exception est également essentiel dans l’approche PRINCE2®. Ce principe met en évidence le rôle de l’exécutif ou sponsor du projet. La définition de la gouvernance de projet ainsi que celle des rôles et responsabilités sont déterminantes. Des limites ou seuils de tolérance sont définis pendant la phase de planification ; elles vont permettre au chef de projet, lors de l’exécution, d’agir par des actions correctives sur les composantes du projet (budget, délai, qualité, périmètre, risques, bénéfices attendus) sans l’intervention du sponsor ou comité de pilotage. Au-delà de ces limites, les écarts remontent au niveau de l’exécutif pour prise de décision. Sur des projets appliquant l’approche PRINCE2® j’ai pu me rendre compte de l’importance de ce principe. L’exécutif (en l’occurrence, le directeur du programme qui couvrait mes projets) apportait un véritable soutien à ses chefs de projet.
J’ai interrogé Richard Pharro, directeur de APMG-International, au sujet des avantages pour les organisations à adopter PRINCE2® : « Les avantages les plus cités par les entreprises qui adoptent PRINCE2® sont la gouvernance des projets et la définition des rôles et responsabilités. Il existe également une importance croissante accordée à la définition d’un solide business case, un meilleur alignement des projets à la stratégie d’entreprise. La crise financière de ces dernières années a en effet mis en évidence l’importance de ces principes. »
PRINCE2® est un modèle de processus qui décrit comment sept principes peuvent aider à minimiser les risques et réaliser les bénéfices définis dans le business case.
Le PMBoK® propose également un modèle de processus (Initialisation – Planification – Exécution – Suivi et contrôle – Clôture) mais il n’est pas aussi détaillé que celui proposé par PRINCE2®. L’accent est mis sur les outils et techniques développés au sein de chaque domaine de connaissances (coût, temps, risques, qualité, communication, etc), alors que l’accent mis dans PRINCE2® est sur les étapes à franchir pour réaliser un projet du début jusqu’à la fin. La méthode PRINCE2® permet de répondre plus facilement aux questions «par quoi commencer? Et par quoi terminer? »
Finalement ces deux approches sont relativement complémentaires. Comme indiqué par l’OGC, « PRINCE2® ne couvre pas tous les aspects du management de projet. Certains domaines comme le leadership et les compétences en management d’équipes, ainsi que les outils et techniques en management de projet sont détaillés par d’autres méthodes existantes qui ont fait leur preuve. »
La certification PMP® nécessite de prouver un certain nombre d’années d’expérience en management de projet, suivre une formation en management de projet, passer un examen de quatre heures, et s’engager à obtenir des PDU (Professional Development Units), indispensables au maintien de la formation PMP® (cycle de 60 PDUs tous les 3 ans). Fin 2010, le PMI® comptait environ 430 000 certifiés PMP®.
La certification PRINCE2® est une approche basée sur la connaissance de la méthode elle-même avec deux niveaux « fondamental » et « praticien ». Ce dernier, l’équivalent de la certification PMP® pour le PMI® s’adresse à des chefs de projet expérimentés. La certification PRINCE2® consiste en un test basé sur la compréhension de la méthode par opposition à l’expérience. La certification PRINCE2® ne nécessite pas que le candidat prouve son expérience en management de projet, mais il sera difficile de comprendre pleinement le modèle de PRINCE2® et l’utiliser correctement, surtout au niveau praticien, sans expérience confirmée en management de projet.
«Fin 2010 plus de 750.000 examens PRINCE2® (dont 35% niveau praticien) ont été enregistrés. La méthode est reconnue à l’international notamment en Europe (solidement implantée au Royaume-Uni) et en Australie. » Kate Winter, PR Manager, APMG-International.
J’ai pu remarquer que de plus en plus d’organisations concilient les deux méthodes sur leurs projets.
Après quelques années d’expérience, mon conseil sera alors d’utiliser et d’adapter les standards de manière à offrir le plus d’avantages à vos projets ; un chef de projet passe plus de 90% de son temps à communiquer avec son sponsor, ses équipes, ses clients, et autres parties prenantes. Passer du temps à développer des compétences en management d’équipe et gestion de la communication, domaines traités par le PMBoK®, n’est pas à négliger.
PRINCE2® offre une liste complète de modèles de livrables (« templates » en anglais), qui est une excellente source d’information. Certains modèles, comme l’exposé du projet (l’équivalent de la charte de projet du PMBoK®) et le document d’initialisation du projet, permettent de définir toutes les étapes de démarrage du projet. D’autres modèles m’ont été très utiles (ex. les rapports d’exception, la gestion des incidents, des leçons apprises, etc.). La méthode PRINCE2® est totalement adaptable, de sorte qu’il n’est pas nécessaire d’utiliser tous ces modèles proposés sur chaque projet (par exemple un exposé de projet détaillé peut suffire et simplifier la phase d’initialisation du projet).
Les deux approches sont reconnues à l’international, mais ceci ne répond pas à la question initiale ; faut-il commencer par étudier le PMBoK® et ensuite s’intéresser à PRINCE2® pour comprendre comment s’articulent toutes ces connaissances en management de projet ? Ou commencer par PRINCE2® comprendre les principes de base, qui doit faire quoi, (rôles et responsabilités, gouvernance, business case), quand (modèle de processus) et compléter le tout par les outils et techniques du PMBoK®?
Je pense que la meilleure façon de voir les choses va dépendre du parcours et des objectifs professionnels de chacun ; le secteur d’activité dans lequel on évolue, la culture de l’entreprise que l’on vient de rejoindre, le pays dans lequel on souhaite s’installer, etc. N’oublions pas que les certifications sont, avant toute chose, un moyen efficace de partager un langage commun en management de projet. Les opportunités de poste peuvent aider à prendre la décision. Personnellement, la méthode PRINCE2® était fortement recommandée dans l’institution financière dans laquelle je travaillais à Londres. De retour en France j’ai eu de belles opportunités pour travailler sur des projets utilisant le PMBoK® . Ai-je ressenti le besoin d’obtenir une certification supplémentaire au-delà de PRINCE2®? Honnêtement non, mais j’avais tort. Avec la certification PMP® et mon expérience des pratiques du PMBoK® j’ai pu développer des compétences dans des domaines dans lesquels j’étais moins familière et démontrer ainsi mon envie d’évoluer professionnellement.
Nathalie Hesters, Product Manager pour Microsoft Project et Visio, a réalisé cette nouvelle vidéo qui présente la solution Microsoft de bout en bout en matière de management de projet.
En une douzaine de minutes, elle réalise une démonstration par l’exemple depuis l’établissement de critères de sélection des projets jusqu’à l’exécution, le suivi de la progression et les reporting associés à ce portefeuille et à l’ensemble des projets qui le compose.
par Lisa Drake
Avez-vous jamais entendu parler de « time boxing » ? Le « time boxing » revient à définir une période fixe dans le temps pour travailler sur une tâche particulière ou un groupe de tâches. Essentiellement, au lieu de travailler sur une tâche jusqu’à ce qu’elle soit finie, vous vous engagez à y travailler pour un laps de temps spécifique.
De quoi vous avez besoin : le seul gadget dont vous aurez besoin est un temporisateur (celui de votre téléphone cellulaire, de votre PC ou de votre cuisine).
Surmonter la procrastination : Pour vous aider à surmonter votre tendance à la procrastination sur certaines tâches, mettez-les dans une « time box ».
Microsoft Project Conference 2012 est le plus important événement international pour partager sur les meilleures pratiques MS Project et Portfolio Management.
La conférence se tiendra à Phoenix en Arizona du 19 au 22 mars 2012.
Si vous avez des meilleures pratiques et expériences réussies que vous aimeriez partager sur Microsoft’s Project Portfolio Management (PPM) et MS Project, vous pouvez proposer de le faire (en anglais bien sûr) à la Microsoft Project Conference 2012 !
The Scrum Framework
Lyssa Adkins qui se présente comme une coach de Coach Agile (les ScrumMasters par exemple), montre dans cette vidéo comment expliquer Scrum à quiconque en reprenant dans un graphique les principes clés de cette approche. Lyssa est l’auteur du livre Coaching Agile Teams.
The Wedding Cake
Elle va plus loin avec cette démonstration de comment expliquer très simplement les différences et les bénéfices qu’il y a à adopter une approche Agile.
http://kenschwaber.wordpress.com/2011/05/03/empiricism-the-act-of-making-decisions-based-on-what-is/
Par Ken Schwaber
L’empirisme est l’acte de prendre des décisions basé sur ce qui est. Scrum est un processus empirique, parfois décrit comme “l’art du possible.” Par cela, je veux dire que nous faisons du mieux nous pouvons avec ce que nous avons.
Un Propriétaire de Produit (« Product Owner ») planifie une version (« release ») basée sur toutes les informations actuellement disponibles. Il ou elle définisse les objectifs, les fonctionnalités et les capacités qui délivreront ces buts ainsi que le coût probable et la date de livraison. À partir de ce moment-là, le travail du Propriétaire de Produit est d’évaluer ce qui est possible vu les capacités de l’Équipe et de prendre les meilleures décisions pour atteindre l’objectif souhaité. Étant donné la nature de la technologie, des marchés, des besoins et des personnes, des compromis sont faits. Parfois le but ne peut pas être atteint pour un prix raisonnable. Parfois le but sera atteint, mais d’une manière différente de ce que le Propriétaire de Produit pensait initialement. C’est l’empirisme en pleine action.
L’Équipe (de développeurs) sur l’Équipe Scrum fait de même. Elle rencontre le Propriétaire de Produit et évalue ce que le Propriétaire de Produit voit comme les choses les plus importantes à faire ensuite. Si réalisées, celles-ci dirigeront le produit émergent dans la meilleure direction vers le but désiré. L’équipe choisit autant de choses qu’elle croit pouvoir en faire pendant le prochain Sprint. Le coût de l’équipe et la longueur de Sprint est fixe. Seule la quantité d’items du « Product Backlog » choisie peut varier. Le Propriétaire de Produit et l’Équipe définissent souvent un objectif pour le Sprint. C’est un sous-ensemble des objectifs de la version (« release »).
Quand l’équipe choisit des items lors d’une réunion de Planification de Sprint, elle s’engage à le faire pendant le Sprint.
Une définition « s’engager » est : « Se lier moralement par une promesse : Il s’est engagé à payer ses dettes dans les huit jours. » selon le Larousse. (ndlt)
Cela correspond à ma compréhension du mot s’engager, qui est une promesse, un engagement à un plan d’action.
Cependant, beaucoup d’équipes Scrum utilisent le mot « s’engager » comme si c’était « une garantie ». C’est un reste des méthodes en cascade, où une évaluation était un contrat. Cependant, cela résonne toujours dans les têtes de propriétaires de produit et des développeurs. J’ai trouvé équipes après équipes qui estiment qu’elles doivent tout faire pour respecter leur engagement. La victime est habituellement la qualité.
Je me demande si nous devrions échanger le mot « s’engager » pour celui de “prédire” ?Ceci pourrait donner la même impression que la présentatrice météo essayant de nous fournir les meilleures informations possibles. Elle fait avec que l’on connaît et avec la science de la météorologie. Elle ne fournit pas de garantie, mais quelque chose que nous pouvons utiliser pour prendre des décisions. Les prévisions sont également utilisées par les organisations de ventes. Peut-être cette clarification nous aidera-t-elle à comprendre qu’ « un engagement » dans Scrum est une promesse de faire de notre mieux avec ce que nous avons.
http://blog.castsoftware.com/technical-debt-no-penalty-for-early-payment/
Posté Par Jon sur le blog de Cast Software
Nous sommes une société de débiteurs. Nous nous endettons pour nos voitures, nos maisons, et grâce aux cartes de crédit nous nous endettons même pour l’épicerie et l’essence.
Dans le développement logiciel, comme dans la vie, avoir un peu de dette peut en réalité être une bonne chose pour faire progresser des choses plus critiques. Bien que dans des blogs précédents nous ayons défini la dette technique comme « le coût pour réparer des problèmes de qualité structurels d’une application qui, si laissés défectueux, pourraient mettre le business en danger », engager une petite et raisonnable somme de dette technique peut en réalité faire avancer le projet plus rapidement et faciliter l’atteinte de l’objectif d’avoir un logiciel exécutable. C’était la pensée de Ward Cunningham, le créateur du concept de dette technique.
Mais comme Derek Huether l’indique dans son blog de conseils technologiques pour le Dumas Lab à propos de la Dette technique : « Comme toute dette habituelle, vous vous trouverez tôt ou tard devant le besoin de la rembourser. »
Huether note aussi que tout comme une dette dans nos vies personnelles, si non remboursée, d’une façon ou d’une autre :
…elle reviendra pour vous hanter. Si votre bidouille d’une solution ne revient pas mordre l’équipe de développement, elle hantera probablement le bureau de support technique, l’équipe de support, ou quelqu’un d’autre en aval.
Il ajoute alors :
Comme toue dette, vous vous retrouvez devant le besoin de la rembourser tôt ou tard …, j’ai vu (et vois) ce que la dette technique peut faire à la vélocité d’une équipe. Elle les prive d’un temps précieux, après coup. L’équipe de développement achète l’idée que faire des choses de la mauvaise manière, qui peut sauver un peu de temps dans l’immédiat, vaut les risques et le coût total. C’est vraiment une vue à court terme du processus de réflexion. La dette technique ressemble à l’obtention d’un prêt d’un usurier qui lance les dés pour décider de votre taux d’intérêt. Aussi, si vous n’êtes pas obligés de prendre le risque, ne le prenez pas.
Mais la dette technique est-elle vraiment une proposition de type tout ou rien ?
Combien est assez ?Quand elle en vient à la Dette Technique, une société doit déterminer combien, si quoi que ce soit, devrait être investit pour y remédier. La meilleure façon de le faire est en donnant une valeur monétaire (en monétisant) la dette technique pour donner une valeur financière à la qualité structurelle de l’application. Cela permet de comparer les coûts informatiques aux pertes potentielles coté business en raison d’un échec qui n’était pas possible précédemment (avant de contracter cette dette).
Le but de monétiser la dette technique est de maintenir le nombre de violations de la qualité structurelle – ou ce qui est plus important, le coût de les réparer – bien en dessous du coût que la société encourrait si le logiciel devait être déployé et aboutir à un échec.
Pour déterminer le point de basculement des problèmes de qualité structurelle et du coût pour les réparer, une société devrait utiliser une plate-forme d’analyse et de mesure automatisée pour évaluer la qualité structurelle de leurs cinq applications les plus cruciales à la mission de l’entreprise. La façon dont chacune de ces applications est construite, leur qualité structurelle devrait être mesurée à chaque version majeure et une fois qu’elles fonctionnent, la qualité structurelle de l’application devrait être mesurée chaque trimestre.
La clé est de garder un œil vigilant sur le compteur des violations; contrôlez les changements et calculez la Dette Technique de l’application après chaque évaluation de qualité. Quand une valorisation monétaire de la dette technique a été vérifiée, elle peut être comparée à la valeur business pour déterminer combien de Dette Technique est trop et combien reste acceptable par rapport au retour marginal sur la valeur business. Pour établir une structure pour calculer la perte de valeur business en raison des violations de qualité structurelles, nous recommandons “The Business Value of Application Internal Quality” par Dr. Bill Curtis.
Une fois que ce point de basculement est déterminé, une société peut décider où et quand elle doit aborder les problèmes de qualité structurelle qui ont créé la dette technique.
La partie agréable de se débarrasser de dette technique est la même que pour la dette personnelle: cela évite le paiement de plein d’intérêts. Pourtant, il n’y a aucune pénalité à rembourser en avance… en fait, cela apporte une récompense significative grâce à un logiciel de meilleure qualité.
A l’occasion du sommet Gartner du mois dernier en Californie, le « Gartner PPM & IT Governance Summit » à San Diego, les analystes de ce groupe ont publié le « MarketScope for Project and Portfolio Management Applications » que vous pourrez lire dans son intégralité en cliquant sur ce lien.
Notre partenaire Microsoft y a obtenu la plus haute distinction « Strong Positive rating », validant les choix stratégiques de placer SharePoint au cœur de la solution intégrée en management de projet et portefeuille de projets que ce soit pour le workflow, la gestion de documents ou la collaboration.
Source: Gartner (June 2011)
Par Marc Biarnès, Escalation Engineer, CSS – EMEA Project Team, Microsoft France
Description de SP1: http://support.microsoft.com/kb/2460052/fr
Le Service Pack contient:
Le Cumulative Update (CU) de juin 2011 contient tous les correctifs jusqu’au mois de juin.
Il y a des packages indépendants pour les Service Packs (SP -> 60xx) et les Cumulative Updates (CU -> 61xx). Ils peuvent être installés dans n’importe quel ordre mais Microsoft recommande l’ordre suivant:
Unique exécution du PSConfig (sur chaque serveur), le n° de version est visible. Distribution par Windows Update manuelle pendant 90 jours puis distribution automatique.
1. Support Multi Navigateurs : Support de « Internet Explorer 9 in Internet Explorer 8 Standards Mode, » ainsi que le support de Google Chrome, Firefox et Safari.
2. Synchronisation des tâches : Avant SP1, la synchronisation était limitée aux tâches manuelles. Avec SP1, la synchronisation des tâches automatiques est supportée et le changement de dates est mis à jour dans Project Pro.
3. Support du « Timephased Tracking », le suivi des heures effectuées par période de temps, sur toutes les tâches, y compris les tâches manuelles pour lesquelles ce n’était pas le cas auparavant: Il est donc possible de reporter du temps dans My Tasks et Timesheets sur toutes les tâches. Cette nouvelle fonctionnalité est supportée par le client et le serveur et nécessite l’installation du SP1 sur le client ET sur le serveur. Attention, ne fonctionne pas si le Backward Compatibilty Mode (BCM) est activé.
4. Edition des projets contenant des tâches à Travail Fixe et Piloté par l’effort dans Project Web Access : Il est maintenant possible d’éditer des plans contenant des tâches Travail Fixe et Pilotées par l’Effort dans Project Web App
5. Auto Publication : Une nouvelle fonctionnalité qui facilitera la vie des chefs de projet, en particulier ceux qui gèrent de nombreux projets : La possibilité si on le souhaite de publier automatiquement les mises à jour de son projet par une règle similaire à celle permettant d’accepter automatiquement des feuilles de temps.
PMI revoit très régulièrement ses standards pour s’assurer qu’ils continuent de coller à la réalité du terrain et de s’enrichir des meilleures nouvelles pratiques. Pour autant, le standard des meilleures pratiques pour le découpage en tâches du projet ne change pas cette année suite à un examen détaillé par trois experts praticiens du management de projet.
écrit par Neil Stolovitsky de Genius Inside
Agile fait beaucoup de bruit actuellement dans les milieux de développement de logiciels. La méthode a été créée par des développeurs pour des développeurs. Son origine remonte à 10 ans lorsqu’un groupe de développeurs ont mis en place l’Agile Manifesto dans une station de ski dans l’Utah. Ce manifeste visait à établir pour les projets de développement de logiciels un système plus inclusif, démocratique et efficace. Il en a résulté plusieurs méthodologies Agile dont notamment Crystal Clear, Scrum et Extreme Programming, toutes créées afin de mettre en place des équipes de projet autonomes qui placent la responsabilité dans les mains de chaque personne qui touche le projet.
Ceci est une toute nouvelle approche de gestion des équipes de projet. Les groupes de développement de logiciels doivent être très prudents lorsqu’ils déploient Agile dans leur organisation, car les équipes sont en général habituées à être surveillées et guidées tout au long du projet. En réalité, il y a de nombreux points à considérer avant d’implémenter Agile afin d’être sûr que les changements proposés par Agile soient positifs et non négatifs par rapport au processus existant. Voici les cinq points les plus importants pour vous aider à déterminer si la méthode Agile est la bonne pour vos développeurs:
Une culture trop différente est l’une des raisons principales à l’échec d’un environnement de travail de gestion de projet. Les environnements Agile sont autonomes, ils font face aux clients et sont démocratiques par nature. Tous les groupes de développement cherchant à adopter Agile doivent avant tout se demander si ces principes sont en accord avec la culture et les valeurs de la société ? S’ils sont en complète opposition, les chances de réussite sont minimes. La dernière chose à faire est de démarrer du mauvais pied!
La plupart des environnements de travail en management de projet réussissent simplement avec une bonne adhésion du leadership. Même si la culture de la société est adéquate, Agile nécessite une adhésion complète depuis la base dès le départ. Chaque personne a un rôle à jouer: des clients aux développeurs, étant donné que chaque personne a sa part de responsabilité avec Agile.
Est-ce que votre société est prête pour un changement? Étant donné qu’Agile requiert un changement d’envergure, il est primordial qu’une stratégie de gestion du changement soit en place afin de minimiser les risques et d’assurer une transition en douceur entre l’ancienne et la nouvelle manière de faire les choses.
La méthodologie Agile nécessite une compréhension complète de sa philosophie et de son environnement de travail dès le début. Cette méthodologie nécessite la participation de tous les membres de l’équipe, il est important que chacun connaisse l’ensemble du processus ainsi que sa propre contribution. Toute autre approche risque de faire échouer son implémentation.
La base de l’efficacité des projets Agile est l’effort concerté de mise en place d’un système qui permette une collaboration efficace entre les parties prenantes internes et externes. Vous devez vous non seulement vous demander s’il existe dans votre société une stratégie de communication efficace, mais surtout vous devez être sûr que vos clients seront prêts à s’investir lourdement dans le développement de leurs projets.
Pour en savoir plus au sujet de la méthodologie Agile, regardez ce bref (6′) et récent web cast (ci-dessous en anglais) et livre blanc (en anglais également).
http://www.allaboutagile.com/10-good-reasons-to-do-agile-development/
by Kelly Waters
Voici 10 bonnes raisons d’appliquer les principes et pratiques de développement agiles …
1. RevenusLa nature itérative du développement Agile implique que des fonctionnalités sont livrées de façon incrémentale, ce qui permet de commencer à encaisser des revenus pendant que le produit continue d’être développé.
La recherche suggère qu’environ 80 % de tous les leaders du marché ont été les premiers à commercialiser sur ce marché. En sus d’un revenu plus élevé grâce à une livraison progressive, la philosophie de développement Agile supporte aussi la notion de sorties en avant-première et de versions régulières et les versions « perpétuellement bêta ».
Un principe clé de développement Agile est que les tests sont intégrés tout au long du cycle de vie. Ce qui permet une inspection régulière d’un produit fonctionnel en cours de développement. Cela permet au propriétaire de produit (le « product owner ») de faire des ajustements si nécessaire et donne à l’équipe de produit la primeur de tout problème de qualité.
Les principes de développement Agile encouragent la participation active des utilisateurs tout au long du développement du produit dans une approche collaborative très coopérative. Cela fournit une excellente visibilité aux principales parties prenantes, à la fois sur l’avancement du projet et sur le produit lui-même, ce qui aide à son tour à s’assurer que les attentes sont gérées efficacement.
De petites versions progressives donnent de la visibilité au « product owner » et à l’équipe produit pendant le développement, permettent d’identifier les problèmes au plus tôt et facilitent la réponse à ceux-ci. La visibilité claire dans le développement Agile aide à s’assurer que les décisions nécessaires peuvent être prises le plus tôt possible, pendant qu’il reste du temps pour apporter une différence substantielle sur le résultat.
Dans des projets de développement traditionnels, nous écrivons de grandes spécifications au préalable et disons ensuite aux responsables business combien il est coûteux de changer quoi que ce soit, particulièrement quant le projet avance. Dans la crainte de dérive du contenu et de projet interminable, nous résistons aux changements et faisons passer les personnes par un comité de contrôle des changements pour les réduire au minimum vital. Les principes de développement Agile sont différents. Dans le développement Agile, le changement est accepté. En fait, on s’y attend. Parce qu’une chose certaine dans la vie est le changement. Au lieu de cela la durée est fixe et les exigences apparaissent et se développent comme le produit est développé. Bien sûr, pour que cela fonctionne, il est impératif d’avoir des parties prenantes impliquées qui comprennent ce concept et prennent les décisions de compromis nécessaires, négociant le contenu existant pour un nouveau.
La susdite approche de durées fixes et besoins en évolution permet d’avoir un budget fixe. Le contenu du produit et ses fonctionnalités sont variables, plutôt que le coût.
8. Satisfaction du client/business La participation active d’un représentant des utilisateurs et/ou un propriétaire de produit (« product owner »), la forte visibilité du produit et de l’avancement et la flexibilité de changer quand le changement est nécessaire, créent un bien meilleur engagement du business et la satisfaction du client. C’est un bénéfice important qui peut créer des relations de travail beaucoup plus positives et durables.
Par-dessus tous les autres points, la capacité des besoins de développement Agile à émerger et à évoluer et la capacité d’embrasser le changement (avec le compromis approprié), fait que l’équipe construit le bon produit. Il est trop commun dans des projets plus traditionnels de livrer un projet « réussi » coté informatique et de constater que le produit n’est pas ce à quoi on s’attendait, dont on avait besoin ou que l’on espérait. Dans le développement Agile, l’accent est mis absolument sur la construction du bon produit.
L’engagement actif, la coopération et la collaboration font des équipes de développement agiles un endroit beaucoup plus agréable pour la plupart des personnes. Au lieu de grandes spécifications, nous discutons des besoins dans des ateliers. Au lieu des longs rapports d’avancement, nous collaborons autour d’un tableau des tâches, discutant du progrès. Au lieu des longs plans de projet et des Comités de Gestion de Changement, nous discutons de ce qui est juste pour le produit et le projet et le L’équipe est autorisée à prendre des décisions. Dans mon expérience, cela donne une approche beaucoup plus utile pour chacun. À son tour, cela aide à créer des équipes fortement motivées, à haute performance qui sont fortement coopératives.
Mais il y a des implications. Il n’existe rien de tel qu’un déjeuner à l’œil ! Et il n’y a aucune baguette magique pour le développement logiciel. Désolé, non, cela n’existe pas 🙂 En échange de tous ces avantages, vous obtenez moins de prévisibilité, le logiciel et les personnes restent complexes, vous ne pouvez plus blâmer quelqu’un d’autre si les choses ne se passent pas bien et cela exige généralement beaucoup plus d’engagement et d’effort de chaque personne impliquée – c’est-à-dire que la collaboration est encore plus importante.
Néanmoins, les bénéfices du développement Agile sont vraiment irrésistibles.
http://blogs.pmi.org/blog/voices_on_project_management/2011/04/prioritizing-agile-project-req.html
par Bill Krebs
Dans la gestion de projet Agile, nous devons prioriser une liste de demandes pour la planification de version, d’itération et l’insertion de nouveaux besoins ou exigences. Mais il y a plusieurs techniques pour le faire.
Une des méthodes les plus populaires pour déterminer la priorité des demandes est l’approche dite « MoSCoW ». Cela signifie ‘ Must (Doit), Should (Devrait), Could (Pourrait), Won’t (ne fera pas). ‘ Le seul problème avec cette méthode est que d’habitude tout est un Must, ce qui ne permet pas une planification appropriée parce que les besoins ne sont pas nécessairement placés dans leur ordre de priorité.
Une autre méthode est le modèle de Kano, développé par le Professeur Noriaki Kano, qui s’efforce de satisfaire les exigences et de faire plaisir aux clients. Ce modèle dispose de quatre composants :
• Must haves (doit avoir) sont des éléments sans lesquels on ne peut livrer le produit.
• Dissatisfiers (générateurs d’insatisfaction) sont des choses que le produit ne doit pas inclure.
• Satisfiers (générateurs de satisfaction) incluent besoins pour lesquels plus vous en avez mieux le produit sera perçu. Comme un catalogue commercial dans lequel chaque fonctionnalité ajoute progressivement de la valeur.
• Delighters (générateurs de plaisir) amènent le produit plus loin que simplement répondre aux exigences vers l’augmentation de la satisfaction client et la recommandation par le client.
Plusieurs modèles de priorisation réunissent deux variables dans un tableau pondéré : fonctionnalités et clients. Chaque fonctionnalité est pondérée par sa valeur pour chaque client. La somme des poids multipliés par le score permet de voir quelles fonctionnalités sont en général les plus utiles pour un jeu de clients exigeants.
Quel que soit la technique utilisée, votre liste d’exigences de projet doit être triée de la plus grande à la plus faible valeur.
Quelles techniques utilisez-vous pour prioriser les besoins ?
SimulTrain est un simulateur de formation en Management de Projet. Pour former des pilotes, on utilise un simulateur de vol – et pour former les chefs de projet, on utilise un simulateur de projet! Plus d’information sur SimulTrain sur Wikipédia.
SimulTrain® est un outil multimédia avec lequel les participants apprennent à:
Structurer et planifier un projet
Piloter le déroulement d’un projet
Utiliser les outils de gestion de projet
En participant à l’une de ces sessions d’une demi-journée, vous apprendrez tout ce qui est nécessaire à la mise en place et à l’utilisation de SimulTrain dans le cadre de vos formations et ses possibilités d’utilisation dans le perfectionnement des chefs de projet.
Tout ce dont vous avez besoin pour y participer est un ordinateur portable, la session est offerte.
Prochaines sessions:
PS : Le nombre de places étant limité par session, merci de nous retourner au plus vite votre demande d’inscription !
Marc Bonnemains, Conseil, développement d’affaires à l’international, a compilé une liste fort utile de différentes méthodes utilisées dans différents contextes.
Une nouvelle vidéo avec Nathalie Hesters (chef de produit Microsoft Project en France) pour avoir une vision d’ensemble de l’offre Microsoft autour de la gestion de projet : Microsoft Project 2010 et Microsoft Project Server 2010. A voir sur le site Microsoft Showcase !
DantotsuPM.com 