SlideShare une entreprise Scribd logo
1  sur  47
Télécharger pour lire hors ligne
Retours sur 4 ans
d’industrialisation de l’agilité
        Rémy Génin - Orange

           Octobre 2010
Les pièges
Les pièges qu’on connait bien …


• le scope fonctionnel va changer pendant le
  projet, donc
  o l’engagement sur un périmètre figé est une utopie
  o les specs trop détaillées avant de démarrer sont
    ineptes
• la formulation en H/J crée un engagement
  implicite.
  préférez les points de complexité
• une stratégie métier qui change en cours de
  route
Les pièges liés à l’agilité


• product owner
  pas assez disponible, pas assez compétent, non-
  légitimé
• des moyens insuffisants
  pas de ScrumMaster, pas de testeur, pas
  d’automatisation
• les règles de base non respectées
  « pas de rétrospective ! pas le temps »
• adaptabilité ne veut pas dire « je fais ce que je
  veux ».
  la rigueur est incontournable                  retour
Construire
      SA
proposition agile
La proposition « Orange Agile »


• part de l’existant

• précise les choses

• inclut l’environnement Orange, qui
  o est complexe
  o contient un grand nombre de contraintes
Diffuser l’information et accompagner :
                                         Un centre d’expertise

Un centre d’expertise est là pour vous aider et vous accompagner dans tout
ce qui touche l’agilité :
  - Présentations (multiples au besoin)
  - Formations
  - Trouver un ScrumMaster
  - Faire monter en compétence un ScrumMaster
  - Coacher le projet
  - Faire un audit ponctuel

Un site intranet pour centraliser l’information et les documents partagés, des
FAQ, des fiches pratiques, des explications détaillées

Une communauté avec des forums par rôle agile

Un « mode d’emploi » informatisé en préparation
                                                                   retour
Les rôles
Les rôles agiles – La base

« Product Owner »
  responsable du contenu fonctionnel



« ScrumMaster »
  facilitateur en l’agilité



 une équipe de développeurs
Rôles – les compléments utiles
– le Coach agile
=> Aide le ScrumMaster à mettre/maintenir un bon niveau d’agilité

– le CP
 => Pilote global
       aspects administratifs, production des documents demandés, gestion des
       interfaces, passage des jalons, reporting
 => s’occupe d’insérer l’application dans le SI
   (métrologie, intégration, exploitation)
– le testeur
 => possède des compétences de développeur
 => a pour fonction d’implémenter et automatiser les tests
   fonctionnels
– le manager
 => supérieur hiérarchique
 => décideur : tranche si l’équipe / le CP n’en ont pas le pouvoir
Le coach agile

Coach agile

• aide ponctuellement et régulièrement le ScrumMaster à
  mettre et maintenir un bon niveau d’agilité sur le projet.

Activités :
• 1 réunion par sprint, pour passer en revue le « ScrumMaster
  assistant » (évalue le niveau d’agilité de l’équipe).
• Prise de contact régulière avec le ScrumMaster
• Participation aux cérémonies tous les 2 à 5 sprints
• Présence plus forte les 3 premiers mois (mise en place), le
  temps pour l’équipe d’acquérir les bons réflexes.
Humilité

Coach agile et ScrumMaster

• Ne sont pas des « gourous »
  Ils ne donnent pas de leçon
• Ils ne sont pas des « supérieurs hiérarchiques »
• Ils sont des « panneaux indicateurs », des « reminders » qui
  rappellent les règles d’un arbitre neutre : l’agilité.

• Humilité : ce n’est pas eux qui ont créé l’agilité, ils ne font
  que la propager.
• Ils n’imposent pas : il faut convaincre, et répéter beaucoup
Le SCRUMMASTER DOIT ETRE D’ABORD SCRUMMASTER
Zoom sur les développeurs

- un expert par technologie fondatrice de l’appli
- non spécialisés sur une seule partie, plutôt pluridisciplinaires
- n’hésitent pas à travailler en binômes pour :
    o répartir les compétences techniques et fonctionnelles de manière
      homogène
    o renforcer la qualité, le respect des normes, l’écriture des tests
    o partager toutes les décisions de conception (« stop the line »)
- ont le droit de demander et recevoir de l’aide
- n’inventent plus les specs, mais vont voir le PO à la moindre
 question fonctionnelle
- l’équipe travaille à un rythme durable (sans pression constante forte)
Zoom sur le testeur (1/2)
Le testeur
- a pour fonction d’implémenter les tests fonctionnels (« How to verify ») fournis par
 le PO pour chaque User story
- possède des compétences de développeur
- l’implémentation des TF se fait pendant l’itération, ce qui oblige les développeurs à
 une conception préalable :-)
- automatise ces tests, qui sont exécutés chaque nuit
- alerte les développeurs de chaque régression fonctionnelle pour correction
 immédiate, ce qui permet de contrôler la non-régression

Compétences très spécifiques
- les tests fonctionnels doivent le plus possible
    -   tester les règles métier (oblige à faire une conception orientée métier)
    -   être décorrelés de l’IHM, grâce à
          - des tests d’intégration (directement dans le langage de l’appli)
          - des « spécifications exécutables » (Fitnesse).
- Les tests IHM seront automatisés via Selenium ou QuickTestPro
Zoom sur le testeur (2/2)
Les tests peuvent soit :
- être gérés dans un backlog spécifique
- faire l’objet d’un statut dans le cycle de vie d’une story

Dans les 2 cas, on peut utiliser le kanban pour fluidifier le travail
ou identifier les goulots d’étranglement

Le testeur participe aux cérémonies de l’équipe, comme membre
à part entière.


Penser à garder les petites stories de test pour la fin du sprint,
pour avoir une chance de tout livrer à la fin du sprint.

                                                                        retour
Le déroulement
   du projet
Une autre façon d’aborder le projet

Habituellement, on définit le scope fonctionnel, puis on cherche à déterminer
la charge, la date de livraison et le budget.

Orange Agile propose une approche différente :
Stratégie changeante + priorités métier changeantes + réorgs
= socle fonctionnel stable sur 8 mois, pas plus

Conséquence :
- une release normale durera environ 8 mois
 une release rapide durera 3 à 4 mois
- une équipe doit faire 7 personnes (5 à 9) (préconisation agile)
Donc on a le budget et la date de livraison !!!

La mission : réaliser la valeur métier la plus pertinente avec !
TTM – Les jalons d’un projet agile

        Etude
                         Conception                            Développement                           Déploiement       Généralisation
       opportunité
     d’opportunité



     T-1              T0            T1                                                            T2               T3              T4



  Pré
  Pré-    Etude      Exploration          Développement itératif &
                                                             ité                 Validation        Stabilisation     Clôture du T3a
         opportunité
 étude d’opportunité                     qualification dans les sprints            de la                               Projet
                              S1                                                  release
                                         S3       S4         S5       S6                           Revue            Revue de
                                                                                                 Technique         Stabilisation
                              S2

                                                   T1x       T1c


     Quelques         Toutes les               Pouvoir partir en production pendant les
     pratiques        pratiques                développements, sur demande du métier
                                                                                 mé
       agiles           agiles
                                                             Prononcé
                                                             Prononcé pour la       T1x : qualification utilisateurs
         supprimé
T1a, T1b supprimés                                           premiè
                                                             première mise en                         d’exploitabilité
                                                                                    T1c : conditions d’exploitabilité OK
                                                                production                    prononcé
                                                                                          GO prononcé
 non utilisé dans un projet agile
 inclus dans le déroulement de chaque sprint             La 1ère MEP « ouvre la voie ». On pourra refaire d’autres MEP facilement.
                                                                                                          d’
