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 🙂