Agile battle - Agile Tour Toulouse 2019

Rappeler les valeurs de l'agilité et du craftsmanship , leur
complémentarité mais aussi la difficulté à les déployer si on
prend partie pour un camp au détriment d’un autre.

Transcript

1. Agile Battle Gilles le SM Stev le dév vs
2. Les règles du jeu 7 min par participant → 1 point à celui qui a le plus de voix 2 questions à tour de rôle → 1 point si majorité de voix → 1 point pour l’autre sinon Pas le droit de parler pendant le tour de l’autre
3. Round 1 : Pitch
4. Recettes de l’agiliste Gilles le SM
5. Des ingrédients
6. Un état d’esprit
7. Une équipe Construisons une équipe colocalisée, responsable, pluridisciplinaire, auto-organisée travaillant dans la transparence et la bienveillance dans un cadre fun favorisant la collaboration et l’entraide
8. Lancement
9. Vision
10. Projection Agile
11. SCRUM
12. Explorer le produit
13. Have Fun
14. Grandir
15. Socle Commun
16. Conclusion La méthode Agile mène automatique à un bon produit
17. Obtiendra-t-il un bon produit ? Vote du public
18. Recettes du dév Stev le dév
19. Modèle SIMPLE Smallest Increment Possible On confectionne On montre On recommence De + en + petit
20. 4 bons dévs … et c’est tout
21. Mais c’est quoi un bon dév 140 compétences sur 1 projet scrum Comptabilité MS Exchange Jenkins Git PHP Symfony Apache Propriété intellectuelle Facturation nginx JavaScript unix React angular GTK npm compose Silex SAGE MySQL postfix SPAM Assassin C# RGPD Vsphere docker Stormshield svn veeam Clean Code Pair programming DDD CQRS TDD Casper https tunnel ssh html Talend ETL VoIP Sisense cron log4php ManageEngine OpManager GitFlow batch bash GitLab Abbyy Flexicapture CSS mantis Mob programming Design patterns PhpStorm keepass VBA WDS REST node RSA ElasticSearch logstash kibana RabbitMQ Excel outlook UX
22. Bon dév → dév apprenant Se forme sur les compétences nécessaires S’exerce en dojo Lit des livres Trouve les compromis Va à des conférences Fait de la veille Pratique avec des experts Prend du recul
23. Bon dév → dév qui produit du code propre • Respectant les standards de l’équipe • Sans redondance → DRY • Sans code “au cas où” → YAGNI • Bien découpé → SOLID • Testé → sans tests le code devient legacy immédiatement • Bien nommé → le nom doit révéler l’intention
24. Bon dév → sachant métier • Comprend tout le métier • Sait explorer le métier • Sait coder le métier ?!? Utilisateur A B Dév ∆A
25. Bon dév → des convictions fortes • Le test n’est pas une option • Tout code doit être revu • La qualité n’est pas négociable • Le code métier et le code technique ne doivent pas se mélanger • Tout ce qui peut être automatisé doit l’être • Le code doit être amélioré sans arrêt • Le code est la meilleure source de vérité
26. Une équipe qu’on laisse bosser • Explore elle-même le besoin • Choisit les technos / patterns les plus pertinents • Livre quand ça s’y prête et en autonomie • Se concentre exclusivement sur le produit ◦ Uniquement ce qui est utile ◦ Pas de réunions ◦ Pas de sollicitations à côté
27. Une équipe qui se pose des questions • Comment gérer les interruptions pour maintenance ? • C’est quoi le TDD ? • Comment le design pourrait-il bien “émerger” ? • Comment vivre avec un legacy ? Quelle stratégie pour en sortir ? • Comment simplifier le besoin ? • ...
28. Conclusion Seul l’excellence technique mène à un bon produit
29. Obtiendra-t-il un bon produit ? Vote du public
30. Round 2 : Questions
31. Entre les katas, les conf, les formations et la veille, il reste du temps pour le produit ? Question de Gilles à Stev
32. Convaincu·e·s par la réponse de Stev ? ·
33. On change tout, sauf la manière de produire du code. N’est-ce pourtant pas l’essentiel ? Question de Stev à Gilles
34. Convaincu·e·s par la réponse de Gilles ? ·
35. Et en dehors d’une StartUp, ça marche ton truc ? Question de Gilles à Stev
36. Convaincu·e·s par la réponse de Stev ? ·
37. Combien d’équipes connais-tu qui peuvent choisir en pleine autonomie : - d’arrêter Scrum, - d’arrêter d’estimer, - de passer 5j en immersion utilisateur, - d’acheter son propre matériel, - de recruter, - de faire venir un expert ? Question de Stev à Gilles
38. Convaincu·e·s par la réponse de Gilles ? ·
39. Et le gagnant est ?
40. Et du coup, on fait comment ?
41. Les devs sont-ils parmis nous? • Deux jours de NewCrafts Bordeaux sans jamais prononcer le mot Agile • “Encore un PO qui va m’apprendre à faire mon travail” • “L’agilité, j’ai arrêté d’en parler depuis 2 ans” • “Je préférerais me concentrer sur mon travail plutôt que de faire le guignol” • “Avant on tapait sur le CP qui tapait sur les devs maintenant c’est direct sur les devs” • “Avant au moins on savait où on allait, aujourd’hui on empile du jetable”
42. Retour au(x) (code) source Des dévs
43. Retours au (code) source
44. Agilité une finalité? une destination? Je suis AGILE
45. Ne créons pas l’ “Agil-isme” Bonheurisme Fun Auto-organisation Lean Emergence Gamification Facilitation graphique Design Thinking Corpoworking Intrapreunariat Lego Serious Game ScrumBan PNL Lean Startup Entreprise libérée Babyfoot CNV Holacratie Sociocratie Management 3.0 Innovation Lab Certification DevSexOps XxxByDesign Green Economy Développement intra-personnel SAFe
46. Simple, c’est difficile
47. La situation n’a pas vraiment changé
48. Les problèmes restent les mêmes Mécompréhension du besoin Changements business rapides Maintenabilité
49. Un logiciel répondant vraiment au besoin Ce qui part en prod c’est ce que comprennent les dev
50. Le code doit permettre à une entreprise de s’adapter
51. Vraiment pas changé !!!
52. Contrer l'obsolescence logicielle
53. Contrer l'obsolescence logicielle → les gens changent Code review Pair-programming Mob-programming
54. Contrer l'obsolescence logicielle → les technos changent Les technos changent mais le métier reste Remettons la technique au service du métier qu’elle sert
55. Contrer l'obsolescence logicielle → le contenu augmente Complexité A x Complexité B Complexité A + Complexité B
56. Notre conclusion • L’agilité sans excellence technique n’a aucun sens → Remettons le logiciel et les développeurs au centre • L’agilité ne doit pas devenir un -isme → Ne prenons rien tel quel : adaptons, partageons et utilisons notre intelligence
57. Questions ?