BAFS 2015 Genève : Frédéric Tremeau - Comment réconcilier l'IT et le métier grâce à l'agilité ?

Comment
réconcilier l’IT et le
métier grâce à
l’agilité
Présentation du 30.06.2015 v1.0a
Par Frédéric Trémeau - Altran
Genève – le 30 juin 2015 Altran - Réconciliation DSI - Métier

Votre interlocuteur
Genève – le 30 juin 2015 Altran - Réconciliation DSI - Métier 2
Frédéric Trémeau
 Practice Manager – Agile Coach pour la société Altran
 Formateur «Agile Unified Process / Scrum / XP / Lean / User Stories»
 Test Manager
frederic.tremeau@altran.com
ch.linkedin.com/in/ftremeau/
Domaines d’activités
 Réalisation d’études d’opportunités agiles.
 Coaching agile sur organisations et projets.
 Formations agiles contextualisées aux contraintes des entreprises.
 Elaboration de stratégies de test agile.
 Porteur de l’offre agile modulaire du groupe Altran
Coaching On Demand.

Agenda
A. Valeurs agiles et interprétation
B. Concept de développement itératif incrémental
C. Principaux rôles Agile et positionnement du client
D. Adaptation des rôles au spécificités de l’organisation cliente (forfait vs Régie)
E. Avant de choisir des pratiques : penser à évaluer l’environnement cultuel client
F. Constituer son Framework Agile en fonction du projet
G. Se doter d’outils contractuels et d’assurance qualité agiles
H. Retours d’expériences

Rappel des valeurs de l’agilité
Genève – le 30 juin 2015 4
I. Privilégier les personnes et
leurs interactions sur les
processus et outils
II. Privilégier le produit sur la
documentation
III. Privilégier la réponse au
changement sur le suivi d’un
plan
IV. Privilégier la collaboration
avec le client sur la
négociation contractuelle
Agile
Extrait de
l’Agile Manifesto
de 2001
- Pratiques collaboratives.
- Cérémonies d’échanges agiles
(Stand-up meetings, Planning
Games, rétrospectives, Sanity
check).
- Pilotage par le périmètre (Product
Backlog et Release Plan).
- Définition des critères d’acceptation
«Produit» (Definiton Of Done).
- Co-construction de la documentation
- Confrontation régulière du client au
produit.
- Implication du métier dans la
construction du cahier des charges
(CDC Agile).
- Mise en place du contrat de
prestations agiles (implication du
juridique).
- Pilotage par les délais (Planning
d’itérations).
- Techniques de priorisation.
- Mécanismes «d’entrée / sortie» au
périmètre (adaptabilité).
Altran - Réconciliation DSI - Métier

Agenda
C. Principaux rôles Agiles et positionnement du client
D. Adaptation des rôles au spécificités de l’organisation cliente (forfait vs Régie)

Cycle de vie d’un projet Agile
1
2
3
4
5
6
7
8
9
(1) Release roadmap
(planification des itérations)
(4) Planning Game
(Tâches de l’itération)
(7) Sprint Review : démonstration
(2) Product Backlog Refinement
(affinage du Product Backlog)
(5) Scrum Meeting
(Point quotidien)
(8) Sprint Review : Backlog Review.
Pointage du reste à faire sur la Backlog.
(3) Poker Game
(estimation du Product Backlog)
(6) Tracking
(Production des indicateurs)
(9) Sprint Review : rétrospective.
(Séance d’amélioration continue)

Agenda
D. Adaptation des rôles aux spécificités de l’organisation cliente (forfait vs Régie)

Rappel : les principaux rôles Agiles
Product Owner
 Gardien du périmètre
 Priorise et met à jour sa Backlog
 Est destinataire des livraisons
 Change le statut de ses Items (Definition Of Done)
Scrum Master
 Gardien du processus
 Assiste le PO à gérer sa Backlog
 Facilitateur pour la Team
Scrum Team
 Analyse et participe aux chiffrages
 Réalisation du système
 Auto-organisée
 Produit des indicateurs d’avancement
Plage de responsabilités du
client. On peut considérer
que naturellement le PO
est un représentant du
métier.

DATE + VILLE 9
Son implication doit d'abord être régulière tout au long du projet. Le rythme est donné
par les itérations et par les cérémonies qui les jalonnent.
Par exemple pour des itérations de 3 semaines, voilà quelle est la participation
minimale du Product Owner :
 Planning Game : Réunion de planification des itérations, pour une durée de 60 minutes toutes
