En Finir Avec ...
•
0 gefällt mir•1,091 views
L'agilité est en pleine expansion. Nombreux sont les projets, nombreuses sont les sociétés qui l'adopte ! Nous devons nous féliciter de cet engouement, et pourtant … Pourtant cette adoption croissante n'est qu'apparence dans certains cas. Dans plus en plus de cas, même. Si Scrum est aujourd'hui l'approche qui fédère le plus, les quelques idées centrales de la méthode sont de plus en plus souvent dévoyées. Il en va de même d'autres pratiques agiles. Ah ! Vous faites du Scrum, je vois que vous avez un P.O. et un Scrum Master. Vous n'avez plus de cahier des charges mais des User Stories, donc tout va bien. Cocher la liste des pratiques agiles en repeignant plus ou moins les vieilles pratiques ne convient pas, il faut en finir avec cela ! Dans cette courte session, je vous propose de faire la peau à 3 pratiques : la Roadmap, le Product Owner et les User Stories. Mais vais-je vraiment les assasiner ? Pour le savoir il vous faudra assister à ce lightning talk !
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie En Finir Avec ...
Ähnlich wie En Finir Avec ... (20)
Mehr von Christophe Addinquy
Mehr von Christophe Addinquy (19)
En Finir Avec ...
- 1. Vieux Fatigue Monotonie 05/05/09 www.agiletour.com
- 2. 2
- 3. En finir avec ... Christophe Addinquy Vidal Novembre 2012
- 4. Product Owner Backlog User Story 4
- 5. 5
- 6. 5
- 7. Vente Pénétration Fidélisation Stratégie Volatilité marché Risques Positionnement concurrence Savoir Alliances métier Opportunités Développement de «verticales» Segmentation marché Maturité Domaine d’activité Profils utilisateur 6
- 8. Vente Pénétration Fidélisation Stratégie Volatilité marché Risques Positionnement concurrence Savoir Alliances métier Opportunités Développement de «verticales» Segmentation marché Maturité Domaine d’activité Profils utilisateur 6
- 9. 7
- 10. 8
- 11. 9
- 12. 10
- 13. 11
- 14. Le changement il ne passera pas par moi ! 11
- 15. 12
- 16. 12
- 17. 13
- 18. 14
- 19. 14
- 20. « La promesse d’une conversation » 14
- 21. +A cce pta tes nce ts ! « La promesse d’une conversation » 14
- 22. 15
- 23. Arbre de décision Service- Design Thinking Oriented Domain Driven Design requirements Analyse Biais cognitifs Story boards UML structurée Personas Collaborative reqt. Programmation gathering Archéologie Contextual neuro- documentair inquiry linguistique Analyse causale e Questionnement Business case Exigences Problem frames non- fonctionnelles Stakeholders taxonomy Story maps Analyse système Spécifications formelles Creativity Social modeling Agent- worksho oriented p Usability engineering requirements Mesures EARS Contraintes Stakeholder Vision s Liespotting Screenwriting Brainstorming assessment Integrated requirements engineering Analyse de risques Analyse Cartes CRC Event-oriented reqt. contextuell Prototypage e Analyse quantitative Reqt. driven design Liste d’attributs Card sort Modèle Product features HCI analysis Gap analysis BPM Glossaire de Kano Use Cases Modèle de Analyse cognitive Pyramide de Leffingwell traçabilité Goal modeling Use Cases maps Mind maps Elevator statement 15
- 24. 16
- 25. 17
- 26. 18
- 27. 18
- 28. Merci ! addinquy@computer.org @addinquy http://addinquy.tumblr.com enFinirAvec addinquy addinquy addinquy addinquy 19
Hinweis der Redaktion
- Sommes-nous devenus vieux ?\nNous les appliquons parfois nos pratiques agiles comme nous appliquions les recettes de nos anciens processus, sans plus nous poser de questions ou les remettre en cause.\nQuand avez-vous réfléchis à vos pratiques pour la dernière fois ? Vraiment réfléchi ! A ce qu’elles apportent et à leurs conséquences.\n
- Tirer avec une arme c’est aussi subir son recul. \nSi le canon est très gros, les dégâts sont plus importants, comme l’est le recul.\nNos pratiques agiles sont des armes redoutables, ne devrions-nous pas nous intéresser à leurs effets secondaires ? Ne pourraient-ils pas être plus redoutables que leurs bénéfices ?\n
- \n
- Mes victimes du jour seront :\n- Le Product Owner\n- Le backlog\n- Les user stories\n\n
- Mon histoire commence lors d’une démo. A la fin de celle-ci, le P.O. déclare « vous avez fait du bon boulot ». Cela semble bien aller, c’est du feedback positif, de l’encouragement.\nEt pourtant cela a déclenché une sonnette d’alarme chez moi !\nPourquoi « vous avez fait du bon travail » et non « NOUS pouvons être fiers de nous » ? Pourquoi se positionner hors de l’équipe ?\nC’est lié à Scrum\nScrum définit 3 rôles (SM, PO, équipe). J’y vois quand même 2 faiblesses principales :\nUne concession aux anciennes pratiques managériales : cadrer un rôle c’est déresponsabiliser cette personne par rapport à l’objectif du projet. Scrum ne dit pas cela et dit même l’inverse. Mais à partir du moment où on définit des rôles, il faudra faire avec le biais que cela induit.\nScrum est surtout définit par rapport au développement logiciel. Le rôle de l’équipe est clair. Celui du SM, garant du processus l’est aussi. Celui du P.O. l’est-il tout autant ?\n\n
- Si on essaie d’avoir une vue globale sur les rôles et les savoirs du PO, on voit qu’ils sont très divers.\nJe suis un ardent défenseur de la poly compétence dans les équipes. Mais là, on est bien au-delà de ça !\n
- Ne nous voilons pas la face : Scrum a définit des rôles au niveau du développement. Le P.O doit se débrouiller avec ce qui reste, quoi que ce soit.\nMais il y a pire : ce cloisonnement des rôles induit des comportements entre l’équipe et le PO. N’avez-vous jamais entendu votre équipe dire :\nOn ne peut commencer à travailler que quand on a un backlog détaillé de bonne qualité.\nIl faut que le PO fasse son travail.\nAlors le P.O., c’est mal ?\n
- Non, c’est bien.\nAvoir quelqu’un qui donne la vision, donne du sens : c’est un vrai vecteur d’énergie et de réussite pour un projet. Ce n’est pas un comité ou des personnes éparses à consulter, mais une personne qui tient les rennes et qui tranche.\nMais ne tombons pas dans l’écueil de « moi je fais ça, toi tu fais ça »…\n\n
- Le backlog, parlons-en !\nOn se donne de la perspective sur ce que nous pensons aujourd’hui que notre produit doit couvrir. En on le fait de manière synthétique.\nMoi ça m’aide d’avoir de la perspective, même sur des choses que je ne vais pas faire sur les deux prochaines itérations, même si toute l’information n’est pas sèche.\nDans l’immédiat, quand je débute une itération où je ne dépilerais que 3 items q’un backlog qui en compte 50, à quoi me servent ces 50 lignes ? Eh bien essentiellement à m’assurer que les 3 items les plus importants ne sont pas dans les 47 restants !\nMais le backlog, c’est aussi…\n
- … Du stock !\nEt le Lean nous dit : le stock, c’est Mal ! Pourquoi ? Dans le cas présent, surtout parce que l’on va travailler pour mettre des items qui ne seront peut-être même pas dépilés. Et ensuite parce que les items seront (pour beaucoup d’entre-eux) pris tellement après avoir été mis dans le backlog qu’il faudra se remémorer tout le contexte.\nMais s’il n’y a que ça, je veux bien payer le prix. Mais il y a pire. Un pire qui n’est pas dans le backlog mais dans des biais comportementaux qu’il induit.\n
- Scrum embrasse le changement. Le feedback doit nous amener à reconsidérer nos idées initiales. Parfois profondément.\nSeulement quand on a travaillé dur à faire un backlog, on va être moins enclin à le remettre en cause, à fortiori de manière radicale. On ne va donc peut-être pas embrasser ce changement comme on devrait.\n
- « On va commencer par faire un backlog complet » : peut-être avez-vous déjà entendu cette phrase ?\nHélas, c’est le début de la fin. Vous êtes déjà dans le mode de pensée que nous avions avant : un périmètre fini, des estimations de l’ensemble qui deviennent des engagements et une date de livraison pour ce périmètre. Bref, on fixe tout à la waterfall, bien déguisé en agile.\nAlors le backlog, c’est mal ?\nNon, c’est bien.\n
- J’aime bien avoir un backlog : il me donne sous une forme synthétique :\n- De la perspective sur le projet\n- Les spécifications à grosse maille\n- Un outil de gestion du projet\n- Un support de spécification des tests\nMais ne tombons pas dans l’écueil du cahier des charges déguisé !\n
- Voyons de plus près les « user stories » qui sont devenues le standard des spécifications dans le monde agile.\nUne User story c’est « en tant que … je veux … afin de … »\nDéjà, tout le monde ne fait pas l’effort de suivre ça. Mais en plus à la base ce n’est pas ça !\nA la base c’est ça ! Simplement un pense-bête ... avec des tests d’acceptance\n\n
- Voyons de plus près les « user stories » qui sont devenues le standard des spécifications dans le monde agile.\nUne User story c’est « en tant que … je veux … afin de … »\nDéjà, tout le monde ne fait pas l’effort de suivre ça. Mais en plus à la base ce n’est pas ça !\nA la base c’est ça ! Simplement un pense-bête ... avec des tests d’acceptance\n\n
- Voyons de plus près les « user stories » qui sont devenues le standard des spécifications dans le monde agile.\nUne User story c’est « en tant que … je veux … afin de … »\nDéjà, tout le monde ne fait pas l’effort de suivre ça. Mais en plus à la base ce n’est pas ça !\nA la base c’est ça ! Simplement un pense-bête ... avec des tests d’acceptance\n\n
- Nous avons créé un formalisme plus simple, plus léger. Et nous allons voir les utilisateurs avec notre calepin sous le bras !\n- A quel moment êtes-vous remonté à l’essence du problème ?\n- Avez-vous vérifié l’adéquation du besoin avec les objectifs du projet ?\n- Et d’ailleurs, êtes-vous certains d’avoir capturé un besoin et non ce que l’utilisateur pense être une solution ?\n- Etes-vous rentré dans le processus métier pour comprendre comment ce besoin s’y inscrivait ?\nJe vous épargne une litanie qui pourrait être longue.\nCertes l’étape ultime est d’arriver à saisir cette story. Mais cela ne se limite pas à griffonner 3 mots sur un bout de carton.\nCe n’est pas assez bien !\nC’est très loin d’être suffisant !\nVous pensez connaître votre métier car vous connaissez cette seule technique ? Je pourrais passer le reste de la journée à en évoquer quelques autres qui pourraient, devraient compléter notre boite à outil dans ce domaine.\nL’ingénierie des besoins est riche de plusieurs décennies de connaissances et de recherches.\n\n
- La littérature sur ce domaine compte certains des meilleurs livres d’informatique que j’ai pu lire.\nAlors les users stories, c’est mal ?\n\n
- Non c’est bien !\nElles nous ont permit de sortir du carcan de la spécification rédigée pour aller vers le vrai travail de compréhension du besoin.\nMais ne tirons pas un trait sur le corpus de connaissances et de techniques qui peut nous aider dans notre travail. Et qu’il ne faut pas hésiter à aller chercher au-delà des murs de l’agilité.\n\n
- Les techniques agiles ne sont pas des remèdes miracles qui vont nous guérir de tous nos maux sans que nous ayons à nous soucier de quoi que ce soit.\nAucune des techniques évoquées ici n’est mauvaise. En fait, je vous les recommande chaudement et avec enthousiasme.\nGéry Derbier me faisait remarquer qu’elles devraient être prescrites comme des médicaments :\nChacune soigne efficacement un ou plusieurs maux.\nMais il faudrait en signaler aussi les précautions d’emploi, les mises en garde, voir les effets secondaires !\nSommes-nous devenus vieux ?\nNos pratiques nous aident-elles, sont-elles réellement agiles ? Ou avons-nous dérivé peu à peu au point qu’elles soient devenues des justifications ?\nPour vous qui débutez, c’est plus difficile à discerner. Mais il appartient à ceux qui vous accompagnent de le faire pour vous.\n\n
- \n