Si le code n'est pas le problème alors pourquoi se focaliser dessu ?

[Antoine Cezar]

L'essentiel des problèmes ne viens pas du code. Alors pourquoi n'a-t-on que des pratiques centrées sur le code ?

[Gaspard POINTEAU]

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. 

[Antoine Cezar]

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…
 

[Olivier Azeau]

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

--
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 software-craftsmanshi...@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Gregory Salvan]

+1 OAZ

il y a un livre aussi sur  gamestorming.
si je me trompe pas il n'y a pas "event storming" 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 :)

[Antoine Cezar]

@OAZ les agiles games ne font pas partie me semble-t-il des pratiques au sens où on les pratiquerait. Les agile games comme les exercices de communication non violente et autres existent mais ne font pas partie intégrantes des discussions et dojos (de ce que j'ai peu en voir jusque là). Sans doute que la plus part des SoCrates sont amené à s'y intéresser et à en pratiquer, mais c'est toujours dans la communauté « agile ». Ça n'est pas un tout intégré dans SoCra où en tout ça c'est loin, me semble-t-il, d'être mis au même niveau que les pratique liées au code.

@Grégory je n'ai que très brièvement survolé sa méthode. C'est surtout l'aspect réfléchir plus avant de coder qui m'a parlé pour en avoir fait les frais. Mais comme partout il y a un curseur à ajuster entre je découvre complètement en codant et je découvre tout (ou du moins essaye) avant de coder. En fonction des cas la réflexion préalable peut être plus ou moins poussée.

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse software-craftsmanship-toulouse+unsubscribe@googlegroups.com.

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 software-craftsmanship-toulouse+unsubscribe@googlegroups.com.