Kanban as Code - Agile France 2017

Kanban as Code
Organisation du code
@dbaeli@beastiefurets
@LeanKanbanFr
@geofberard

@YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli
Comparateur d’assurance
5 domaines
3M de devis par an
Au contrat signé
LesFurets.com

La plateforme
• Des formulaires riches
• 40-200 questions (Expedia c’est 10 !)
• Orchestration de demande de tarifs
• 50+ webservices appelé par tariﬁcation
• 2 Milliards de questions échangées avec les assureurs
• Module de paiement en ligne
LesFurets
WebSite
Panel Partners
Data Partners

Avantages compétitifs
Catalogue produit:
Nombre de partenaires
Vitesse d’intégration
Offres à prix précis
Mutualisation d’acquisition de trafﬁc:
Coût d’acquisition moindre qu’en direct sur Google
Clients de qualité pour les partenaires
UX - Ergonomie:
Vitesse d’obtention de 10 à 20 propositions fermes
Saisie unique d’information

L’équipe IT
• 70 Employés
• 7 Experts métier, 23 développeurs, 2 Ops, 2 Data Scientists
• 3 Feature Teams (Aquisition, Conversion, Infrastructure)
• 1 code base de 500.000 lines
• 40.000 tests (unitaires & intégration)
• 200 tests selenium + tests de regression graphique
•1 à 3 release par jour (1 à 10 changements)
• 1 branche par fonctionnalité :“Kanban as code”
• 20-30 branches en parallèle
@beatiefurets
github.com/lesfurets

7 dictionnaires de 500 pages (140 lignes / page)
2 fois les 7 tomes d’Harry Poter (3400 pages)
Une nouvelle version par jour
5-10 changement par 25 rédacteurs
Intermezzo : 500.000 lignes de code ?
x 7
x 2

Releases quotidiennes ?
Nos lectures & avis

Manifeste agile
Principe #1
« Our highest priority is to satisfy the customer through early
and continuous delivery of valuable software. »
http://agilemanifesto.org/principles.html

A lire sans attendre : l’entreprise agile

Kanban : Evolutionary Change
1. Visualiser le travail
2. Limiter l’encours de travail (Limit WIP)
3. Mesurer et gérer le flux
4. Rendre les règles explicites
5. S’engager dans une Amélioration Continue
6. Encourager le Leadership

Ce que vous ne pouvez ignorer
1. Travailler en ﬂux
2. Réduire le coût de livraison
3. Temps qui passe plutôt que l’effort
4. Le coût du délai
5. Observer les stocks (non ﬁni)

Livrer tôt, livrer souvent : implications
http://paulhammant.com/2013/03/13/facebook-tbd-take-2/

Leçon #1 : Livrer tôt, livrer souvent
• L’intention de réduire le Time to Market :
• Pouvoir livrer quand c’est prêt
• Faire des petits lots
• Impacte l’organisation
• Gestion du code source
• Organisation de la qualité (autonomie des développeurs)
• Outillage au service du Time to market
• Fail fast : Un feedback c’est un cadeau

Continuous Delivery : 5 Règles d’or
1. Assemblage rapide (local)
2. Assemblage incassable (staging)
3. Déploiement automatisés rapides
4. Monitoring et alerting partout
5. Root cause analysis des incidents

Gestion du code en 2017
Le minimum à savoir !

Git / Git Flow / Github Flow
Outillage indispensable pour gérer le ﬂux non linéaire
http://nvie.com/posts/a-successful-git-branching-model/
Master
Branch
Pull
Request
Github

Le vocabulaire minimum GIT (1/2)
•Commit:
• Une modiﬁcation dans la base de code
• Résumé: différence de l’original (diff ou patch)
• Historique / Commit Log :
• Séquence de commits
• Branche:
• Une copie complète du code
• Géré comme un historique alternatif
• Merge:
• Fusion de 2 historiques / 2 histoires
branch 1
branch
commit 1
commit 2
commit 4
commit
merge
commit 3

Le vocabulaire minimum GIT (2/2)
• Conflit:
• Lorsque deux commits sont incompatibles
• Lors du merge de 2 branches
• Conflict Résolution :
• Commit solution à un conflit
• Rebase :
• mettre 2 branches en séquence
• modifier le point de départ de l’histoire d’une branche
• flash back, voyage dans le temps
branch 1
branch 2 commit 2
commit a
conflict
commit 3
commit 2
commit a
commit 3
rebase

@beastiefurets@dbaeli
ticket1
ticket2
ticket3
ticket4
ticket5
features releaseslocal
ticket3
master
ticket3
ticket1
master
octopus-features
octopus-releases
few minutes 1 jour à 1 mois 1 - 2 jours
Validation
0 - 2 jours
release

Livrer plus souvent - Step 1
Livraison chaque mois
(2012)

Plan / estimate / code / test / release
Sprints mensuels - 12 releases par an
2012 : Monthly release

branch (prod)
trunk trunk
Release
Code Freeze
branch
Model 1: Branche de Release

Storie 1
branch (prod)
trunk trunk
Release
Code Freeze
branch
Model 1: Branche de Release

Storie 1
branch (prod)
trunk trunk
Storie 2
Release
Code Freeze
branch
Model 1: Branche de Release — En Théorie

