6. Les 8 principales différences Implicite, "effort" Séparée, formelle Gestion des coûts Vision, valeur Plan Dirigé par… Participatif, polyvalent Directif, fonctions Rôles et collaboration Continu En fin de cycle Contrôle qualité Intégrée, informelle Séparée, formelle Gestion des risques et des changements Continu En début de cycle Planification Dév. produit, itératif Projet, ± cascade Cycle de vie Minimal Exhaustif Processus Agile PMBOK
15. Le modèle APM Envision Speculate Source: Jim Highsmith, Agile Project Management: Creating Innovative Products Explore Adapt Close Vision Liste des fonctionnalités Plan de livraison Fonctionnalités complétées Produit fini Démarrage Planification Exécution Surveillance Clôture APM PMBOK
16.
17.
18.
Notes de l'éditeur
Genèse de la présentation: deux mondes qui communiquent peu. Évangélistes agiles. Discussions ressemblent plus à guerres de religion qu’à arguments rationnels. Objectif principal: comprendre pourquoi et comment combiner Agile avec PMBOK
Nous n'allons parler… des principes Agiles des pratiques Agile de réalisations logicielles (car perspective GP) Nous nous concentrons sur la gestion de projets: Les éléments les plus importants à considérer pour gérer un projet Agile La manière dont on peut implémenter Agile dans les organisations traditionnelles en le combinant avec le PMBOK
“ gestion de projets agile” oxymoron car on pourrait dire que Agile tente de faire disparaître la gestion de projets. Convergence Pourquoi parler du PMBOK? Parce que c’est la référence à laquelle toutes les méthodes se comparent
PMBOK est un standard décrivant les pratiques de gestion de projets établies. PMBOK 4e édition = 496 pages Agile est une philosophie guidant les pratiques de développement logiciel. Manifeste Agile = 9 lignes + 12 principes Le but n’est pas de déterminer lequel est meilleur.
Processus: Minimal car basé sur les personnes, pas sur les processus Minimal car philosophie, pas standard. Minimal de cérémonial requis. Personnes plus importantes que les processus. Plan vs. vision: autre slide Cycle de vie: Portée: agile ne se soucie pas de la sélection du projet, etc. Itératif: chaque itération peut être vue comme un projet en soi (selon déf projet de PMBOK) Planification: niveau de détail et point de référence PMBOK: au début, approche prédictive. Le succès dépend de la qualité de la planification et du suivi des changements sur le plan. Agile: Plan subordonné à la vision. Continu. On ne planifie que ce que l’on peut prévoir. Priorisation selon valeur livrée. Deux niveaux de détail: itération et version (release) Plan de référence: PMBOK = plan initial. Agile = plan avec info la plus récente Gestion des changements: PMBOK: à cause du plan (qui est détaillé), les changements sont perçus comme problèmes et génèrent des tâches administratives. Feedback tardif. Agile: intégré dans les pratiques de manière non disruptive, mais pas formalisé. Feedback rapide. Priorisation et ajustement des fonctionnalités. L’équipe et le client devient l’équivalent du comité de gestion des changements. Gestion des risques: PMBOK: explicite, quantitatif et qualitatif. Processus distincts. Fait par le CdP. Agile: implicite ou explicite, souvent qualitatif uniquement. Intégré dans les pratiques (réunion quotidienne, etc.). Fait par l’équipe. Gestion de la qualité: PMBOK: Q dernier dans le cycle. Rôle distinct. Agile: Q impliqué dès l’analyse (défínition de “done”). Meilleure qualité car incrémental. Responsabilité Q partagée par toute l’équipe. AQ par feedback constant. CQ pour chaque itération. Possible de faire TDD. Rôles: PMBOK: diriger, contrôler. Chef de projet et membres d’équipes ayant fonctions définies. Prescriptif: dit comment les membres doivent travailler. Agile: faciliter, mener, collaborer. “chef serviteur” accompagnateur, membres polyvalents et auto-organisés. Les membres choississent sur quoi ils travaillent (dans le cadre de l’itération), donc responsabilisation. Se repose sur les membres pour gérer la complexité de leur rôle. C’est la différence qui a le plus d’impact sur la culture de l’organisation
Note sur cascade/PMBOK Définition du succès, et sponsor vs. client (Agile plus éthique que PMBOK) PMBOK: succès = respect du plan, donc le succès dépend principalement de la qualité du plan Agile: succès = satisfaction client, donc le succès dépend principalement de la capacité à réaliser la vision Mesure du progrès: perspective client, compatible avec EVM Priorisation Exemple de la documentation: PMBOK: pas un but en soi, mais facile de perdre de vue la valeur livrée au client Agile: faire le minimum requis pour livrer de la valeur, mais facile de perdre de vue que la doc doit servir après, notamment pour l'entretien
Autodiscipline: Agile requiert de la discipline. Simplement, elle est déléguée au niveau des équipes et non imposée. Arrimage: présence de points d’ancrage qui permettent d’intégrer Agile sans tout chambouler. Gouvernance et conformité: exemple audit chez DC BE Agile home ground: Low criticality Senior developers Requirements change often Small number of developers Culture that thrives on chaos Plan-driven home ground: High criticality Junior developers Requirements do not change often Large number of developers Culture that demands order
Pourquoi devrait-on combiner Agile avec une méthode traditionnelle? Car dans la réalité une transition vers 100% Agile n'est ni réaliste ni même désirable. Le but n'est pas d'implémenter une méthode agile spécifique, mais bien de trouver une manière de tirer profit de l'agilité sans chambouler ce qui fonctionne et ce qui est nécessaire (ex: gouvernance, conformité (ISO)). Aussi: comprendre la marge de manœuvre du CDP Agile: il ne peut pas tout changer, il faut faire avec l'existant. Incroyable que des organisations avec projets variés utilisent une seule méthodologie. Exemple des cadres de développement chez Loto-Québec
Silos fonctionnels: aide à la collaboration et à la planification collective Planifier au bon niveau de détail: petit blocs en détail. Efficacité de l’équipe grâce à la collaboration et l’auto-organisation Quantité documentation: évite la suranalyse car la documentatin est produite le plus tard possible.
Démarrage : (élaborer la charte du projet, identifier les parties prenantes) Agile n’aide pas à sélectionner le projet, acquérir l’équipe, gérer un contrat, etc. La charte de projet PMBOK devrait expliquer l’approche itérative et mettre en avant le principe d’élaboration progressive Planification : (plan de management du projet, exigences, contenu, SDP, activités x3, ressources, échéancier, coûts, budget, qualité, RH, communication, risques x5, approvisionnement) PMBOK planifie déjà le comment au début du projet, alors qu’il y a bcp d”incertitudes PMBOK planifie à l’aide d’outils (ex: MS Project) et de techniques (ex: Gantt) qui requièrent bcp de travail en cas de changements. La GP devient facilement le bottleneck et le CDP se transforme en planificateur à temps plein. Importance de l’élaboration progressive pour éviter de sur-planifier Important de lister les risques et exigences non fonctionnelles. (problème Agile) Agile permet de raffiner le plan de manière itérative grâce au feedback continu des livraisons intermédiaires Planifier en terme de fonctionnalités et non de tâches, ce qui permet de suivre le progrès sur base de la valeur livrée. Exemple: au lieu de dire que Michel travaillera sur la tâche X le 12 novembre, on se contentera de dire qu'en novembre on livrera ces 4 fonctionnalités. La question devient de décider quelle est la plus petite unité livrable. Exécution : (diriger exécution, AQ, équipe x3, information, gérer attentes parties prenantes, appro) Très peu dans PMBOK car indépendant de l’industrie Gérer par objectifs et laisser l’équipe prendre possession des objectifs par auto-attribution. L’équipe doit participer à la planification. Aligner les métriques sur la valeur livrée, qui représente le but du projet. Métriques telles que heures consommées ou code produit génèrent comportement suboptimal car pas alignées avec le but du projet. Surveillance : (surveiller travail, maîtrise intégrée des modifications, vérif contenu, maîtriser contenu, maîtriser échéancier, maîtriser coûts, CQ, perf, risques, appro) La surveillance PMBOK part du principe que le plan initial est correct, et calcule les écarts par rapport à ce plan initial. Avec Agile, le plan représente la meilleure estimation, faite avec les informations connues à ce jour. En conséquence le plan de référence PMBOK génère un comportement négatif par rapport aux objectifs: écarts = problèmes et changements sont malvenus. Revues d’itérations fréquentes, mais plus formalisées que ce que Scrum préconise. Exemple Loto-Québec. Demandes de changements, bugs et risques répertoriés dans la liste des fonctionnalités à livrer. Priorisation continue de la liste des fonctionnalités avec échéance et budget fixes permet de contrôler l’envergure (scope creep). Clôture : (clore projet ou phase, clore appro) Le bilan de projet doit se baser sur la satisfaction du client plutôt que sur le respect d’un contrat ou d’un plan
Une des principales limitations Agile: taille d'équipe, due à la nature participative Cycle de développement Besoin de communication directe entre client et équipes pour prioriser les listes de fonctionnalités Liste de fonctionnalités « haut niveau » gérée au niveau projet Subdivision du produit en modules. Suggestion: définir les modules par proximité fonctionnelle. Coordination des équipes: chaque équipe remonte les éléments qui pourraient affecter les autres équipes Une liste de fonctionnalités gérée par chaque équipe Risques et changements gérés aux deux niveaux: Équipe: fonctionnalités (liste et prio), risques techniques Projet: fonctionnalités haut niveau (liste et priorités), autres risques
Si l'on veut une méthodologie Agile qui permet de prendre en compte tous les besoins des grandes organisations. Pourquoi pas Scrum: car incomplet et trop éloigné des besoins des grandes organisations
Aide à adopter agile: pratiques terre-à-terre qui indique par où commencer . Similarités avec PMBOK: facilitent transition et arrimage Système de pratiques pouvant être implémentées indépendamment mais se renforçant mutuellement. Au-delà du développement logiciel: projet, applicable à n’importe quel domaine permettant de livrer la valeur par incrément. Les processus n’ont pas bonne réputation auprès des agilistes, pourtant les processus ne sont pas nécessairement mauvais. Les personnes sont plus importantes que les processus, mais cela ne veut pas dire que les processus ne sont pas importants.
Le fait que les phases ont un nom différent des phases PMBOK est important: cela souligne ce qui distingue APM de PMBOK Envision: Importance de la vision Produit la vision, identifie les intervenants, et explique comment l’équipe va travailler Exemple de pratiques: product vision box, project data sheet, participant identification Speculate: plan de projet = plan d’itérations avec fonctionnalités Incertitude, adaptation des prévisions. >< PMBOK planification qui réfère à une relative certitude Prévoit un plan de livraisons et d’itérations définies par les fonctionnalités liées à la vision, gestion des risques, estimation coûts, etc. Exemple de pratiques: product feature list, release, milestone, and iteration plan Explore: Itératif, non linéaire, implique flexibilité allant de pair avec les prédictions incertaines faites dans Speculate Livre des fonctionnalités fréquemment CDP responsable de créer une communauté de projet collaborative et auto-organisée Exemple de pratiques: workload management, daily interaction with the customer team Adapt: Examine les résultats et performances et s’adapte si nécessaire Modification aux prévisions >< adhésion au plan (qui implique succès/échec selon respect du plan), càd attitude PMBOK = correction, attitude APM = adaptation Vérification des résultats à tous les niveaux (pas seulement fonctionnel) Replanification sur base de nouvelle info Exemple de pratiques: product, project, and team review (customer, technical, team perf, project report, etc.) Close: Cf PMBOK, avec accent sur leçons apprises
PMBOK: Élaboration progressive, planification par vagues Itératif, mais par phase Itérations courtes suggérés pour projets de recherche ou comportant beaucoup d’incertitudes Articles: il y a un documents dans la CdP Agile PMI qui liste les publications PMI qui ont trait à Agile
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)