Charte du projet - la trade-off matrix


• En une page, la charte pose les     •   But et contexte du projet, en 30 secondes
 fondements du projet, partagés       •   Utilisateurs / Clients destinataires
 par tous                             •   Avantages / bénéfices métier escomptés

 Elle est entérinée à l’unanimité     •   Fonctionnalités principales
 par vote à main levée                •   Dates principales connues (contraintes)
 (Trade-off incluse).                 •   Contraintes identifiées (charge, perf, etc)
                                      •   Risques majeurs identifiés
                                      •   Comment mesurer que l’objectif a été atteint ?
• La « trade-off matrix » ou
 « matrice des compromis »                           Fixe       Ferme      Pourrait      Changera
                                                                           changer      sûrement !
 identifie LA contrainte du projet.   Scope
                                      fonctionnel
 L’utopie du « tout-figé » au         Planning
 démarrage (date de livraison +       Coûts /
 budget + contenu fonctionnel)        Ressources
 est révolue !                        Qualité
Le déroulement du projet agile

Initialisation
   o Workshop physique, à la fin de l’étude
     Les acteurs du projet doivent se rencontrer, créer la relation humaine
   o Démarrage du projet, avec
        • la charte du projet
        • la PS (proposition de solution, 2 à 3 pages; très synthétique;
          valide la faisabilité de la demande fonctionnelle)
Exploration (le mûrissement en mode classique)
   o préparation proprement dite, gérée comme un projet Scrum
   o 2 sprints de calibrage, pour :
        • Rôder le fonctionnement dans un mode opérationnel
        • Déterminer une estimation de la vélocité
Production (post T1)
   o sprints de développement normaux
   o dernier(s) : finalisation / accompagnement & qualification
   o en option : garder un sprint à blanc (pas une provision)
Le « processus Scrum » - L’exploration

Phase de Préparation & Exploration


Préparer l’organisation du projet
    ● rédiger le PMP.
    ● se synchroniser avec les acteurs externes
    ● inclure les utilisateurs (un panel, un forum de feedback …)

    ● sélectionner les pratiques agiles qui seront utilisées
    ● fixer les règles de codage
    ● déterminer les DoD
    ● définir les modes de communication
    ● définir la durée d’un sprint                           Agilité
                                                             Technique
    ● former les acteurs du projet et                        Fonctionnel
       sensibiliser leur hiérarchie
Démarrer un projet par une formation


• Un projet démarre ?
  => 2 jours de formations pour tout le monde
     afin que chacun partent sur de bonnes bases
     afin que chacun partent sur les mêmes bases

  => 2 jours de formations complémentaires
     dédiées au Product Owner



                                             retour
Catégories de projet
  et labellisation
Les catégories de projets agiles

Les contextes de certains projets ne permettent pas toujours d’appliquer
tout ce que l’agilité propose.

Afin de cadrer et d’aider au mieux tous les projets désirant utiliser autant
que possible l’agilité, il existe désormais des catégories de projets
permettant officiellement d’utiliser l’agilité à la mesure de ce qui est
possible

                routière                     sportive
                               Formule 1
Les catégories de projets agiles

3 catégories de projets agiles permettent d’utiliser une
proposition agile cohérente et adaptée quel que soit le
contexte

• routière : contexte peu favorable. projet non agile, mais qui
  choisit néanmoins d’utiliser les valeurs agiles, les itérations
  courtes et les rôles agiles.

• sportive : projet à volonté affirmée, mais à maturité agile
  faible. certaines pratiques sont optionnelles.

• formule 1 : utilise correctement toutes les pratiques agiles.
Pourquoi un label ?

Lorsque l’agilité est bien appliquée,
• les qualités technique et fonctionnelle sont grandes
• le métier et les utilisateurs finaux fournissent un feedback régulier et les
   itérations courtes permettent de garantir la pertinence fonctionnelle de
   l’application
• les tests automatisés certifient le bon fonctionnement du début à la fin
UN PROJET VRAIMENT AGILE NE PEUT PAS ECHOUER.


• Les coaches du Centre d’Expertise Agile accordent ou non le label à
   chaque fin d’itération.
• Il s’agit de s’assurer que les gens ne font pas « n’importe quoi » sur le dos
   de l’agilité.
• On donne des objectifs atteignables aux projets
• on crée un réflexe managérial : « Agile ? as-tu un label ? »
à propos du « Agile cow-boy »


le « agile cowboy »
(qui prend l’agilité comme
prétexte pour faire n’importe quoi)
conduit à des catastrophes
pires qu’un cycle en V figé



Si on n’a pas les prérequis
pour commencer, il ne faut pas commencer !
                                                   retour
la qualité
« Orange Agile »
DoD … les Definition of Done

exemples

Tâche unitaire      User story             Sprint
• Compilation       • Conception mise à    • Démo faite sur les
• Refactoring         jour                   User stories
                    • Tests fonctionnels     « vraiment
• Tests unitaires                            terminées »
  en local          • Guide util/Admin
                                           • Doc de specs
• Intégration       • Intégration            fonctionnelles mis à
• Tests sur         • Impact                 jour
  intégration OK      exploitabilité
                                           •…
                    • Validation PO
                    • Affichage < 3 sec.
Une qualification au fil de l’eau

Pour pouvoir certifier le bon fonctionnement de
l’application en permanence, il devient
indispensable d’automatiser les tests techniques et
fonctionnels et de les passer tous les jours




          15 tests            40 tests         80 tests
Les KPI agiles
Un certain nombre de KPI issus du mode classique ne sont plus pertinents
pour mesurer la performance d’un projet.


Pour les projets VRAIMENT agiles (au moins « Sportives »), les KPI agiles sont :
● Vélocité : mesure et stabilité de la capacité de production de l’équipe
● Tests fonctionnels : les « how to verify » sont automatisés et OK
● Objectifs métier : la contrainte « Fixe » de la TradeOff matrix annoncée au T0,
 confirmée au T1, est respectée. Les objectifs mesurables de la charte sont atteints
● Qualité technique : les normes sont respectées, les tests techniques sont tous
 OK, la couverture de tests technique est >= 80%, aucun bug issu du travail de
 l’équipe
● Note d’agilité de 3,5 sur 5 (moyenne pertinente du « ScrumMaster assistant »)
  et au moins 3 sur les critères obligatoires de la catégorie du projet
● Satisfaction métier + utilisateurs finaux : minimum 3 (intervalle 0 à 5)
  Les exceptions (test non automatisable par exemple) sont tolérées si
            elles sont validées par l’équipe, le coach et le Pole Agile
Documentation : l’utile, mais pas plus


En tant que vecteur fort de la communication entre les services et équipes
qui se succèdent sur un projet, la doc est indispensable
PMP (Plan de Management de Projet)
Toutes les stratégies, l’organisation du projet et ses spécificités sont dans le
PMP, y compris les contraintes d’exploitabilité
Les documents d’architecture
DAT, DAF, DAL : architectures technique, fonctionnelle, logicielle
Spécifications fonctionnelles
Il reste indispensable d’avoir ce document à jour.
Proposition : le PO le met à jour à chaque fin de sprint.

L’exploitabilité (pour que l’application survive à son équipe de dev)
Guides d’install, utilisateurs, administrateurs technique et fonctionnel, les
descriptions (alimentées au fil des développements) des sauvegardes,
supervision, ordonnancement, gestion des erreurs                     retour
Outils pour
 l’agilité
Un système qualité adapté,
                                                  appuyé par l’outil

