Microsoft DevOps Day 2015 02122015 The Microsoft Way

Le voyage de Microsoft vers
l’agilité et DevOps…
Bernard Ourghanlian
Chief Technology & Security Officer
Microsoft France

4 | Le voyage de Microsoft en Agilité
“Firms today experience a much higher velocity of
business change. Market opportunities appear or
dissolve in months or weeks instead of years.“
Diego Lo Giudice and Dave West, Forrester
February 2011
Transforming Application Delivery
Pourquoi agilité et DevOps ?

49%
Transformation to
agile
will create one of the
greatest challenges
for my organization
this year
Source: CA / Coleman Parkes Research 2012

La destination pour Visual Studio…
Visual Studio Online
Team Foundation
Server

La destination pour Exchange…
Mise à jour
cumulatives
Service Packs vNext
Mise à jour
Cumulative
Mise à jour
Cumulative
Service
pack
Mise à jour
Cumulative
Nouvelle
version
Exchange
Server
Office365

La destination pour Windows…
Current Branch for BusinessCurrent BranchBranche Windows
Insider Preview
Validation
interne
Microsoft
Engineering
builds
Utilisateurs
Dizaines
de milliers
Plusieurs
millions
Centaines
de millions
Temps
4 à 6 mois
4 mois
8 mois

9 | Un-Managing Agile Teams
« Déconstruire » le
management des
équipes agiles…

manager
VERBE
discipliner ou contrôler une personne
ou un animal : pour garder le contrôle
d’une personne ou d’un animal, ou
d’un ensemble de personnes ou
d’animaux, spécialement quand ils
sont sauvages ou indisciplinés
Manager

Déconstruire le management ?
Contrôle Environnement

Déconstruire le management ?
Contrôle
Environment

Environnement

1. Motivation
2. Objet, règles, points
3. Liberté de religion
Qu’est qui crée un bon environnement ?

Drive: The Surprising Truth
About What Motivates Us
Dan Pink
Motivation
 Autonomie
 Maitrise
 Sens

16 | Le voyage de Microsoft en agilité
Autonomie
L’envie de diriger nos propres vies
Drive
Maitrise
Compétence d’expertise : connaissance
d’expert ou capacité exceptionnelle
Sens
La raison de l’existence de quelque-chose

Cela vous semble-t-il familier ?
• Autonomie
• Maitrise
• Sens

Objet du jeu ?
Règles du jeu ?
Comment marquer des points ?
Objet, règles, points

Scrum
Kanban
Lean
TDD
XP
MSF
Chute d’eau
Liberté de religion
Les guerres de méthodologies sont
terminées

Comment avons-nous
déconstruit le
management de nos
propres équipes ?

AVANT : Le calendrier
2 ans

Planning M1 M2

Planning M1 M2
Specs
?

Planning M1 M2
Specs
Nous savions exactement que construire et
nous savions que c’était nécessairement
les bonnes choses que nous construisions

AVANT : Les étapes
Planning M1 M2
Nous avions un planning parfait et nous
savions exactement quand la version
serait prête !

AVANT : Les étapes
Code Test et Stabilisation Code Test et Stabilisation
Nous avions des estimations parfaites et
nous comprenions parfaitement
comment tout allait se synchroniser !

AVANT : Ecrire le code
Code
Complete
Nous écrivions tout le code des mois
avant de livrer une version !

AVANT : Corriger les bogues
Stabiliser
Nous avions juste besoin de stabiliser le
code et de le rendre prêt à livrer aux
clients

AVANT : Feedback
Planning
Feedback des clients : vous devez changer la
façon dont fonctionne une fonctionnalité
… mais notre planning est déjà défini

Feedback
« Super feedback. Merci ! Nous allons voir
comment insérer votre demande dans le planning
de la prochaine version. Vous devriez avoir ce que
vous voulez…. dans quelques années »

• Dette technique
• Aucun moyen de réagir par rapport aux retours
des clients
• Le succès dans un mode « ça passe ou ça
casse »…
• Très peu d’autonomie des équipes
Quels étaient les problèmes ?

Windows Vista… Passer à l’échelle est difficile…
Science
Art
?

Voici l’objectif que nous nous sommes fixés…
Autonomie
Alignement

Rien n’aboutit ! L’exemple de Vista…
Trop
d’alignement

Chaos !!
Trop
d’autonomie

Organisation
Rôles
Equipes
Cadence
Taxonomie
Plan
Pratiques
Les principes de base
Alignement
Autonomie
« Essayons de donner à nos équipes 3 choses :
Autonomie, Maitrise, Sens »

1. Nos Rôles
2. Notre Organisation
3. Nos Equipes
4. Notre Rythme
5. Notre Plan
6. Nos Pratiques
Comment avons-nous changé ?

Nos Rôles – Au début…
Program Manager – Chargé de s’assurer que nous construisons les
bonnes choses.
Développeur – Chargé de s’assurer que nous construisons des
produits ou des services qui sont performants, fiables, et bien conçus.
Testeur – Chargé de s’assurer que nous construisons des produits de
haute qualité qui répondent aux besoins des clients.

Notre Organisation – V1
Program Manager Développeur Testeur

Program Management Engineering

Program Management Engineering Service DeliveryUX UE

Les équipes
Program Management Engineering
Le « product owner »

