> > 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 plus d'options, visitez le site https://groups.google.com/d/optout .
