P.O. non certifié

View Github Repository Open presentation in a new window

lcottereau

See all presentation from lcottereau

P.O. non certifié

0 0

po-non-certifie-slides

Présentation "Product Owner Non Certifié"

On Github lcottereau / po-non-certifie-slides

P.O. non certifié

Spécifier agile sans connaître l'agilité

  • N'hésitez pas à m'interrompre
  • Qui a à peu près une idée sur le rôle du PO ?
  • ici utilisé "générique" : représentant des utilisateurs
  • Qui a à peu près une idée sur le backlog ?
  • liste des tâches à réaliser sur projet
  • Tout le monde ici connaît la RATP ou pas ?

Expérimentations agiles à la RATP

  • DSI RATP : 25% des projets pour 65% des montants
  • DSI habituée à gros projets et structures MOA
  • obj. équipe : répondre au besoin sur les autres projets
  • interlocuteurs pas organisé en mode projet
  • métier primordial, très spécifique (logement, gestion de crise, déchêts, ...)
  • demande exprimée : améliorer le TTM
  • non exprimée : arriver à transposer le métier
  • agilité pour répondre à cette problématique de spec

Des contraintes projet

  • interdire (puis limiter) interactions non agiles
    • architecture standard, connue et maîtrisée
    • offre de service d'exploitation standard
    • vigilance interfaces
  • pilotage par les délais, specs volatiles
  • si contraintes fonctionneles fixées, agile pas idéal

Qualités du futur Product Owner

  • connaissances métier au minimum
  • idéalement utilisateur lui-même
  • bon réseau (centralisation et arbitrage des demandes)
  • habitué exploitation, rarement connaissance projet
  • accepte direction projet côté MOE
  • mais capacité de décision : éviter les goulots
  • pas évident dans une grosse boîte
  • retours arrières OK (pas trop souvent)
  • disponibilité importante

Premier jet de backlog

  • échange(s) + ou - informel
  • idéal si idée de métaphore (ex. mémoire PC)
  • pas toutes réponses mais obliger PO à se questionner
  • estimation de charge sur cette projection
  • ajout d'un alea de 30% (risques et évolutions)
  • aboutit à date de livraison finale
  • backlog pas promesse sur produit final

Le Juste Nécessaire

  • concentrer sur fonctions utilisées tout le temps
  • 20% / 80% du temps
  • 1ère étape : MEP du MVP
  • retour utilisateur le plus rapide possible
  • par la suite, MEP (ou pilotes) réguliers

Spécification itérative

  • PO utilise retours pour maj backlog
  • bouts de fonctionnalités : prototypes
  • permet de mûrir les fonctionnalités
  • souvent on ne garde que le prototype

Substantifique moelle

  • (pour ceux qui ont encore faim)
  • ici objectif : réduire la fonctionnalité
  • différents leviers possible
    • pas d'ergonomie plutôt que wizard complexe
    • moins d'attributs
    • cas complexes à la main (imports ou traitements)
    • interface d'administration automatisée brute
    • impression HTML seulement, PDF si besoin
  • équipe propose des coupes avec gain d'effort

Ordonnancement des tâches

  • prise en compte feedback/prototypages ou contexte
  • Non Certifié !
  • souvent plus difficile que décrire la fonctionnalité
  • pas de gestion complexe des priorités ou ROI/Risque
  • mais pas de groupes de priorité : ordre complet

Et si on s'arrêtait demain ?

  • toujours prêt à passer en production
  • très bien compris par l'utilisateur
  • et si on avait un jour de plus itératif
  • permet aussi de ne pas oublier les tâches techniques (risques à lever souvent repoussés comme login)

Pas de nettoyage du backlog

  • très difficile d'abandonner une tâche
  • raison principale des grosses specs en cascade
  • on repousse pour quand on aura le temps
  • pas classique mais évite blocage du PO
  • la tâche meurt de sa belle mort à la fin du projet

Co-localisation

  • facteur de succès important pour spécification
  • (outre confiance réciproque et concret pour les dev)
  • permet spec détaillée en cours de dev
  • écrire moins pour éviter téléphone arabe
  • discussions informelles débusquent les loups
  • particulièrement utile sur applications métier

Retarder la spécification

  • conclusion : agile utile car retarde la spécification
  • pour peut-être ne pas faire (gage de maintenabilité)
  • et sinon faire bien (le plus de feedback/maturité possible)
  • spécification difficile. agilité la facilite

Merci à Greg Borenstein, Keoni Cabral, Yann Caradec, coba, droetker0912, Hakim El Hattab, Jacob Gube, Alexander Henning Drachmann, Dan Leech, Florent Mathé, Emma Mykytyn, Duncan Odds, Kim Seng, Renée Sueng et tomfkemp pour le partage de leurs contributions

Merci

Des questions ?