les 3 semaines. La réunion dure 2 heures, mais la présence du PO n'est obligatoire que pour la
première partie (aspect fonctionnelle).
 Revue de Backlog : Prévoir une durée de 15 à 60 minutes toutes les semaines.
 Sprint Review : pour une durée de 60 minutes en fin d’itération.
 Scrum Meeting : Participation facultative (ou à la demande de l’équipe). Pas d’intervention
directe. Permet de prendre la température.
 Sa présence à la Rétrospective est souhaitable mais pas indispensable.
A côté des réunions, le travail du PO est aussi de :
 mettre à jour la Backlog, ajuster les priorités
 répondre aux questions de l’équipe sur ses User Stories
 définir ses critères d'acceptation sur les Stories.
 Contribuer à l’effort de test sur la solution cible (cf. Quadrants de BM)
C'est du temps et si le PO n'est pas capable d’assurer ces cérémonies, il est alors
envisageable d'avoir dans l'équipe un PO délégué (PO Proxy).
Niveau d’implication attendu pour un PO

Agenda

Adapter les rôles agiles à l’organisation
Cas de figure 1 : Pilotage de l’équipe de réalisation par la DI (interne et/ou avec régie)
Scrum Master
Direction informatique
Architecte
Sponsor
Métier
Direction
Informatique
Services de
soutien
Entités métier
Assurance
Qualité
Analystes
Développeurs Testeurs
Experts métier Utilisateur(s)
pilotesProduct Owner
Métier
Ressources réalisation

Adapter les rôles agiles à l’organisation
Cas de figure 2 : Projet réalisé par un fournisseur externe au forfait.
Product Owner
Proxy
Direction informatique
Architecte
Scrum Master
Intégrateur
Sponsor
Métier
Direction
Informatique
Services de
soutien
Entités métier
Direction
de projet
Service juridique
Assurance
Qualité
Analystes
Développeurs Testeurs
Experts Métier
PO Métier
Utilisateur(s)
pilotes

Agenda

Comment évaluer la dimension culturelle
Collaboration
Accomplissement Compétence
Contrôle
Nous réussissons en
travaillant ensemble
Nous réussissons en
accompagnant ceux qui
partagent notre vision
Nous réussissons en prenant
et gardant le contrôle
Nous réussissons en étant
les meilleurs
Le modèle de culture de William Schneider met en lumière les valeurs, principes et normes
en vigueur au sein d’une organisation.
Il identifie ce qui est important, la façon dont les gens abordent les travaux et l’approche
relationnelle en vigueur entre les collaborateurs.
Ce dernier a défini un modèle de culture orienté selon 4 quadrants :
William Schneider «Why Good Management Ideas Fail - Understanding Your Corporate Culture”

Exercice culturel : Exemple d’application
Préparation de la collecte des
informations dans le cadre
d’une rétrospective
1
Répartition des informations
collectées dans la matrice
2
Schématisation des résultats
3
Interprétation des résultats
4

Agenda
F. Constituer son Framework Agile en fonction du contexte projet

Scrum ou Scrumban ?
Scrumban reprend les éléments forts du cadre et des dynamiques d’équipe stimulantes de
Scrum en y intégrant les pratiques essentielles de l’exécution Lean. Cette approche cible
l’efficacité et la fluidité des processus.

Stratégie de test Agile
Brian Marick, référent dans le monde de la qualité logicielle et signataire de l’Agile
Manifesto, a définit 4 quadrants de test qui, à eux seuls, guideront l’ensemble d’une
stratégie de test agile:
Q2 Q3
Q1 Q4
Q1 : Tests orientés technologie en
soutien de l’équipe (ex : Tests unitaires
et approche TDD, le plus automatisé
possible).
Q2 : Tests orientés métier en soutien
de l’équipe (ex: les tests sur
Storyboard, les tests fonctionnels
automatisés pour vérifier les critères
d’acceptation du Product Owner ainsi
que les aspects ergonomie).
Axe technologie
Axe métier
Axe produitAxe équipe
Q3 : Tests orientés métier pour critiquer le
produit (c’est avant tout du test manuel, à
tout moment ou en « End Game » pour le
système complet en test d’acceptation.
L’approche ergonomique ressort encore).
Q4 : Tests orientés technologie pour
critiquer le produit (des tests essentiels qui
se doivent d’être outillés et qui peuvent
nécessiter la présence de spécialistes, perf /
sécurité; souvent en « End Game » ou fin de
Release).

Stratégie de test Agile
Itérations IT1 IT2 IT3 (R1) IT4 IT5 IT6 (R2) IT7 IT8 IT9 (V1)
Quadrants Q1 Q1, Q2 Q2, Q3 Q1 Q1, Q2 Q3, Q4 Q2, Q3 Q2, Q3 Q3, Q4
Exemple de
transposition des
quadrants sur un plan
d’itération

