Charte du software craftsman

[Guillaume Lebur]

Je suis tombé l'autre jour sur un article sur Developpez.com qui faisait référence à un billet de Jeff Atwood : « The Programmer’sBill of Rights ». Il y est surtout question des droits du développeur à un cadre de travail décent, mais ça m’a donné l’idée suivante : pourquoi pas une charte du Software Craftsman ?

Contrairement au Manifesto qui est une sorte de bouteille lancée à la mer, un appel au rassemblement autour d’idées, la charte énoncerait les responsabilités et des droits de l’artisan logiciel. Un genre de code de conduite et d’éthique professionnelle comme il en existe dans d’autres métiers.

Cette charte pourrait aussi servir de document de base à approuver pour l’adhésion à l’annuaire des craftsmen dont on a parlé sur un autre thread.

Je me suis amusé à imaginer un exemple de charte en faisant la synthèse des différents points abordés dans ce groupe :

*

En tant que professionnel pratiquant la discipline du développement logiciel, il est de la responsabilité du Software Craftsman de :

 

·        Rechercher l’excellence technique afin de produire du code logiciel de haute qualité.

 

·         Transmettre à ses pairs un code chaque fois plus maintenable, assurant aux applications une grande pérennité.

 

·         Bâtir des collaborations productives avec utilisateurs et clients pour faire émerger des logiciels à forte plus-value métier.

 

·      Mettre en oeuvre des solutions techniques au juste coût et à la juste complexité en regard du contexte.

 

·      Se tenir à jour des dernières avancées technologiques pour proposer une meilleure expérience utilisateur et réaliser des choix techniques éclairés.

 

·         Améliorer continuellement sa pratique du développement à travers l’apprentissage et l’entrainement réguliers, y compris dans un cadre extra-professionnel (conférences, coding dojos, code retreats, etc.)

 

·         Participer à l’évolution de la communauté des professionnels du développement logiciel : entraide, mentoring, promotion des bonnes  pratiques de développement.

 

En contrepartie, pour mener à bien ces missions, nous estimons que tout développeur professionnel a droit :

 

·         À la prise en compte de ses recommandations et choix techniques, au même titre que tout autre professionnel.

 

·         Au temps nécessaire à la garantie d'un code de qualité (tests unitaires, revues de code...)

 

·         À un temps minimum réservé à l’amélioration du code logiciel existant (refactoring).

 

·         À des opportunités d'échanges réguliers avec les utilisateurs et les experts métiers.

 

·         À un temps minimum réservé à la veille technologique et à la formation.

·         À un environnement de travail (hardware, software et mobilier de bureau) performant et productif.

 

*

 

Qu’en pensez-vous ? Trop hardcore, pas assez ? Personnellement, que mettriez-vous dans une charte du Software Craftsman ?

 

Guillaume

[BodySplash]

Je trouve l'idée très intéressante. Ensuite c'est surtout la 2ème partie sur laquelle je tique un peu. 

"Temps nécessaire à la garantie d'un code de qualité" : toujours le vieux débat "la qualité ça coute cher". Hors la productivié d'aujourd'hui est la qualité d'hier tout ça. Bref, cette partie peut entretenir l'ambiguité que nous cherchons la qualité pour la qualité. 

Quelque chose comme 

"L'acceptation de nos estimations comme une réalité et non comme une base de négociation" ou un quelque chose dans cette veine

Dans la même veine, la partie refactoring me gène un peu. Le refactoring se pratique tout le temps, et je vois souvent le fait de le planifier comme une tâche comme une odeur. 

Sinon le reste est parfait à mes yeux :) 

[Olivier Azeau]

Oui c'est int�ressant.

Pour rappel, il existe aussi la "Software Craftsman�s Ethic" :
http://agilitateur.azeau.com/post/2010/06/22/L-%C3%A9thique-de-l-artisan-du-logiciel-%3A-proposition-de-traduction-en-fran%C3%A7ais

Mes remarques sur la charte :
- le terme "qualit�" est ambigu. Peut-on citer des caract�ristiques observables qui d�finissent cette qualit� ?
- "Transmettre � ses pairs", c'est bien mais prendre la responsbilit� du code �crit aussi longtemps que possible, c'est mieux.
- "y compris dans un cadre extra-professionnel". Cet engagement l� est-il obligatoire ? Y a-t-il une vie en dehors de l'artisanat du logiciel ? Est-on forc�ment mauvais si on limite son engagement � son temps de travail ?
- "temps minimum r�serv�" N'est-ce pas de la responsabilit� d'un artisan de faire en sorte qu'un temps r�serv� � quoi que ce soit, le soit effectivement ?
- Plus particuli�rement sur un temps r�serv� "� la veille technologique et � la formation", citons le toujours tr�s radical Uncle Bob sur "l'�thique du travail" dans Clean Coder : "You owe your employer a certain amount of time and effort. For the sake of argument, let�s use the U.S. standard of 40 hours per week. These 40 hours should be spent on your employer�s problems, not on your problems."