Tous les principes qualité sont conservés.
Seule leur mise en œuvre a été adaptée au contexte agile

La réelle simplification vient de l’outil :
• pour gérer le projet (exigences, scope fonctionnel, risques, actions, etc)
• pour gérer le backlog produit
• pour gérer l’historisation et la traçabilité de manière automatique
• pour gérer le quotidien de l’équipe (backlog de sprint, stories, taches)
• pour générer automatiquement le reporting utile
• pour stocker tout élément documentaire (wiki)
• pour gérer les tests et leur liens aux stories et aux exigences
• pour centraliser les informations en un seul endroit
• pour faciliter le partage entre des sites distants

• Avec le serveur d’intégration, on suit les couvertures de test, respect des
  normes, indice de complexité du code, détection de duplication, etc
Les outils : Backlog
Les outils : Storyboard
Les outils : Reporting
Les outils – Gestion documentaire
Les outils - Hudson

Hudson est un portail centralisant les informations techniques.
C’est en général le « chapeau » de l’intégration continue.

On y trouve notamment :
- Le résultat du dernier build
- Les résultats des tests techniques
- La couverture de tests
- Des propositions de refactoring
- Le résultat du contrôle de respect des normes, etc …


                                                                  retour
Faire un backlog produit
backlog produit :
                            des specs progressives

Pour le démarrage du projet, on demande 2
niveaux de précision : les Thèmes et les Epics
Cela donne les grandes lignes de l’investissement
(SOX).
backlog produit :
                                          des specs progressives

Pendant l’exploration, le PO va détailler un seul niveau
supplémentaire : les user stories



                                                      Thèmes, epics et
                                                      user stories auront
                                                      une priorité métier
                                                      et une note de
                                                      complexité
                                                      technique (en
                                                      points)




                                                                retour
A propos des
« cérémonies »
A propos des « cérémonies »

Les réunions qui ponctuent les sprints sont en
général appelées « cérémonies »

Drôle de nom ! (pour certains)

La raison : elles suivent toutes un « cérémonial »,
et ont une structure bien définie.

Toutes les cérémonies sont timeboxées.

Le PO participe à toutes, même au standup !
A propos du stand-up

On met à jour le « reste à faire » de chaque tâche en cours
L’estimation et les ré-estimations : heures ou ½ jour
1h, 2h, 3h, 4h, puis 1 jour, 1,5 jours, 2 jours (pas plus !)

Autre possibilité :
Utiliser l’avancement de la story en %

Rappel : un Stand-up N'EST PAS
• n’est pas un tribunal
• n’est pas un moment pour les reproches et remontrances
• n’est pas un lieu pour les conversations ou les débats
• n’est pas un moment de reporting
A propos de la rétrospective

• Moment de grande subjectivité :
   o chacun exprime son ressenti
   o chaque avis compte et doit être respecté
• On peut utiliser un lieu inhabituel au projet (dehors ?)

• Les actions d’amélioration : attention à leur nombre.
  Il est essentiel que toutes les actions priorisées et
  retenues soient vraiment réalisées à la fin du sprint
  => Le ScrumMaster y veille !

                                                      retour
Bonne route !


    merci

Contenu connexe

Tendances

Creating Agile Product Roadmaps Everyone Understands
Creating Agile Product Roadmaps Everyone UnderstandsCreating Agile Product Roadmaps Everyone Understands
Creating Agile Product Roadmaps Everyone Understandsuxpin
 
Certified Scrum Product Owner: class desk, posters and photos
Certified Scrum Product Owner: class desk, posters and photosCertified Scrum Product Owner: class desk, posters and photos
Certified Scrum Product Owner: class desk, posters and photosAlexey Krivitsky
 
Product Discovery At Google
Product Discovery At GoogleProduct Discovery At Google
Product Discovery At GoogleJohn Gibbon
 
SFA2018 Project to Product - Carmen DeArdo
SFA2018 Project to Product - Carmen DeArdoSFA2018 Project to Product - Carmen DeArdo
SFA2018 Project to Product - Carmen DeArdoCarmen DeArdo
 
Agile Transformation
Agile TransformationAgile Transformation
Agile TransformationMax Carlin
 
Agile Software Development Overview
Agile Software Development OverviewAgile Software Development Overview
Agile Software Development OverviewStewart Rogers
 
The Disturbing Reality of Today's PMO
The Disturbing Reality of Today's PMOThe Disturbing Reality of Today's PMO
The Disturbing Reality of Today's PMOIan Needs
 
OKRs, KPIs, and hypothesis driven product development
OKRs, KPIs, and hypothesis driven product developmentOKRs, KPIs, and hypothesis driven product development
OKRs, KPIs, and hypothesis driven product developmentLauren Young
 
Product roadmap-guide-by-product plan
Product roadmap-guide-by-product planProduct roadmap-guide-by-product plan
Product roadmap-guide-by-product planLewis Lin 🦊
 
Strategies for Large Scale Agile Transformation
Strategies for Large Scale Agile TransformationStrategies for Large Scale Agile Transformation
Strategies for Large Scale Agile TransformationNishanth K Hydru
 
Agile Maturity Assessments
Agile Maturity AssessmentsAgile Maturity Assessments
Agile Maturity AssessmentsDavid Hanson
 
Roadmap Infographics by Slidesgo.pptx
Roadmap Infographics by Slidesgo.pptxRoadmap Infographics by Slidesgo.pptx
Roadmap Infographics by Slidesgo.pptxssuserc31980
 
Product is Hard - Marty Cagan
Product is Hard - Marty CaganProduct is Hard - Marty Cagan
Product is Hard - Marty CaganAnthony Marter
 

Tendances (20)

Creating Agile Product Roadmaps Everyone Understands
Creating Agile Product Roadmaps Everyone UnderstandsCreating Agile Product Roadmaps Everyone Understands
Creating Agile Product Roadmaps Everyone Understands
 
Certified Scrum Product Owner: class desk, posters and photos
Certified Scrum Product Owner: class desk, posters and photosCertified Scrum Product Owner: class desk, posters and photos
Certified Scrum Product Owner: class desk, posters and photos
 
Product Discovery At Google
Product Discovery At GoogleProduct Discovery At Google
Product Discovery At Google
 
SFA2018 Project to Product - Carmen DeArdo
SFA2018 Project to Product - Carmen DeArdoSFA2018 Project to Product - Carmen DeArdo
SFA2018 Project to Product - Carmen DeArdo
 
Agile Transformation
Agile TransformationAgile Transformation
Agile Transformation
 
Untangling the Lean MVP
Untangling the Lean MVPUntangling the Lean MVP
Untangling the Lean MVP
 
Agile Software Development Overview
Agile Software Development OverviewAgile Software Development Overview
Agile Software Development Overview
 
The Disturbing Reality of Today's PMO
The Disturbing Reality of Today's PMOThe Disturbing Reality of Today's PMO
The Disturbing Reality of Today's PMO
 
Atelier Story Map
Atelier Story MapAtelier Story Map
Atelier Story Map
 
OKRs, KPIs, and hypothesis driven product development
OKRs, KPIs, and hypothesis driven product developmentOKRs, KPIs, and hypothesis driven product development
OKRs, KPIs, and hypothesis driven product development
 
Product roadmap-guide-by-product plan
Product roadmap-guide-by-product planProduct roadmap-guide-by-product plan
Product roadmap-guide-by-product plan
 
Strategies for Large Scale Agile Transformation
Strategies for Large Scale Agile TransformationStrategies for Large Scale Agile Transformation
Strategies for Large Scale Agile Transformation
 
