Publié par

Il y a 4 années -

Temps de lecture 3 minutes

Chapitre 14 du livre de Sandro Mancuso sur le Software Craftsmanship

sandro_book-xebia.png

Comme chaque semaine, nous vous proposons un résumé d’un chapitre de l’excellent livre de Sandro Mancuso Software Craftsmanship – Professionalism Pragmatism Pride. Nous vous proposons cette semaine le résumé du chapitre 14 décrivant comment amener un changement technique dans un projet.

Si vous êtes intéressés par la vision d’un craftsman sur son logiciel, vous pouvez retrouver Sandro dans le catalogue de formation de Xebia Training.

Déjà publié :

  1. Software Development
  2. Agile
  3. Software Craftsmanship
  4. The Software Craftsmanship Attitude
  5. Heroes, Goodwill and Professionalism
  6. Working Software
  7. Technical Practices
  8. The Long Road
  9. Recruitment
  10. Interviewing Software Craftsmen 
  11. Interview Anti-patterns
  12. The Cost of Low Morale 
  13. Culture of Learning

Driving Technical Changes

L’attitude du craftsman

Les changements techniques sont souvent plus difficiles à faire adopter par les développeurs que les managers.

Avant de pousser au changement il faut savoir à qui on s’adresse :

  • le non-informé,
  • le timide/suiveur,
  • le cynique qui refusera tout en bloc,
  • l’expérimenté déçu qui a déjà tenté mais a une mauvaise expérience,
  • l’occupé qui n’a jamais le temps,
  • le manager avec lequel il faut reformuler les arguments,
  • l’irrationnel,
  • l’indifférent,
  • l’aigri qui dira tout le temps : je vous l’avais dit,
  • l’inapte,
  • l’architecte dans sa tour d’ivoire,
  • l’inquiet,
  • le fanboy.

Vous devez être courageux, honnête, transparent, employer un vocabulaire adapté à votre interlocuteur, exposer vos idées simplement, être sûr de vous, respectueux et écouter les arguments.

Par où commencer ? Il est nécessaire d’établir un climat de confiance : délivrer un logiciel de qualité, bien-sûr, mais également faire part de sa passion, se rendre visible et être bon.
Ne brûlez pas les étapes : pour convaincre il faut que vous soyez convaincu par ce que vous voulez changer. Convaincu et expert dans ce domaine.
Quoi de plus naturel pour promouvoir une technique ou une pratique que de démontrer qu’elle fonctionne en pairant avec un collègue ou en l’utilisant soi même ?

Il est impensable de vouloir tout changer en même temps. Il faut évaluer les chantiers les plus pertinents et se focaliser sur eux.

Les actions à mettre en œuvre

Une fois identifiés, ces chantiers peuvent être amenés petit à petit. L’équipe peut essayer tel ou tel changement durant une itération et décider par la suite. Il est important de donner un pouvoir de décision à tous les membres de l’équipe pour que l’adoption soit efficace.

La peur et l’incompétence sont les freins majeurs à l’amélioration. Lorsque vous identifiez quelque chose qui peut être amélioré dans votre société, n’ayez pas peur de provoquer ce changement tant que vous êtes suffisamment compétent et motivé pour le mener à bien.
Dans le cas de tâches purement techniques, il ne faut pas demander l’avis de votre manager. Son objectif est que le logiciel que vous livrez réponde au besoin du client. Toute tâche technique que l’équipe considère comme indispensable pour atteindre cet objectif doit être menée à bien et c’est la responsabilité de l’équipe et non celle de votre manager de prendre la décision de l’exécuter.
Comment convaincre mon équipe d’utiliser le TDD pour développer ? Le plus simple est de choisir la personne la plus enthousiaste et de lui montrer par une séance de pair programming sur une vraie tâche comment on peut prendre du plaisir à utiliser cette technique.

Quels sont les profils qui vous poseront le plus de problème ?

L’architecte car il a la responsabilité des décisions qu’il prend pour toutes les équipes mais qu’il n’est pas redevable de ses décisions. Une équipe de software craftsmen souhaitera toujours avoir la liberté de prendre toutes les décisions qu’elle juge nécessaire pour aboutir à un logiciel de qualité et endossera les conséquence de ses décisions.
L’aigri : la meilleure solution consiste à essayer de leur insuffler à nouveau de la passion.

Un software craftsman n’est pas simplement un excellent développeur. C’est également un modèle pour les développeurs moins expérimentés ainsi qu’un professionnel responsable qui délivre une solution complète qui satisfait pleinement son client.

Publié par

Publié par Sébastian Le Merdy

Sébastian est entré chez Xebia en 2011 pour mettre en pratique le Software Development Done Right.
Il est passionné par le développement logiciel et les technologies innovantes et le met au service de l'utilisateur final à travers l'agilité dans les projets.
Vous pourrez peut-être le rencontrer lors d'un coding dojo ou une présentation de live coding.

Commentaire

1 réponses pour " Chapitre 14 du livre de Sandro Mancuso sur le Software Craftsmanship "

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.