Olivier


Le 28/03/2012 00:55, BodySplash a �crit�:

Je trouve l'id�e tr�s int�ressante. Ensuite c'est surtout la 2�me partie sur laquelle je tique un peu.�

"Temps n�cessaire � la garantie d'un code de qualit�" : toujours le vieux d�bat "la qualit� �a coute cher". Hors la productivi� d'aujourd'hui est la qualit� d'hier tout �a. Bref, cette partie peut entretenir l'ambiguit� que nous cherchons la qualit� pour la qualit�.�

Quelque chose comme�

"L'acceptation de nos estimations comme une r�alit� et non comme une base de n�gociation" ou un quelque chose dans cette veine

Dans la m�me veine, la partie refactoring me g�ne un peu. Le refactoring se pratique tout le temps, et je vois souvent le fait de le planifier comme une t�che comme une odeur.�

Sinon le reste est parfait � mes yeux :)�

Le 27 mars 2012 21:45, Guillaume Lebur <infosa...@gmail.com> a �crit :

Je suis tomb� l'autre jour sur un article sur Developpez.com qui faisait r�f�rence � un billet de Jeff Atwood�: ��The Programmer�sBill of Rights��. Il y est surtout question des droits du d�veloppeur � un cadre de travail d�cent, mais �a m�a donn� l�id�e suivante :�pourquoi pas une charte du Software Craftsman�?

Contrairement au Manifesto qui est une sorte de bouteille lanc�e � la mer, un appel au rassemblement autour d�id�es, la charte �noncerait les responsabilit�s et des droits de l�artisan logiciel. Un genre de code de conduite et d��thique professionnelle comme il en existe dans d�autres m�tiers.

Cette charte pourrait aussi servir de document de base � approuver pour l�adh�sion � l�annuaire des craftsmen dont on a parl� sur un autre thread.

Je me suis amus� � imaginer un exemple de charte en faisant la synth�se des diff�rents points abord�s dans ce groupe�:

*

En tant que professionnel pratiquant la discipline du d�veloppement logiciel, il est de la responsabilit� du Software Craftsman de�:

�

�������� Rechercher l�excellence technique afin de produire du code logiciel de haute qualit�.

�

��������� Transmettre � ses pairs un code chaque�fois plus maintenable, assurant�aux applications�une grande p�rennit�.

�

� ������� B�tir des collaborations productives avec utilisateurs et clients pour�faire �merger�des logiciels � forte plus-value m�tier.

�

� ���� Mettre en oeuvre des solutions techniques au juste co�t et � la juste complexit� en regard du contexte.

�

�������Se tenir � jour des derni�res avanc�es technologiques pour proposer une meilleure exp�rience utilisateur et r�aliser des choix techniques �clair�s.

�

��������� Am�liorer continuellement sa pratique du d�veloppement � travers l�apprentissage et l�entrainement r�guliers, y compris dans un cadre extra-professionnel (conf�rences, coding dojos, code retreats, etc.)

�

��������� Participer � l��volution de la communaut� des professionnels du d�veloppement logiciel�: entraide, mentoring, promotion des bonnes� pratiques de d�veloppement.

�

En contrepartie, pour mener � bien ces missions, nous estimons que tout d�veloppeur professionnel�a droit :

�

��������� � la�prise en compte�de ses�recommandations et choix techniques, au m�me titre que tout autre professionnel.

�

� ������� Au temps n�cessaire �la�garantie d'un code de qualit�(tests unitaires, revues de code...)

�

��������� � un temps minimum r�serv� � l�am�lioration du code logiciel existant (refactoring).

�

� ������� � des opportunit�s d'�changes r�guliers avec les utilisateurs et les experts m�tiers.

�

��������� � un temps minimum r�serv� � la veille technologique et � la formation.

� ������� � un environnement de travail (hardware, software et mobilier de bureau) performant et productif.

�

*

�

Qu�en pensez-vous�? Trop hardcore, pas assez ? Personnellement, que mettriez-vous dans une charte du Software Craftsman�?

�

Guillaume

[Rui Carvalho]

Hello,

Je suis comme JB, j'aime bien la première partie qui apporte peut-être plus que la simple traduction du manifesto, mais je suis beaucoup moins d'accord avec la deuxième partie. 

Cette contrepartie, même si elle serait top dans l'absolu, est en contradiction avec le principe du développeur professionnel. C'est de sa responsabilité de veiller à s'améliorer, c'est sur son temps perso (aaaarg) qu'il doit s'entretenir et s'améliorer pour être le plus professionnel possible dans le cadre de l'entreprise (on ne paie pas un mec en concert pour le voir faire ses gammes par ex). 

