Ce talk est un retour d'expérience de mon aventure en tant que Lead Dev produit chez Akeneo. Avec le recul, je ne ferai probablement pas toujours les mêmes choix. Certains étaient bons d'autres moins. L'idée est de les partager sur des exemples concrets de situation avec ce qu'il faut et ne pas faire.

1. Devenir un Lead Dev
Echecs et Succès

2. @RomainMonceau
Lead Developer
@Akeneo

3. Responsabilités du Lead Dev
- L’implémentation d’une solution qui réponde à un
besoin
- Le qualité technique du livrable
- Respecter les délais de livraison
- Pas de management par le Lead Dev

4. Contexte du Projet
Franklin Insights Ask Franklin Franklin Library
NOUVELLE EQUIPE
NOUVEAU
PROJET
STAGING STAGING
RELEASE DANS 3 MOISLead Dev Junior
Product Owner Junior
Product Owner ne connaît PAS le produit
FONCTIONNALITE
LA PLUS IMPORTANTE

5. What the fuck!?

6. Que faire dans cette situation ?

8. Ne perdez pas votre
temps sur les choses
négatives !
Allez de l’avant !

9. En tant que Product Owner, je dois
connaître l’application
Demande de formation fonctionnelle
Mais c’est trop tard pour une formation
Pas beaucoup de solution hormis aider davantage

10. Responsabilités
Le Product Owner est responsable de
répondre à des besoins et de les prioriser

11. Responsabilités
L’équipe est responsable de
construire une solution

12. Définir une solution en équipe
Brainstorming
UX Grooming
Event Storming
Example Mapping
Discussions
Ubiquitous
Language

13. Choisissez le
bon atelier !!!

14. Qui est responsable de quoi?
Franklin Insights
PO Léo
Ask Franklin
PO Thomas
Franklin Library
PO Léo

16. Bon mais la release c’est pour quand ?
- Stories pas toutes écrites
- Aucun “edge case”
- Nouvelles décisions
- Consommateur des autres
applications

17. Manque de visibilité
- J’ai défini le workflow global de la solution
- J’ai clarifié les “edge cases”
- J’ai estimé le temps nécessaire
- On a décalé la date de release

18. Qu’est-ce qui est mal ?
- J’ai travaillé SEUL
- J’ai involontairement imposé MA solution à mon
équipe
- Je suis devenu leur référent

19. Aider votre Product Owner à prioriser
Valeur d’une fonctionnalité
=
Valeur Métier - Coût de Dev

20. Vous n’êtes PAS responsable du temps
dont vous avez besoin pour développer
une fonctionnalité
A retenir !

21. Vous êtes responsable
d’estimer le temps dont vous
avez besoin

22. L’art d’estimer !
http://www.commitstrip.com/en/2018/02/05/it-project-estimates/

23. Plein de façons d’estimer
- Temps
- Complexité (Tshirt sizing, Fibonacci)
- Comparaison de fonctionnalités

24. Ma façon d’estimer
Estimation grossière pour l’équipe
+
Confiance dans l’estimation

25. Proof Of Concept
- Valider une solution technique
- Etre capable d’estimer
- Evaluer les avantages et inconvénients
Il faut timeboxer !!!

26. Expliquez votre choix !
L’équipe technique choisit la stack technique
Le Product Owner choisit combien de temps
il souhaite investir sur la fonctionnalité

28. Appuyez vous sur votre
équipe !!!

29. Merci