Multidisciplinaires
10-12 personnes
Autogérées
Gestion autonome du backlog
Préservée pour 12-18 mois
Salle d’équipe
Equipes

Organisation des équipes
IHM
API
Données

Au lieu d’un decoupage horizontal…
IHM
API
Données

Nous recherchons le vertical
IHM
API
Données

Q : Qui est le Scrum Master ?
PM Engineering

• Oui, nous avons des collaborateurs distants. C’est
l’exception, pas la règle
• Nous visons à utiliser des équipes distantes mais
pas des groupes entiers focalisés sur, par
exemple, une discipline
Q : Quid des collaborateurs distants

Sprints de 3 semaines
Semaine 1 Semaine 2 Semaine 3
Semaine 1 Semaine 2 Semaine 3emaine 2 Semaine 3
Sprint 69Sprint 68 Sprint 70
Deploiement
Planning du Sprint Fait !

Ce que nous avons accompli
Semaine 1 Semaine 2 Semaine 3maine 2 Semaine 3
Plan du sprint

Mails du Sprint
Plan Accompli !

Semaine 1 Semaine 2 Semaine 3maine 2 Semaine 3
Revue du Backlog
du Backlog Revue du Backlog

Scrum
Chute d’eau
Kanban
Microsoft
…
Quelles pratiques utilisons-nous ?

Chute d’eau
• Planning d’ensemble
• Conception
• Spécifications
Les règles que nous suivons
Scrum
• Planning du Sprint
• Daily Standup
• Equipe cross-
fonctionnelle
• Rétrospectives
Kanban
• Suivi visuel
• Limitation du WIP
(Work in Progress)

Les règles que l’on viole 
Chute d’eau
• Nous changeons d’avis
… souvent !
• Conception
• Spécifications
Scrum
• Alternance du Scrum
master
• Déployer une semaine
après le sprint
Kanban
• Limitation du WIP
• Itérations
• Planning

1. Nous devons nous attendre au changement
2. Nous devons arrêter d’essayer de prédire le futur
3. Nous devons optimiser autour des feedbacks des clients
Faire les choses différemment…

A quoi ressemble le travail ?
Scénario – Une initiative importante au
sein d’une version
Expérience – Un ensemble d’histoires
utilisateur de bout en bout
Histoire utilisateur – Une exigence
capturant le rôle, la fonctionnalité et la
valeur
Tâche – Travail effectué par l’équipe pour
accomplir une histoire
Expérience
Histoire
utilisateur
Tâche

Scénarios
Expérience/Fonctionnalités
Histoire Utilisateur
Tâches
Taxonomie et alignement
Alignement
Chaque équipe et chaque business suit
en permanence les scénarios et les
expériences
Autonomie
Chaque équipe choisit comment gérer histoire et/ou taches

Taxonomie et alignement
Sprint
3 semaines
3
Plan
3 sprints
Saison
6 mois
Scénario
18 mois
Ambitieux
60%
Optimiste
80%
Sérieux
90%
Confiant
95%

Chats d’équipe
Chats
d’équipe
Chats
d’équipe
Chats
d’équipe
3 questions :
1. Qu’y-a-t-il après ?
2. Comment va l’équipe ?
3. Des problèmes ?

Rester alignés
PrintempsAutomnePrintemps Automne

Scénario sur 18 mois

Saison de 6 mois

Plan sur 3 Sprints

1. Qu’avons-nous appris ?
2. Que nous disent nos clients ?
3. Quels sont les éléments du marché qui ont changé ?
3 questions que nous nous posons en permanence…

http://aka.ms/vsonews
Nous livrons CHAQUE Sprint

Qu’en est-il du code flow ?

Chacun crée « sa » branche…

Ecrit un paquet de code…

Et tout cela a besoin de se rassembler à la fin…



Feature Flags
if Feature.is_enabled(‘new_feature’)
# do something new
else
# do same as before
end

Feature Flags
ON
OFF

Feature Flags

Code Test et stabilisation Code Test et stabilisation
Code
Complete
Avant…

Après…

Satisfaction de l’engineering
Ecrire le Code
Les clients
utilisent le
Code
Ecrire le Code
Les clients
utilisent le
Code



Conclusion

Environnement – Construisez une environnement où vos équipes vont prospérer.
Ne laissez pas les processus et la bureaucratie leur barrer la route.
Motivation – Autonomie, maitrise, sens.
Objet, règles, points – Est-ce que vos équipes comprennent le jeu ? Est-il clair ?
Liberté de religion – Est-ce que vous suivez un processus dogmatique parce que
vous pensez qu’il est bon ? Ou bien faites-vous ce qui fait du sens dans votre
organisation ?
En résumé (1)

Soyez bon sur la science… mais ne soyez pas trop prescriptif
Ne cherchez pas à copier les autres… apprenez des autres
Construisez d’abord la culture que vous voulez… et vous obtiendrez alors le
comportement que vous souhaitez…
En résumé (2)

Microsoft DevOps Day 2015 02122015 The Microsoft Way

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Microsoft DevOps Day 2015 02122015 The Microsoft Way

Similaire à Microsoft DevOps Day 2015 02122015 The Microsoft Way (20)

Microsoft DevOps Day 2015 02122015 The Microsoft Way