Bon, en tout cas j'aime bien la première partie, ça c'est sur ;-)

Je me demande par contre si on arrivera à produire quelque chose de concret de toutes ces discussions cross-threads au final?

est-ce qu'il ne serait pas bon de mettre en place un grand open-space pour discuter de toutes ces questions, importantes, et d'essayer  d'en sortir quelque chose? Comme il serait difficile de réunir tout le monde en france, peut être que de réunir des groupe locaux en open space pour que chacun de ces groupes sortent des propositions nous permettra d'avancer?

Après tout, l'open space, c'est aussi avant tout un outil de production et de décision ;-)

Rui.

2012/3/28 BodySplash <bodys...@gmail.com>

[Guillaume Lebur]

Je vais essayer d'expliquer pourquoi je voyais la charte en 2 parties (responsabilités et droits). Les membres de ce groupe ont peut-être pour leur bonheur majoritairement réussi à s'extraire d'un contexte professionnel où on fabrique de la big ball of mud à tour de bras. Mais n'oublions pas qu'encore aujourd'hui dans plein de boîtes, écrire des tests c'est le mal, faire du refactoring un caprice d'artiste, se former sur des nouveautés une perte de temps, pair programmer une hérésie passible du bûcher, etc.

 

Si on se contentait d'énoncer ce qu'un craftsman doit exiger de lui-même, est-ce que tout le monde ferait automatiquement le lien avec ce qu'il est en droit d'exiger de l'organisation qui l'emploie ? Pas sûr... Du coup est-ce qu'on aboutirait pas à des réactions du style "respecte ton code d'éthique autant que tu veux, mais fais-le à iso moyens et je veux pas que ça se voie sur la productivité à court terme" ?

Je suis d'accord que le mot qualité devrait en théorie spontanément déclencher l'idée de cercle vertueux et donc de gain et non de coût. Mais ce n'est juste pas (souvent) le cas aujourd'hui. Je suis conscient que ça a un côté revendicatif, mais je vois mal comment on peut se passer de l'expliquer pour faire évoluer les choses...
Pareil pour le refactoring. Comment faire passer le concept et dire qu'il est indispensable sans le faire sortir du lot et donc forcément faire un peu oublier qu'il doit être noyé dans le flux de travail et venir naturellement ? Il y a sûrement une forme à trouver.

 

Le mercredi 28 mars 2012 10:26:54 UTC+2, oaz a écrit :

Oui c'est int�ressant.

Pour rappel, il existe aussi la "Software Craftsman�s Ethic" :
http://agilitateur.azeau.com/post/2010/06/22/L-%C3%A9thique-de-l-artisan-du-logiciel-%3A-proposition-de-traduction-en-fran%C3%A7ais

 

Merci, je ne connaissais pas ce texte. Ca recoupe pas mal de points de la charte, en mieux agencé :) Du coup elle perd un peu de son intérêt... 

 

 

- "y compris dans un cadre extra-professionnel". Cet engagement l� est-il obligatoire ? Y a-t-il une vie en dehors de l'artisanat du logiciel ? Est-on forc�ment mauvais si on limite son engagement � son temps de travail ?

[...] 

- Plus particuli�rement sur un temps r�serv� "� la veille technologique et � la formation", citons le toujours tr�s radical Uncle Bob sur "l'�thique du travail" dans Clean Coder : "You owe your employer a certain amount of time and effort. For the sake of argument, let�s use the U.S. standard of 40 hours per week. These 40 hours should be spent on your employer�s problems, not on your problems."

 

Ces deux  idées me semblent se contredire. Limiter son engagement à son temps de travail => pas de formation et d'entrainement ("your problems" si j'ai bien compris) en-dehors => pas de craftsmanship. Non ?

 

 

Le mercredi 28 mars 2012 12:18:06 UTC+2, Rui a écrit :

 

Je me demande par contre si on arrivera à produire quelque chose de concret de toutes ces discussions cross-threads au final?

est-ce qu'il ne serait pas bon de mettre en place un grand open-space pour discuter de toutes ces questions, importantes, et d'essayer d'en sortir quelque chose? Comme il serait difficile de réunir tout le monde en france, peut être que de réunir des groupe locaux en open space pour que chacun de ces groupes sortent des propositions nous permettra d'avancer?

 

+1, bonne idée. Par contre il faut trouver moyen efficace de faire la synthèse de ces propositions ce qui n'est jamais facile.

 

Guillaume 

 

[Olivier Azeau]

Le 28/03/2012 20:02, Guillaume Lebur a écrit :

- "y compris dans un cadre extra-professionnel". Cet engagement l� est-il obligatoire ? Y a-t-il une vie en dehors de l'artisanat du logiciel ? Est-on forc�ment mauvais si on limite son engagement � son temps de travail ?