Agile Maturity Assessments
Agile Maturity AssessmentsAgile Maturity Assessments
Agile Maturity Assessments
 
Roadmap Infographics by Slidesgo.pptx
Roadmap Infographics by Slidesgo.pptxRoadmap Infographics by Slidesgo.pptx
Roadmap Infographics by Slidesgo.pptx
 
Agile coach - roadmap and user story map
Agile coach - roadmap and user story map Agile coach - roadmap and user story map
Agile coach - roadmap and user story map
 
Professional Scrum Product Owner I (PSPO-I)
Professional Scrum Product Owner I (PSPO-I)Professional Scrum Product Owner I (PSPO-I)
Professional Scrum Product Owner I (PSPO-I)
 
Agile Requirements
Agile RequirementsAgile Requirements
Agile Requirements
 
Product is Hard - Marty Cagan
Product is Hard - Marty CaganProduct is Hard - Marty Cagan
Product is Hard - Marty Cagan
 
Product Roadmap
Product RoadmapProduct Roadmap
Product Roadmap
 
Introduction to Scrum@Scale
Introduction to Scrum@ScaleIntroduction to Scrum@Scale
Introduction to Scrum@Scale
 

En vedette

Appswiss.Net
Appswiss.NetAppswiss.Net
Appswiss.NetAppswiss
 
Buenos dias senor!
Buenos dias senor!Buenos dias senor!
Buenos dias senor!LUZ M.
 
Standard fci bruno du jura type saint hubert
Standard fci bruno du jura type saint hubertStandard fci bruno du jura type saint hubert
Standard fci bruno du jura type saint hubertelyaneforet
 
Case study module6 fr
Case study module6 frCase study module6 fr
Case study module6 frsparoad
 
YADOR CENTRO DE BELLEZA Y ESTETICA
YADOR CENTRO DE BELLEZA Y ESTETICAYADOR CENTRO DE BELLEZA Y ESTETICA
YADOR CENTRO DE BELLEZA Y ESTETICAASPM
 
Esclavos de las medallas...
Esclavos de las medallas...Esclavos de las medallas...
Esclavos de las medallas...LUZ M.
 
Standard fci braque allemand poil court
Standard fci braque allemand poil courtStandard fci braque allemand poil court
Standard fci braque allemand poil courtelyaneforet
 
World wide web andrea perez
World wide web andrea perezWorld wide web andrea perez
World wide web andrea perezAndreita Perez
 
Webassadors Mixology #29 - L'actu' Web de la semaine du 06.02.2015
Webassadors Mixology #29 - L'actu' Web de la semaine du 06.02.2015Webassadors Mixology #29 - L'actu' Web de la semaine du 06.02.2015
Webassadors Mixology #29 - L'actu' Web de la semaine du 06.02.2015Webassadors
 
Diferencias entre las agendas digitales peruanas
Diferencias entre las agendas digitales peruanas Diferencias entre las agendas digitales peruanas
Diferencias entre las agendas digitales peruanas jadfr
 
Trabajo de aleja y helena
Trabajo de aleja y helenaTrabajo de aleja y helena
Trabajo de aleja y helenahelenalvarado
 
Voyage en chine_1e_partie
Voyage en chine_1e_partieVoyage en chine_1e_partie
Voyage en chine_1e_partieInfosCollège
 
Le livre d'or
Le livre d'orLe livre d'or
Le livre d'orEPSILIM
 

En vedette (20)

Appswiss.Net
Appswiss.NetAppswiss.Net
Appswiss.Net
 
Is
IsIs
Is
 
Buenos dias senor!
Buenos dias senor!Buenos dias senor!
Buenos dias senor!
 
Standard fci bruno du jura type saint hubert
Standard fci bruno du jura type saint hubertStandard fci bruno du jura type saint hubert
Standard fci bruno du jura type saint hubert
 
Las tic’s
Las tic’sLas tic’s
Las tic’s
 
Case study module6 fr
Case study module6 frCase study module6 fr
Case study module6 fr
 
YADOR CENTRO DE BELLEZA Y ESTETICA
YADOR CENTRO DE BELLEZA Y ESTETICAYADOR CENTRO DE BELLEZA Y ESTETICA
YADOR CENTRO DE BELLEZA Y ESTETICA
 
Esclavos de las medallas...
Esclavos de las medallas...Esclavos de las medallas...
Esclavos de las medallas...
 
Standard fci braque allemand poil court
Standard fci braque allemand poil courtStandard fci braque allemand poil court
Standard fci braque allemand poil court
 
Les tumeurs
Les tumeursLes tumeurs
Les tumeurs
 
World wide web andrea perez
World wide web andrea perezWorld wide web andrea perez
World wide web andrea perez
 
Webassadors Mixology #29 - L'actu' Web de la semaine du 06.02.2015
Webassadors Mixology #29 - L'actu' Web de la semaine du 06.02.2015Webassadors Mixology #29 - L'actu' Web de la semaine du 06.02.2015
Webassadors Mixology #29 - L'actu' Web de la semaine du 06.02.2015
 
Diferencias entre las agendas digitales peruanas
Diferencias entre las agendas digitales peruanas Diferencias entre las agendas digitales peruanas
Diferencias entre las agendas digitales peruanas
 
Trabajo de aleja y helena
Trabajo de aleja y helenaTrabajo de aleja y helena
Trabajo de aleja y helena
 
PresentacióN1
PresentacióN1PresentacióN1
PresentacióN1
 
Voyage en chine_1e_partie
Voyage en chine_1e_partieVoyage en chine_1e_partie
Voyage en chine_1e_partie
 
Akouenaomi
AkouenaomiAkouenaomi
Akouenaomi
 
France
FranceFrance
France
 
Le livre d'or
Le livre d'orLe livre d'or
Le livre d'or
 
Moxie trends 2013
Moxie trends 2013Moxie trends 2013
Moxie trends 2013
 

Similaire à Agile Tour Nantes 2011 - Rémy génin - retours d'expérience sur 4 ans d'agilité chez orange

Introduction à l'agilité iut lyon 1 sept2013
Introduction à l'agilité   iut lyon 1 sept2013Introduction à l'agilité   iut lyon 1 sept2013
Introduction à l'agilité iut lyon 1 sept2013agnes_crepet
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_finalagnes_crepet
 
Presentation sa fe 2 zoom sur pi planning safe v1.0
Presentation sa fe 2 zoom sur pi planning safe v1.0Presentation sa fe 2 zoom sur pi planning safe v1.0
Presentation sa fe 2 zoom sur pi planning safe v1.0Pierre Medina
 
Introduction à l'agilité ensmse
Introduction à l'agilité   ensmseIntroduction à l'agilité   ensmse
Introduction à l'agilité ensmseagnes_crepet
 
L'agilité en quelques slides
L'agilité en quelques slidesL'agilité en quelques slides
L'agilité en quelques slidesNicolas Deverge
 
Retour Experience Atchik Sigma T9 200903[1]
Retour Experience Atchik Sigma T9 200903[1]Retour Experience Atchik Sigma T9 200903[1]
Retour Experience Atchik Sigma T9 200903[1]almerys
 
2016-04-13 Anne Claire Jacob Poulin Gestion par projet dans un centre de R&D
2016-04-13 Anne Claire Jacob Poulin Gestion par projet dans un centre de R&D2016-04-13 Anne Claire Jacob Poulin Gestion par projet dans un centre de R&D
2016-04-13 Anne Claire Jacob Poulin Gestion par projet dans un centre de R&DPMI Lévis-Québec
 
