Le mouvement du Software Craftsmanship, que l’on peut traduire par connaissance du mĂ©tier, fait le tour des blogs anglophones en ce moment. Au delĂ de ce mot, c’est un ensemble de valeurs qui me semble intĂ©ressant de prĂ©senter et de partager avec vous. Alors ĂȘtes-vous craftsmanship ou non ? Vous le saurez Ă la fin de cet article.
Définition
Le mouvement du Software Craftsmanship a été lancé en 2009 avec la mise en place du « Manifesto for Software Craftsmanship« . Inspiré du Manifeste Agile, il regroupe des développeurs reconnus comme Bob Martin (« Uncle Bob ») par exemple. Il a été inspiré par le livre « The Pragmatic Programmer » publié en 1999 par Andrew Hunt et David Thomas.
En signifiant que vous ĂȘtes « Craftsman« , pour vous un logiciel qui fonctionne n’est pas suffisant, il doit ĂȘtre aussi bien Ă©crit. Pour cela vous mettez en oeuvre des techniques de programmation pour que le rĂ©sultat soit le plus propre et le plus simple possible. Les Anglais parlent de rĂ©sultat « artistique » au sens piĂšce unique.
Le Manifeste Agile parle de gĂ©rer et d’accepter le changement, ce Ă quoi le Manifeste du Software Craftsmanship rĂ©pond en prĂ©cisant qu’il ne faut pas cesser d’ajouter de la valeur Ă un programme. Chaque ligne de code doit crĂ©er de la valeur, elle ne doĂźt pas coĂ»ter. Il faut voir le logiciel comme quelque chose qui doit ĂȘtre simple.
Etre Craftsmanship ce n’est pas seulement privilĂ©gier les individus et les interactions comme expliquĂ© dans le Manifeste Agile. C’est aussi appartenir Ă une communautĂ© de professionnels. Enfin le dernier point prĂ©cise que si la collaboration avec le client est importante, il faut aussi avoir une relation productive avec eux.
C’est donc le mĂ©tier de dĂ©veloppeur au sens premier du terme. Ce manifeste rappelle l’importance du dĂ©veloppeur. Le mouvement Agile privilĂ©gie la gestion et le dĂ©veloppement d’un projet. Le mouvement du Craftsmanship essaye de parler du dĂ©veloppeur et de le placer comme un artisan. Il y a quelques annĂ©es, l’eXtreme Programming plaçait les dĂ©veloppeurs au centre d’une nouvelle organisation. Cela fonctionnait dans les Ă©quipes, mais les 13 pratiques XP ne structuraient pas assez les relations avec l’utilisateur final. Scrum ensuite est arrivĂ© pour prendre une place diffĂ©rente. Il a eu le mĂ©rite de faire passer les valeurs de l’AgilitĂ© et il a certainement contribuĂ© Ă l’essor de l’AgilitĂ© en France. Le mouvement du Software Craftsmanship essaye de rééquilibrer la place du dĂ©veloppeur dans une Ă©quipe de dĂ©veloppement, en le prĂ©sentant comme un artisan-dĂ©veloppeur.
Pour essayer de rĂ©sumer cela Ă ma sauce, si nous Ă©tions cuisinier, nous serions comme ces chefs Ă©toilĂ©s plutĂŽt que le cuisiner de la cantine scolaire de votre fils. Nous cherchons Ă exprimer l’importance du travail bien fait et de la conscience professionnelle.
Points positifs et valeurs
J’aime ce mouvement mĂȘme si j’ai encore du mal Ă l’expliquer. Il vise Ă essayer de fĂ©dĂ©rer les dĂ©veloppeurs qui souhaitent faire leur mĂ©tier diffĂ©remment. Il existe une population d’informaticien qui subit et qui attend des formations de leur SSII. Il existe une population qui se met dans le sens du courant, qui se forme et qui travaille avec passion. Chez le client, il y a ceux qui travaillent et qui codent des spĂ©cifications. Et il y a ceux qui travaillent avec le client final, qui cherchent Ă comprendre le mĂ©tier, qui sont fiers du code Ă©crit et qui rĂ©alisent des applications simples.
Si cela doit s’appeler « Software Craftsmanship » cela me va trĂšs bien. D’autres diront simplement « conscience professionnelle » et cela marchera aussi. Mais l’idĂ©e qu’une certaine pratique de l’informatique porte un nom me plaĂźt bien.
Autre point intĂ©ressant : nous pouvons voir notre mĂ©tier comme un art qui se pratique pendant nos heures de bureaux et au delĂ . Je pense Ă un guitariste de concert. Il joue pendant les concerts mais il passe aussi beaucoup de temps Ă s’entrainer. Prenez un sportif de haut niveau, c’est pareil. Ou prenez aussi un chirurgien comme dans cette superbe sĂ©rie que regarde mon Ă©pouse oĂč les chirurgiens sont des dieux qui ont terminĂ© un long apprentissage, et qui travaille comme des artistes.
Finalement ĂȘtre dĂ©veloppeur c’est coder pendant ses heures de boulot, mais c’est aussi prendre un peu de temps pour se former le soir et les week-ends. C’est se faire une petite soirĂ©e JUG pour rencontrer des gens ou c’est faire un coding-dojo pour apprendre quelques techniques sympas de programmation. Bref c’est envisager son mĂ©tier comme une passion ou un art, comme la musique. Que cela vous fasse bondir, je m’en fiche pas mal.
Ce qui est plus souhaitable, et je sais que des entreprises le font, c’est de laisser du temps aux salariĂ©s pour s’auto-former. Il suffit d’organiser des Ă©vĂ©nements sur une journĂ©e par exemple comme le fait Zenika, SFEIR ou Xebia. Si vous voyez cela comme une journĂ©e de non-facturation c’est que vous n’avez pas encore compris le mĂ©tier de dĂ©veloppeur. Si c’est une dĂ©pense au lieu d’un investissement pour vous, pas de soucis. Mais ne soyez pas Ă©tonnĂ© le jour oĂč vos petits gars iront voir en face. Car croyez-moi dans notre mĂ©tier, il n’est plus possible de voir le dĂ©veloppeur comme un TJM placĂ© dans une trayeuse Ă lait, dans l’attente qu’il parte au bout de 5 ans, devenu trop cher. Hop Ă l’abattoir, je vais chercher de nouveaux jeunes diplĂŽmĂ©s…
Alors si cela doit porter une étiquette, et bien moi cela me va trÚs bien.
Critiques du mouvement
Dan North dans un long article critique le manifeste en expliquant que celui-ci tend Ă donner trop d’importance au mĂ©tier/Ă l’art au lieu de privilĂ©gier la relation avec l’utilisateur final. Il dĂ©fend l’idĂ©e qu’un logiciel bien codĂ© doit ĂȘtre transparent. Lorsque vous roulez sur l’autoroute, vous ne pensez pas Ă l’architecture qui a construit la route ou le pont. Pourquoi les informaticiens devraient-ils se considĂ©rer comme des « artistes » (l’une des traductions possibles de craftsman) alors que ce qu’ils font c’est simplement du code ?
Bob Martin a publiĂ© un article plus dĂ©taillĂ© pour rĂ©pondre aux questions de Dan North et de Martin Fowler. Il recentre le mouvement et montre bien l’importance de la place du client dans l’approche. Contrairement Ă ce que Dan explique, pour Bob Martin c’est avant tout le ras-le-bol d’Ă©crire de la m…e et l’envie de faire les choses bien qui motive ce mouvement.
Dan North propose plutĂŽt de parler de simplicitĂ© (au lieu de technique de programmation). Nous devons Ă©crire des logiciels faciles Ă utiliser pour les utilisateurs plutĂŽt que de beaux logiciels style cathĂ©drale. Etre fier de son mĂ©tier apporte de la valeur, mais peut entrainer le phĂ©nomĂšne « bĂątisseur de cathĂ©drale ». Lorsqu’une discussion d’architecture technique autour d’un tableau blanc prend trop de temps, pensez Ă l’utilisateur final du logiciel. N’oubliez pas que ce que vous faĂźtes doit ĂȘtre simple, Ă©conomique et efficace. Et ensuite vous pouvez faire beau, bien Ă©crit et bien architecturĂ©.
Pensez aussi au domaine, comme Eric Evans et l’approche DDD que j’ai rencontrĂ© en 2010. Ce gars lĂ a tout compris et n’a Ă©crit qu’un seul livre car son problĂšme est simple : le domaine d’application de votre logiciel doit piloter le design. Martin Fowler dans son dernier article termine par ces quelques phrases :
[…]the software shouldn’t be at the center of a programmer’s world, instead a programmer should focus on the benefit that the software is supposed to deliver.
Le plus important est donc le domaine et la valeur que nous crĂ©ons, plutĂŽt que les techniques de programmation. Bien qu’importantes et intĂ©ressantes, il ne faut pas oublier les utilisateurs. IntĂ©ressant non ?
Une autre critique serait de tomber dans les travers de la certification comme Scrum l’a fait. Nos amis amĂ©ricains adorent l’idĂ©e de la certification et du badge de boy-scout ou de l’autocollant sur le pickup : « Certified Scrum Master« . J’espĂšre que nous n’aurons pas besoin de certification. Je pense que la rĂ©putation de chacun doit suffire Ă reconnaĂźtre la valeur de chaque dĂ©veloppeur. J’aimerai qu’un jour, un CV marque explicitement : « j’ai travaillĂ© 12 mois avec Bob Martin » ce qui aura plus de valeur que « CertifiĂ© Craftsmanship Level 3 ».
Il faudrait que les Geeks soient aussi cĂ©lĂšbre que ces mĂ©decins dans Grey’s Anatomy. David Gageot serait le pape de la cardio et des tests unitaires. Didier Girard serait le gourou de Google et un expert en traumatologie Ă©mĂ©rite, Emmanuel Bernard serait un chirurgien plastique qui maitrise les Annotations comme un dieu…
Enfin bref, c’est le sujet du moment.
Et comme tout blog people qui se respecte, il fallait que j’en parle.
Références
Page du Manifesto Software Craftsmanship
Article de Dan North
Why I didn’t sign the SCM
Martin Fowler Craftsmanship and The Crevasse
Définition Wikipedia (en)
J’adhĂšre complĂštement mais le craftmanship ne serait-il pas le Don Quichotte des SSII?
Ouh lĂ lĂ , qu’est ce que c’est ce truc de Craftmanmachin ? Pas sĂ©rieux ! Je vais vous dire, ça me paraĂźt totalement artisanal !
Et pendant qu’on y est, pourquoi pas un titre de meilleur developpeur de France comme il y a des meilleurs ouvriers de France ? Non pas sĂ©rieux du tout ! Non,Non,Non ! Il faut un CPIL et un COMITE DE PROJET, une cellule PMO et un reporting hehdomadaire et puis attention si vous dĂ©calez, on fera du pilotage « re-serré » (2 fois plus de CPIL et de CPROJ et de reporting). Et la mĂ©thodologie ? Elle est oĂč la mĂ©thodologie ? Et le respect des normes internes ! Et puis, petit malin, quand allez vous livrer des 257 fichiers XML pour faire tourner l’application de gestion sous WebsphĂšre ?
Anarchiste !! Non mais !
signé un vieux de 48 ans (ex super grand top manager certifié) qui se remet au dev parce que vous avez bien raison !
@pj excellent đ
J’approuve Ă 200%. Je pense d’ailleurs que je vais faire suivre le lien de ton article Ă toute mon Ă©quipe dans les plus brefs dĂ©lais !
Et vive le code propre…
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 )
Tu aurais aussi pu parler d’ARxTA (http://arxta.net/) de Brian Marick qui Ă©tait explique bien pourquoi il faut se comparer Ă de l’artisanat : http://arxta.net/explanation (traduite en français d’ailleurs).
La vidĂ©o vaut aussi le coup d’Ćil (http://arxta.net/video surtout la fin Ă mon avis đ )
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 !
J’aime beaucoup de mouvement, qui rejoint ma dĂ©marche.
Juste un point : pour ceux d’entre nous qui ont une vie de couple voire de famille, ou mĂȘme simplement des loisirs ou une vie sociale, coder le soir ou le week-end, ou mĂȘme faire de la veille, ne peut ĂȘtre que marginal.
Certes, ca incite Ă aller Ă l’essentiel, mais c’est trĂšs frustrant.
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.
Nicolas,
Merci pour cet excellent billet qui est trĂšs didactique et qui apporte de l’eau au moulin de ceux qui considĂšrent l’ingĂ©nierie logicielle comme un art.
La définition du Software Craftsmanship est encore en devenir.
Les joutes blogguesques sur le sujet entre experts de chaque camp sont intéressantes. Nous pensons de notre cÎté que tout mouvement, toute initiative de nature à améliorer notre métier est positive.
Je pense sincĂšrement que ce mouvement est porteur d’une grande valeur.
Il est en rupture avec cette stupide approche de massification de la prestation informatique (cf centres de services et autres joyeusetés que les Directions Achats de nos chers clients tentent de mettre en place).
P
TrĂšs complĂ©mentaire de l’agilitĂ© et de l’amour des technologies, le Software Craftsmanship adresse l’attitude gĂ©nĂ©rale et personnelle d’une Ă©quipe vis Ă vis de son travail.
Nous avons initié un travail de fond sur le sujet.
Mon but lĂ n’est pas de faire de la pub mais de livrer notre vĂ©cu.
Nous avons tout d’abord travaillĂ© sur l’Ă©laboration d’un deck de cartes listant les grands principes Ă respecter pour ĂȘtre un bon Craftsman.
Ce deck sera mis Ă dispo sur iPhone et Gphone pour consultation.
L’application donne accĂšs, pour chaque principe Ă une page complĂšte sur le sujet avec les liens interessants associĂ©s.
Ce deck part au print cette semaine et sera délivré à chacun des 200 consultants de Xebia dans le monde.
Le format est plus sympa qu’un livre qui par nature est non Ă©volutif et plus fun Ă utiliser.
Cette premiĂšre Ă©tape a Ă©tĂ© longue, trĂšs longue car il faut ĂȘtre exaustif, diffĂ©rentier ce qui est une pratique de ce qui est une astuce.
Nous avons ensuite mis en place des Ateliers Software Craftsmanship bi mensuels chez Xebia.Ils complétent nos XKE.
Nous avons choisi une application « fil rouge » qui sert de base à nos expérimentations.
BasĂ© sur le volontariat, ce travail nous conduit Ă adresser en profondeur, une par une les pratiques de nature nĂ©cessaires Ă atteindre ce graal de l’oeuvre d’art.
C’est assez plaisant, c’est aussi difficile car il faut sans cesse remettre l’ouvrage sur le mĂ©tier, se remettre en question, dĂ©faire pour recommencer.
Ce travail gĂ©nĂšre des frustrations car il remet profondĂ©ment en cause certains idĂ©es reçues. Il eut mĂȘme s’avĂ©rer ĂȘtre vexatoire.
Une fois ce travail terminĂ©, nous ouvrirons Ă la communautĂ© ces ateliers afin d’Ă©largir le champs des Craftsmen avec lesquels nous Ă©changeons.
Enfin, nous faisons venir Uncle Bob pour nous et nos clients.
Les joutes blogguesques sur le sujet entre experts de chaque camps sont intéressantes. Nous pensons de notre cÎté que tout mouvement, toute initiative de nature à améliorer notre métier est positive.
Luc Legardeur (Xebia)
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.
Quelle belle image que le bon ouvrier « local » du numérique qui aime son métier et travaille avec amour pour faire un travail de qualité.
Il est clair que cette vision n’est pas possible en France si vous travaillez en SSII. Par exemple la convention syntec ne considĂšre pas un informaticien comme un « artiste » … En SSII, le commercial va vous placer en fonction de mots clefs …
Dans les sociĂ©tĂ©s « finales » française, c’est parfois un peu mieux, surtout si c’est une sociĂ©tĂ© trĂšs technologiques. Mais cela peut changer d’une rĂ©organisation Ă une autre … Bien sur, cela ne fera pas partie de vos objectifs … D’ailleurs qui pourrait Ă©valuer la beautĂ© de votre travail?
Aux USA, il est vrai que les sociĂ©tĂ©s s’arrachent certains de ces experts (voir la guerre Google, Facebook, Microsoft) et que les carriĂšres techniques existent et sont valorisĂ©s (la fameuse « double ladder », ou vous avez deux Ă©chelles pour progresser l’une MĂ©tier, l’autre Technique avec des ponts entre les deux). D’ailleurs allez voir les campus dans lesquels ils travaillent … Cela est inexistant en France.
La seule solution est donc l’indĂ©pendance pour pouvoir rĂ©aliser son rĂȘve. Un rĂȘve de passionnĂ© (certains touille đ ), qui peut choisir comment il travaille et pour qui il travaille.
Bien sur, cela requiert une certaine notoriĂ©tĂ©. Une nouvelle classe d’artisans du numĂ©rique est en train de naitre. Moins protĂ©gĂ©e socialement, plus agile, et plus versatile. Mais aussi plus heureuse, plus indĂ©pendante et terriblement efficace.
J’ai toujours espĂ©rĂ© que les incubateurs puisse accueillir ces ressources rares. Innovation, art de faire et faire savoir (marketing) doivent se mĂȘler et s’associer avec agilitĂ©.
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.
Cool, l’article.
Dans ce que l’avais lu jusqu’ici, le parallĂšle simpliste avec l’artisanat me gonflait. Parce que l’artisanat, c’est aussi le maçon qui monte le mur de travers parce qu’il est bourrĂ© du matin au soir, c’est le plombier qui te fait payer une fortune pour changer un bĂȘte joint, et c’est le mĂ©chant plombier polonais qui prend le travail de nos gentils plombier français de chez nous. L’artisanat a Ă peu prĂšs les mĂȘmes dĂ©rives que notre mĂ©tier.
Donc j’aime bien que tu soulignes qu’on peut avoir une certaine vision de notre mĂ©tier, comme il y a une certaine vision de l’artisanat, avec le petit cotĂ© artiste.
Un remarque quand mĂȘme. Pour la conclusion, j’aurais remplacĂ© « Emmanuel Bernard serait un chirurgien plastique[…] » par « Emmanuel Bernard serait… Emmanuel Bernard ».
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.
Si j’adhĂšre Ă cette idĂ©e d’artisan, je pense qu’il ne faut pas confondre artisan et artiste…
L’artisan satisfait son client avec un bel ouvrage ayant souvent une finalitĂ© pratique. L’ouvrage est bien fait, propre. Il est fait avec des outils Ă©prouvĂ©s qui accompagnent l’artisan dans la durĂ©e. L’artisan suit les techniques qui Ă©voluent dans son mĂ©tier mais ne les adoptent qu’avec pragmatisme.
L’artiste, lui, satisfait souvent plus son Ă©go que son client. Il prĂ©tend rĂ©volutionner le monde avec sa derniĂšre crĂ©ation alors que dans 80% des cas c’est une grosse bouze qui ne sera considĂ©rĂ©e « gĂ©niale » que par ceux qui aime succomber aux effets de mode passagers ou tout les intermĂ©diaires chargĂ©s de la vendre.
Alors oui, il y ‘a de vrais artistes…mais si peu !
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…
@ArtisteAgile merci pour ton retour qui est trĂšs complet. Agiliste depuis 2008, tu prĂȘches un convaincu. Dans ce que tu exposes, quelle part serait la responsabilitĂ© de l’organisation et quelle part est de la responsabilitĂ© de ceux qui rĂ©alisent ? L’idĂ©e du Craftsmanship c’est de dire que l’AgilitĂ© c’est sympa, mais il faut aussi savoir bien rĂ©aliser. Par rapport Ă Scrum particuliĂšrement, nous savons que ce n’est pas suffisant pour rĂ©ussir. Il faut aussi des pratiques de rĂ©alisation comme celles portĂ©es par XP. Et c’est lĂ que le Craftsmanship se positionne. C’est donc pas l’un ou l’autre, mais l’un et l’autre. Et encore, cela dĂ©pend des mĂ©thodes Agiles…
Je vais encore y rĂ©flĂ©chir mais je trouve aussi que les Ă©changes sont trĂšs intĂ©ressants. Comment mieux faire son mĂ©tier… c’est trĂšs riche.
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
Merci, Nicolas pour cet article trÚs intéressant sur le sujet.
Malheureusement, je trouve que l’approche de Robert Martin n’est pas trĂšs constructive : en constatant que le dĂ©veloppement est une activitĂ© d’artisan, il tombe dans la vile flatterie en encourageant la dimension « compagnonnage » dans la transmission du savoir faire. Il serait plus intĂ©ressant, Ă mon sens (mais moins valorisant pour notre ego de dĂ©veloppeurs) d’essayer de dĂ©passer l’artisanat pour aller vers plus d’industrialisation.
Etant un peu Ă©nervĂ© par les tentatives (un peu faciles) de rĂ©cup du sujet, je me suis permis un billet d’humeur en rĂ©fĂ©rence Ă ton post.
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» đ
Excellent le concept du Mouton 2.0 đ Cela mĂ©ritera un article.
Surveillez votre lecteur de flux RSS, je vous cuisine une version spĂ©ciale…
Nicolas
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…
Pour tous les ingĂ©nieurs informatique qui ont manquĂ© leur orientation, je dĂ©die cet article: Le goĂ»t des autres… domaines d’ingĂ©nierie. En espĂ©rant ne pas ĂȘtre trop offensant đ