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, communicationIl 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] <mailto:[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 .
