Qui suis-je?
Julien Carreaud
Source : https://alness.gnomio.com/pluginfile.php/209/mod_resource/content/1/Onine%20Resources/C%20Systems%20Int2/images/pic017.jpghttp://unbreakablepo.files.wordpress.com/2010/05/herobusinessmancape.jpg?w=300&h=300
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.
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
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
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
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
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.
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/
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
++ --
Top Related