Planning

Daily Scrum

Le Sprint un sport individuel par définition

Le dernier jour du Sprint...

Potentiellement livrable...

Une tâche non livrée est
une dette qui génère des intérêts

Une tâche crée de la valeur à partir du moment où son contenu est utilisé par un client

i.e.

Quand son ROI est activé

Si les priorités changent, on préfère attendre le sprint suivant

Met en place des réunions lourdes à l'efficacité discutable
 

Ne favorise pas le travail d'équipe

N'est pas assez flexible vis-à-vis du changement et des aléas

N'optimise pas le ROI, et la création de valeur

S'appuie sur des estimations subjectives qui sont souvent fausses

Taiichi Ōno

On se focalise sur ce qui créer le plus de valeur

ToDo

In Progress

Code Review

To Release

+ prioritaire

- prioritaire

Règle #2

 Les stocks coûtent de plus en plus chers à mesure qu'ils se rapprochent du client final

Règle #3

Limiter le travail en cours !

Pensez à un ThreadPool

Evitez le "coding frenzy"!

Plusieurs tâches par personne
=
Goulot d’étranglement

ToDo

In Progress

Code Review

To Release

3

2

No!

Une tâche qui est commencée doit absolument être terminée le plus rapidement possible

Lead Time

Loi de Little

Cycle Time

ToDo

Done

Réduire le WIP = Réduire le Lead Time

⇔

Accélérer la création de valeur

ToDo

New

New

Avantage #1: la Flexibilité

Avantage #2

Ne pas avoir de Sprints favorise le Continuous Delivery

La performance:
maintenir le leadTime à son minimum

Le leadTime se termine lors de la mise en production

Une tâche n'est réellement finie que lorsqu'elle est livrée en production i.e. à partir du moment où elle crée de la valeur

Le rôle du développeur n'est pas que d'écrire du code !

S'assurer que le pipeline de production fonctionne est le rôle de tous

En admettant que les priorités peuvent changer à chaque instant, la réunion de planning n'a plus de sens

Et parce qu'on livre à chaque tâche

Pas de réunions interminables où tout le monde s'ennuie

=

Plus de temps à se consacrer à la création de valeur

Mais alors comment fait-on pour savoir quand vont être livrées nos features ?

Petite expérience!

A good estimation approach should provide estimates that are within 25% of the actual results 75% of the time

Conte, Dunsmore and Shen (1986)         

Estimer coûte cher sans fiabilité garantie et sans ROI

A quoi servent les estimations?

La prédictibilité

Il y'a 2 sortes de tâches:

• Les trop grosses

• Les assez petites

ToDo

...

...

Last

Last

#15

#1

#25

Si les priorités changent,

Les dates de livraison changent !

Il faut que le pipeline de production soit assez stable !

Se focaliser sur la vision produit

Faire des cycles courts

Prédire par les data

L'alternative

Représentant du client sur site

Intégration continue

Rythme soutenable

Convention de nommage
Tests!!! TDD

Poker Planning

----------------

Petites livraisons

Conception simple

Refactoring

Le pairing

1 pilote

1 copilote

Permet de faire de meilleurs choix plus vite

Moins de risques qu'une tâche se retrouve à l'arrêt

Changement des rôles et des paires à chaque nouvelle tâche

Réduit fortement la courbe d'apprentissage

ToDo

In Progress

Code Review

To Release

Pair
Review

Tout le monde fait toutes les codes reviews!

Appropriation collective du code

Des stand-up plus efficaces

La connaissance individuelle tend vers la connaissance collective

Mais...

• Consomme plus d'énergie

• Nécessite une adhésion complète de l'équipe

• Demande plus de discipline

• Peut augmenter les interdépendances

• Requière une grande capacité de recul

• Exige une vision claire des priorités

• S'adapte mal aux grosses équipes