Click to edit Master subtitle style
Améliorer l’excellence
opérationnelle et gagner un avantage compétitif grâce aux
méthodes agiles
30 avril 2009
Pierre Jannez
Planning
§
Le système de management Lean
§
Pourquoi agile?
§
Scrum et eXtreme Programming
§
Retours d’expérience
§
Questions / réponses
Planning
§
Le système de management Lean
§
Pourquoi agile?
§
Scrum et eXtreme Programming
§
Retours d’expérience
§
Questions / réponses
Le système de management Lean
Planning
§
Le système de management Lean
§
Pourquoi agile?
§
Scrum et eXtreme Programming
§
Retours d’expérience
§
Questions / réponses
Pourquoi agile?
Statistiques projets IT
§
Selon IEEE Spectrum (2005),
10% projets IT abandonnés
Au moins 70% des projets
– Livrés en retard
– Hors budget
– Nécessitent des adaptations importantes après livraison
§
Raisons multiples
Problèmes de spécifications
Mauvaise compréhension des risques
Problèmes avec les process
…
vers les méthodes agiles en réponse aux différentes difficultés
Les difficultés du modèle classique (1)
Rigidité de la méthode et intégration difficile du changement
Analyse des besoins et faisabilité
Spécifications
Conception Architecturale
Conception détaillée
Codage
Tests de validation
Agile
à Cycles itératifs de courte durée avec livraison d’un produit UTILISABLE à la fin de chaque itération
à Modes de développement et de capture des besoins
permettant de prendre en compte le changement à tout moment (voir capture des besoins, just in time
specification)
Analyse des besoins et faisabilité
Spécifications
Conception Architecturale
Conception détaillée
Codage
Tests de validation
Installation
Itération 1
Itération 2
Itération 3 INCEPTION
§
Itérations de 1 à 6 semaines
§
Résultat d’une itération prototype version
intermédiaire du produit final
Les difficultés du modèle classique (2)
Effet tunnel, manque d’interaction avec le client
Analyse des besoins et faisabilité
Tests de validation
Installation Grosse interaction
pour la réalisation de l’analyse Acceptation de
l’analyse
Faible interaction
Grosse interaction Acceptation de
Agile
à
Client intégré à l’équipe (de préférence sur site)
à
Feedback régulier du client
à
Client fortement impliqué (avec support du scrummaster) dans
•
la définition des fonctionnalités sous forme de stories
•
la définition des scénarii de tests
à
Client « maître » des fonctionnalités à développer
Les difficultés du modèle classique (3)
Documentation pléthorique et difficilement maintenable
o
On veut capturer TOUS les besoins en début de projet
o
Nombreux documents d’analyse, conception, architecture…
o
Maintenance de ces documents difficile (voire
Agile
à
Capture des besoins très « high-level » en début de projet = users stories
En tant que <type d’utilisateur>, je veux <fonctionnalité à implémenter>
pour <valeur business>
Ex: CRM – En tant que manager commercial, je veux pouvoir voir les nouveaux contacts ajoutés par mes commerciaux pour suivre la prospection // use case UML mais bcp moins formel
à
Analyse détaillée du besoin juste avant (just in time
specification) le développement par la définition des cas de test (TDD). QUE les fonctionnalités utiles.
à
Documentation dans le code (mais juste le nécessaire)
Bénéfices
Client Fournisseur
Transparence Relation client plus saine
ROI plus rapide Meilleure réponse aux besoins Mesure de l’avancement Respect des plannings
Adéquation par rapport aux besoins Rentabilité
Augmentation de la qualité
Les valeurs et les principes “agiles”
à
2001 : Manifeste Agile et Agile Alliance
§
17 experts dont K.Schwaber, K.Beck, W.Cunningham
§
Le Manifeste Agile débute par la déclaration suivante (traduction) :
" Nous avons trouvé une voie améliorant le
développement logiciel en réalisant ce travail et en aidant les autres à le faire. De ce fait nous avons déduit
des valeurs communes. "
Les 4 valeurs « agiles »
1.
L'équipe
« Personnes et interaction plutôt que processus et outils »
2.
L'application
« Logiciel fonctionnel plutôt que documentation complète »
3.
La collaboration
« Collaboration avec le client plutôt que négociation de contrat »
4.
L'acceptation du changement
« Réagir au changement plutôt que suivre un plan »
Les 12 principes
1.
Satisfaction client (livrer tôt et régulièrement)
2.
Acceptation du changement
3.
Livraison fréquente d’une application opérationnelle
4.
Collaboration quotidienne
5.
Confiance et support
6.
Transmettre les informations en face à face
7.
Mesure de l'avancement avec le logiciel réalisé
8.
Avancer à un rythme de développement durable
9.
Attention continue à l'excellence technique
10.
Simplicité
11.
Auto-organisation
12.
Feedback et ajustement
Planning
§
Le système de management Lean
§
Pourquoi agile?
§
Scrum et eXtreme Programming
§
Retours d’expérience
§
Questions / réponses
Introduction à Scrum
à
K.Schwaber - J.Sutherland
à
1990-1992 1996 : SCRUM development process – K.Schwaber
à
« scrum » = « mêlée » rugby plutôt que course relais
à
Gestion de projet guidée par la valeur business
à
Actuellement, environ 70% des projets « agiles » utilisent
Caractéristiques de Scrum
• Petite équipe (5-10 personnes)
• Equipe responsable, en auto-organisation
• « sprints » d’un mois ou moins
• Utilisation de règles génériques permettant de créer un environnement agile pour un
projet (ex: outil de communication visuels)
Tableau de suivi
Déroulement Scrum
Image disponible à
Le cadre Scrum
• Dir. Produit (product owner)
• ScrumMaster
• Equipe
Rôles
• Planification du sprint
• Revue du sprint
• Rétrospective
• Scrum quotidien
Réunions
• Backlog de produit
• Backlog de sprint
• Burn Down charts
Artefacts
Les rôles
• Planification du sprint
• Revue du sprint
• Rétrospective
• Scrum quotidien
Réunions
• Backlog de produit
• Backlog de sprint
• Burn Down charts
Artefacts
• Dir. Produit (product owner)
• ScrumMaster
• Equipe
Rôles
Le directeur de produit (product owner)
•
Définit les fonctionnalités du produit (backlog du produit)
= user stories
En collaboration avec l’équipe (estimation)
•
Choisit la date et le contenu de la release
•
Définit les priorités dans le backlog valeur « métier » =
« points » client
•
Ajuste les fonctionnalités et les priorités à chaque sprint si nécessaire
En tant que client potentiel, je veux voir les photos des maisons.
Le Scrum Master
•
Représente le management du projet
•
Garant des valeurs et des pratiques de Scrum
•
Résout les problèmes
•
S'assure que l'équipe est complètement fonctionnelle et productive
•
Facilite une coopération poussée entre tous les rôles et fonctions
•
Protège l'équipe des interférences extérieures
L’équipe
•
De 5 à 10 personnes
•
Regroupant tous les rôles
o
Architecte, concepteur, développeur, spécialiste IU, testeur, etc.
•
A plein temps sur le projet, de préférence
o
Exceptions possibles (administrateur, …)
•
L’équipe s’organise par elle-même
•
La composition de l’équipe ne doit pas changer pendant un Sprint
• Backlog de produit
• Backlog de sprint
• Burn Down charts
Artefacts
Réunions
• Dir. Produit (Product Owner)
• ScrumMaster
• Equipe
Rôles
• Planification du sprint
• Revue du sprint
• Rétrospective
• Scrum quotidien
Réunions
Planification du sprint (1)
• Point de départ: le backlog de produit avec les estimations planning game
1. Phase exploratoire:
o Liste des scénarii
o Explication/Clarification (Q&A)
o Refactorisation (scission/fusion)
2. Estimation en “points”
o Scénarii similaires comme référence
1. Classement des stories selon
le ratio “Valeur business”/”Estimation en points”
Valeur business
En tant que client potentiel, je veux voir les photos des maisons.
V500 / T3
8 Risque technique
(fort, moyen, faible)
Estimatio
n en
points
Planification du sprint (2)
Planification du sprint
Périmètre
• Analyser et évaluer le backlog de produit
• Définir le but du sprint Plan
• Conception (comment s'y prendre)
• Créer la liste des tâches à partir des éléments du
backlog de produit
• Estimer les tâches en heures
But du sprint
Backlog du sprint
Condition s
métier Capacité
de l'équipe Backlog de produit
Technos Produit
actuel
Planification du sprint (3) – le but du sprint
Un bref énoncé de sur quoi le travail va essentiellement porter pendant le sprint
Database Application
Services financiers Location de
maisons
Mettre en place le
processus de réservation
Offrir plus d'indicateurs que le produit ABC sur les
données de streaming . Faire tourner l'application
sur une base MySQL en
plus d'Oracle.
Planification du sprint (4)
• L'équipe choisit, à partir du backlog de produit, les éléments qu'elle s'engage à finir.
•
Le backlog de sprint est créé
o Les tâches sont identifiées et estimées (1-16 heures si possible) o Collectivement, pas seulement par le ScrumMaster
• La conception de haut niveau est abordée
En tant que client
potentiel, je veux voir les photos des
maisons.
Coder la couche de persistance (8h) Coder l’IU(4h)
Ecrire les tests (4h)
Coder la classe business (6h) Tests (4h)
Scrum quotidien
• Paramètres
o Tous les jours
o 15 minutes maximum (!) o Debout
o 3 questions:
1.
Qu’ai-je fait hier?
2.
Que vais-je faire aujourd’hui?
3.
Problèmes (passés/futurs)?
• Pas un compte rendu au scrum master: réunion par et pour l’équipe
• Pas fait pour résoudre les problèmes
o Tout le monde est invité
o Seuls les membres de l'équipe peuvent parler
Revue et retrospective de sprint
• Revue
•
L'équipe présente ce qu'elle a fait pendant le sprint démo des nouvelles fonctionnalités ou de l'architecture
• Retrospective
•
A la fin de chaque sprint: réfléchir
régulièrement à ce qui marche et ce qui ne
marche pas amélioration constante
Artefacts
• Dir. Produit (Product Owner)
• ScrumMaster
• Equipe
Rôles
• Planification du sprint
• Revue du sprint
• Rétrospective
• Scrum quotidien
Réunions
• Backlog de produit
• Backlog de sprint
• Burn Down charts
Artefacts
Backlog de produit (1)
• Exigences
• Une liste de tout ce qui va entraîner du travail
• Chaque élément doit apporter de la valeur aux utilisateurs ou clients du produit
• Les priorités sont définies par le directeur produit (valeur « business »)
• Les priorités peuvent être revues à chaque sprint
Backlog de produit (2)
Elément de backlog Estim. Valeur
Un client potentiel peut voir les images d’une maison 8 500
Un client peut faire une réservation 10 1000
Un client peut annuler une réservation 4 200
Un client peut changer les dates d’une réservation 2 300 Un administrateur peut créer une nouvelle annonce 15 1000 Un propriétaire peut introduire une rectification de tarif 3 50
… 30
… 50
Backlog de sprint (1)
• Chacun s'engage sur du travail qu'il choisit
o Le travail n'est jamais assigné par un autre
• L'estimation du « reste-à-faire » est ajustée tous les
jours
Backlog de sprint (2)
Tâches Estimation
Story: Un client potentiel peut voir les images d’une maison
Coder la couche de persistance 8h
Coder l’IU 4h
Ecrire les tests 4h
Coder la classe business 6h
Tests 4h
Story: Un client peut faire une réservation
… 8h
Backlog de sprint (3) - Suivi
Tâches Lu Ma Me Je Ve
Coder la couche de
persistance 8h 4h - - -
Coder l’IU 4h - - - -
Ecrire les test 4h 3h 1h - -
Coder la classe business 6h 5h 3h 2h -
Test de performance 4h 4h 4h 4h -
Burn Down charts – Sprint burn down
Tâches Lu Ma Me Je Ve
Coder la couche de
persistance 8h 4h - - -
Coder l’IU 4h - - - -
Ecrire les test 4h 3h 1h - -
Coder la classe business 6h 5h 3h 2h -
Test de performance 4h 4h 4h 4h -
Nombre d’heures
restant
4 6 8 10 12
eXtreme Programming (XP) (1)
à
Kent Beck, Ward Cunningham et Ron Jeffries (1999)
o
Projet Chrysler « C3 » : amélioration réécriture
à
Orienté développement
à
Plus complet de Scrum (dev)
à
Assez similaire à Scrum pour planification / gestion
Les drivers d’XP
à
Pousser les bonnes pratiques à l’extrême:
o revue de code elle sera faite en permanence par un binôme (pair programming)
o tests ils seront faits systématiquement avant chaque
implémentation (Test Driven Development ) + AUTOMATISATION
o conception elle sera faite tout au long du projet (refactoring)
o l'intégration des modifications elle sera effectuée jusqu’à plusieurs fois par jour
o Règles de codage
à
Responsabilité collective du code:
o Travail sur n’importe quelle partie
o Amélioration
à
Séparation business - technique
Planning
§
Le système de management Lean
§
Pourquoi agile?
§
Scrum et eXtreme Programming
§
Retours d’expérience
§
Questions / réponses
Retours d’expérience
Planning
§
Le système de management Lean
§
Pourquoi agile?
§
Scrum et eXtreme Programming
§
Retours d’expérience
§
Questions / réponses
Questions / réponses
à
Beaucoup de méthodes agiles disponibles:
à PUMA (Processus Urbanisant les Méthodes Agiles)
à Crystal Clear
à Agile Unified Process
à …
à
Ces méthodologies ne se font pas concurrence, mais répondent à des besoins différents. Chacune propose
des éléments intéressants en fonctions du type de projet, de la taille de l’équipe…
à
Ex: Wavenet – Scrum / XP
Copyright
Cette présentation contient des extraits de “Introduction à Scrum” par Mike Cohn, traduction par Claude Aubry
Merci à eux
Wavenet
Avenue de la libération 46 7900 Leuze-en-Hainaut
Tel :+32 69 67 03 35 info@wavenet.be www.wavenet.be
End of slides
Références
Références Web
à
www.agilealliance.org
à
www.scrumalliance.org
Lectures (1)
En anglais:
• Agile and Iterative Development: A Manager’s Guide de Craig Larman
• Agile Estimating and Planning de Mike Cohn
• Agile Retrospectives d'Esther Derby et Diana Larsen
• Agile Software Development Ecosystems de Jim Highsmith
• Scrum and the Enterprise par Ken Schwaber
• User Stories Applied for Agile Software Development de Mike Cohn
• Des articles toutes les semaines à www.scrumalliance.org
Lectures (2)
En français :
•
Gestion de projet – Vers les méthodes agiles de V. Messager Rota
•
Gestion de projet – eXtreme Programming de JL Bénard, L.Bossavit, R.Medina, D. Williams
•
Le blog Scrum Méthodes Agiles : scrum.aubryconseil.com
Slides supplémentaires
Burn Down charts – Release burn down
Nombre de points
restant
2 4 6 8 10 12
Nombre de points restant
Itération 1 15/01
Itération 2 15/02
Itération 3 15/03
Itération 4 15/04
Itération 5 15/05
Itération 6 15/06
Itération 7 15/07
550 495 365 235
Outil de suivi / reporting de Wavenet
Les 5 mots-clés XP
1.
Communication
A l’origine d’un problème : souvent une
non-communication
1.
Feedback
o Le remède contre un trop plein d’optimisme
o Plus de feedback = plus de capacité à réagir
2.
Simplicité
« le mieux est l’ennemi du bien »
Courage
Les rôles XP
à Programmeur
o créateur et artisan
à Client
o stories + scenarii de tests
à Testeur
o bras droit du client transcription des scénarii
à Tracker
o suivi pendant l’itération (psychologie)
o Uniquement suivi, pas d’action (coach)
à Manager
o supérieur hiérarchique (logistique).
o Interface avec l’extérieur
à Coach:
o rôle très important.
o Garant du processus XP (rôles, pratiques). Intervention diminue au fur et à
Informations additionnelles
•
Test Driven Development
1. On écrit le test
2. On vérifie que le test échoue (la fonctionnalité n’est pas encore développée)
3. On écrit le code le plus simple qui permet de faire passer le test
4. On vérifie que le test passe
5. On remanie le code
•
Outils open-source d’automatisation de tests:
§. SELENIUM: http://selenium.seleniumhq.org/index.html
§. APODORA: http://www.apodora.org/
Les difficultés de mise en place
à
Philosophie générale. Le client est-il prêt?
à
Logistique
à
Agile vs contrat au forfait? (2 phases)
à
Maturité des développeurs (tâches multiples, auto- organisation…)
à
