Software Craftsmanship

J’adhère complètement mais le craftmanship ne serait-il pas le Don Quichotte des SSII?

Bravo ! Je trouve que tu as vraiment la bonne approche pour prendre un certain nombre d’idées dans l’air du temps et les présenter à ta manière, pour leur donner plus de visibilité, aider à leur diffusion.

Les méthodes évoluent petit à petit, elles convergent jusqu’à être intégrées par de plus en plus de personnes, et que de nouvelles pratiques émergent, à diffuser de nouveau.

A noter, un mouvement que j’ai découvert récemment et que me paraît intéressant de suivre (même si à priori ça n’est pas directement lié à l’informatique) : « Employee first, customer second » (bouquin : http://www.amazon.com/Employees-First-Customers-Second-Conventional/dp/1422139069 )

Je vois un argument MAJEUR à ce coté « Artisan » !

Bientot une emission sur M6 avec 3 juges (1 black costaud, 1 gros sympa, 1 tout sec sévère avec des lunettes) qui tailleront des costards à des candidats par qu’ils sont oublié un « ; » ou parleront de « génie du software » a celui qui aura combiné 3 design patterns de façon créative !

Je ne vous parle même pas de la présentation assurée par Stéphane Plazza qui en profitera pour se faire refaire son logiciel de gestion d’appartements en disant (« et oui, le D dans DDD, ca veut dire domain…et là on commence par l’immobilier ! ») pendant que les bambins des candidats seront gardés par la nouvelle supernany !

Ca correspond tout à fait à ma vision du métier et c’est à l’exact opposé de ce que j’ai pu vivre en dehors des PME… je pense que la notion d’artisanat est fondamentalement liée à la nature des logiciels, mais même avec la meilleure volonté, ces efforts n’ont strictement aucun sens sans que l’utilisateur final lui-même s’implique fortement dans la définition des solutions.

Encore un article intéressant. Je vais le faire tourner à nos « décideurs », histoire de réveiller quelques une de ces idées mises en retraits par manque de temps à y consacrer.

Merci.

@Luc : Très curieux de découvrir ce que ce deck peut donner.

Bonjour,

L’article est de qualité et je souscrit à beaucoup des idées qui y sont exposées.

Je n’ai pas lu la version originale du craftmanship.

Ceci dit mon expérience de CP (encore les mains dans le développement) me pousse à réagir à certains de vos COMMENTAIRES. Ca ne vous concerne pas tous, mais c’est une tendance de fond.

Se reconnaîtrons ce qui le voudrons bien, et ceux-là je dis :

– 1 –

Encore une fois vous opposez toutes les méthodes de management de projet à SCRUM ou encore à des dérives de SSII.
Je suis CP, et comme n’importe quel manager je conçois que les développeurs sont humains et ont leur caractère ce qui les rends différents.

Donc j’uniformise pas à grand coup de CMMI etc etc
Par contre je me sert d’outil comme les COPIL, les reportings, etc etc, c’est utile parce que sinon un (beaucoup ok) développeur ne finit jamais rien.

Avant que vous me sortiez une réflexion de type : « tu développes pas… » ben si je développe. ça existe aussi, et plus souvent que beaucoup ne veulent le voir. Ce sont 2 activités différentes et à dissocier.
L’expérience de l’une influence l’autre, et vice-versa.

– 2 –

Je réagis à « En SSII, le commercial va vous placer en fonction de mots clefs … ».

Effectivement, il va faire ça.

Mais rien ne vous empêche, à l’instar de beaucoup d’autres professions, de faire un peu de commerce, de management, … etc etc, et ainsi à commencer de vous abstraire de la bande d’incompétents qui nous pourrissent à tous la vie.

Ce sont des postes intéressants : autant que les vôtre.
Il faut souvent méditer sur une réflexion très terre à terre : peut-on être aimer si on ne s’aime pas soi même. Je pense qu’il y a beaucoup d’humilité mélée à trop d’égo dans la profession : bref de grands paradoxe à résoudre.

Conclusion : un peu de tolérance, mais surtout un peu plus de courage pour se mettre en avant à chaque fois que vous sentez qu’on brade votre travail.
Rien dans la loi ne vous interdit de vous immiscez dans les affaires des commerciaux : testé en vrai.
Souvent, après avoir justifié que si la frontière de compétence est poreuse dans un sens, elle est aussi dans un autre.

Ca sert aussi parfois de se défouler, ce qui est pas une honte et même salutaire : on accumule, on accumule et on finit chez prozac Inc. ou on finira tous freelance (no offense au freelance, mais y aurait un débat là aussi).

Je serai heureux d’échanger avec vous là-dessus.

Je savais que mon passage sur les commerciaux des SSII ferait réagir. Dans mon message, j’essaye de rester factuel et je parle en général.

Et pour ceux qui souhaitent vraiment en savoir plus sur le mondes des SSII, je recommande la lecture de « Derriere l’écran de la révolution sociale » de Nicolas Sené ou d’aller visiter le MUNCI (http://munci.org/).

Regardez les offres d’emploi des SSII (les autres aussi), JAMAIS vous ne trouverez quoi que ce soit en rapport avec craftmanship.

C’est d’ailleurs aussi l’un des principaux reproches que j’ai entendu dans l’outsourcing des developpements. C’est (parfois) moins cher, ca marche (parfois 😉 ), mais c’est mois bien fait. Grace à des outils comme Sonar (http://www.sonarsource.org/) on peut mesurer la qualité et créer ses propres règles de craftmanship a vérifier.

Enfin, l’article de référence sur le débat pilosophique lancé reste: la cathédrale et le bazar. http://fr.wikipedia.org/wiki/La_Cath%C3%A9drale_et_le_Bazar

Pour moi, il est primordial que le développeur soir architecte dans l’âme, qu’il aime construire. C’est pourquoi j’aime aussi le laisser choisir ses matériaux (outils de dev, langage, etc). Plus on met de contraintes (gros framework java interne, app server dynosauresque genre BEA ou WS) moins la structure et belle, maintenable et agile.

Bonjour,

Je viens de lire votre article. Je le trouve très intéressant car il me fait davantage prendre conscience que le débat se situe (peut-être) ailleurs qu’au niveau du manifeste agile ?

Bien souvent je constate que les enjeux réels de l’agilité et de ce qui en découle en terme d’organisation, de respect de rôles, de la compréhension des principes du manifeste (et en extrapolant des valeurs et pratiques XP) ne sont peut-être pas suffisamment compris et expliqués.

En effet les objectifs de l’agilité ne sont-ils pas de :

– faire une application la plus utile possible au client/ utilisateur final ?

– faire une application industrialisée en vue de pérenniser l’investissement sur la version du SI ?

– produire un code de qualité pour faciliter la maintenance et les évolutions futures ?

Le manifeste agile énonce des principes clairs pourtant une part belle est laissée aux interprétations. Je pense aussi que dans beaucoup de cas l’agilité n’est pas suffisamment maîtrisée (souvent par ceux, même certifiés, censés l’expliquer et la promouvoir) d’où les nombreuses interprétations, négligences et erreurs conduisant (dans le pire des cas) à l’échec de nombreux projets avec incrimination de l’agilité.

Je me permets de donner notre vision de l’agilité (et quelques rappels) telle que nous l’exerçons au quotidien (en laissant la place à l’amélioration continue) en tant que coachs et scrum masters faisant partie d’un pôle agile.

L’agilité n’invente rien, mais remet au premier plan les bons principes et les bonnes pratiques qui produisent de bons résultats.

La PROPOSITION agile n’est pas une simple énumération de ces pratiques, mais une mise en forme intelligente et très cohérente, formant un tout homogène.

Après la phase d’apprentissage théorique et de compréhension des principes, valeurs et pratiques, il devient indispensable dans l’organisation de projet agile de connaître et de respecter les 3 rôles incontournables et non hiérarchiques (Product Owner, équipe de développeurs et ScrumMaster) et à terme de choisir les bonnes personnes pour exercer ces rôles.

Une équipe SCRUM ne se monte pas en « 2Heures » et pas n’importe quand (ex : au moment de réaliser les développements, c’est trop tard).
Non sa constitution est le fruit d’une réflexion menée sur une durée suffisante et qui commence dès la phase d’exploration du projet où sont énumérées (souvent de façon macroscopique) les différentes exigences fonctionnelles et non fonctionnelles en considérant les risques et les contraintes inévitablement liés.
Des actions sont mises en place pour « lever » les risques et vérifier la faisabilité des solutions envisagées.

La première action (pour les nouveaux projets j’entends, c’est aussi vrai pour les portages techniques) est de disposer d’un socle technique robuste pour accueillir les fonctionnalités futures.
à ce stade il est possible de faire intervenir des experts (architectes…) qui pourront pourquoi pas faire partie de l’équipe de développeurs en tant que contributeurs une fois la proposition de solution technique validée.
Puisque nous parlons équipe de développeurs, elle doit être homogène c’est à dire constituée de personnes pouvant, certes avoir une expertise dans un domaine particulier, mais surtout capables à terme de travailler sur toutes les parties de l’application.
Ceci est important et entre en ligne de compte dans l’identification des personnes qui vont composer l’équipe et permet de s’entourrer des « bonnes » personnes.
Notons que le fait de faire ce casting « suffisamment tôt » permet de corriger le tir en cas d’erreur de casting.

Une fois l’équipe composée on ne part pas en freestyle, il faut beaucoup de rigueur et le cadre agile (organisation, scrum master et coach agile) permet à l’équipe d’acquérir l’autonomie nécessaire pour s’auto-organiser et aide chacun à apprendre son rôle, à connaître parfaitement les principes, les valeurs et les pratiques pour déployer la meilleure agilité sur le projet et faire une application utile au client / utilisateur final.
Ainsi en agilité la réussite du projet est fondée sur la confiance dans la qualité du travail que fournira chaque intervenant.
On confie un rôle à chaque personne, on la responsabilise et on lui fait confiance.
Cela comporte une part de risque mais qui s’avère payante dans la majorité des cas.
L’idée est de collaborer pour trouver ensemble la MEILLEURE solution possible pour satisfaire à un besoin Réel et Immédiat qui apportera de la valeur métier.
De plus plutôt que de figer au maximum les choses pour espérer garantir un résultat, on va accepter dès le départ que des changements sont possibles. Et on aura raison !
Si le fonctionnel change, il est dans l’intérêt du métier que ce changement soit pris en compte au plus tôt.
Si les contraintes techniques changent, ou que le code se révèle plus difficile que prévu à écrire, il faut aussi le prendre en compte, puisque c’est la réalité !

Si on fait de nouveau un focus sur le rôle de développeur :
Si les objectifs de l’agilité (surtout l’objectif principal) sont connus,
que les principes du manifeste sont compris et bien expliqués,
chaque rôle de l’équipe Agile bien appréhendé également (le scrumMaster a son « rôle » à jouer dans l’accompagnement jusqu’à autonomie),
il sera donc possible dans la pratique (en gardant à l’esprit les valeurs, fondamental pour permettre une adaptation éventuelle des pratiques), d’atteindre les objectifs.
Cela sous-entend de se fixer des objectifs « petits » donc clairement identifiables avec possibilité d’engagement !
Surtout l’agilité propose une approche « complète » dans l’objectif de faire les choses une seule fois pour gagner du temps (et s’épargner les coûts de maintenance corrective…)
Il devient donc indispensable que la qualité soit la meilleure possible et que le comportement métier attendu soit vérifié en permanence ! (Tests Unitaires, TDD recommandé et automatisation) pour garantir une couverture de tests satisfaisante (80% minimum).
Le respect de règles et normes de codage, la mise en place de binômes tournants (un expérimenté avec un débutant fonctionnellement et/ou techniquement), le refactoring sont autant d’atouts qui permettent non seulement d’avoir un code de qualité mais aussi
d’avoir une garantie pour soi et pour les autres que ce qui est codé l’est de la meilleure façon possible,
fonctionne (le respect des DoD, des conditions de validations, le feedback du PO et la cérémonie de sprint review permmettent de le valider)
et pourra être repris (pour terminer ou pour implémenter de nouvelles fonctionnalités) par une autre personne sans douleur et avec fluidité.

Voilà en ce qui concerne « notre » compréhension du manifeste de part la mise en oeuvre de l’Agilité.

Je ne veux pas être rabat-joie je pense juste qu’une bonne compréhension de l’agilité permet de faire simple et de ne pas multiplier les manifestes. L’engouement sur le sujet met en évidence qu’il y a encore beaucoup de travail à accomplir.

En tout cas je trouve les échanges sur le sujet intéressants.

Agilement…

C’est comme si XP c’était scindé en Scrum d’un côté et Software Craftsmanship de l’autre.

Intéressant à lire également : http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot

Bonjour,

Permettez moi de me présenter, je ne suis pas un Geek 2.0, ça fait dix ans que je suis dans la même boite. Je ne développe plus, pire je suis commercial depuis deux ans. Oh mon Dieu, Père Damien Karras (Nicolas), Père Merrin (Didier), vite aidez-moi, je suis possédé par le démon Mouton 2.0. Exemple, en 2009, je faisais partie des 2,52% de développeurs à utiliser encore la 3.1 d’Eclipse. Un retard de 4 générations, un vrai Mouton 2.0 !

Mouton 2.0, mais je me soigne ! Ma thérapie :

NS – Abonnements Twitter bien tunnés, sur mon PC le matin et le soir, et sur Blackberry plusieurs fois par jours – A renouveler.

NR – Des heures et des heures sur des blogs sérieux : Standblog, L’informatique Conviviale, Le Touilleur Express, …

NS : Non Substituable ; NR : Non Remboursable

Et puis un jour, je suis tombé sur un article super intéressent Software Craftsmanship par Nicolas Martignole.
Quelques jours après, en prenant mon médicament discrètement pendant une réunion Go/NoGo où certains parlent de choses qu’ils ne connaissent pas. Hé oui syndrome bien connu chez certains commerciaux : IABMC (Intelligence Artificielle à Base de Mots Clés). Je tombe sur le twitt de @nmartignole lien vers le billet de Grégory Weinbach ‘Software Craftsmanship, ou le marketing de l’échec’.

Heuuuu, serait-on pas entrain de réveiller le vieux démon de l’éternel débat Standardisation vs Customisation ?

Entre agilité, mouvement du Software Craftsmanship, Ingénierie, industrialisation. Je me dis que le point commun est peut être ‘comment mieux faire son métier ?’

Je doute l’existence d’une réponse définitive à cette question structurante et le métier de l’informatique, c’est d’abord un métier intellectuel, alors comment nous motiver pour mieux le faire ?
Daniel Pink nous propose 3 facteurs principaux de motivations pour mieux faire un métier intellectuel : Autonomie, Maitrise et Sens.

Qu’en pensez-vous ?

Un grand MERCI à Nicolas, Didier, Grégory, Guillaume, Pierre , Tug et tous ceux qui œuvrent à animer des blogs de qualité et à vous de m’avoir lu.

Je retourne à ma cotation 🙁

Un Mouton 2.0 qui rêve de «Travailler en sifflant» 😉

Bonjour,

@Nicolas, désolé pour la réponse tardive.
Ce que tu dis est juste. là où nous opérons nous plantons le décor dès la présentation (définition) de l’agilité.
En fait nous mettons en avant la complémentarité des méthodes agiles ce qui nous permet de placer l’organisation au même rang que celui de l’équipe, des valeurs, des principes et des rôles afin d’atteindre l’objectif unique (application la plus utile possible au client et utilisateurs finaux) sans dégrader les niveaux de qualité et d’industrialisation :
Nous parlons moins de Scrum ou d’XP que d’Agilité puisque ces différentes méthodes sont complémentaires. Ainsi nous utilisons tout ce qui sera applicable au contexte du projet quelle que soit la méthodologie qui le préconise.
Voici ce que nous présentons.
« L’Agilité est régit par :
– une organisation pour gérer le projet > SCRUM
– des valeurs, piliers de la « philosophie » agile
– des pratiques (XP) concrètes, qui proposent un cadre d’application
– des rôles bien définis (tous acteurs, tous responsables)? »

Ainsi l’équipe et son travail sont la clé de voûte de l’application.
De plus, nous faisons prendre conscience aux équipes qu’il n’y a rien à inventer > il faut « juste » utiliser des pratiques agiles qui ont fait leurs preuves et qui se renforcent les unes les autres (à l’image d’un framework). La notion de rôle et de respect de ces rôles agiles est très importante et met l’accent sur la responsabilisation de chaque membre de l’équipe.

Dans la pratique chaque projet débute par 2 à 3 itérations de rôdage et de calibrage qui permettent à chacun de monter en compétences aussi bien sur l’agilité, le contexte du projet et le domaine technique associé. Dès lors par la suite la notion d’engagement futur sera possible en terme de vélocité min de qualité et d’industrialisation (non négociables) > les personnes se responsabilisent, se font confiance, se respectent et respectent (entre autres) des règles et normes de qualité et de codage (générales et surtout propres au contexte projet, ces dernières sont rédigées et approuvées par l’ensemble de l’équipe des développeurs…).
Donc effectivement le travail doit être bien réalisé d’où l’importance « du casting » lors de la mise en place de l’équipe qui permet de s’entourer (on l’espère) des « bonnes » personnes > le freestyle ne fait pas bon ménage avec l’agilité 🙂
un coup de balai sur ceux qui ont la tête dure ou trop réfractaires au changement. ça ne veut pas dire que nous avons uniquement des « moutons » (sans rapport avec le post de Mouton) dans nos équipes 🙂
Agilement…