Construction du Product Backlog
les étapes de construction d’une Backlog sont les suivantes :
1) Identification des acteurs du système cible
2) Identifier les domaines fonctionnels
3) Par domaine : identifier les Users Stories
4) Identifier les grosses Stories sous formes d’Epics.
5) Mise en Backlog des exigences techniques sous forme de Technical Stories.
6) Mise Backlog des exigences non fonctionnelles (performance, fraicheur, sécurité,…)
7) Si nécessaire : Identifier un indice de maturité, voir de risque par item de Backlog.
8) Adresser les différentes provisions sur forme de Spikes.
Les domaines fonctionnels
Les User Stories / Les EPICs
Les Technical Stories
Les Exigences «métier»
Les Exigences non fonctionnelles
Les acteurs du système
Product Backlog projet
Les Spikes
En tant que
ACTEUR, je
veux….
Arborescence
«type» d’une
Backlog

La technique de User Story
Qu’est-ce qu’une User Story
 Description concise d’une fonctionnalité source de valeur pour l’utilisateur ou le
client du produit.
 Les User Story sont au niveau des spécifications générales.
En tant que RECRUTEUR, je veux
déposer des offres d’emploi en ligne
afin d’embaucher de nouveaux
collaborateurs
Est : 5 Priorité : Must
US32 : Déposer offre d’emploi
Technique de levée de périmètre
inventée par Mike Cohn

User Story : Les 3 C de Ron Jeffries
1
Carte
2
Conversation
3
Confirmation
 Card
L’histoire est courte (écrite sur un post-it par
exemple)
 Conversation
Les détails de l’histoire sont discutés par les
équipes avec le métier
 Confirmation
L’histoire est confirmée par des tests
d’acceptation rédigés au même
moment que celle-ci (au dos de
la carte)

User Story : Les 3 C de Ron Jeffries
Les 6 critères Qualité pour une bonne User Story (Bill Wake)
Indépendante
Négociable
Valeur ajoutée
Estimable
Testable
Fruit d’un consensus avec entre le PO et le métier
(le second « C », Conversation).
Source de valeur pour l’utilisateur ou le client
final du produit.
Possibilité d’estimer la complexité de la Story par
l’équipe de réalisation.
Possibilité de réalisation en une itération.
Validation par les critères d’acceptation (le
troisième « C », Confirmation).
Suffisamment petite
Indépendante des autres User Stories et de la
technique.

User Story : Les critères d’acceptation
 Conditions à satisfaire pour que le Product Owner accepte la User Story en fin de
Sprint.
 A faire avant les estimations !
 Chaque User Story doit avoir un ou plusieurs critères d’acceptation.

Le modèle de priorisation MoSCoW
La méthode MoSCoW est une technique inventé
par Dai Clegg pour Oracle UK visant à prioriser
des besoins ou des exigences dans le cadre de
l’implémentation d’un produit client à
contrainte budgétaire fixe.
Les lettres majuscules de l'acronyme MoSCoW signifient
en Anglais :
 Must : C'est ce qui « doit être fait » (Vital).
 Should : C’est ce qui « devrait être fait dans la mesure du possible » (Essentiel).
 Could : C’est ce qui « pourrait être fait dans la mesure où cela n'a pas d'impact sur les autres
stories » (Confort).
 Won’t : C’est ce qui « ne sera pas fait cette fois mais sera fait plus tard » (Luxe). C'est une
zone d'optimisation budgétaire.
Must
Should
Could
Won’t
60%
20%
20%
Objectif de répartition

Exemple de Product Backlog priorisé
Identifiant des items Libellé des items Priorité MoSCoW
Poids initial et RAF actualisé à
terminaison des itérations
Cibles en terme
d’itération
Statuts
d’avancement
Exemple de Product Backlog dématérialisé dans l’outils collaboratif Confluence :

27
Les spécifications détaillées sont
décrites «pas à pas» selon une approche
«Test oriented»
Le wiki intègre nativement le Plug-in de
maquettage «Low Gui Design» Balsamiq
La production de spécifications collaboratives
Genève – le 30 juin 2015 Altran - Réconciliation DSI - Métier

Agenda

Se doter d’outils contractuels agiles
Objectifs du glossaire agile
 Constituer un glossaire Agile définissant de façon universelle toutes terminologies ou acronymes
