Valtech - Quel ROI pour ma transformation Agile ?Valtech
Quel ROI pour ma transformation Agile ?
PARTIE 1 : Un retour aux principes fondamentaux
Valérie Wagoner, Agile Coach, Valtech France
valerie.wagoner@valtech.fr
Agile Day 2012
Valtech
Plus aucun secteur d'activité n'échappe aujourd'hui au management par projet et à son langage bien particulier.
Des expressions comme "maître d'oeuvre", "jalon", "livrable", "recette" et bien d'autres, jadis confinées aux métiers de l'industrie, envahissent aujourd'hui des domaines aussi divers que l'informatique, l'humanitaire ou la finance.
Honte au chef de projet qui ne sait pas qu'un indicateur doit être SMART, que REX n'est pas le chien du commanditaire ou qu'une immobilisation corporelle n'est pas une prise de judo !
Ce lexique puise aux sources les plus sérieuses et les mieux documentées. Il dresse une liste exhaustive des termes rencontrés dans le quotidien du chef du projet, en accompagnant chacun d'entre eux d'une explication claire et concise.
La précision des définitions, la présence de nombreux schémas et d'exemples simples et compréhensibles en font un véritable manuel de gestion de projets.
Valtech - Quel ROI pour ma transformation Agile ?Valtech
Quel ROI pour ma transformation Agile ?
PARTIE 1 : Un retour aux principes fondamentaux
Valérie Wagoner, Agile Coach, Valtech France
valerie.wagoner@valtech.fr
Agile Day 2012
Valtech
Plus aucun secteur d'activité n'échappe aujourd'hui au management par projet et à son langage bien particulier.
Des expressions comme "maître d'oeuvre", "jalon", "livrable", "recette" et bien d'autres, jadis confinées aux métiers de l'industrie, envahissent aujourd'hui des domaines aussi divers que l'informatique, l'humanitaire ou la finance.
Honte au chef de projet qui ne sait pas qu'un indicateur doit être SMART, que REX n'est pas le chien du commanditaire ou qu'une immobilisation corporelle n'est pas une prise de judo !
Ce lexique puise aux sources les plus sérieuses et les mieux documentées. Il dresse une liste exhaustive des termes rencontrés dans le quotidien du chef du projet, en accompagnant chacun d'entre eux d'une explication claire et concise.
La précision des définitions, la présence de nombreux schémas et d'exemples simples et compréhensibles en font un véritable manuel de gestion de projets.
MS TechDays 2012 -Mise en place d'une usine logicielle avec TFS et Test Manag...Raynald M
Au cours de cette session, nous montrerons comment SOGET, éditeur de solutions logicielles innovantes dédiées à la gestion des sites portuaires, a réussi sa transformation vers les méthodes Agiles. Accompagnée par Neos-SDI, SOGET met en oeuvre les technologies Microsoft et son usine logicielle TFS2010 pour mener ses différents projets du programme e-Maritime. Nous aborderons les différentes facettes de cette méthodologie : gestion des exigences, organisation des équipes, personnalisation et déploiement des outils de production logicielle, automatisation des tests. De nombreuses démonstrations viendront illustrer cet exposé d'une véritable success story.
Cours de gestion de Projet - Les FondamentauxRémi Bachelet
À l’issue de ce cours, vous devez être capable de :
1. Pouvoir expliquer ce qu’est fondamentalement un projet et quelles en sont les particularités
2. Caractériser les différents modes d’organisation des projets et leurs configurations dans l’entreprise
3. Comprendre la notion de coût global
4. Expliquer la répartition des rôles et des responsabilités en projet
Dans le contexte actuel où les technologies web 2.0 gagnent progressivement en maturité, plusieurs domaines organisationnels tels que le marketing et les ressources humaines se sont mis à la page et utilisent d’une manière novatrice ces technologies au point qu’elles sont devenues indispensables à la profession. La gestion de projet n’échappe pas à la tendance et c’est un vent nouveau qui souffle sur la pratique. Désignée par le terme « Gestion de projet 2.0 », cette évolution tire profit de l’intelligence collective et des avancées technologiques du web pour contrer les limites des pratiques traditionnelles de gestion de projet. Prendre la direction de la gestion de projet 2.0 requiert deux éléments clés, d’un côté, l’intégration des outils web 2.0 – tels que les réseaux sociaux, les signets sociaux, les outils de collaboration en ligne, la syndication de contenu, les wikis, le microblogage, etc. –, et d’un autre côté, l’adoption de nouveaux modèles de gestion favorisant, notamment la collaboration, la participation, l’agilité et la transversalité. Ceci étant dit, l’objectif de la présentation est, premièrement, de montrer le potentiel des outils web 2.0 dans le domaine de la gestion de projet et de décrire comment ils peuvent se présenter comme une complémentarité (voire une alternative) aux outils de gestion de projet traditionnels; deuxièmement de discuter des fondements de la gestion de projet 2.0 en posant un regard attentif sur les enjeux relevant des processus, la culture, la structure, la sécurité, l’éthique et la confidentialité.
5 ETAPES CLES DE LA PREPARATION D'UN PROJET R&D COLLABORATIFExpernova
Economisez le temps de vos ressources clés sur les phases exploratoires et les états de l'art ! Détectez de nouvelles opportunités et challengez vos partenariats historiques ! Accédez à d'importants financements publics !
Expernova vous présente les 5 étapes de la préparation d'un projet d'innovation ouverte et collaborative :
- Cartographier votre environnement scientifique
- Identifier les projets européens déjà financés
- Comprendre les travaux d'un centre de recherche
- Cibler un expert ou une équipe
- Parcourir les réseaux internationaux
En 45min, et en toute confidentialité, vous découvrirez comment expernova.com, outil de cartographie de compétences scientifiques de dimension mondiale, peut vous permettre de prendre une longueur d'avance dans la mise en oeuvre de tels projets.
MS TechDays 2012 -Mise en place d'une usine logicielle avec TFS et Test Manag...Raynald M
Au cours de cette session, nous montrerons comment SOGET, éditeur de solutions logicielles innovantes dédiées à la gestion des sites portuaires, a réussi sa transformation vers les méthodes Agiles. Accompagnée par Neos-SDI, SOGET met en oeuvre les technologies Microsoft et son usine logicielle TFS2010 pour mener ses différents projets du programme e-Maritime. Nous aborderons les différentes facettes de cette méthodologie : gestion des exigences, organisation des équipes, personnalisation et déploiement des outils de production logicielle, automatisation des tests. De nombreuses démonstrations viendront illustrer cet exposé d'une véritable success story.
Cours de gestion de Projet - Les FondamentauxRémi Bachelet
À l’issue de ce cours, vous devez être capable de :
1. Pouvoir expliquer ce qu’est fondamentalement un projet et quelles en sont les particularités
2. Caractériser les différents modes d’organisation des projets et leurs configurations dans l’entreprise
3. Comprendre la notion de coût global
4. Expliquer la répartition des rôles et des responsabilités en projet
Dans le contexte actuel où les technologies web 2.0 gagnent progressivement en maturité, plusieurs domaines organisationnels tels que le marketing et les ressources humaines se sont mis à la page et utilisent d’une manière novatrice ces technologies au point qu’elles sont devenues indispensables à la profession. La gestion de projet n’échappe pas à la tendance et c’est un vent nouveau qui souffle sur la pratique. Désignée par le terme « Gestion de projet 2.0 », cette évolution tire profit de l’intelligence collective et des avancées technologiques du web pour contrer les limites des pratiques traditionnelles de gestion de projet. Prendre la direction de la gestion de projet 2.0 requiert deux éléments clés, d’un côté, l’intégration des outils web 2.0 – tels que les réseaux sociaux, les signets sociaux, les outils de collaboration en ligne, la syndication de contenu, les wikis, le microblogage, etc. –, et d’un autre côté, l’adoption de nouveaux modèles de gestion favorisant, notamment la collaboration, la participation, l’agilité et la transversalité. Ceci étant dit, l’objectif de la présentation est, premièrement, de montrer le potentiel des outils web 2.0 dans le domaine de la gestion de projet et de décrire comment ils peuvent se présenter comme une complémentarité (voire une alternative) aux outils de gestion de projet traditionnels; deuxièmement de discuter des fondements de la gestion de projet 2.0 en posant un regard attentif sur les enjeux relevant des processus, la culture, la structure, la sécurité, l’éthique et la confidentialité.
5 ETAPES CLES DE LA PREPARATION D'UN PROJET R&D COLLABORATIFExpernova
Economisez le temps de vos ressources clés sur les phases exploratoires et les états de l'art ! Détectez de nouvelles opportunités et challengez vos partenariats historiques ! Accédez à d'importants financements publics !
Expernova vous présente les 5 étapes de la préparation d'un projet d'innovation ouverte et collaborative :
- Cartographier votre environnement scientifique
- Identifier les projets européens déjà financés
- Comprendre les travaux d'un centre de recherche
- Cibler un expert ou une équipe
- Parcourir les réseaux internationaux
En 45min, et en toute confidentialité, vous découvrirez comment expernova.com, outil de cartographie de compétences scientifiques de dimension mondiale, peut vous permettre de prendre une longueur d'avance dans la mise en oeuvre de tels projets.
- Présenter les ressemblances et les différences entre l’approche Agile et celle du PMI
-Souligner comment une entreprise peut passer à une approche Agile
-Fournir des éléments de réflexion pour la mise en œuvre d'améliorations dans vos projets
Le Project Management Body of Knowledge (PMBOK) est un guide de standards créé par l’institut de gestion de projets, définissant les champs de connaissances et les règles de gestion de projet d’une manière générale, tout en regroupant les meilleures pratiques professionnelles actuellement en vigueur. Ces standards sont très répandus, mis à jour par un comité de volontaires et par les utilisateurs eux-mêmes, ayant ainsi la vocation d'amener les entreprises à atteindre l’excellence dans leur gestion.
La gestion de projet agile propose une alternative crédible aux méthodes traditionnelles de gestion de projets.
La méthode SCRUM est à ce jour la plus utilisée des méthodes agiles. Réputée comme la plus simple à mettre en œuvre, elle définit un cadre précis d’organisation du projet qui doit être appliqué avec discipline mais qui se prête parfaitement à une adaptation au contexte métier de chaque entreprise.
To be Agile or not to be ? Les méthodologies de développement doivent s'adapter aux demandes de plus en plus spécifiques et changeantes tout en respectant les besoins pratiques du client.
Chez TheCodingMachine, on pense que chaque projet mérite un instant de réflexion pour adopter la bonne approche méthodologique ! Pour certains types de projets ou bien certains contextes clients, la methode agile est très bien adaptée. Dans d’autres situations, c’est naturellement moins le cas et il est préférable d'employer les méthodes classiques.
Zoom sur les meilleures méthodologies de développement web et informatique (methode agile et methode classique de développement.)
This document discusses the importance of organizational agility in today's changing business environment. It defines agility as the ability to quickly adapt to changing market conditions and disruptive competitors. The key aspects that enable agility are a supportive culture, strategic flexibility, collective leadership, capable people, and adaptive processes. Organizations with a highly developed culture of agility are better able to anticipate changes, implement responsive strategies, and quickly respond to market needs. Building agility requires organizations to develop capabilities in change management, risk management, and monitoring the external environment. It also involves establishing structures and policies that promote flexibility, empowerment, and an ethos of experimentation.
This document discusses the importance of organizational agility in today's changing business environment. It defines agility as the ability to quickly adapt to changing market conditions and disruptive competitors. The key aspects that enable agility are a supportive culture, strategic flexibility, collective leadership, capable people, and adaptive processes. Organizations with highly developed agility are better at responding to changes, implementing strategies, and achieving business results. While difficult, cultivating agility requires changes to policies, structures, and mindsets to empower teams and accept failures as learning opportunities. When successfully implemented, agility allows organizations to navigate disruption and thrive during uncertain times.
Making the leap from project manager to program
manager requires not just different skills but a different
mindset. We asked seven experienced program
managers, “What should project managers
know and do when taking on broader, more
strategic roles?”
Sustainable project management a whole programme indeedHSBC Private Bank
paper about Sustainable PM: our world is changing. Organizations evolve in a moving socio-political context so they must understand the impact and influence of this context on their own performance and competitiveness. But organizations are also part of the global "system" and thus interact with their environment. These interactions require a real social and environmental responsibility. This responsibility leads companies to work in link with stakeholders and society, interact with each other, or influence them in a common respect...
Une gestion de projet durable : tout un programme ... !HSBC Private Bank
paper about Sustainable PM: our world is changing. Organizations evolve in a moving socio-political context so they must understand the impact and influence of this context on their own performance and competitiveness. But organizations are also part of the global "system" and thus interact with their environment. These interactions require a real social and environmental responsibility. This responsibility leads companies to work in link with stakeholders and society, interact with each other, or influence them in a common respect...
This document provides an overview of agile project management best practices. It discusses agile basics like iterative development and valuing human factors. Key aspects of agile projects covered include using use cases, prioritizing backlog items, and estimating tasks. The document also describes challenges of smooth delivery like governance and pitfalls to avoid. Various agile processes are outlined such as sprint planning, daily standups, demonstrations, and retrospectives. Focus is placed on running successful iterations and adjusting as needed based on outcomes.
This document discusses agile project management and delivery. It covers agile basics, best practices for agile projects including use cases and keys for success. It also discusses challenges for smooth delivery such as context, pitfalls and governance. Finally, it focuses on the importance of the human factor in agile approaches.
This document discusses principles and best practices for implementing agile project management. It covers topics such as agile basics, conducting agile projects through iterations, challenges of smooth delivery, and focusing on the human factors. Key points include iterative and incremental development processes, collaborative work that values user feedback, and addressing risks early. Sprint planning, daily standups, demonstrations, and retrospectives are presented as important agile ceremonies.
OCTO TALKS : 4 Tech Trends du Software Engineering.pdfOCTO Technology
En cette année 2024 qui s’annonce sous le signe de la complexité, avec :
- L’explosion de la Gen AI
-Un contexte socio-économique sous tensions
- De forts enjeux sur le Sustainable et la régulation IT
- Une archipélisation des lieux de travail post-Covid
Découvrez les Tech trends incontournables pour délivrer vos produits stratégiques.
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...OCTO Technology
Par Nicolas Bordier (Consultant numérique responsable @OCTO Technology) et Alaric Rougnon-Glasson (Sustainable Tech Consultant @OCTO Technology)
Sur un exemple très concret d’audit d’éco-conception de l’outil de bilan carbone C’Bilan développé par ICDC (Caisse des dépôts et consignations) nous allons expliquer en quoi l’ACV (analyse de cycle de vie) a été déterminante pour identifier les pistes d’actions pour réduire jusqu'à 82% de l’empreinte environnementale du service.
Vidéo Youtube : https://www.youtube.com/watch?v=7R8oL2P_DkU
Compte-rendu :
L'IA connaît une croissance rapide et son intégration dans le domaine éducatif soulève de nombreuses questions. Aujourd'hui, nous explorerons comment les étudiants utilisent l'IA, les perceptions des enseignants à ce sujet, et les mesures possibles pour encadrer ces usages.
Constat Actuel
L'IA est de plus en plus présente dans notre quotidien, y compris dans l'éducation. Certaines universités, comme Science Po en janvier 2023, ont interdit l'utilisation de l'IA, tandis que d'autres, comme l'Université de Prague, la considèrent comme du plagiat. Cette diversité de positions souligne la nécessité urgente d'une réponse institutionnelle pour encadrer ces usages et prévenir les risques de triche et de plagiat.
Enquête Nationale
Pour mieux comprendre ces dynamiques, une enquête nationale intitulée "L'IA dans l'enseignement" a été réalisée. Les auteurs de cette enquête sont Le Sphynx (sondage) et Compilatio (fraude académique). Elle a été diffusée dans les universités de Lyon et d'Aix-Marseille entre le 21 juin et le 15 août 2023, touchant 1242 enseignants et 4443 étudiants. Les questionnaires, conçus pour étudier les usages de l'IA et les représentations de ces usages, abordaient des thèmes comme les craintes, les opportunités et l'acceptabilité.
Résultats de l'Enquête
Les résultats montrent que 55 % des étudiants utilisent l'IA de manière occasionnelle ou fréquente, contre 34 % des enseignants. Cependant, 88 % des enseignants pensent que leurs étudiants utilisent l'IA, ce qui pourrait indiquer une surestimation des usages. Les usages identifiés incluent la recherche d'informations et la rédaction de textes, bien que ces réponses ne puissent pas être cumulées dans les choix proposés.
Analyse Critique
Une analyse plus approfondie révèle que les enseignants peinent à percevoir les bénéfices de l'IA pour l'apprentissage, contrairement aux étudiants. La question de savoir si l'IA améliore les notes sans développer les compétences reste débattue. Est-ce un dopage académique ou une opportunité pour un apprentissage plus efficace ?
Acceptabilité et Éthique
L'enquête révèle que beaucoup d'étudiants jugent acceptable d'utiliser l'IA pour rédiger leurs devoirs, et même un quart des enseignants partagent cet avis. Cela pose des questions éthiques cruciales : copier-coller est-il tricher ? Utiliser l'IA sous supervision ou pour des traductions est-il acceptable ? La réponse n'est pas simple et nécessite un débat ouvert.
Propositions et Solutions
Pour encadrer ces usages, plusieurs solutions sont proposées. Plutôt que d'interdire l'IA, il est suggéré de fixer des règles pour une utilisation responsable. Des innovations pédagogiques peuvent également être explorées, comme la création de situations de concurrence professionnelle ou l'utilisation de détecteurs d'IA.
Conclusion
En conclusion, bien que l'étude présente des limites, elle souligne un besoin urgent de régulation. Une charte institutionnelle pourrait fournir un cadre pour une utilisation éthique.
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Laurent Speyser
(Conférence dessinée)
Vous êtes certainement à l’origine, ou impliqué, dans un changement au sein de votre organisation. Et peut être que cela ne se passe pas aussi bien qu’attendu…
Depuis plusieurs années, je fais régulièrement le constat de l’échec de l’adoption de l’Agilité, et plus globalement de grands changements, dans les organisations. Je vais tenter de vous expliquer pourquoi ils suscitent peu d'adhésion, peu d’engagement, et ils ne tiennent pas dans le temps.
Heureusement, il existe un autre chemin. Pour l'emprunter il s'agira de cultiver l'invitation, l'intelligence collective , la mécanique des jeux, les rites de passages, .... afin que l'agilité prenne racine.
Vous repartirez de cette conférence en ayant pris du recul sur le changement tel qu‘il est généralement opéré aujourd’hui, et en ayant découvert (ou redécouvert) le seul guide valable à suivre, à mon sens, pour un changement authentique, durable, et respectueux des individus! Et en bonus, 2 ou 3 trucs pratiques!
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...OCTO Technology
par Claude Camus (Coach agile d'organisation @OCTO Technology) et Gilles Masy (Organizational Coach @OCTO Technology)
Les équipes infrastructure, sécurité, production, ou cloud, doivent consacrer du temps à la modernisation de leurs outils (automatisation, cloud, etc) et de leurs pratiques (DevOps, SRE, etc). Dans le même temps, elles doivent répondre à une avalanche croissante de demandes, tout en maintenant un niveau de qualité de service optimal.
Habitué des environnements développeurs, les transformations agiles négligent les particularités des équipes OPS. Lors de ce comptoir, nous vous partagerons notre proposition de valeur de l'agilité@OPS, qui embarquera vos équipes OPS en Classe Business (Agility), et leur fera dire : "nous ne reviendrons pas en arrière".
1. Agilité:
Une main de fer
dans un gant de velours…
Marc BURLEREAUX, marc.burlereaux@pmi-fr.org
Release Manager Européen auprès d’une banque suisse
PMP, PMI-RMP, PgMP, ITIL V3
Sylvain GAUTIER, sylvain@sygit.ch
Consultant Agile / ITIL / BPMN société SYGIT, Suisse
Christine RIEU, christine.rieu@univ-savoie.fr
Maître de Conférences en Informatique, Laboratoire LISTIC,
Université de Savoie, Annecy
14/11/2012 1
3. Sommaire
Introduction
1. Principes de base Agile
2. Bonnes pratiques pour le cadrage et le
développement de projet en mode Agile
3. Challenges de la mise en production
4. Valoriser le facteur humain
Conclusion
14/11/2012 3
4. 1. Principes de base Agile
Tout type de projet
Alternative aux méthodes traditionnelles
Processus de développement itératif &
incrémental
Mode collaboratif qui met l’accent sur le
facteur humain
Pilotage par les cas d’utilisation
SOA
Démarche d’architecture d’entreprise
Approche Référentiel
Pilotage par les risques processus d’entreprise
’
14/11/2012 4
5. 1. Principes de base Agile suite
Des méthodes pragmatiques, partant du principe que les besoins
évoluent
Grande importance des retours utilisateurs
Le changement n’est plus considéré comme une perturbation,
mais est intégré dans l’organisation du projet
Un feedback permanent, rapide et concret
Une simplicité assumée : se focaliser sur l’essentiel et maximiser
la quantité de travail à ne pas faire
Objectifs : gagner du temps et de l’évolutivité
14/11/2012 5
6. 2.1. Bonnes pratiques pour
le cadrage d’un projet
Trois notions fondamentales:
• Backlog des fonctionnalités
• Notion de cas d’utilisation
• Notion d’activités d’un processus business
Analyse des risques métiers
Identifier les principales exigences non fonctionnelles
• Utiliser un référentiel d’exigences
• Exprimer les exigences par une phrase claire, courte
Planning poker: atelier le plus stratégique
• Chiffrer le projet
• Se mettre d’accord sur le sujet traité
14/11/2012 6
7. Cas d’utilisation (Use case ou UC)
Les cas d’utilisation ne sont pas seulement une technique pour
gérer les exigences, ils permettent de relier toutes les activités
à l’intérieur d’un projet Ivar
Jacobson
Use case y Use case z
<<fragment>>
spécifié par réalisé par Implémenté par distribué par vérifié par
Modèle des cas
d’utilisation : le
’
cœur du projet
Modèle
d’analyse
’
Modèle de
conception
Modèle
d’implémentation
’
Modèle de
déploiement
Modèle de tests
14/11/2012 7
8. 2.2 Bonnes pratiques pour le
développement d’un projet
Le processus d’itération : SPRINT !
construire un incrément fonctionnel du produit
2 à 4 semaines
Itérations synchrones entre tous les projets
Scrum Master = coordinateur des itérations du projet
Product Owner : pilote les itérations par les risques
Seulement 2 itérations planifiées maximum
14/11/2012 8
9. Processus : Conduire une itération
9H00 Game Over
Début Evènement
SCRUM Master
d’itération majeur
Ajuster le périmètre
Démonstration
Mêlée quotidienne
Mêlée Backlog
Cérémonie du
Quotidienne ajusté Rétrospective
Planning d’itération effectuée Démonstration
effectuée
Plan d’action
rédigé
Scribe
Backlog Tâche Clôture de
Saisie du plan
d’itération réalisée Saisie de
d’itération L’itération
déterminé Plan l’avancement Avancement
d’itération
saisi
saisi
Equipe projet
Non Mise à jour
Itération
Oui Des livrables
clôturée
Analyse Agile
CPU
Game
Over ?
Livrables
Test MOA Agile
À jour
Fin d’itération
Modélisation – 4 Jours
Itération
Conception terminée
CPI
Développement
Revue de Backlog Revue technique
Backlog
projet Test MOE
ajusté Suite du discours
14/11/2012 9
10. Processus : Conduire une itération
ID du Processus xxxxxxxxx Lien vers les documents de référence
Résumé du processus Gérez votre projet de manière Agile
Link 1
Propriétaire du processus Agile
Version 0.1 Link 2
Statut Draft / à valider / validé / communiqué
Link 3
Revue par Carine et Hermann
Date du statut 08/11/2011 Link 4
Enoncé de mission
Itération : période de quelques semaines durant laquelle l’équipe construit un incrément fonctionnel du produit
Objectifs du processus
1. Une itération débute par une réunion de planification, et se termine par une revue du produit et une rétrospective
2. L’équipe est « protégée » durant l’itération, le traitement des nouvelles demandes est repoussé à l’itération suivante
3. Pour donner le rythme au projet, et pouvoir comparer les itérations entre elles, toutes doivent avoir la même durée pour un projet donné
Meilleures pratiques :
1. Les engagements donnent lieu à des livrables avec un niveau de qualité convenu, comme un exécutable passant les tests unitaires, des spécifications acceptables pour le
développement, etc.
2. En fin d’itération, on analyse formellement les résultats sur la base de faits et de livrables tangibles.
3. Les conclusions sont rassemblées dans un bilan d’itération avec des recommandations d’actions correctives, pour éviter que les mêmes erreurs ne se répètent.
4. Les objectifs d’itération restent stables au cours de l’itération.
5. Les objectifs de l’itération ne sont pas revus en cours d’itération, aucun objectif supplémentaire n’est ajouté.
6. Les changements seront demandés sur l’itération suivante, sauf cas vraiment exceptionnels.
7. Un changement des objectifs ne peut que déresponsabiliser les équipes sur les engagements en cours.
8. On doit créer un véritable esprit « projet » et un objectif commun où chacun participe depuis son point de vue et depuis son domaine de responsabilité.
9. Chaque objectif / tâche est un engagement personnel, non contraint, de la part de chaque contributeur, qui s’engage pleinement sur sa capacité à livrer.
10. La fiabilité de l’engagement est d’autant plus forte que le contributeur s’engage uniquement sur le mois à venir, donc sur le futur proche.
11. L’itération se termine à sa date de fin, et non pas quand tous les objectifs sont atteints. On constate à la date de fin d’itération si les objectifs ont été atteints et les causes
précises des retards ou impossibilités.
12. Le Scrum Master est le coordinateur des itérations du projet. Ils s’assurent que chaque contributeur impliqué dans le projet a les moyens de travailler correctement.
Home Suivant
14/11/2012 10
11. Processus : Conduire une itération
Objectifs du processus
Bonnes pratiques sur la façon de mener la phase Elaboration
1. Faire des itérations par les risques
2. Dès la première itération, concevoir, implémenter et tester les cas d’utilisation prioritaires
3. Concevoir, implémenter et tester les parties centrales et risquées de l’architecture; l’architecture est construite en implémentant itérativement les cas d’utilisation
structurant du point de vue de l’architecture
4. S’adapter à chaque itération en fonction des résultats des tests, et des feedbacks des utilisateurs & développeurs
5. On n’a que deux itérations planifiées devant soi, au delà c’est imprévisible.
6. Ne pas produire trop de spécifications à l’avance : La MOA doit dégager du temps pour assister la MOE (l’objectif est de disposer de 80% des spécifications à la fin de la
phase d’élaboration).
7. Le Scrum Master est le dépositaire de la méthode.
8. La première priorité du Scrum Master est de lever les obstacles, qui se dressent devant son équipe.
9. Le terme « Sprint » qui est donné au déroulement d’une itération est impropre :
1. On réalise en fait une course de fond.
2. Une itération = un tour de piste.
3. Dès qu’une itération est terminée, on en commence immédiatement une autre, il n’y a pas de pause.
4. Le Scrum Master ménage ses troupes.
Facteurs de succès
1. L’atteinte des objectifs est confirmé par la démonstration
2. L’équipe projet est motivée
Home Précédent
14/11/2012 11
12. Tâche : Cérémonie du Planning d’itération
ID de la tâche xxxxxxxxx Lien vers les documents de référence
Résumé de la tâche Construisez votre « Cocon » de travail pour le mois à venir Link 1
Outil principal utilisé Manuel Link 2
Risque à mal faire Probabilité 10% Impact Stratégique Link 3
Objectifs de la tâche
• « En tant qu’équipe, nous planifions l’itération à venir en fonction des priorités et de notre capacité, afin de pouvoir nous engager sur le périmètre à réaliser. »
• Planifier l’itération immédiatement à venir = détailler les tâches à réaliser.
• Sélection des fonctionnalités à réaliser, identification des tâches, finalisation des critères d’acceptation, et ce à partir du Backlog de produit : fonctionnalités priorisées et
estimées (points).
Opérations de la tâche / procédure
1. Préparation
• La MOA révise le Backlog de produit, ajoute, supprime et modifie des stories, modifie les priorités si nécessaire. Product Backlog
2. Planification
• La MOA présélectionne les stories à développer dans l’itération, et présente la liste à la MOE
• La MOE identifie les stories additionnelles (défauts à corriger, travaux techniques, etc.)
• On ne traite pas formellement les dépendances des tâches d’une itération : on traitera cet aspect au jour le jour, tous les matins lors de l’attribution des tâches
(Mêlée quotidienne).
3. Déterminer le niveau de finition attendu pour l’itération
• La définition de « fini » est établie ou revue, et validée conjointement C’est quoi C’est quoi
• Les objectifs de l’itération sont précisés une une
4. Déterminer la capacité de l’équipe « bonne » « bonne »
• Capacité calendaires : CC = (effectif X durée de l’itération) - congés prévus - autres engagements story? tâche ?
• Capacité planifiée : CP = CC X facteur de focalisation (estimé)
5. Décomposition
• Pour chaque UC ou composant, l’équipe imagine les tâches à accomplir (spécification, conception, codage, métier, codage interface données, codage d’IHM, tests
unitaires, tests techniques, tests d’intégration, documents et manuels, etc.)
6. Estimation
• Chaque tâche est estimée par les « spécialistes » de l’équipe. Une valeur consensuelle est retenue.
• Note : l’estimation d’une tâche varie de 0,25 à 2 « jours idéals ». Si une tâche requiert 2 personnes, multiplier par 2 !
7. Contrôler les comptes…
• Totaliser les estimations de tâches et comparer avec la capacité calculée. Contrôler la faisabilité en fonction de la nature des tâches et des compétences des
personnes présentes sur la période
8. Négocier…
• La MOA et la MOE négocient une réduction (ou une augmentation !) du périmètre de l’itération en cas de sous- ou surcapacité.
9. S’engager
• Collectivement, l’équipe donne son sentiment sur la faisabilité du plan…
• Obtenir l’engagement de chacun sur les tâches qui lui sont attribuées, y compris les tâches reportées de l’itération précédente.
Home
14/11/2012 12
13. Product Backlog
Cas
nominal
Story 1
Tâche
1
Tâche
2 … Tâche
n
Story 2
Use
Variante 1
Case Story 3
• Pas plus d’ ½ itération
• Démontrable
Exigence
Exigence
1 Variante 2
Exigence
2
3
Exigences non
fonctionnelles
Story n
Tâche
1
Tâche
2 … Tâche
n
Précédent
14/11/2012 13
14. Tâche : Mêlée quotidienne
ID de la tâche xxxxxxxxx Lien vers les documents de référence
Résumé de la tâche Réunion de coordination d’équipe Link 1
Outil principal utilisé Manuel Link 2
Risque à mal faire Probabilité 40% Impact Sensible Link 3
Objectifs de la tâche
Chaque jour, une réunion, permet à l'équipe et au Scrum Master de suivre les progrès sur les tâches et les difficultés rencontrées.
Réunion de 15 minutes maximum : le Daily Scrum.
Présents : Le Scrum Master, le coach Agile, et les contributeurs.
Opérations de la tâche / procédure
1. S’assurer de nommer le « scribe » en début de séance.
2. Chaque membre répond à trois questions :
1. Qu'est ce que j'ai fait hier ?
2. Qu'est-ce que je vais faire aujourd'hui ?
3. Quels sont les défis / difficultés que je rencontre ?
3. Le tour de parole doit être strictement respectée afin d'éviter toute dérive.
4. Les activités peuvent se dérouler en parallèle: analyse, conception, codage, intégration, tests, etc.
5. Le choix de traiter une tâche avant une autre est effectué ici (dépendances, compétences, …).
6. Le choix de suspendre une tâche bloquée par des difficultés techniques est effectué lors de cette séance.
7. Si une tâche s’avère non réalisable, on peut la replacer dans la Backlog.
Bonnes pratiques :
1. Si possible, l'équipe travaille dans la même pièce.
2. Si le besoin s'en fait sentir, la discussion peut alors être prise librement, après le Daily Scrum.
3. Cette réunion est un point de synchronisation pour l'équipe et ne doit pas être considéré comme un rapport d'activité.
Exceptions
1. Problème grave détecté : en référer immédiatement au CMPU/CMPI et tracer le problème dans le rapport hebdomadaire de la semaine en cours
Home
14/11/2012 14
15. Tâche : Démonstration
ID de la tâche xxxxxxxxx Lien vers les documents de référence
Résumé de la tâche Démontrer l’incrément produit Link 1
Outil principal utilisé Manuel Link 2
Risque à mal faire Probabilité 40% Impact Critique Link 3
Objectifs de la tâche
1. L’équipe présente les nouvelles fonctionnalités aux parties prenantes et recueille le feedback = Revue du produit (qualité de la conception / code ….).
Opérations de la tâche / procédure
1. Effectuer la démonstration de l’incrément de produit réalisé lors de l’itération qui se termine :
1. L’incrément produit est vérifié, démontré et validé
2. Les défauts constatés sont notés pour être saisis comme tâches de la story « correction de bugs » de l’itération suivante
2. Faire la revue des tâches de l’itération précédente :
1. Fait / pas fait.
2. Nombre de défauts constatés.
3. Reporter le non fait sur l’itération suivante (nouvelles tâches).
4. Reporter les défauts sur l’itération suivante (nouvelles tâches), avec une priorité 1.
5. Calculer l’état d’avancement : Exemple : 70% des points sont démontrés (% d’un statut du processus de fabrication).
3. Ecrire le résumé de l’itération et mesures d’amélioration dans le rapport hebdomadaire.
Exceptions
1. …
Home
14/11/2012 15
16. Tâche : Rétrospective
ID de la tâche xxxxxxxxx Lien vers les documents de référence
Résumé de la tâche Analyser le processus, Rechercher les causes, Proposer des améliorations Link 1
Outil principal utilisé Manuel Link 2
Risque à mal faire Probabilité 40% Impact Critique Link 3
Objectifs de la tâche
1. En tant que participants au projet, nous analysons régulièrement notre processus et nos procédures de travail afin d’améliorer notre efficacité.
2. L’équipe fait le bilan méthodologique, outil et humain de l’itération qui se termine = Revue du processus (efficacité, efficience).
Opérations de la tâche / procédure
• Durée : 1 à 3 heures
• La rétrospective est une cérémonie de fin d’itération, dont l’objectif est d’optimiser le processus. Toute l’équipe (MOA, MOE) participe
1. Les bonnes pratiques et les pratiques à faire évoluer sont identifiées
2. Les décisions sont prises pour optimiser le processus
• Déroulement
1. Initialisation (15’)
• Un membre de l’équipe résume ce qui a été livré, l’état du reste à faire en fin d’itération (planifié non fait), et fait le point sur les décisions prises à la
rétrospective précédente.
2. Identification des points positifs et négatifs (20’ – 30’)
• Chaque membre du projet liste les points positifs et négatifs de l’itération (seul ou en binôme)
3. Analyse (60’ – 90’)
• Les membres de l’équipe exposent leurs idées, et le groupe recherche les causes des dysfonctionnements ou les facteurs qui ont permis de bons
résultats.
• L’équipe sélectionne les éléments les plus significatifs
4. Décisions (30’ – 60’)
• L’équipe décide du plan d’action pour :
1. améliorer certaines pratiques
2. reconduire les pratiques qui ont eu des effets positifs
5. Clôture
• Engagement de l’équipe
Exceptions
1. …
Home
14/11/2012 16
17. Tâche : Ajuster le périmètre
ID de la tâche xxxxxxxxx Lien vers les documents de référence
Résumé de la tâche Modifier le Backlog de l’itération en cours, en cas de force majeure Link 1
Outil principal utilisé Redmine / RTC ... Link 2
Risque à mal faire Probabilité 20% Impact Faible Link 3
Objectifs de la tâche
Modification des objectifs de l’itération, les items les moins prioritaires sont éventuellement exclus
Opérations de la tâche / procédure
1. Retirer une story du Backlog d’itération, et la replacer dans le Backlog de projet
2. Déplacer une tâche d’une story de l’itération vers une story de l’itération suivante
3. Pratiquer le change for free
4. Tracer les déplacements de story / tâche dans le rapport hebdomadaire de la semaine en cours
Exceptions
Home
14/11/2012 17
18. Tâche : Revue de Backlog
ID de la tâche xxxxxxxxx Lien vers les documents de référence
Résumé de la tâche Préparer l’itération suivante Link 1
Outil principal utilisé Redmine / RTC ... Link 2
Risque à mal faire Probabilité 20% Impact Sensible Link 3
Objectifs de la tâche
• « En tant qu’équipe, nous maintenons le Backlog de Produit à jour afin d’avoir une vision réaliste du reste à faire et des priorités, et pour planifier la prochaine itération. »
• Tenir compte de ce qui a été modifié dans le Backlog du projet
• Préparer l’itération suivante, faciliter la planification, et rendre ainsi la cérémonie de planning d’itération à venir plus efficace et moins longue.
Opérations de la tâche / procédure
Durée : deux à 4 heures. Cette durée supplémentaire en réunion est largement amortie par la diminution de celle de planification et par le temps gagné sur le travail
préparatoire de la prochaine itération.
1. La Revue de Backlog est un travail d’équipe, mené par les CPU / CPI, assistés de membres du projet selon le besoin. Il n’est pas nécessaire que toute l’équipe participe (sauf
en cas de ré-estimation de stories)
2. S’assurer que les Stories couvrent l’ensemble des besoins
1. Tous les UC et fragments sont représentés par des Stories
2. Des Stories peuvent être créées pour des activités de formation, construction de plateforme de développement, etc.
3. Vérifier les estimations en points
1. Toutes les stories sont estimées en points
2. Les estimations sont cohérentes (avec les connaissances du moment…)
3. Les nouvelles stories sont estimées
4. Revoir les priorités
1. ≈ 20% de stories à réaliser : priorité Elevée
2. ≈ 30% de stories à réaliser : priorité Moyenne.
3. ≈ 50% de stories à réaliser : priorité Faible
5. Décomposer les Stories prioritaires en Stories de taille appropriée
1. Choisir un ou plusieurs axes de décomposition
2. Créer les stories identifiées, les décrire, planifier, estimer en points
3. Supprimer la story décomposée ( obsolète), ou lier les stories subdivisées à la story d’origine ( lien parent)
4. Mettre à 0 la charge de la story décomposée
Exceptions
1. Si suffisamment d'éléments sont prêts à être inclus dans la prochaine itération, la réunion n'est pas utile.
Home
14/11/2012 18
19. Tâche : Revue Technique
ID de la tâche xxxxxxxxx Lien vers les documents de référence
Résumé de la tâche S’assurer du respect des standards qualité au fil de l’eau Link 1
Outil principal utilisé RSA, …. Link 2
Risque à mal faire Probabilité 40% Impact Sensible Link 3
Objectifs de la tâche
Effectuer des revues sur les livrables de l’ensemble des outils utilisés
Opérations de la tâche / procédure
1. Relecture de code entre pairs.
2. Revue des « logs » des outils utilisés (gestion de versions, SGBD, CMDB) : lister les items qui ont effectivement été créés, modifiés, supprimés, par qui et quand.
3. Vérification de la bonne application des normes et standards des outils utilisés.
4. Créer les tâches de réajustement nécessaires dans une story « Réajustement qualité / standards » au sein de l’itération suivante.
1. Créer les tâches de réajustement nécessaires dans une story « Payer la dette technique » en fonction de la définition de « fini » établie conjointement en début d’itération.
Cette story sera réalisée vers la fin de la phase de construction.
Exceptions
Home
14/11/2012 19
20. Tâche : Tests MOE
ID de la tâche xxxxxxxxx Lien vers les documents de référence
Résumé de la tâche Tester la story Link 1
Outil principal utilisé Poste de travail socle standard + environnement de test Link 2
Risque à mal faire Probabilité 40% Impact Sensible Link 3
Objectifs de la tâche
S’assurer que les stories sont développées selon la conception et la modélisation validées
Opérations de la tâche / procédure
1. Tester ce qui est produit, selon ce qui a été décrit dans les documents de conception et de modélisation.
2. Faire corriger immédiatement ce qui peut l’être.
1. Reporter les défauts non immédiatement corrigeables sur l’itération suivante (nouvelles tâches), au sein d’une story de priorité 1.
Exceptions
Home
14/11/2012 20
21. Tâche : Tests MOA
ID de la tâche xxxxxxxxx Lien vers les documents de référence
Résumé de la tâche Tester le Use Case et ses exigences Link 1
Outil principal utilisé Poste de travail socle standard + environnement de test Link 2
Risque à mal faire Probabilité 40% Impact Sensible Link 3
Objectifs de la tâche
S’assurer que l’incrément développé est en ligne avec les spécifications de Use Cases spécifiés (ainsi que les exigences et règles de gestion associées).
Opérations de la tâche / procédure
1. Tester ce qui est produit, selon les spécifications (Use cases, fragments, variantes, exigences, règles de gestion), si possible au fil de l’eau du développement et de sa
concrétisation sur l’environnement de test.
2. Reporter les bugs ainsi que le non alignement des spécifications avec le code et / ou la conception lors du Daily Scrum du lendemain.
Exceptions
Home
14/11/2012 21
22. Tâche : Modélisation
ID de la tâche xxxxxxxxx Lien vers les documents de référence
Résumé de la tâche Un bon modèle vaut mieux que 100 pages de documentation Link 1
Outil principal utilisé Visual Paradigm, PowerAMC, RSA, IDA, ARIS Link 2
Risque à mal faire Probabilité 40% Impact Stratégique Link 3
Objectifs de la tâche
La MOE ainsi que les architectes réalisent les modèles de conception nécessaires, utilisant les outils idoines.
Opérations de la tâche / procédure
1. Organiser des ateliers
2. Réaliser les modèles (Diagrammes de classes, de séquences, modèles de données, architecture des composants ….).
3. Reformuler les modèles
4. Remonter les modèles aux architectes
5. Corriger les modèles selon les remarques émises par les architectes
Exceptions
Home
14/11/2012 22
23. Tâche : Conception
ID de la tâche xxxxxxxxx Lien vers les documents de référence
Résumé de la tâche Décrire la cinématique entre les modèles Link 1
Outil principal utilisé ….. Link 2
Risque à mal faire Probabilité 40% Impact Sensible Link 3
Objectifs de la tâche
Ecrire les spécifications techniques, les diagrammes explicatifs associés, indiquant la logique de conception de la solution
Opérations de la tâche / procédure
1. Ecrire les spécifications techniques complémentaires aux modèles.
2. Décrire comment collaborent les modèles entre eux.
3. Décrire le comportement des composants logiciels.
4. Etablir le ou les schéma explicatifs nécessaires, en utilisant les outils de référence, dans la mesure du possible.
Exceptions
Home
14/11/2012 23
24. Tâche : Analyse
ID de la tâche xxxxxxxxx Lien vers les documents de référence
Résumé de la tâche Rédiger les spécifications fonctionnelles Link 1
Outil principal utilisé RRC Link 2
Risque à mal faire Probabilité 40% Impact Critique Link 3
Objectifs de la tâche
Ecrire les spécifications fonctionnelles, au sein du référentiel d’entreprise RRC.
Rester succin, non ambiguë et clair.
Opérations de la tâche / procédure
1. Décrire précisément les Use Cases (cas nominal et variantes)
2. Décrire clairement les règles de gestion associées aux use cases
3. Décrire les enchainement d’écrans
4. Réaliser les maquettes d’IHM
5. Se coordonner et échanger avec les autres MOA afin d’éviter les chevauchements de fonctionnalités entre les PAC (Le partage d’accès en lecture aux zones de projets RRC
est une aide importante pour traiter ce point).
6. Exporter les spécifications RRC dans un document MS-WORD partageable et archivable.
Exceptions
Home
14/11/2012 24
25. C’est quoi une « bonne » tâche ?
C’est une tâche limitée dont la réalisation est limitée dans le temps (2 jours)
– Pour supprimer l’effet tunnel et détecter au plus tôt les dépassements liés à des difficultés
• L’effort pour une tâche est donc compris entre 2 et 12 heures « idéales » en général
– Attention aux tâches planifiées pour une exécution en binôme (on multiplie l’effort par 2 !)
Le résultat attendu est décrit de façon intelligible, précise et quantifiée
– Exemples : un document, du code, la description de 3 scénarios de test, déploiement d’un outil, …
– Permet de dire « c’est fini »
C’est une tâche qui concours aux objectifs de l’itération en cours …
– Développement d’une story (de la spécification à l’intégration)
– Tâches techniques : « tester l’environnement de développement », …
– Montée en compétence : formation, travail en binôme senior/junior
… ou qui permet d’obtenir un indicateur d’avancement réaliste
– Congés et autres absences planifiées (ne pas créer après coup de tâche pour absence imprévue !)
Et c’est quoi une « pas bonne tâche »
– Les tâches récurrentes et obligatoires du processus ne sont pas planifiées (planning, démo, etc.)
– Les tâches de type « là je me garde 10 heures au cas ou j’aurais un problème, on ne sait jamais »
– Les réunions de pilotage de projet
Précédent
14/11/2012 25
26. C’est quoi une « bonne » story ?
C’est une fonction métier compréhensible et utilisable par un utilisateur (ou
par un informaticien si c’est une fonction technique du socle)
– Ceci est nécessaire pour que l’avancement du projet soit basé sur des fonctionnalités
livrées (avec le niveau de finition et de qualité attendus)
C’est un UC, ou un fragment, ou une partie de UC/fragment dont :
– Les tâches de la conception à la démonstration peuvent être réalisées au cours d’une et
une seule itération
– La « bonne » durée de réalisation tourne autour d’1/2 itération
• Pour limiter l’effet tunnel
• Faciliter l’ordonnancement des travaux
• Pour maximiser le nombre de stories terminées en fin d’itération
En synthèse :
– Un Cas d’utilisation est strictement une vue fonctionnelle ou utilisateur
– Une story est une vue fonctionnelle qui prend en compte les nécessités d’ingénierie
(découpage du UC en de multiples stories qui peuvent être implémentées en 1 itération)
Précédent
14/11/2012 26
27. 3. Challenges de la mise en production
Contexte
Domaine bancaire
Cycle de Release
– Mise en Production des Changements par Release Mensuelle et Hebdomadaire
– Changements : « Livrables de projets et / ou d’évolutions mineures »
– Release corrective Mensuelle pour certains produits
Taille des livraisons
– 100 à 150 projets par an
– 100 à 150 évolutions mineures par an
Contexte Méthodologique
– Méthodologie classique (« waterfall ») avec gestion des risques
– Quelques projet agiles sur certaines applications
– Volonté d’introduire de l’agilité à commencer par le processus des « Release »
Hors du cadre
– Corrections des incidents (ITIL niveaux 1, 2 et 3)
– Interventions et changements infrastructure sans besoins de tests utilisateurs
14/11/2012 27
28. 3. Challenges de la mise en production
Ecueils dus à l’agilité
Livraisons trop fréquentes
– Tous les acteurs ont du mal à suivre, y compris les utilisateurs :
– Test
– Formation / Support de cours
– Coordination de mise en place des changements
– Visibilité partagée amoindrie -> risque de « louper » des dépendances
– Risque de déstabilisation de la production
Manque d’implication des architectes et de la sécurité dès l’origine
– Remise en cause tardive des livrables
– Création de dette technique
Manque d’implication des équipes d’intégration et infrastructure
Manque d’implication des équipes de déploiement et support
Résultats :
• Production gérée par les équipes projet (voire le fournisseur)
• Instabilité de la production et mauvais service rendu au client
• Dette technique coûteuse
• Pérennité de la solution amoindrie
• Image de marque de l’IT écornée
• Etc …
14/11/2012 28
29. 3. Challenges de la mise en production
Conseils
Impliquer tous les acteurs dès l’initiation du projet et la première itération
– Architectes
– Equipes de sécurité
– Equipes d’intégration, infrastructures et déploiement
Aligner tous les acteurs sur le niveau d’exigences requis (qualité et homologation)
– Remise en cause tardive des livrables
– Création de dette technique
Engager tôt les équipes de test et travailler sur l’automatisation des tests
Impliquer à temps les équipes de déploiement et support
Résister à la tentation de livrer trop fréquemment en production
Attacher de l’importance aux exigences Non Fonctionnelles
Garantir la bonne transition en production en intégrant les préceptes ITIL
14/11/2012 29
30. 3. Difficultés de la mise en production
Gouvernance
Assurer l’initiation des projets en phase avec la stratégie métier
Mettre en place une intégration continue
Soigner la réception et l’homologation
– Acceptation fonctionnelle par les utilisateurs
– Acceptation non fonctionnelles par les équipes techniques et de support
Veiller à la bonne transition en production par un processus de mise en
production rigoureux
– Partager les informations décrivant le changement et les phases de mise en
œuvre
– Vérifier le respect de la qualité requise
– S ’assurer de la dépendances des changements
– Tenir compte des contraintes de ressources et contraintes externes
– Gérer le risque de la mise en production
14/11/2012 30
31. 4. Valoriser le facteur humain
Changement de rôle du chef de projet
Leader
Manager
inspirateur et
gestionnaire
facilitateur
Acteur de la production de la valeur
Coach, rôle « protecteur »
Autogestion des équipes
Redonner envie de travailler ensemble
Favoriser l’apprentissage par une approche empirique
Capitaliser l’expérience
Privilégier la performance à long terme
Qualité = objectif commun
!
Faire mieux n’est pas synonyme de faire plus ou faire trop :
attention au STRESS
L’intelligence collective ne doit pas freiner la capacité créative des
individus
14/11/2012 31
32. Conclusion
Méthodes Agile = philosophie de développement (pas une boîte à
outils!)
Pas de démarche universelle mais panachage conseillé
Prendre le « bon » et laisser les lourdeurs
Gestion du risque
Exemple de PMI Project Management Institute qui intégre l’Agilité
• Nouvelles certification PMI-ACP (Agile Certification Practitioner)
• Prise en compte des méthodes Agiles dans le PMBOK 5th Ed. 2012
14/11/2012 32