bafs 2015 genève : frédéric tremeau - comment réconcilier l'it et le métier grâce à...

Comment réconcilier l’IT et le

métier grâce à l’agilité

Présentation du 30.06.2015 v1.0aPar 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 [email protected]/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

AgileExtrait de

l’Agile Manifestode 2001

- Pratiques collaboratives.- Cérémonies d’échanges agiles

(Stand-up meetings, Planning Games, rétrospectives, Sanitycheck).

- 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

23

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

SponsorMétier

DirectionInformatique

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 OwnerProxy

Direction informatique

Architecte

Scrum Master

Intégrateur

SponsorMétier

DirectionInformatique

Services de soutien

Entités métier

Directionde projet

Service juridique

Assurance Qualité

Analystes

Développeurs Testeurs

Experts MétierPO 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 Q4Q1 : 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 cible2) Identifier les domaines fonctionnels3) Par domaine : identifier les Users Stories4) 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


1Carte

2Conversation

3Confirmation

CardL’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

GlossaireAgile

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 BeaugrandAvocat au Cabinet Staub & Associés,intervenant sur les projets et contrats [email protected]

« Un contrat non Agile ne peut encadrer efficacement un projetAgile, et conduit les Parties à une crispation fatale si elles s’yréfèrent en cas de divergence.Le résultat, objectif du Client, doit s’exprimer par les métriquesagiles 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 ledé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


TodoSprint

CtrlSpéc.Wiki

Spéc.Dét.Wiki

CtrlSpé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 à...

Leadership & Management