SCRUM et KANBAN - Agile Grenoble 2011
SCRUM et KANBAN - Agile Grenoble 2011SCRUM et KANBAN - Agile Grenoble 2011
SCRUM et KANBAN - Agile Grenoble 2011Christophe NEY
 
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011agnes_crepet
 
Iut lyon 1 introduction à l'agilité - 20 juin 2012
Iut lyon 1   introduction à l'agilité - 20 juin 2012Iut lyon 1   introduction à l'agilité - 20 juin 2012
Iut lyon 1 introduction à l'agilité - 20 juin 2012agnes_crepet
 
Methodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XPMethodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XPNicolas Perriault
 
Formation scrum - back to basics
Formation scrum -  back to basicsFormation scrum -  back to basics
Formation scrum - back to basicsOpenska
 

Similaire à Agile Tour Nantes 2011 - Rémy génin - retours d'expérience sur 4 ans d'agilité chez orange (20)

Introduction à l'agilité iut lyon 1 sept2013
Introduction à l'agilité   iut lyon 1 sept2013Introduction à l'agilité   iut lyon 1 sept2013
Introduction à l'agilité iut lyon 1 sept2013
 
#7 méthodes
#7 méthodes#7 méthodes
#7 méthodes
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
 
Presentation sa fe 2 zoom sur pi planning safe v1.0
Presentation sa fe 2 zoom sur pi planning safe v1.0Presentation sa fe 2 zoom sur pi planning safe v1.0
Presentation sa fe 2 zoom sur pi planning safe v1.0
 
Introduction à l'agilité ensmse
Introduction à l'agilité   ensmseIntroduction à l'agilité   ensmse
Introduction à l'agilité ensmse
 
L'agilité en quelques slides
L'agilité en quelques slidesL'agilité en quelques slides
L'agilité en quelques slides
 
Methodologies agiles
Methodologies agilesMethodologies agiles
Methodologies agiles
 
Retour Experience Atchik Sigma T9 200903[1]
Retour Experience Atchik Sigma T9 200903[1]Retour Experience Atchik Sigma T9 200903[1]
Retour Experience Atchik Sigma T9 200903[1]
 
2016-04-13 Anne Claire Jacob Poulin Gestion par projet dans un centre de R&D
2016-04-13 Anne Claire Jacob Poulin Gestion par projet dans un centre de R&D2016-04-13 Anne Claire Jacob Poulin Gestion par projet dans un centre de R&D
2016-04-13 Anne Claire Jacob Poulin Gestion par projet dans un centre de R&D
 
Plm lab btb12
Plm lab btb12Plm lab btb12
Plm lab btb12
 
SCRUM et KANBAN - Agile Grenoble 2011
SCRUM et KANBAN - Agile Grenoble 2011SCRUM et KANBAN - Agile Grenoble 2011
SCRUM et KANBAN - Agile Grenoble 2011
 
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
 
20mn scrum
20mn scrum20mn scrum
20mn scrum
 
Iut lyon 1 introduction à l'agilité - 20 juin 2012
Iut lyon 1   introduction à l'agilité - 20 juin 2012Iut lyon 1   introduction à l'agilité - 20 juin 2012
Iut lyon 1 introduction à l'agilité - 20 juin 2012
 
Méthodes agiles & Scrum
Méthodes agiles & ScrumMéthodes agiles & Scrum
Méthodes agiles & Scrum
 
Methodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XPMethodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XP
 
Introduction à Scrum
Introduction à ScrumIntroduction à Scrum
Introduction à Scrum
 
Formation scrum - back to basics
Formation scrum -  back to basicsFormation scrum -  back to basics
Formation scrum - back to basics
 
Agile Tour Lille 2008
Agile Tour Lille 2008Agile Tour Lille 2008
Agile Tour Lille 2008
 
Les pratiques Scrum
Les pratiques ScrumLes pratiques Scrum
Les pratiques Scrum
 

Plus de Association Agile Nantes

Agile Tour Nantes 2014 - Comment impliquer vos clients dans leurs projets ?
Agile Tour Nantes 2014 - Comment impliquer vos clients dans leurs projets ?Agile Tour Nantes 2014 - Comment impliquer vos clients dans leurs projets ?
Agile Tour Nantes 2014 - Comment impliquer vos clients dans leurs projets ?Association Agile Nantes
 
Le projet Aristote / Steeve Evers & Marc Dugué
Le projet Aristote / Steeve Evers & Marc DuguéLe projet Aristote / Steeve Evers & Marc Dugué
Le projet Aristote / Steeve Evers & Marc DuguéAssociation Agile Nantes
 
Initiation à l'agilité - Agile Tour 2017
Initiation à l'agilité - Agile Tour 2017Initiation à l'agilité - Agile Tour 2017
Initiation à l'agilité - Agile Tour 2017Association Agile Nantes
 
Agile Tour Nantes 2014 - 10 ans d'agile, c'est chouette ! La rétro des points...
Agile Tour Nantes 2014 - 10 ans d'agile, c'est chouette ! La rétro des points...Agile Tour Nantes 2014 - 10 ans d'agile, c'est chouette ! La rétro des points...
Agile Tour Nantes 2014 - 10 ans d'agile, c'est chouette ! La rétro des points...Association Agile Nantes
 
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAgile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAssociation Agile Nantes
 
Et si on maîtrisait vraiment notre produit
Et si on maîtrisait vraiment notre produitEt si on maîtrisait vraiment notre produit
Et si on maîtrisait vraiment notre produitAssociation Agile Nantes
 
Agile Tour Nantes 2013 - L'EPOPEE DU CHEVALIER AGILE FILS DU ROI PRAGMATIQUE ...
Agile Tour Nantes 2013 - L'EPOPEE DU CHEVALIER AGILE FILS DU ROI PRAGMATIQUE ...Agile Tour Nantes 2013 - L'EPOPEE DU CHEVALIER AGILE FILS DU ROI PRAGMATIQUE ...
Agile Tour Nantes 2013 - L'EPOPEE DU CHEVALIER AGILE FILS DU ROI PRAGMATIQUE ...Association Agile Nantes
 
Agile Tour Nantes 2013 - Urbanisation des services : Pour changer le monde du...
Agile Tour Nantes 2013 - Urbanisation des services : Pour changer le monde du...Agile Tour Nantes 2013 - Urbanisation des services : Pour changer le monde du...
Agile Tour Nantes 2013 - Urbanisation des services : Pour changer le monde du...Association Agile Nantes
 
Agile Tour Nantes 2013 - Scrum ou kanban - Alexandre BOUTIN
Agile Tour Nantes 2013 - Scrum ou kanban - Alexandre BOUTINAgile Tour Nantes 2013 - Scrum ou kanban - Alexandre BOUTIN
Agile Tour Nantes 2013 - Scrum ou kanban - Alexandre BOUTINAssociation Agile Nantes
 
Agile Tour Nantes 2013 - Introduction aux méthodes agiles - Grégoire ROBIN - ...
Agile Tour Nantes 2013 - Introduction aux méthodes agiles - Grégoire ROBIN - ...Agile Tour Nantes 2013 - Introduction aux méthodes agiles - Grégoire ROBIN - ...
Agile Tour Nantes 2013 - Introduction aux méthodes agiles - Grégoire ROBIN - ...Association Agile Nantes
 
Agt nantes 2013 aurélien morvant - agiletour.comment.etre.agile.et.le.rester
Agt nantes 2013   aurélien morvant - agiletour.comment.etre.agile.et.le.resterAgt nantes 2013   aurélien morvant - agiletour.comment.etre.agile.et.le.rester
Agt nantes 2013 aurélien morvant - agiletour.comment.etre.agile.et.le.resterAssociation Agile Nantes
 
