+1 OAZ il y a un livre aussi sur gamestorming. si je me trompe pas il n'y a pas "event storming <http://ziobrando.blogspot.fr/2013/11/introducing-event-storming.html>" dans les refs d'OAZ qui est particulièrement efficace.
Sur la démarche de l'article que tu as cité Antoine, je voudrais juste rappeler quelques points: - on livre de la valeur et pas des exigences. dans sa méthode c'est limite, ça peut devenir confus. - a mon avis il parle d'un paradigme d'apprentissage/ découverte du domaine différent. Il est dans une démarche béhaviouriste alors que les méthodes agiles sont nettement plus connectivistes (Stephen Downes, Lev Vygotsky, Piaget). Je veux dire par là qu'on a pas la même connaissance du domaine au début d'un projet, au milieu ou a la fin, on va le découvrir en confrontant notre vision à la réalité par différente boucles de feedback en délivrant de la valeur. Plus la boucle de feedback est courte et moins on risque de décalage entre notre vision et la réalité. Chaque nouvelle découverte va nous pousser vers une solution, si la découverte est trop grande, l'effort à fournir peut être trop important. - sur le property based testing: Antoine Vernois insiste bcp sur le fait d'avoir une seule assertion par test et je suis plutôt d'accord avec lui, ça permet de retrouver plus vite ce qui s'est cassé lorsque ça arrive. L'autre aspect qui me semble important, c'est que lorsque tu reprends le code de quelqu'un d'autre ça permet de rentrer plus facilement dans sa logique (le "comment est il arrivé a cette solution?"). C'est nettement moins flagrant avec le property based testing. Enfin, je n'ai vu aucun agiliste dire qu'il fallait se jeter sur le code sans réfléchir :) Le 3 avril 2016 à 18:38, Olivier Azeau <[email protected]> a écrit : > Il existe beaucoup de "katas" pour "soft" skills. > > Quelques liens : > http://tastycupcakes.org > http://gamestorming.com/ > http://www.agilegamesfrance.fr/index.php?title=Jeux > > Olivier > > > On 03/04/2016 15:46, Antoine Cezar wrote: > > il ne parle que très peu de code, mais beaucoup de courage, confiance, >> communication >> > Il n'y a pourtant pas d'exercices autres que ceux portant sur le code. Et > si certaines contrainte débordent du cadre de code les exercices restent > centrés sur le code. > Ya pas un « kata j'ai pas le temps » por s'entrainer avec un collègue dont > l'excuse est de n'avoir pas le temps. Pas de « kata bien formuler une > critique », « Kata comment recevoir une critique » (et celle là est > fichtrement nécessaire dans ce monde de likes only), « Kata comment parler > aux non techos », etc… > > Le dimanche 3 avril 2016 15:35:48 UTC+2, Gaspard POINTEAU a écrit : >> >> Je dirais qu'il n'y a pas que des pratiques centrées sur le Code. En >> lisant Extrème Programming Explainned de Kent Beck, j'ai été surpris qu'au >> final il ne parle que très peu de code, mais beaucoup de courage, >> confiance, communication... >> >> Après, dans la pratique, souvent il est facile de changer des pratiques >> au niveau du code. Les devs comprennent facilement l'intérêt de faire du >> code propre, puis des tests. Faire comprendre l’intégration continue, >> l'automatisation, ça parle. Faire des codings dojos, des présentations >> techniques, c'est jouable. >> >> Le soucis, c'est justement au dessus : il y a plein de pratiques pour >> changer les façons de discuter avec le client, de prendre des décisions, >> d'organiser le temps de travail... mais c'est des problématiques qui ne >> concernent plus qu'une population de personnes (les devs, aux sens larges), >> mais plusieurs : dev, clients, utilisateurs, rh, commerciaux, qualité... Et >> ces autres populations n'ont pas forcément le même but, ni la même façon de >> travailler, ni la même "culture". >> Et d'un point de vue pratique : 10 devs dans le même open-space, c'est >> facile de discuter des pratiques. 3 devs + 3 utilisateur + un responsable >> achat client + un commercial + etc, c'est des gens qui ne sont pas tous >> au même endroit au même moment. >> >> Et surtout, ça oblige chacun à se remettre en question. Et j'ai un peu >> l'impression que c'est là que ça bloque : tant que l'équipe de dev >> s'auto-organise, très bien, par contre quand elle tente de "contaminer" le >> reste de l'entreprise avec ses idées, là, ça passe ou ça casse. >> >> Après, peut être aussi que, une certaine hiérarchie tacite faisant que >> les devs étant considéré comme le bas de l'échelle par le management, si >> les idées d'amélioration et de changement viennent d'un coach extérieur >> (payé cher, donc compétent) c'est plus efficace que si ça vient de la base. >> >> >> >> >> >> On Sunday, April 3, 2016 at 12:48:42 PM UTC+2, Antoine Cezar wrote: >>> >>> L'essentiel des problèmes ne viens pas du code. Alors pourquoi n'a-t-on >>> que des pratiques centrées sur le code ? >>> >> -- > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes > "Software Craftsmanship Toulouse". > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le > concernant, envoyez un e-mail à l'adresse > [email protected]. > Pour obtenir davantage d'options, consultez la page > https://groups.google.com/d/optout. > > > -- > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes > "Software Craftsmanship Toulouse". > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le > concernant, envoyez un e-mail à l'adresse > [email protected]. > Pour obtenir davantage d'options, consultez la page > https://groups.google.com/d/optout. > -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Software Craftsmanship Toulouse. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