emprunts au monde de l’agilité susceptibles d’apparaitre dans des documents applicables
contractuellement (Cahier des charges, Contrat, Plan Assurance Qualité, Protocole de réception,…).
 Valider et adapter ces définitions avec le service juridique de l’organisation.
Composantes
Glossaire
Agile
Cahier des charges
Agile
Contrat de prestations
Agiles
Objectifs du cahier des charges agile
Composantes propres à l’agilité :
 Présentation du contexte agile et des pratiques retenues par l’organisation émettrice.
 Emission d’un macro-planning et d’un Product Backlog à estimer et à compléter par les
soumissionnaires (méthode de chiffrage attendue).
 Description des engagements non fonctionnels attendus (intégration continue, fréquence des
livraisons, automates usines logicielle, outillage collaboratif,…).
Objectifs du contrat de prestations agiles
 Identifier et prioriser les documents contractuels applicables (le
Product Backlog entrera dans cette liste),
 Emettre les dispositions générales, les principes de collaboration
et obligations des parties,
 Etablir les délais d’exécution (principes généraux, de pénalité),
description des jalons de livraison,
 Identifier les procédures de livraison et d’installation,
 Cartographier les méthodologies de réalisation,
 Etablir les principes d’évolution du Product Backlog et du Release
Plan,
 Autres clauses décrites : Propriété intellectuelle, Garantie,
Réversibilité, Confidentialité, Résiliation,…

Le point de vue juridique
Genève – le 30 juin 2015 Réconciliation DSI - Métier 30
Thomas Beaugrand
Avocat au Cabinet
Staub & Associés,
intervenant sur les projets
et contrats Agiles
Beaugrand@staub-associes.com
« Un contrat non Agile ne peut encadrer efficacement un projet
Agile, et conduit les Parties à une crispation fatale si elles s’y
réfèrent en cas de divergence.
Le résultat, objectif du Client, doit s’exprimer par les métriques
agiles afin d’éviter tout litige sur la compréhension de ce qui doit
être livré.
L’adhésion du service juridique est donc capitale pour sécuriser le
déroulement du projet et l’issue du contrat ».

Agenda

Construction d’un Release Plan avec le métier
Items de la Backlog en
attentes de distribution
Release Plan vierge
Team Capacity estimée par itération
Des provisions (Spikes) sont levées pour traiter les
demandes de correctifs
Priorisation MoSCoW
(Must, Should, Could,
Won’t)
Poids de la Story en points
d’ingénierie (Poker Game)
Exemple de User Story
Acteur de la Story
Le Product Owner et le métier distribuent les
Stories sur le Release Plan
(selon la capacité des itérations)

Mise en place de Scrumban pour SAP
Todo
Sprint
Ctrl
Spéc.
Wiki
Spéc.
Dét.
Wiki
Ctrl
Spéc.
DSI
Todo Développements Tests
Todo En cours En test
Paramétrage
Paramétrage SAP
Todo Spéc. tech. Ctrl SIG
Préparation DEV
Todo En cours En Test
Développement SAP Niveau PO
Todo En cours Crlt Run Run
Cahiers
de tests
Métier
Done
Bon pour
MEP
Légendes :
: Zones d’attentes
: Analystes SAP
: Développeurs SAP
: Interventions client
Cycle Time
(temps de cycle)
Spécifications

Agilité et systèmes embarqués
DO 178C
Source Altran
Suisse & Toulouse

Conclusion : Réconciliation Métier - DSI
1. Le métier (PO) devient acteur actif : Pilotage par le périmètre (Product Backlog)
2. Les User Stories permettent une expression de besoin rapide et précise
3. Les outils collaboratifs fluidifient les échanges et prises de décisions
5. Le cahier des charges Agile prend en compte les évolutions de périmètre
6. Le contrat de prestations Agiles réconcilie la DSI avec les juristes (contexte forfait)
4. L’approche itérative incrémentale confronte au plus tôt le métier au produit
7. La priorisation MoSCoW permet de faire des transactions d’E/S à la Backlog cadrées
Merci de votre attention.
Avez-vous des questions ?

BAFS 2015 Genève : Frédéric Tremeau - Comment réconcilier l'IT et le métier grâce à l'agilité ?

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à BAFS 2015 Genève : Frédéric Tremeau - Comment réconcilier l'IT et le métier grâce à l'agilité ?

Similaire à BAFS 2015 Genève : Frédéric Tremeau - Comment réconcilier l'IT et le métier grâce à l'agilité ? (20)

Plus de BAFS

Plus de BAFS (20)

BAFS 2015 Genève : Frédéric Tremeau - Comment réconcilier l'IT et le métier grâce à l'agilité ?