articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
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 !
Je vous avais en février dernier déjà indiqué un article qui traitait du sujet de la dette technique.
Voici de récentes études plus complètes réalisées par Cast Software et Gartner sur ce problème endémique du développement logiciel.
http://blog.castsoftware.com/gartner-cast-whitepaper-how-to-monetize-application-technical-debt/
L’automne dernier, Andy Kyte, Gartner VP, a jeté une lumière significative sur un fait connu depuis longtemps dans l’industrie technologique : des milliards de dollars sont dépensés sur la Dette Technique (Technical Debt, écoutez le Podcast en ligne à cette adresse) en coûts de réparation des problèmes de qualité structurels d’une application que, si laissés inchangés, pourraient causer des perturbations majeures et mettre le business à risque. Kyte dit que la Dette Technique a explosé ces dernières années; il a estimé la valeur actuelle de la Dette Technique à approximativement 500 milliards de $ à l’échelle mondiale et a dit qu’elle s’intensifiait rapidement vers la barre du 1 trillion de $ d’ici 2015.
Alors que Kyte annonçait ses résultats, CAST annonçait les résultats de sa propre Étude de Qualité Logicielle Mondiale d’Application (Worldwide Application Software Quality Study), dans laquelle ont été évaluées 288 applications informatiques de 75 sociétés partout dans le monde et dans une variété d’industries et qui comprennent un total de 108 millions de lignes de code. En utilisant une évaluation très, presque excessivement conservatrice du coût de maintenance par ligne de code pour réparer les problèmes découverts, nous avons estimé qu’une société de taille moyenne dépensait plus de 1 million de $ sur la Dette Technique d’Application.
Pour évangéliser ce problème et aider les services informatiques dans la construction d’une justification pour supporter l’amélioration des processus, des plate-formes et du personnel dans la qualité structurelle de logiciel, CAST a regroupé ses forces avec Kyte pour produire un papier blanc intitulé, « Comment Monétiser la Dette Technique d’Application : une Approche Pilotée par les données pour Équilibrer l’Agilité d’exécution avec le risque business » (How to Monetize Application Technical Debt: A Data-Driven Approach to Balance Delivery Agility with Business Risk).
Le papier de recherche illustre comment calculer la dette technique et ensuite établir et contrôler le bon niveau de qualité pour équilibrer l’agilité d’exécution avec le risque de perturbation du business. De plus, le papier inclut le rapport de recherche, « Mesurez et Gérez-le Votre Dette Informatique » (“Measure and Manage Your IT Debt”) écrit par Kyte, qui explique le risque systémique dans le portefeuille d’application causé par l’accumulation de Dette Technique au cours de la dernière décennie.
Le papier de recherche intégral, y compris des extraits le rapport de recherche, « Mesurez et Gérez-le Votre Dette Informatique » (“Measure and Manage Your IT Debt”), est disponible chez CAST ici.
MS Project permet de planifier les tâches, de maximiser l’utilisation des ressources, d’assurer le suivi des projets pendant leur réalisation et le contrôle des coûts.
La version 2010 contient beaucoup de nouveautés extrêmement utiles pour les chefs de projet. Je n’en citerai que quelques unes car je ne suis pas un expert mais celles-ci me paraissent répondre à des besoins concrets du chef de projet :
Technical DebtLa 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.
Plus sur la dette technique sur Wikipedia
Vous trouverez sur Excel Downloads un fichier Excel présentant 4 calendriers dynamiques réalisés avec Excel par Daniel Demilly. Tous soignés et gratuits.
Combien de fois vous est-il arrivé que la date prévue de démarrage soit reportée une fois, puis encore une autre fois avant de réellement pouvoir commencer?
Quand la date de début du projet change, vous pouvez très simplement mettre à jour la date de début du projet au niveau des informations projet et beaucoup de dates seront mises à jour automatiquement mais pas toutes (ex: dates butoirs, contraintes, tâche avec du travail déjà réalisé). Si vous voulez que ces dernières bougent également, aller sur « Move Project ».
L’avantage de « Move Project » est que tout sur le projet est déplacé en respectant le décalage par rapport à la date originale de début. Par exemple, dans ce projet la tâche b à une date butoir 5 jours après le démarrage du projet et tâche c a une contrainte de débuter 2 jours après le démarrage du projet (le 3 janvier 2011 : 1/3/11).
Maintenant, je sélectionne « Move Project » pour déplacer la date de démarrage du projet au 12 janvier 2011 (1/12/11).
Et tout dans l’échéancier est mis à jour respecte les mêmes délais par rapport à la date de démarrage du projet qu’auparavant. La tâche b a une date butoir 5 jours après le démarrage du projet et la tâche c a la contrainte de débuter 2 jours après le démarrage du projet.
Dans MS Project 2007 et versions précédentes, vous pouvez actionner cette fonctionnalité à partir de l’ « Analysis toolbar », ajuster les dates mais avec quelques limitations: les dates butoir et les tâches qui ne sont à 0% de complétude ne bougent pas.
At TechEd this year, Christophe Fiessenger and Jan Kalis, technical product managers, presented an overview of MS Project 2010, Project Server and also how these products integrate with the reporting and collaboration capabilities of Sharepoint 2010 and of Microsoft Exchange.
A very powerful session that was recorded for our perusal at: http://www.msteched.com/2010/NorthAmerica/OSP209
To speed up your one hour video experience: the first 26′ are focused on MS Project, before moving at that time to Project Server. At 42’from start you’ll get further explanations on the integration capabilities for reporting, collaboration, time-sheeting and « statusing ». And, there is a short demo of the integration between project with MS Exchange at 50′ into the video which is something quite a few of us were requesting since a long time.
There are many more videos and slides from sessions with the same speakers for different audiences and different aspects of MS Project and Project Server 2010.
Si vous vous intéressez aux outils de PPM, vous êtes probablement déjà familier de Primavera qui fut acquis il y a déjà quelque temps par Oracle.
La nouvelle version qui date de quelques mois paraît très enrichie. Vous pouvez accéder à des « white papers », webcasts, Podcasts et démonstrations sur Internet telle que celle de 3’00 du produit (voir « Primavera’s Portfolio Management Solution Demo ») dans la section Resource Center du site web du Oracle’s EPPM virtual summit.
PARTAGEZ VOTRE EXPÉRIENCE SUR CE PRODUIT SI VOUS ÊTES UTILISATEURS
Les partenaires et clients Microsoft présents à Barcelone ont témoigné sur la valeur du Management de Portefeuille de Projet (PPM) et tous en arrivent à la même conclusion: PPM apporte réellement de la valeur au business.
Selon le Campana and Schott Group, PPM apporte de la valeur de 3 façons différentes :
1. Il réduit les dépassement de délais (de 37% à 15%)
2. Il réduit les dépassement de budget (de 25% à 11%)
3. Il augmente le pourcentage de projet qui apporte une vraie valeur économique à l’entreprise
Les meilleures entreprises qui utilisent le PPM le font non seulement pour standardiser les processus et les règles mais aussi pour être en position de réviser souvent leurs priorités si nécessaires en fonction des conditions business, ce qui leur donne un réel avantage compétitif.
Il faut remarquer que PPM siginifie des choses différentes selon les personnes et souvent amène à des implémentation un peu différentes qui amènent toutes de la valeur:
UMT Consulting Group mentionna que, de leur point de vue, PPM facilite aussi les 3Cs du management de la demande: Centraliser, Contrôler et Cataloguer. Cela fournit à la société la capacité de saisir les coûts estimés et bénéfices escomptés sur la durée du projet de manière pluri-annuelle si nécessaire.
Le fondateur de PM Consulting Services, Vladimir Ivanov, utilises aussi PPM pour accepter et planifier les demandes de changement sur des projets existants. Cela lui permet de centraliser ces demandes et de les mettre en visibilité de toutes les parties prenantes.
L’après midi, nous avons écouté le passionnant témoignage de Stéphane Perrin deVolvo IT qui a récemment déployé Project Server 2010. Selon lui, les raisons qui motivent le choix de l’outil de Enterprise Portfolio Management sont multiples.
3 furent clés dans son cas : La couverture fonctionnelle, la facilité d’utilisation de l’outil et la capacité à s’adapter à la croissance de la solution.
Compte tenu du nombre important de projets gérés en parallèle et des mutilples portefeuilles managés pour les divers clients de son service transverse d’informatique globale, ses avis furent bien écoutés de tous. Il nous parla en particulier des différents types de PPM que les sociétés ou dans son cas les Business Units de Volvo peuvent désirer. Quand ses clients lui disent: « nous voulons un PPM », il essaie de faire la distinction entre ceux qui veulent un PPM operationnel versus un PPM stratégique . Le PPM opérationnel se rapproche du tableau de bord pour contrôler les projets en cours alors que le PPM Stratégique implique des processus de gouvernance et d’optimisation de portefeuille de projets. Donc, avant de se lancer dans une implémentation complète de PPM, vérifier ce que veut réellement votre service ou société…
Nous avons aussi pu bénéficier de son approche coté formation des PMs à PPM. Il a choisi de ne donner qu’une journée et demi de formation initiale pour acquérir les principes de bases. Puis, il fait accompagner les PMs pendant une journée entière dans leur travail quotidien avec l’outil par un PM plus expérimenté avec Project Server.
« Commencez petit et soyez très clair sur l’objectif » fut le conseil final que j’ai retenu de Kudelski group cet après-midi.
The Microsoft partners and customers testimonials on the value of Project Portfolio Management were all leading to this same conclusion: PPM does really add value to the business.
According to the Campana and Schott Group, PPM adds value in 3 major ways:
1. It reduces time overrun (37% to 15%)
2. It reduces budget overrun (25% to 11%)
3. It increases the share of projects that really add economic value to the business
Top performers in PPM use it not only to standardize processes and rules but also to be in position to re-prioritize and review projects often as business conditions evolve and this is a key advantage for them over their competitors.
It is to be noted that PPM means different things to different people and often drives slightly different implementations while all add value:
UMT Consulting Group mentioned that in their view PPM also facilitates the 3 Cs of demand management: Centralize, Control and Catalog. It provides the company with the ability to capture estimated costs and expected benefits over the course of the entire project over multiple years if necessary.
PM Consulting Services founder, Vladimir Ivanov, also uses PPM to accept and schedule change requests to existing projects in order to centralize and make these very visible to all involved with the project.
During the afternoon, we had the striking testimonial of Stéphane Perrin of Volvo IT who has recently deployed Project Server 2010. For him, the reasons for deciding an Enterprise Portfolio Management tool can be multiple.
3 were key to his choice of the Project Server tool: Required functionalities coverage, quality/ease of the user interface and scalability of the solution.
Running many projects in parallel and managing several projects portfolios for the various customers of the transversal and global IT function, his advices were well listened to. He notably spoke about the different types of PPM that companies or in his case business units within the company may need. When his customers tel him « we want a PPM », he tries to make the distinction between those who want an operational PPM versus a strategic PPM. The operational PPM is mainly a dashboard to control projects execution while the strategic one involves processes and governance for project portfolio optimization. So, before launching a full blown PPM implementation, check out what your company of B.U. really wants…
We also benefited from his insight on the training aspect. The approach he has retained for new PMs coming on board the PPM solution is a day and a half course to get the basic concepts followed by one the job coaching for 1 day with an experiences PM to help with the real day to day work the PM will need to perform on the new tool set.
« Start small and be very clear on the objective » was the final advice I retained from Kudelski group this afternoon.
Arpan Shah, director of product management for Project, a lancé l’événement ce matin. Arpan a commencé par un bref rappel des événements qui ont pavé la route du management de projet sur les 100 dernières années. Depuis la conception des Gantt Charts vers 1910, au lancement de PMI dans les années 60 et de Prince2 dans les années 70… En parallèle à cette évolution du management de projet, nous avons vu grandir et se multiplier les outils pour supporter cette nouvelle discipline: au départ des applications sur PC destinées aux chefs de projet, et de nos jours des suites totalement intégrées en support du management de portefeuilles de projets. Donc, avec la plus grande maturité des organisations en matière de management de projet, les outils ont évolués d’une position de support aux « seuls » chefs de projet à apporter un réel bénéfice à l’ensemble des acteurs du projet: Managers de programmes, de portefeuilles de projet, directions, sponsors, membres de l’équipe, clients, fournisseurs…
Je retiendrais de l’intervention suivante qui fut donnée par Ludovic Hauduc, Programme Management for the work management products chez Microsoft, 3 principes fondateurs de Project et Project Server 2010: Une interface simple et intuitive, l’unification de Projet et portfolio management en un serveur unique et une plate-forme extensible sur laquelle partenaires et clients peuvent bâtir.
1. Une interface utilisateur simple et intuitive: « Après tout, le premier compétiteur de MS Project est Excel ! » commença Ludovic. De nombreuses améliorations apportées à l’interface utilisateurs de Project 2010 proviennent d’un simple concept qui pourrait s’appeler « en coulisses ». Le moteur MS Project est en effet dans cette nouvelle version du produit placé en retrait pour laisser au chef de projet la direction des opérations. Quand le chef de projet à besoin de la puissance du moteur MS Project, il ou elle lui fait appel à la demande plutôt que de se le voir imposer en permanence. Deuxième principe: « Sharepoint Server est au cœur de Project 2010, en fait, Project Server 2010 est une application Sharepoint et les développements réalisés pour Project Server enrichissent également Sharepoint » poursuivit Ludovic. La nouvelle interface web pour éditer les projets est devenue aussi riche que le client « lourd » et est devenu un élément clé du déploiement dans les entreprises car cela permet à de nombreuses parties prenantes d’accéder directement aux fonctions dont ils ont besoin: notamment donner le statut d’une tâche et reporter le temps passé et le reste à faire.
2. l’unification de Projet et portfolio management en un serveur unique. Le serveur unifié permet de créer de manière flexible de nouveaux projets avec un workflow d’approbation intégré pour mettre en place la nécessaire gouvernance, analyse de portefeuille projet et son optimisation. L’objectif a été d’ouvrir project server à davantage de personnes dans l’organisation que les seuls PMs: exécutifs, membres d’équipes projet, sponsors, partenaires…
3. une plate-forme extensible sur laquelle bâtir: Avec des fonctionnalités telles que les connecteurs qui permettent aux partenaires et équipes techniques internes d’ajouter des fonctionnalités sans toucher au cœur de project server.
La matinée s’est poursuivie avec des démonstrations des nouveautés phares des versions 2010 de ces outils puis des témoignages de partenaires Microsoft.
Une partie des démonstrations qui m’a particulièrement intéressé parlait de la capacité de priorisation des projets par rapport à 7 critères business proposés en standard dans Project Server. Et, la possibilité de jouer des scénarios différents sur le jeu de projets retenus pour 1. rentrer dans une enveloppe budgétaire qui vous serait imposée et 2. faire ceci en connaissance de cause et en maximisant le retour sur investissement global du portefeuille de projets.
I retained from the following presentation delivered by <strong>Ludovic Hauduc</strong>, Programme Management for the work management products at Microsoft, 3 key drivers that were behind Project and Project Server 2010: A simple and intuitive user interface, Unified Project and Portfolio Management within a single server product and an extensible platform for partners to build upon.
<strong><a href= »https://dantotsupm.com/wp-content/uploads/2010/11/slide_008.jpg »><img class= »aligncenter size-full wp-image-3803″ title= »Slide_008″ src= »https://dantotsupm.com/wp-content/uploads/2010/11/slide_008.jpg » alt= » » width= »640″ height= »480″ /></a></strong>
<strong>1. Simple and Intuitive User Interface:</strong> « after all, the first competitor of MS Project is MS Excel ! » started Ludovic Auduc. Many of the improvements brought to the user interface of Project 2010 come from a concept that could be called « back stage ». The MS Project engine is indeed with this new version taking the back seat and letting the PM do more if not all of the driving. When the PM needs the power of the scheduling engine of MS project, he/she will get it upon demand without having it forced on him/her. « Sharepoint Server is at the heart of Project 2010, in fact, Project Server 2010 is a Sharepoint application and developments done for Project are also enriching Sharepoint » continued Ludovic. The new web interface for Project editing has become as rich as the client version and is an asset for global deployment of functions widely used by many team memebers on projet: statusing and timesheeting.
<strong>2. Unified Project and Portfolio Management</strong> within a single server product. The unified server enables flexible project capture and initiation with customizable workflows to implement the required governance, portfolio analysis and portfolio optimization. The goal has been to open up project server to many more people in the organization that PMs: executives, team members, sponsors, partners…
<strong>3. an extensible platform for partners to build upon</strong>: With features such as connectors to enable partners to add functionality on top of Project and Project Server.
The morning continued with demos of some striking features of the so called <em> »twentyten »</em> 2010 versions of the toolset and partners testimonials.
</div>
<div>A part of the demo that I found very interesting was around the prioritization of a portfolio of projects based on 7 drivers proposed out of the box on project server. And the ability to play what if scenarios to 1. match your budget constraints and 2. do this while maximizing the overall ROI of the portfolio.</div>
<div><a href= »https://dantotsupm.com/wp-content/uploads/2010/11/slide_010.jpg »><img class= »aligncenter size-full wp-image-3804″ title= »Slide_010″ src= »https://dantotsupm.com/wp-content/uploads/2010/11/slide_010.jpg » alt= »Portfolio Business Drivers » width= »640″ height= »480″ /></a><a href= »http://www.microsoft.com/france/office/project/2010/Default.aspx »></a></div>
<div>
</div>
Arpan Shah, director of product management for Project kicked off the event this morning. Arpan welcomed us with a brief reminder of the events that paved the way towards project management as we know it Today over the past 100 years. From the initial thoughts around Gantt charts in 1910, to PMI lauch in the 60s and Prince2 in the 70s… In parallel to this evolution, we also saw the growth of tools to support this new discipline: initially standalone SW applications for project managers, and nowadays fully integrated projects portfolio management.So, together with the increase of the maturity of Project Management in organizations, tools evolved from a position of supporting « only » the PM to benefiting all projects stakeholders: Programme managers, portfolio managers, executives, sponsors, team members, customers, suppliers…
I retained from the following presentation delivered by Ludovic Hauduc, Programme Management for the work management products at Microsoft, 3 key drivers that were behind Project and Project Server 2010: A simple and intuitive user interface, Unified Project and Portfolio Management within a single server product and an extensible platform for partners to build upon.
1. Simple and Intuitive User Interface: « after all, the first competitor of MS Project is MS Excel ! » started Ludovic Auduc. Many of the improvements brought to the user interface of Project 2010 come from a concept that could be called « back stage ». The MS Project engine is indeed with this new version taking the back seat and letting the PM do more if not all of the driving. When the PM needs the power of the scheduling engine of MS project, he/she will get it upon demand without having it forced on him/her. « Sharepoint Server is at the heart of Project 2010, in fact, Project Server 2010 is a Sharepoint application and developments done for Project are also enriching Sharepoint » continued Ludovic. The new web interface for Project editing has become as rich as the client version and is an asset for global deployment of functions widely used by many team memebers on projet: statusing and timesheeting.
2. Unified Project and Portfolio Management within a single server product. The unified server enables flexible project capture and initiation with customizable workflows to implement the required governance, portfolio analysis and portfolio optimization. The goal has been to open up project server to many more people in the organization that PMs: executives, team members, sponsors, partners…
3. an extensible platform for partners to build upon: With features such as connectors to enable partners to add functionality on top of Project and Project Server.
The morning continued with demos of some striking features of the so called « twentyten » 2010 versions of the toolset and partners testimonials.
Si vous êtes séparé par des mètres ou des kilomètres de vos clients, équipe ou bureau, voici quelques outils qui pourraient vous aider à combler toute distance et adresser ce défi.
Le service de partage de bureau inclut une partie des outils de l’excellent tableau blanc. Gratuit, puis $36.95/mois pour les fonctionnalités supplémentaires telles qu’une plus grande capacité.
Je vous suggère de profitez des vacances pour vous reposer bien sûr mais aussi prendre un peu de temps pour en gagner beaucoup ensuite en consultant ces modèles prédéfinis et pointeurs suivants:
1. N’oubliez pas de visiter régulièrement le site de Microsoft qui propose des modèles gratuits et qui sont régulièrement enrichis pour Word, Excel, Powerpoint ou Project…
2. Consultez le site indépendant « Excel Downloads ». Vous trouverez sur ce site des forums de discussions et plus de 500 programmes en Freeware et en Shareware (versions complètes ou limitées) à télécharger pour votre tableur préféré.
3. Un spécialiste de MS Excel, Jon Peltier anime également un blog sur MS Excel et vend des « add-ons » assez sophistiqués pour Excel sur son site. Certains vous permettront de produire les tableaux que vos financiers affectionnent probablement déjà et qui y sont expliqués en détail car il est toujours très utile de mieux communiquer avec eux ! Par exemple, le tableau « waterfall » (cascade) fort utile pour montrer visuellement et très simplement l’évolution du budget de votre projet au fil des changements de majeurs de périmètre ou de contenu qui seraient agréés par les instances adéquates.
Un aperçu de Project Server, la solution de management de portefeuille de projets de Microsoft.
Voici une présentation donnée lors de TechEd 2010 en Français.
Avec cette solution, Microsoft adresse les attentes des clients en matière de solution unifiée de gestion de projets et de portefeuilles (PPM, Projet et Portfolio Management). Et ce, depuis la gestion des demandes, leur évaluation par rapport aux objectifs stratégiques, jusqu’à la gestion opérationnelle des projets.
Voici une présentation pour entrer dans les détails de la nouvelle version du logiciel phare MS Project 2010. Cette vidéo a été enregistrée au TechDays de Microsoft et passe au travers des principales nouveautés de MS Project 2010. Elle est délivrée par Vincent Capitaine, consultant en management de projet chez TeamSquare.
Les nouvelles fonctionnalités, et en particulier le ruban qui regroupe les fonctions logicielles de manière plus intuitive pour l’utilisateur, sont commentées par ailleurs sur plusieurs blogs. On y trouve aussi une description de la fonctionnalité de planification manuelle qui permet de faciliter les saisies du planning même avec des informations incomplètes. La ligne chronologique de temps paramétrable pour communiquer et partager l’information plus facilement avec toutes les parties prenantes.
Frédéric Bojman, chef de produit MS Project chez Microsoft, nous conseille également de visionner cette autre vidéo en Anglais sur MS Project 2010
Un interview en vidéo sur l’évolution des outils de management de projet de Yves Cavarec, secrétaire général du chapitre PMI Ile de France, réalisé par Frédéric Bojman, chef de produit Microsoft Project. Yves Cavarec nous rappelle l’évolution des outils de management de projets au cours des 20 dernières années. Avantages et développement des outils, besoins et attentes des chefs de projet…
Yves met en exergue un très net besoin d’outils pour collecter l’information, l’organiser, la synthétiser, puis la communiquer plus facilement à la fois pour le manager de projet, ses équipes et toutes les parties prenantes.
J’ai apprécié cet article où l’auteur a pris le parti de la complémentarité plutôt que de l’opposition entre les méthodes de développement traditionnelles et plus récentes.
Le choix entre les méthodes « en cascade », RUP et agile, y dépend à la fois de l’expérience de l’équipe, de la culture d’entreprise, du type de projet, de l’environnement, du mode de développement interne/externe, et prend en compte la dimension géographique.
Ce qui représente en soi, un bon exemple d’agilité dans le choix même de l’approche qui pourrait être une combinaison des trois méthodes selon les moments du cycle de développement.
Utilisez vous d’autres critères de choix de l’approche de développement?
Article original de Serhiy Kharytonov, SoftServe © 2009
Http://www.executivebrief.com/software-development/waterfall-rup-agile/
Rationalisez la production avec les processus rapides et efficaces « en cascade », RUP et Agiles. Créez le bon mélange des stratégies de développement de logiciels afin de répondre aux besoins spécifiques de votre projet.
Malgré les signes de reprise dans l’économie, la réalité persiste dans le développement logiciel. La plupart des sociétés et clients ont besoin de leur logiciel pour hier avec les fonctionnalités les plus avancées au coût le plus faible possible. Pour atteindre ces buts apparemment contradictoires, les développeurs cherchent à rationaliser la production avec les processus rapides, efficaces qui peuvent donner au client ce qu’il/elle veut en un laps de temps le plus court possible.
Ces faits et les échecs de développement passés ont mené à un changement dans le développement logiciel depuis des méthodes très structurées, séquentielles de développement logiciel du passé, souvent appelé le modèle « en cascade », aux modèles plus itératifs et progressifs tels que « Rational Unified Process (RUP) » et « Agile. »
Les partisans d’Agile sont nombreux et il peut parfois sembler que des processus de développement plus traditionnels sont tombés en défaveur, mais en réalité les trois modèles ont leurs avantages, des côtés négatifs et leurs environnements de projet favoris. Au bout du compte, la meilleure méthode ou le meilleur mélange de méthodes pour vous dépend d’une compréhension minutieuse des trois processus et comment ils s’adaptent à votre projet logiciel, la culture business et l’environnement de développement.
La programmation en « cascade » est un processus fortement structuré qui compte lourdement sur la planification initiale et un ensemble d’étapes séquentielles, prescrites qui coulent de l’une dans l’autre comme une chute d’eau. Chaque étape a typiquement son équipe propre d’experts et des jalons soigneusement préparés d’avance et aucune étape ne peut commencer tant que l’étape précédente n’a pas été complétée. Le but est de recueillir tous vos besoins détaillés tôt dans le processus et de fournir une seule solution complète avec des résultats qui sont fortement prévisibles.
Typiquement les étapes dans le développement en « cascade » sont :
Le développement en « cascade » peut marcher très bien pour des applications complexes, critiques à la mission de l’entreprise et qui s’intègrent avec de nombreux autres systèmes ou pour des organisations comme la NASA ou l’armée qui exigent les plus hauts niveaux de fiabilité.
Les détracteurs disent que la « cascade » demande simplement trop longtemps et manque de la flexibilité – ou de l’agilité – requise pour le marché logiciel d’aujourd’hui et un environnement de développement en constant mouvement. Les projets qui suivent la méthode en « cascade » prennent typiquement des mois ou des années et au moment où ils sont finis, on découvre parfois que les besoins ont changé ou que les besoins originaux étaient incorrects depuis le départ. Le résultat peut être des corrections onéreuses, explosant le budget.
Comme la « cascade », le Rational Unified Process (RUP), produit par Rational Software et plus tard par IBM, est aussi un processus lourd, mais c’est une approche itérative qui prend en compte le besoin d’accommoder le changement et l’adaptabilité pendant le processus de développement.
Comme la « cascade », RUP a une série de phases et des jalons qui coulent l’un dans l’autre. Les phases consistent en :
RUP définit aussi les rôles et les activités de membres de l’équipe en détail et compte à chaque étape sur la production de modèles visuels, qui sont les représentations graphiques riches de systèmes logiciels et des cas d’utilisation spécifiques plutôt que les grandes quantités de documentations requises pour chaque étape de la « cascade ». Tous les membres de l’équipe ont accès à la même grande base de connaissance de directives, modèles, outils et autres articles pour assurer qu’ils partagent les mêmes langage et perspective sur le projet.
Alors que cela apparaît semblable au développement en « cascade » de prime abord, la plus grande différence du RUP est son approche de développement itérative, qui construit le produit dans plusieurs étapes basées sur des revues fréquentes avec les parties prenantes. Les premières itérations RUP sont surtout de la définition de besoin et d’architecture et l’exploration d’idées différentes, tandis que les itérations ultérieures essayent de rassembler un produit complet. Chaque itération est un livrable exécutable et chaque phase RUP peut interagir avec les phases précédentes pour s’adapter au besoin.
Non seulement le processus RUP est itératif dans son ensemble mais RUP suppose aussi que chaque phase ait plusieurs itérations internes basées sur des retours d’utilisateur.
RUP adresse bon nombre des critiques du développement en « cascade » et est une bonne méthode pour des agences gouvernementales et institutions éducatives qui apprécient un cycle de développement de logiciel stable et répétable, ainsi que pour des organisations qui « offshore » dans des pays comme l’Inde et la Chine, ou qui produisent des progiciels.
Les critiques disent que RUP n’est pourtant pas aussi rapide et adaptable que d’autres méthodes, comme Agile et ne marche pas bien quand un délai de mise sur le marché rapide est crucial ou bien pour le Web 2.0 et les environnements Software-as-a-Service (SaaS) où on s’attend à des mises à jour fréquentes et des compléments de fonctionnalités.
Tandis que la « cascade » et RUP penchent vers la prévisibilité, les buts principaux d’Agile sont la vitesse et l’adaptabilité. Il y a beaucoup de types différents de processus de développement Agile, y compris XP et SCRUM, mais tous s’efforcent de mettre une version de produit basique mais fonctionnelle entre les mains du client aussi vite que possible.
Ils font alors suivre cette version par des versions successives qui ajoutent et changent des fonctions nécessaires au fil du temps pour fournir un produit plus robuste. Chaque module successif est planifié, codé, testé et complété sur de courtes sessions de deux à quatre semaines. Bien que le processus Agile soit planifié d’avance comme la « cascade » et RUP, il fait passer les gens et la collaboration avant le processus lui-même.
Plutôt que de dépendre de nombreuses équipes d’experts, le processus de développement Agile entier est typiquement entrepris par une seule, petite équipe, cross-fonctionnelle, censément auto-organisée, qui doit inclure un représentant client, qui suit des réunions quotidiennes et s’assure que l’équipe travaille sur les choses dont le business a vraiment besoin. La collaboration en face à face constante est le but, avec le représentant du client utilisé comme l’un des collaborateurs les plus importants. La documentation est dé-priorisée par rapport à la « cascade » et même à RUP pour sortir quelque chose aussi rapidement que possible.
Avec son approche modulaire, progressive, faite en collaboration, Agile est rapide et fortement adaptative au changement de besoins et des défis compétitifs, qui sont les raisons de tant de partisans. British Telecom est fréquemment cité comme une société qui a utilisé la programmation Agile avec beaucoup de succès, avec des cycles de développement de 30 à 90 jours qui ont rapporté une productivité spectaculaire et des avantages business par rapport aux 18 mois ou plus pris dans le passé pour produire un logiciel utilisable.
Mais même s’il est facile de tomber amoureux d’Agile, elle a aussi ses limitations et inconvénients. Son accent sur les réunions quotidiennes en physique et la collaboration rapprochée rendent le processus difficile à adapter à l’externalisation des développements, aux clients et développeurs géographiquement distribués, ou aux clients qui n’ont tout simplement pas la main d’œuvre, les ressources ou l’attention nécessaires.
Son accent sur la modularité, le développement progressif et l’adaptabilité ne convient pas facilement aux clients qui veulent des contrats avec des évaluations fermes et des calendriers fixes. Sa dépendance sur de petites équipes auto-organisées rend difficile l’adaptation aux grands projets logiciels avec beaucoup de parties prenantes aux besoins différents et néglige de prendre en compte du besoin de leadership pendant que les membres de l’équipe s’habituent à travailler ensemble.
De plus, le manque de documentation complète peut rendre la maintenance et les nouveaux développements difficiles quand les membres de l’équipe originale laissent leur place à d’autres. Cela peut mener à des modules aux fonctionnalités et interfaces inconsistantes. Finalement, plus qu’avec la « cascade » et RUP, le développement Agile dépend éminemment de la capacité à recruter des analystes fonctionnels très expérimentés qui savent comment travailler indépendamment et s’interfacer efficacement avec des utilisateurs métiers.
Si Agile, RUP et des modèles en « cascade » ont chacun leurs inconvénients, lequel devriez-vous choisir ? De plus en plus, le secret au développement logiciel réussi est de comprendre les trois processus dans le détail et sélectionner les parties de chacun qui conviennent le mieux à votre livrable et environnement particuliers. Puis, être agile dans l’approche même du processus, en regardant sans cesse sur ce qui a été réalisé, en réévaluant et révisant le processus de développement jusqu’à ce qu’il s’adapte au mieux à vos circonstances actuelles.
Par exemple, si vous développez du logiciel SaaS ou Web 2.0 dans un marché fortement concurrentiel, alors vous ferez probablement le meilleur choix en penchant vers des méthodologies Agiles. SaaS se prête particulièrement bien à Agile puisqu’il prévoit un accès constant au logiciel pour ajouter ou changer des caractéristiques. Dans un tel marché concurrentiel avec des besoins utilisateur changeants vous voudrez probablement être capables d’apporter rapidement des changements.
D’un autre coté, si vous produisez pour le médical, l’ingénierie, ou d’autres systèmes qui exigent un haut degré de conception et de certitude, alors il semble logique de commencer par la « cascade ».
Si vous produisez un progiciel grand public « sur étagère », avec de nouvelles versions qui doivent être des enrichissements des versions précédentes, votre processus devrait probablement pencher vers RUP, avec une attention particulière au recueil des besoins, à la définition du périmètre et du contenu au début, ainsi que des standards de navigation, et d’interface utilisateur.
Cependant, les développeurs peuvent tout de même utiliser des techniques Agiles pour présenter des prototypes fréquents et des modules progressifs aux chefs de produit de la société pour s’assurer qu’ils sont sur la bonne voie. La fréquence et l’intensité de collaboration entre chefs de produit et développeurs dépendent vraiment de leur proximité et de la culture de société – selon que ces équipes soient plus ou moins habituées à une telle collaboration. Quand la géographie est un problème, les outils de collaboration comme la conférence à plusieurs sur le web et la vidéo peuvent être d’une grande aide.
Ce même mélange de techniques peut être utilisé dans un environnement d’entreprise externalisant le développement en « offshore ». En fait, avec les différences de fuseaux horaires et de cultures, il est important d’intégrer autant d’étapes itératives et progressives et autant de contact de suivi qu’il est possible pour votre projet, la culture de votre société et celle de vos partenaires de développement.
Choisir de partir sur des équipes auto-organisées ou une approche plus « top-down » de management dépend vraiment du niveau de compétence et d’expérience de vos développeurs. Beaucoup de projets peuvent exiger au départ un leader qui va ajouter une certaine urgence, une direction et une gestion des risques du projet jusqu’à ce que les membres de l’équipe s’habituent à travailler ensemble. Alors le rôle de leadership peut être réduit selon les besoins pour les itérations suivantes.
Le bilan est qu’il n’y a probablement aucun processus parfait pour tous les projets et environnements, ni même pour un seul. C’est pourquoi les sociétés doivent intégrer fréquemment « les leçons apprises » pour évaluer et réviser le processus lui-même, qui peut se déplacer d’un bout à l’autre du spectre à différents moments dans le cycle de développement. Bref, en choisissant entre Agile, RUP et en « cascade », adaptez le processus à vos besoins, plutôt que d’adapter votre projet au processus.
DantotsuPM.com 
