Du cycle en V au kanban, je vous propose le retour d'expérience d'une transformation en profondeur de notre gestion des projets, et des contributions. En tant qu'agiliste en devenir, je vous présenterai un témoignage de ce que la mise en oeuvre du kanban et ses pratiques associées ont changé concrètement au sein des équipes CP/PO, développement et qualification.

1. REX Passage au Kanban
Julien Carreaud

2. REMERCIEMENTS
À nos partenaires
MédiasFormation
À nos sponsors

3. Qui suis-je?
Julien Carreaud
Source : https://alness.gnomio.com/pluginfile.php/209/mod_resource/content/1/Onine%20Resources/C%20Systems
%20Int2/images/pic017.jpg
http://unbreakablepo.files.wordpress.com/2010/05/herobusinessmancape.jpg?w=300&h=300

4. Avant j’étais cycle en V…
o Plan projet plutôt rigide
o Gestion de livrables exigeante, avec
validation stricte et prise d’engagement.
o Les changements ne sont acceptés qu’au
travers d’un processus long et administratif.
o Interactions entre les équipes très
formalisées, se dégradant rapidement en
cas de problème. Fonctionnement en
contribution.
o Effet tunnel pour le métier.

5. Changement de projet : la nouvelle équipe
• Arrivée sur la release 6 d’une
application de souscription de contrats
collectifs santé et prévoyance
• Mes premiers pas dans l’agilité
• Méthode « scrumisante », mais encore
non aboutie
• Des équipes non co-localisées
• Des contributeurs agiles, d’autres cycle
en V
• Un PO au centre
Qualification
Dév. site
Dév. éditique
Dév. mainframe Métier
PO
NANTERRE
NANTERRE
NANTERRE
LILLE
LA DEFENSE
INDE
NANTES

6. Transformation agile de la DSI : Passage au kanban
Nouvelles pratiques :
•Découpage en US.
•Le périmètre est ajustable, les fonctionnalités
sont priorisées par valeur métier.
•Identification des étapes nécessaires à la
livraison des US.
•Rendre visible le découpages des tâches et
l’avancement de chaque US : construction du
kanban physique.
•Instauration des rituels (daily, démo, rétro).
•Travail en flux tiré.
•Mise en place de limites.
•« Allo Houston, on a un problème »  la fast line.
Source : https://twitter.com/HistoryInPics/status/561242500502126592/photo/1

7. Test !
Intégration des testeurs dès la conception des US : écriture
des cas de test en préalable aux développements.
oLa relecture de l’US par un tiers (qualif) permet, en plus,
de s’assurer de son intelligibilité et de sa complétude,
avant de passer aux dev.
Des tests au plus tôt
oPair test des US
oTests d’itération (“sprint”) : après chaque démo, 1
journée de tests sur l’itération par la qualif + métier et PO.
oTests de recette de la release
→ meilleure qualité perçue du métier
→ meilleur appropriation des features par le métier

8. Un kanban pour les gouverner tous
PO
Qualif.
Dev.
Qualif.
PO
Backlog CA BDD INVEST To do Dev Code review Pair test A livrer
recette Recette Done

9. Quelques singularités de notre organisation
Une release ne comporte pas que des US du projet, elle embarque également :
oDes demandes de fonctionnement (bug de production ou petites évolutions), car une
équipe spécifique est dédiée au support utilisateurs.
oDes Technical Stories, nécessaires au traitement de la dette technique et à
l’amélioration continue.
De plus le kanban comporte 2 autres types de cartes :
oLes bug, détectés lors des séances de tests d’itération ou en test de release
oLes US « externes » qui permettent de suivre l’avancement des développements des
équipes non agile. Cela nous permet d’identifier à quel moment une fonctionnalité est
complètement testable.
Pour que tout cela fonctionne le rendez vous du daily meeting est indispensable.

10. Etre à l’écoute
à l’écoute des contributeurs
ocomprendre et composer avec les contraintes
(méthodologiques, techniques ) de chaque équipe
à l’écoutes des individus
opar les interactions quotidiennes (daily)
opar les déplacements sur les sites
à l’écoute du métier
ofeedback post démo,
ojournée de test
Source : http://www.retronaut.com/2011/07/listening-before-radar/

11. Bilan
o Utilisation des métriques perfectible
o Equipes non encore co-localisées &
hétérogénéité des pratiques
o Agilité encore timide du coté métier
(mais on y travaille)
o Peu / pas de production de
documentation pérenne sur l’applicatif
o Implication des acteurs
o Coopération
o Résilience de l’organisation
o Qualité
o Time to market
o + d’interaction avec le métier
→ ajustements au plus tôt
++ --

12. Ma conclusion
J’adore qu’un plan se
déroule sans accro !
Source : http://www.hulu.com/watch/14387