Agt nantes 2013 rémy génin - l'agilité peut changer le monde
Agt nantes 2013   rémy génin - l'agilité peut changer le mondeAgt nantes 2013   rémy génin - l'agilité peut changer le monde
Agt nantes 2013 rémy génin - l'agilité peut changer le mondeAssociation Agile Nantes
 
Patrons de conception de la programmation fonctionnelle
Patrons de conception de la programmation fonctionnellePatrons de conception de la programmation fonctionnelle
Patrons de conception de la programmation fonctionnelleAssociation Agile Nantes
 

Plus de Association Agile Nantes (20)

PI Planning-Vos échanges!.pdf
PI Planning-Vos échanges!.pdfPI Planning-Vos échanges!.pdf
PI Planning-Vos échanges!.pdf
 
Agile Tour Nantes 2014 - Comment impliquer vos clients dans leurs projets ?
Agile Tour Nantes 2014 - Comment impliquer vos clients dans leurs projets ?Agile Tour Nantes 2014 - Comment impliquer vos clients dans leurs projets ?
Agile Tour Nantes 2014 - Comment impliquer vos clients dans leurs projets ?
 
Le projet Aristote / Steeve Evers & Marc Dugué
Le projet Aristote / Steeve Evers & Marc DuguéLe projet Aristote / Steeve Evers & Marc Dugué
Le projet Aristote / Steeve Evers & Marc Dugué
 
Tous en scène - Arnaud Garnier
Tous en scène - Arnaud GarnierTous en scène - Arnaud Garnier
Tous en scène - Arnaud Garnier
 
Initiation à l'agilité - Agile Tour 2017
Initiation à l'agilité - Agile Tour 2017Initiation à l'agilité - Agile Tour 2017
Initiation à l'agilité - Agile Tour 2017
 
Agile nantes leanstartup_20160323
Agile nantes leanstartup_20160323Agile nantes leanstartup_20160323
Agile nantes leanstartup_20160323
 
Agile Tour Nantes 2014 - 10 ans d'agile, c'est chouette ! La rétro des points...
Agile Tour Nantes 2014 - 10 ans d'agile, c'est chouette ! La rétro des points...Agile Tour Nantes 2014 - 10 ans d'agile, c'est chouette ! La rétro des points...
Agile Tour Nantes 2014 - 10 ans d'agile, c'est chouette ! La rétro des points...
 
Agile Tour Nantes 2014 - Sois autonome !
Agile Tour Nantes 2014 - Sois autonome !Agile Tour Nantes 2014 - Sois autonome !
Agile Tour Nantes 2014 - Sois autonome !
 
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAgile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
 
Et si on maîtrisait vraiment notre produit
Et si on maîtrisait vraiment notre produitEt si on maîtrisait vraiment notre produit
Et si on maîtrisait vraiment notre produit
 
Agile Tour Nantes 2013 - L'EPOPEE DU CHEVALIER AGILE FILS DU ROI PRAGMATIQUE ...
Agile Tour Nantes 2013 - L'EPOPEE DU CHEVALIER AGILE FILS DU ROI PRAGMATIQUE ...Agile Tour Nantes 2013 - L'EPOPEE DU CHEVALIER AGILE FILS DU ROI PRAGMATIQUE ...
Agile Tour Nantes 2013 - L'EPOPEE DU CHEVALIER AGILE FILS DU ROI PRAGMATIQUE ...
 
Agile Tour Nantes 2013 - Urbanisation des services : Pour changer le monde du...
Agile Tour Nantes 2013 - Urbanisation des services : Pour changer le monde du...Agile Tour Nantes 2013 - Urbanisation des services : Pour changer le monde du...
Agile Tour Nantes 2013 - Urbanisation des services : Pour changer le monde du...
 
Agile Tour Nantes 2013 - Scrum ou kanban - Alexandre BOUTIN
Agile Tour Nantes 2013 - Scrum ou kanban - Alexandre BOUTINAgile Tour Nantes 2013 - Scrum ou kanban - Alexandre BOUTIN
Agile Tour Nantes 2013 - Scrum ou kanban - Alexandre BOUTIN
 
Agile Tour Nantes 2013 - Introduction aux méthodes agiles - Grégoire ROBIN - ...
Agile Tour Nantes 2013 - Introduction aux méthodes agiles - Grégoire ROBIN - ...Agile Tour Nantes 2013 - Introduction aux méthodes agiles - Grégoire ROBIN - ...
Agile Tour Nantes 2013 - Introduction aux méthodes agiles - Grégoire ROBIN - ...
 
Agt nantes 2013 aurélien morvant - agiletour.comment.etre.agile.et.le.rester
Agt nantes 2013   aurélien morvant - agiletour.comment.etre.agile.et.le.resterAgt nantes 2013   aurélien morvant - agiletour.comment.etre.agile.et.le.rester
Agt nantes 2013 aurélien morvant - agiletour.comment.etre.agile.et.le.rester
 
Agt nantes 2013 rémy génin - l'agilité peut changer le monde
Agt nantes 2013   rémy génin - l'agilité peut changer le mondeAgt nantes 2013   rémy génin - l'agilité peut changer le monde
Agt nantes 2013 rémy génin - l'agilité peut changer le monde
 
Patrons de conception de la programmation fonctionnelle
Patrons de conception de la programmation fonctionnellePatrons de conception de la programmation fonctionnelle
Patrons de conception de la programmation fonctionnelle
 
Des mots, des maux ? Démo !
Des mots, des maux ? Démo !Des mots, des maux ? Démo !
Des mots, des maux ? Démo !
 
REX Scrum mature
REX Scrum matureREX Scrum mature
REX Scrum mature
 
L'agilité dans la mobilité
L'agilité dans la mobilitéL'agilité dans la mobilité
L'agilité dans la mobilité
 

