Borghi scrum day-s

893 vues

Publié le

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
893
Sur SlideShare
0
Issues des intégrations
0
Intégrations
63
Actions
Partages
0
Téléchargements
29
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Borghi scrum day-s

  1. 1. Mettre en œuvre SCRUM : ScrumDay Paris 27 mars 2012 Bruno Borghi Akeirou
  2. 2. Mercià nos sponsors Platinum 2
  3. 3. Et mercià nos sponsors Gold et Silver 3
  4. 4. système social managementingénierie système technique Développer un produit, c’est simultanément construire et faire fonctionner deux systèmes indissociables : un système social et un système technique. 4
  5. 5. La constructionet le fonctionnement du système social génèrent 5
  6. 6. Par exemple, 6
  7. 7. 7
  8. 8. 8
  9. 9. Pourquoi y a-t-ildes sujets qui fâchent ? 9
  10. 10. Les connaissances, les convictions,les croyances sur la marche de l’entreprise s’affrontent Objectifs Efficacité Pertinence Résultats Efficience Moyens 10
  11. 11. Démarche générale de traitement des sujets qui fâchent• Accueillir chaleureusement tous les sujets qui fâchent, d’où qu’ils viennent – Reconnaître la légitimité des désaccords• Créer les conditions d’un dialogue entre les protagonistes sur ces sujets• Considérer ces sujets comme des obstacles à lever progressivement 11
  12. 12. Revue desujets qui fâchent 12
  13. 13. Les estimations• Les demandes d’estimations sur un périmètre fonctionnel flou, voire inconnu• La précision attendue par le business pour les estimations• Les estimations « macro » en story points 13
  14. 14. Pour calmer le jeu• Le business comprend les estimations en charge et en délai – Ne pas les énerver inutilement avec nos histoires de story points• Le business veut estimer un retour sur investissement et une date de disponibilité – Faire des chiffrages « macro » à la mode analytique – Fournir des chiffrages uniquement sous forme de fourchettes 14
  15. 15. Pour calmer le jeu• La technique a besoin d’un périmètre clair pour chiffrer – Organiser les besoins en Sagas, Épopées, Histoires – Chiffrer au niveau Épopée – Pour chaque épopée, instituer une conversation entre business et technique pour préciser le périmètre • Appeler ces conversations « Réunions de cadrage » 15
  16. 16. 16
  17. 17. Le planning, la valeur business• « Ce sera fait pour quand ? » – « Ce sera fait quand on en sera là dans le Product Backlog » – « Cela dépend des priorités entre le business B2B et le business B2C »• « Et si j’augmente la valeur business, ce sera fait avant ? »• « C’est super-urgent. Vos sprints, ils sont trop longs. » 17
  18. 18. Pour calmer le jeu• La transparence est clé – Afficher une Roadmap en fiches Bristol dans le bureau du Product Owner – Rester ferme sur la durée des sprints• Les différentes lignes de business en concurrence ont besoin d’une instance pour négocier les priorités – Instaurer une cérémonie du genre « Comité d’Orientation Roadmap » 18
  19. 19. 19
  20. 20. Les coûts• « La moindre fonctionnalité nous coûte trop cher ! »• « Vous ne prenez pas assez de fonctionnalités dans un sprint ! » 20
  21. 21. Pour calmer le jeu• Augmenter la qualité – User stories au format standard – Contrôles croisés fréquents• Ramener le débat sur la question des coûts complets Développement + correction des bugs en cours de mise au point + recette + incidents de production + correction des bugs après déploiement 21
  22. 22. Pour calmer le jeu• Remplacer la réduction des coûts par la réduction des gaspillages – Expliquer au business et à la technique les 3 M • Muda (gâchis) • Mura (variabilités entraînant des stocks) • Muri (excès) 22
  23. 23. La dette technique• Pour la technique : un cauchemar• Pour le business : un truc de développeur pour se faire plaisir plutôt que de développer des nouvelles fonctionnalités 23
  24. 24. Pour calmer le jeu• Mettre des items de dette technique explicitement au backlog Visible Invisible + Evolutions Valeur Fonctionnalités architecture / Business infrastructure Positive - Valeur Anomalies Dette Technique Business Négative 24
  25. 25. L’équipe auto-organisée• Qui prend les décisions ? – 2 tendances cohabitent souvent • Tendance à prendre des décisions techniques par un processus supposé démocratique – Immobilisme • Tendance à ce que chacun n’en fasse qu’à sa tête – Désordre• Qui est le chef ?• Qui fait passer les entretiens annuels ? 25
  26. 26. Pour calmer le jeu• En tant que coach, être directif – Quand il le faut …• Redonner du sens à la vie de ceux qui étaient chefs 26
  27. 27. SCRUM• « Pourquoi on fait SCRUM ? On pourrait simplement faire de l’agile ! »• « On n’a pas besoin de faire tout SCRUM ! »• « On n’a pas besoin d’un Product Owner ! »• « On n’a pas besoin d’un Scrum Master ! » 27
  28. 28. Pour calmer le jeu• Former le maximum de monde à SCRUM – Le business comme la technique – Si possible, tous Certified Scrum Master• Faire des sessions d’information SCRUM avec ceux qui ne sont pas formés et qui sont un peu périphériques 28
  29. 29. En conclusion,lors du déploiement de SCRUM, il y a des foyers permanents de tensions entre la direction, le business et la technique Quand ces foyers de tensions n’existent pas, il vaut mieux s’inquiéter … 29
  30. 30. Merci de votre attention

×