Storie 1
branch (prod)
trunk trunk
Storie 2
Release
Code Freeze
branch
Conflits potentiels
Model 1: Branche de Release — En pratique

Releases weekly (2013)

2013 : Weekly release
Planiﬁer / estimer / coder / tester
Release weekly
50 releases par an

branch (prod)
trunk trunk
3 - 4 semaines 1 - 4 jours5 jours
Release
Code Freeze
branch
Model 2: Patches releases

branch (prod)
trunk trunk
Release
Code Freeze
branch
Storie 1

Storie 1
branch (prod)
trunk trunk
Storie 2
Release
Code Freeze
branch

Storie 1
branch (prod)
trunk trunk
Storie 2
Release
Code Freeze
branch
3 - 4 weeks 1 - 4 days5 days
1 week

• Conservation du planning mensuel, mais release hebdo
•Evolution:
• Utilisation du processus de patch (cherry pick)
• Nouveau code plus vite en production
•Blocages:
• Toujours une branche de release à maintenir
• Livraison toujours coûteuse avec duplication de code
2013 : Livrer chaque semaine

Leçon #2 : Release via le processus de patch
• En cas d’incident de prod
•Avez-vous un processus robuste de livraison des patches ?
• NON, c’est dangereux, fabriquez-en un !
• OUI, Pourquoi ne pas l’utiliser ?
•Avoir un processus robuste de livraison de patches n’est pas une option !

Release quotidiennes
(depuis 2014)

2014: Daily Releases
Livrer ce qui est prêt … chaque jour !
En mode Marathon
250+ releases par an (déjà 100 in 2017 !)

master
trunk
1 day 1 day
Model 3: Kanban as code
Storie 1
Storie 2
Storie 3

master
trunk
1 day 1 day
Storie 1

master
trunk
1 day 1 day
Storie 1
Travail terminé ?

master
trunk
1 day 1 day
Storie 1
merge, test & drop (octopus)
Merge, Test & Drop

master
trunk
1 day 1 day
Storie 1
Merge, Test & Drop

master
trunk
1 day 1 day
Storie 1
Storie 2
Merge, Test & Drop

master
trunk
1 day 1 day
Storie 1
Storie 2
Storie 3
Release de ce qui est prêt

master
trunk
1 day 1 day
Storie 1
Storie 2
Storie 3
Model 3: Kanban as code : Livrer quand c’est prêt

Garder les branches indépendantes
Détecter les conflits
Merge, Test & Drop
git-octopus by lesfurets (on GitHub)

Garder les branches indépendantes
Détecter les conflits
Continuous Merge
git-octopus by lesfurets (on GitHub)

En cas de conflit ?
Détecter, éviter, livrer.

Code d’origine:
master

master
Commit 1 : Beastie Furets
commit 1

master
Commit 2 : Hello Agile France
commit 2

Change 3 : Original (conflict with Change 2)
master
commit 3

???????
Change 3 : Hello Beastie
master
conflict
commit 3
commit 2

Eviter les conflits plutôt que les résoudre !
Pour garder l’indépendance des taches

Change 3bis : New version (avoid conflict)
master
commit 3
commit 2

Commit 1, 2: Easy merge
master
commit 3
commit 2
resolved
commit 1

Change 1, 2 & 3bis : Merge automatique
master
merged
commit 3
commit 2
commit 1

Leçon #4 : Ne pas bloquer les autres
• Garder les fonctionnalités séparées jusqu’au dernier moment
• Alors que tout le monde les fusionne par défaut !!!
• Merge Continu (comme outil de test):
• Détecter les conﬂits (sans être bloqués — build incassable)
• Laisse le temps de gérer le conﬂit
• Autorise à jeter facilement, ou mettre de côté sans frais
•Bonus:
• Le code non terminé n’est pas accessible aux autres !

Nos Stratégies d’évitement de conflit
1. Eviter d’avoir des zones de conflit (dette technique)
2. Modifier une des branches
3. Supprimer une des branches (mise en attente)
4. Fusionner les branches (date de sortie commune)
5. “Rebase” d’une branche sur l’autre (sortie en séquence)
6. Publier une résolution de conflit (git-octopus)

Les Leçons de Kanban as Code
#1 : Livrez tôt, livrez souvent
#2 : Patch de production comme processus
#3 : Evitez les conflicts
#4 : Ne pas bloquer les autres
Détecter, éviter, livrer.

Take away : Kanban as Code
Objectifs :
• # Les branches sont vos cartes Kanban (vers un flux tiré)
• # Flux de fonctionnel (Feature Branches ou Trunk based)
• # Livrez ce qui est prêt (Commencez par finir)
Pourquoi ça marche ?
• # Assure l’indépendance des taches (non adhérence)
• # Risques très faibles de conflits sur 500.000 lignes de code
• # Détection non bloquante des conflits

Beastie Furets (LesFurets IT Team)
@beastiefurets
beastie.lesfurets.com
lesfurets

66
LesFurets.com LeanKanban.fr29, 30 Novembre 2017
www.leankanban.fr

@dbaeli
@beastiefurets
MERCI !
@geofberard
@LeanKanbanFr

Kanban as Code - Agile France 2017

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Kanban as Code - Agile France 2017

Semelhante a Kanban as Code - Agile France 2017 (20)

Kanban as Code - Agile France 2017