Agile Tour Nantes 2011 - Rémy génin - retours d'expérience sur 4 ans d'agilité chez orange

  • 1. Retours sur 4 ans d’industrialisation de l’agilité Rémy Génin - Orange Octobre 2010
  • 3. Les pièges qu’on connait bien … • le scope fonctionnel va changer pendant le projet, donc o l’engagement sur un périmètre figé est une utopie o les specs trop détaillées avant de démarrer sont ineptes • la formulation en H/J crée un engagement implicite. préférez les points de complexité • une stratégie métier qui change en cours de route
  • 4. Les pièges liés à l’agilité • product owner pas assez disponible, pas assez compétent, non- légitimé • des moyens insuffisants pas de ScrumMaster, pas de testeur, pas d’automatisation • les règles de base non respectées « pas de rétrospective ! pas le temps » • adaptabilité ne veut pas dire « je fais ce que je veux ». la rigueur est incontournable retour
  • 5. Construire SA proposition agile
  • 6. La proposition « Orange Agile » • part de l’existant • précise les choses • inclut l’environnement Orange, qui o est complexe o contient un grand nombre de contraintes
  • 7. Diffuser l’information et accompagner : Un centre d’expertise Un centre d’expertise est là pour vous aider et vous accompagner dans tout ce qui touche l’agilité : - Présentations (multiples au besoin) - Formations - Trouver un ScrumMaster - Faire monter en compétence un ScrumMaster - Coacher le projet - Faire un audit ponctuel Un site intranet pour centraliser l’information et les documents partagés, des FAQ, des fiches pratiques, des explications détaillées Une communauté avec des forums par rôle agile Un « mode d’emploi » informatisé en préparation retour
  • 9. Les rôles agiles – La base « Product Owner » responsable du contenu fonctionnel « ScrumMaster » facilitateur en l’agilité une équipe de développeurs
  • 10. Rôles – les compléments utiles – le Coach agile => Aide le ScrumMaster à mettre/maintenir un bon niveau d’agilité – le CP => Pilote global aspects administratifs, production des documents demandés, gestion des interfaces, passage des jalons, reporting => s’occupe d’insérer l’application dans le SI (métrologie, intégration, exploitation) – le testeur => possède des compétences de développeur => a pour fonction d’implémenter et automatiser les tests fonctionnels – le manager => supérieur hiérarchique => décideur : tranche si l’équipe / le CP n’en ont pas le pouvoir
  • 11. Le coach agile Coach agile • aide ponctuellement et régulièrement le ScrumMaster à mettre et maintenir un bon niveau d’agilité sur le projet. Activités : • 1 réunion par sprint, pour passer en revue le « ScrumMaster assistant » (évalue le niveau d’agilité de l’équipe). • Prise de contact régulière avec le ScrumMaster • Participation aux cérémonies tous les 2 à 5 sprints • Présence plus forte les 3 premiers mois (mise en place), le temps pour l’équipe d’acquérir les bons réflexes.
  • 12. Humilité Coach agile et ScrumMaster • Ne sont pas des « gourous » Ils ne donnent pas de leçon • Ils ne sont pas des « supérieurs hiérarchiques » • Ils sont des « panneaux indicateurs », des « reminders » qui rappellent les règles d’un arbitre neutre : l’agilité. • Humilité : ce n’est pas eux qui ont créé l’agilité, ils ne font que la propager. • Ils n’imposent pas : il faut convaincre, et répéter beaucoup Le SCRUMMASTER DOIT ETRE D’ABORD SCRUMMASTER
  • 13. Zoom sur les développeurs - un expert par technologie fondatrice de l’appli - non spécialisés sur une seule partie, plutôt pluridisciplinaires - n’hésitent pas à travailler en binômes pour : o répartir les compétences techniques et fonctionnelles de manière homogène o renforcer la qualité, le respect des normes, l’écriture des tests o partager toutes les décisions de conception (« stop the line ») - ont le droit de demander et recevoir de l’aide - n’inventent plus les specs, mais vont voir le PO à la moindre question fonctionnelle - l’équipe travaille à un rythme durable (sans pression constante forte)
  • 14. Zoom sur le testeur (1/2) Le testeur - a pour fonction d’implémenter les tests fonctionnels (« How to verify ») fournis par le PO pour chaque User story - possède des compétences de développeur - l’implémentation des TF se fait pendant l’itération, ce qui oblige les développeurs à une conception préalable :-) - automatise ces tests, qui sont exécutés chaque nuit - alerte les développeurs de chaque régression fonctionnelle pour correction immédiate, ce qui permet de contrôler la non-régression Compétences très spécifiques - les tests fonctionnels doivent le plus possible - tester les règles métier (oblige à faire une conception orientée métier) - être décorrelés de l’IHM, grâce à - des tests d’intégration (directement dans le langage de l’appli) - des « spécifications exécutables » (Fitnesse). - Les tests IHM seront automatisés via Selenium ou QuickTestPro
  • 15. Zoom sur le testeur (2/2) Les tests peuvent soit : - être gérés dans un backlog spécifique - faire l’objet d’un statut dans le cycle de vie d’une story Dans les 2 cas, on peut utiliser le kanban pour fluidifier le travail ou identifier les goulots d’étranglement Le testeur participe aux cérémonies de l’équipe, comme membre à part entière. Penser à garder les petites stories de test pour la fin du sprint, pour avoir une chance de tout livrer à la fin du sprint. retour
  • 16. Le déroulement du projet
  • 17. Une autre façon d’aborder le projet Habituellement, on définit le scope fonctionnel, puis on cherche à déterminer la charge, la date de livraison et le budget. Orange Agile propose une approche différente : Stratégie changeante + priorités métier changeantes + réorgs = socle fonctionnel stable sur 8 mois, pas plus Conséquence : - une release normale durera environ 8 mois une release rapide durera 3 à 4 mois - une équipe doit faire 7 personnes (5 à 9) (préconisation agile) Donc on a le budget et la date de livraison !!! La mission : réaliser la valeur métier la plus pertinente avec !
  • 18. TTM – Les jalons d’un projet agile Etude Conception Développement Déploiement Généralisation opportunité d’opportunité T-1 T0 T1 T2 T3 T4 Pré Pré- Etude Exploration Développement itératif & ité Validation Stabilisation Clôture du T3a opportunité étude d’opportunité qualification dans les sprints de la Projet S1 release S3 S4 S5 S6 Revue Revue de Technique Stabilisation S2 T1x T1c Quelques Toutes les Pouvoir partir en production pendant les pratiques pratiques développements, sur demande du métier mé agiles agiles Prononcé Prononcé pour la T1x : qualification utilisateurs supprimé T1a, T1b supprimés premiè première mise en d’exploitabilité T1c : conditions d’exploitabilité OK production prononcé GO prononcé non utilisé dans un projet agile inclus dans le déroulement de chaque sprint La 1ère MEP « ouvre la voie ». On pourra refaire d’autres MEP facilement. d’
  • 19. Charte du projet - la trade-off matrix • En une page, la charte pose les • But et contexte du projet, en 30 secondes fondements du projet, partagés • Utilisateurs / Clients destinataires par tous • Avantages / bénéfices métier escomptés Elle est entérinée à l’unanimité • Fonctionnalités principales par vote à main levée • Dates principales connues (contraintes) (Trade-off incluse). • Contraintes identifiées (charge, perf, etc) • Risques majeurs identifiés • Comment mesurer que l’objectif a été atteint ? • La « trade-off matrix » ou « matrice des compromis » Fixe Ferme Pourrait Changera changer sûrement ! identifie LA contrainte du projet. Scope fonctionnel L’utopie du « tout-figé » au Planning démarrage (date de livraison + Coûts / budget + contenu fonctionnel) Ressources est révolue ! Qualité
  • 20. Le déroulement du projet agile Initialisation o Workshop physique, à la fin de l’étude Les acteurs du projet doivent se rencontrer, créer la relation humaine o Démarrage du projet, avec • la charte du projet • la PS (proposition de solution, 2 à 3 pages; très synthétique; valide la faisabilité de la demande fonctionnelle) Exploration (le mûrissement en mode classique) o préparation proprement dite, gérée comme un projet Scrum o 2 sprints de calibrage, pour : • Rôder le fonctionnement dans un mode opérationnel • Déterminer une estimation de la vélocité Production (post T1) o sprints de développement normaux o dernier(s) : finalisation / accompagnement & qualification o en option : garder un sprint à blanc (pas une provision)
  • 21. Le « processus Scrum » - L’exploration Phase de Préparation & Exploration Préparer l’organisation du projet ● rédiger le PMP. ● se synchroniser avec les acteurs externes ● inclure les utilisateurs (un panel, un forum de feedback …) ● sélectionner les pratiques agiles qui seront utilisées ● fixer les règles de codage ● déterminer les DoD ● définir les modes de communication ● définir la durée d’un sprint Agilité Technique ● former les acteurs du projet et Fonctionnel sensibiliser leur hiérarchie
  • 22. Démarrer un projet par une formation • Un projet démarre ? => 2 jours de formations pour tout le monde afin que chacun partent sur de bonnes bases afin que chacun partent sur les mêmes bases => 2 jours de formations complémentaires dédiées au Product Owner retour
  • 23. Catégories de projet et labellisation
  • 24. Les catégories de projets agiles Les contextes de certains projets ne permettent pas toujours d’appliquer tout ce que l’agilité propose. Afin de cadrer et d’aider au mieux tous les projets désirant utiliser autant que possible l’agilité, il existe désormais des catégories de projets permettant officiellement d’utiliser l’agilité à la mesure de ce qui est possible routière sportive Formule 1
  • 25. Les catégories de projets agiles 3 catégories de projets agiles permettent d’utiliser une proposition agile cohérente et adaptée quel que soit le contexte • routière : contexte peu favorable. projet non agile, mais qui choisit néanmoins d’utiliser les valeurs agiles, les itérations courtes et les rôles agiles. • sportive : projet à volonté affirmée, mais à maturité agile faible. certaines pratiques sont optionnelles. • formule 1 : utilise correctement toutes les pratiques agiles.
  • 26. Pourquoi un label ? Lorsque l’agilité est bien appliquée, • les qualités technique et fonctionnelle sont grandes • le métier et les utilisateurs finaux fournissent un feedback régulier et les itérations courtes permettent de garantir la pertinence fonctionnelle de l’application • les tests automatisés certifient le bon fonctionnement du début à la fin UN PROJET VRAIMENT AGILE NE PEUT PAS ECHOUER. • Les coaches du Centre d’Expertise Agile accordent ou non le label à chaque fin d’itération. • Il s’agit de s’assurer que les gens ne font pas « n’importe quoi » sur le dos de l’agilité. • On donne des objectifs atteignables aux projets • on crée un réflexe managérial : « Agile ? as-tu un label ? »
  • 27. à propos du « Agile cow-boy » le « agile cowboy » (qui prend l’agilité comme prétexte pour faire n’importe quoi) conduit à des catastrophes pires qu’un cycle en V figé Si on n’a pas les prérequis pour commencer, il ne faut pas commencer ! retour
  • 29. DoD … les Definition of Done exemples Tâche unitaire User story Sprint • Compilation • Conception mise à • Démo faite sur les • Refactoring jour User stories • Tests fonctionnels « vraiment • Tests unitaires terminées » en local • Guide util/Admin • Doc de specs • Intégration • Intégration fonctionnelles mis à • Tests sur • Impact jour intégration OK exploitabilité •… • Validation PO • Affichage < 3 sec.
  • 30. Une qualification au fil de l’eau Pour pouvoir certifier le bon fonctionnement de l’application en permanence, il devient indispensable d’automatiser les tests techniques et fonctionnels et de les passer tous les jours 15 tests 40 tests 80 tests
  • 31. Les KPI agiles Un certain nombre de KPI issus du mode classique ne sont plus pertinents pour mesurer la performance d’un projet. Pour les projets VRAIMENT agiles (au moins « Sportives »), les KPI agiles sont : ● Vélocité : mesure et stabilité de la capacité de production de l’équipe ● Tests fonctionnels : les « how to verify » sont automatisés et OK ● Objectifs métier : la contrainte « Fixe » de la TradeOff matrix annoncée au T0, confirmée au T1, est respectée. Les objectifs mesurables de la charte sont atteints ● Qualité technique : les normes sont respectées, les tests techniques sont tous OK, la couverture de tests technique est >= 80%, aucun bug issu du travail de l’équipe ● Note d’agilité de 3,5 sur 5 (moyenne pertinente du « ScrumMaster assistant ») et au moins 3 sur les critères obligatoires de la catégorie du projet ● Satisfaction métier + utilisateurs finaux : minimum 3 (intervalle 0 à 5) Les exceptions (test non automatisable par exemple) sont tolérées si elles sont validées par l’équipe, le coach et le Pole Agile
  • 32. Documentation : l’utile, mais pas plus En tant que vecteur fort de la communication entre les services et équipes qui se succèdent sur un projet, la doc est indispensable PMP (Plan de Management de Projet) Toutes les stratégies, l’organisation du projet et ses spécificités sont dans le PMP, y compris les contraintes d’exploitabilité Les documents d’architecture DAT, DAF, DAL : architectures technique, fonctionnelle, logicielle Spécifications fonctionnelles Il reste indispensable d’avoir ce document à jour. Proposition : le PO le met à jour à chaque fin de sprint. L’exploitabilité (pour que l’application survive à son équipe de dev) Guides d’install, utilisateurs, administrateurs technique et fonctionnel, les descriptions (alimentées au fil des développements) des sauvegardes, supervision, ordonnancement, gestion des erreurs retour
  • 34. Un système qualité adapté, appuyé par l’outil Tous les principes qualité sont conservés. Seule leur mise en œuvre a été adaptée au contexte agile La réelle simplification vient de l’outil : • pour gérer le projet (exigences, scope fonctionnel, risques, actions, etc) • pour gérer le backlog produit • pour gérer l’historisation et la traçabilité de manière automatique • pour gérer le quotidien de l’équipe (backlog de sprint, stories, taches) • pour générer automatiquement le reporting utile • pour stocker tout élément documentaire (wiki) • pour gérer les tests et leur liens aux stories et aux exigences • pour centraliser les informations en un seul endroit • pour faciliter le partage entre des sites distants • Avec le serveur d’intégration, on suit les couvertures de test, respect des normes, indice de complexité du code, détection de duplication, etc
  • 35. Les outils : Backlog
  • 36. Les outils : Storyboard
  • 37. Les outils : Reporting
  • 38. Les outils – Gestion documentaire
  • 39. Les outils - Hudson Hudson est un portail centralisant les informations techniques. C’est en général le « chapeau » de l’intégration continue. On y trouve notamment : - Le résultat du dernier build - Les résultats des tests techniques - La couverture de tests - Des propositions de refactoring - Le résultat du contrôle de respect des normes, etc … retour
  • 40. Faire un backlog produit
  • 41. backlog produit : des specs progressives Pour le démarrage du projet, on demande 2 niveaux de précision : les Thèmes et les Epics Cela donne les grandes lignes de l’investissement (SOX).
  • 42. backlog produit : des specs progressives Pendant l’exploration, le PO va détailler un seul niveau supplémentaire : les user stories Thèmes, epics et user stories auront une priorité métier et une note de complexité technique (en points) retour
  • 43. A propos des « cérémonies »
  • 44. A propos des « cérémonies » Les réunions qui ponctuent les sprints sont en général appelées « cérémonies » Drôle de nom ! (pour certains) La raison : elles suivent toutes un « cérémonial », et ont une structure bien définie. Toutes les cérémonies sont timeboxées. Le PO participe à toutes, même au standup !
  • 45. A propos du stand-up On met à jour le « reste à faire » de chaque tâche en cours L’estimation et les ré-estimations : heures ou ½ jour 1h, 2h, 3h, 4h, puis 1 jour, 1,5 jours, 2 jours (pas plus !) Autre possibilité : Utiliser l’avancement de la story en % Rappel : un Stand-up N'EST PAS • n’est pas un tribunal • n’est pas un moment pour les reproches et remontrances • n’est pas un lieu pour les conversations ou les débats • n’est pas un moment de reporting
  • 46. A propos de la rétrospective • Moment de grande subjectivité : o chacun exprime son ressenti o chaque avis compte et doit être respecté • On peut utiliser un lieu inhabituel au projet (dehors ?) • Les actions d’amélioration : attention à leur nombre. Il est essentiel que toutes les actions priorisées et retenues soient vraiment réalisées à la fin du sprint => Le ScrumMaster y veille ! retour
  • 47. Bonne route ! merci