[...] 

- Plus particuli�rement sur un temps r�serv� "� la veille technologique et � la formation", citons le toujours tr�s radical Uncle Bob sur "l'�thique du travail" dans Clean Coder : "You owe your employer a certain amount of time and effort. For the sake of argument, let�s use the U.S. standard of 40 hours per week. These 40 hours should be spent on your employer�s problems, not on your problems."

 

Ces deux  idées me semblent se contredire. Limiter son engagement à son temps de travail => pas de formation et d'entrainement ("your problems" si j'ai bien compris) en-dehors => pas de craftsmanship. Non ?

 

 

Oui ! Ces 2 notions sont antagonistes mais je les ai exprimées à dessein pour mettre en avant la difficulté de la chose :-)
Je connais des développeurs qui n'ont pas une passion suffisante pour leur métier au point d'aller passer une soirée dans un coding dojo mais qui sont conscients de la nécessité de la formation continue et pratiquent volontiers un kata pendant leur pause repas.
A mon avis, cela est suffisant pour être sur le chemin de l'artisanat du logiciel, même si celui sera plus long ou ne mènera pas aussi loin.

L'éthique de l'artisan logiciel est beaucoup moins prescriptive sur ces sujets là. Elle ne dit ni quand (pendant le temps personnel ou pendant le temps payé), ni où :
"nous explorons en permanence de nouvelles technologies"
"nous lisons et étudions les travaux des autres artisans"
"nous engageons activement, avec les autres artisans, dialogue et pratique"

Olivier

[Rui Carvalho]

J'aime beaucoup la traduction de l'éthique de l'artisan que je n'avais pas lu non plus et effectivement cela va tout à fait dans le sens de la proposition de la première partie de la charte de Guillaume (avec un coté plus romanesque comme dirait Thierry Cros à propos du manifeste agile ;-)

Le point sur la difficulté d'être artisan en entreprise est parfaitement juste malheureusement mais la réponse donnée par Olivier est très importante aussi. Je suis complètement partisan du fait que un peu ce soit mieux que rien auprès de beaucoup de personnes. Je suis absolument contre les discussions élitistes de toute façon et amener plus de monde un peu plus haut est beaucoup plus enrichissant.

A mon sens, les principes repris par les artisans logiciel sont très proches de ceux prônant l'agilité (pour ne pas dire identiques) mais avec un coté plus axé sur le métier même du développeur, sa personne et sa carrière alors que l'agilité en général est plus une question de moyens, d'équipe et d'organisation. L'agilité commence à rentrer dans les moeurs et surtout à s'étendre car elle montre ses preuves. La condition du développeur professionnel prendra très certainement encore plus de temps à se démocratiser mais se fera d'autant mieux que les organisations en place on déjà intégré l'agilité et l'importance de la qualité. 

Le fait d'être un artisan dans une structure non-bisounours ramant contre vents et marées, entrainant ses petits camarades dans un petit kata le midi, peut être très moteur pour toute l'équipe. Et pourquoi pas une petite session de pair programming discretos?

Au sujet du temps pris par l'artisan pour s'entretenir pendant ses heures de travail ou pas, je suis partisan du double demi effort ;-). je m'explique. 

Oncle Bob, nous dit qu'étant supposé une semaine de 40h salarié on devrait prendre 20h perso pour s'améliorer.  Hum bien, mais à coté de ça il explique qu'il n'est pas anormal de faire un peu plus en période critique et que lui meme s'est souvent fait des semaines de 70-80h. ça veut dire que les 20h, déjà c'est pas toutes les semaines. Mais surtout faire 3h de coding après le taf prend une dimension toute différente quand on est dans un bled aux us et qu'on est à 17h à la maison et qu'on rentre à la maison à 21h parce transport et autres joyeusetés...pareil, suivant que l'on a une femme et des enfants, les libertés ne sont pas les mêmes que si on est célibataire. Donc pour moi, s'investir 5-10h par semaine répartis entre le soir et le midi au travail par exemple c'est déjà très bien. 

Pour ce qui est de l'open space, je suis très confiant qu'il en ressortirait beaucoup de choses si cela peut se faire ;-)

Rui.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 

* Mob        ›› +33610047040

* Blog (fr)   ›› http://www.rui.fr 

* Home      ›› http://www.artofnet.com

* Twitter     ›› @rhwy

* G+          ›› https://plus.google.com/117394683250045815434

* LinkedIn  ›› http://fr.linkedin.com/in/ruifr

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 

2012/3/28 Olivier Azeau <olivie...@gmail.com>

[Jean-Baptiste Dusseaut]

Je suis pour garder la deuxième partie, elle me semble indispensable. Je proposais juste quelques remaniements :) 

-- 

Jean-Baptiste Dusseaut