Cette collection cohérente de "règles de vie" du développeur est une pierre utile à l'édifice "AGILE", une façon d'incarner ces valeurs.
- Comprendre et accepter que nous pouvons faire des erreurs
- Nous ne sommes pas notre code
- Peu importe combien nous connaissons le karate, il y aura toujours quelqu'un qui en connaîtra plus que nous
- Ne pas réécrire le code d'un autre programmeur sans le consulter avant
- Traitons les gens qui en savent moins que nous avec respect, déférence et patience
- La seule constante dans le monde est le changement
- La seule vrai autorité vient du savoir et non de la position
- Battons-nous pour ce que nous croyons mais acceptons gracieusement la défaite
- Ne soyons pas "the guy in the room"
- Critiquons le code plutôt que le codeur. Soyons gentil avec le codeur, pas avec le code
1 Comprendre et accepter que nous pouvons faire des erreurs
Je comprends cette première "règle" dans le sens où blâmer soi-même ou les autres pour des erreurs commises est contre-productif. Il est suffisant d'être de bonne foi et d'essayer de ne pas refaire les mêmes erreurs plusieurs fois.L'auto-organisation et les rétrospectives sont des moyens efficaces d'atteindre ce but.
Un bémol quand même. Ce n'est pas le cas nominal et il ne faut pas partir avec cet a priori, mais il existe des gens qui ne sont pas de bonne foi sur Terre, je sais c'est moche mais c'est vrai, il faut y faire attention et agir en conséquence si le cas se présente. Il n'est pas possible de s'auto-organiser avec des personnes que l'on juge de mauvaise fois.
2 Nous ne sommes pas notre code
Les mécanismes d'identification, sont un des principaux freins à l'agilité et à l'adaptabilité dans un monde complexe et chaotique, quelque soit le sujet d'identification. Ne pas s'identifier à son code, permet de ne pas mal prendre une critique sur le code que l'on a écrit, permet ainsi de le retailler plus rapidement avec moins de psycho-drame.C'est un préalable nécessaire à quasiment tous les points de ce manifeste.
On pourrait clairement étendre ce point à tout autre objet que le code : je ne suis pas mon équipe, mon entreprise, mon pays, mes échecs, mes réussites etc...
J'ai coutume de jouer à des petits jeux de désidentification :
- comme quand on me demande ce que je fais dans la vie : je joue au tennis, je lis des livre d'heroic fantasy, je développe des applications informatique ...
- j'essaie de ne pas dire et penser que je SUIS développeur, mais plutôt que je pratique le développement. Cela me permet de ne pas m'identifier au fait que je développe en java, scala, et ainsi d'éviter les puériles guerre de clocher qui agite la web-sphere.
3 Peu importe combien nous connaissons le karate, il y aura toujours quelqu'un qui en connaîtra plus que nous
Une évidence pour moi. Il y a toujours des choses à apprendre des autres, même des débutants (d'où le point 5).Avoir un état d'esprit ouvert, écouter ce que les autres disent, nous permet (en tant qu'individu mais aussi en tant qu'équipe) de nous améliorer continuellement.
4 Ne pas réécrire le code d'un autre programmeur sans le consulter avant
Une des règles de ce manifeste qui fera, je pense, le plus débat. En effet, j'ai vu et continu de voir quantité de "grand développeur" changer le code existant sans en parler à personne au préalable. Pour moi c'est une entorse flagrante au principe de coopération dans une équipe agile. Il n'est pas question de demander la permission, à l'auteur original du code, de changer son code mais juste de le prévenir, voir de s'enquérir auprès de lui "du pourquoi" de certains de ses choix de conception et de voir ensemble quelle solution serait plus acceptable.Cette façon de faire permet :
- de ne pas froisser ses collègues
- d'échanger de l'information sur les façons de voir des autres
- de trouver des consensus sur les pratiques de code, les choix d'architecture
Le point 3 et 5 sont des bons compléments pour appliquer comme il faut cette "règle".
5 Traitons les gens qui en savent moins que nous avec respect, déférence et patience
Toujours dans une optique d'auto-organisation efficace, traiter avec respect les "noob", permet un partage des pratiques, une montée en compétence des équipiers et une convergence des points de vue très efficace.Cela met une bonne ambiance , évite de stresser les nouveaux, facilite la communication entre tous et donc augmente le niveau moyen de l'équipe.
Et traiter les gens avec respect c'est bien !
6 La seule constante dans le monde est le changement
S'adapter, s'adapter, s'adapter ... Pas qu'un leitmotiv, mais aussi un questionnement de tous les instant. Comment faisons-nous pour nous adapter aux changements ? Si nous subissons un changement comment faire pour que cela ne se reproduise plus ?La conscience de la nature chaotique du monde, l'acceptation de cet état de fait nous permettra d'y faire face plus efficacement non ?
L'utilisation systématique de boucle de rétro-action courte est le seul moyen de s'adapter au changement. Tout ce qui permet l'acquisition et le traitement de feedback est bon à prendre.
Les méthodes types eXtreme programmming, LEAN (startup), Kanban sont fortement basé sur ce principe de boucle de rétro-action, permettant de collecter des données pertinentes permettant des actions d'ajustements.
7 La seule vrai autorité vient du savoir et non de la position
A quoi sert une hiérarchie verticale, faite de chefs éloignés du terrain dans un monde hyper-complexe et chaotique, où l'adaptation au changement (point n°6) est une règle pour survivre (gagner des sous-sous)?Un chef n'est pas utile dans une équipe auto-organisée, composée de gens qui connaissent leur travail.
Nous avons plutôt besoin de responsables !
Qui décide des fonctionnalités métier à développer ? Celui qui sait, donc les représentant du métier ou le métier lui-même !
Qui décide de comment ces fonctionnalités seront implémentées techniquement ? Celui qui sait, donc l'équipe de développement.
La hiérarchie passe de verticale à horizontale, c'est une hiérarchie de responsabilité. Naturellement ceux qui adressent les problématiques sont ceux qui sont à même de décider comment les faire.
8 Battons-nous pour ce que nous croyons mais acceptons gracieusement la défaite
Il m'est souvent arrivé de trouver des situations où il était mal vu de défendre activement ses points de vue. Pourtant il est nécessaire que les membres d'une équipe défende leur point de vue, de manière positive, pour permettre une réelle mutualisation des cerveaux, c'est à dire une réelle coopération. Une équipe avec un leader et des suiveurs ne pourra jamais atteindre les sommets d'une équipe auto-organisée, travaillant en synergie vers un objectif commun.A contrario, il n'est pas bon de s'accrocher mordicus à une croyance en mettant de côté celle des autres, les contre-arguments qu'ils peuvent apporter. Le but d'une séance de design participatif, par exemple, n'est pas d'avoir raison mais d'aboutir à un consensus.
Il est pour moi clair, que dans une équipe agile, si nous arrivons à un point où il est impossible d'avoir un consensus sur un nombre trop important de sujet, c'est qu'il est temps de quitter l'équipe.
9 Ne soyons pas "the guy in the room"
J'ai personnellement l'habitude de parler du "développeur dans sa cave". Le développeur qui ne communique avec personne et sûrement pas avec son code, qui est assez illisible. Les plus pervers d'entre eux peuvent même en tirer une énorme satisfaction.Rappelons le mais le boulot d'un développeur professionnel, a fortiori dans une équipe agile, est de communiquer avec ses co-équipiers pour pouvoir livrer dans les meilleurs conditions l'application nécessaire. Oralement, en binômant, via des revues de pairs, avec son code (qui doit être clair et explicite).
Les "développeurs dans leur cave" sont un trou noir où l'information, le partage se perdent à jamais et empêche l'équipe de progresser dans son auto-organisation.
Il est souvent conseillé de sortir ce type de développeur de l'équipe, et que celle-ci devienne cliente de ce développeur, lui confiant des tâches qu'il peut réaliser seul et minimisant les problèmes que peuvent causer ce type de comportement (en fixant des conditions de livraisons sur la qualité, clarté du code, peer-review systématique).
10 Critiquons le code plutôt que le codeur. Soyons gentil avec le codeur, pas avec le code
Rejoint fortement le point 2, 3 et 5. Ce qui est à améliorer c'est le code. Nous devons être sans pitié avec un code de mauvaise qualité, difficile à faire évoluer, à lire, à comprendre. Mais nous ne devons pas identifier le code à son codeur, et celui-ci ne doit pas s'attacher à son "oeuvre" plus que de raison.Critiquer le code plutôt que le codeur permet à une équipe de s'améliorer constamment, en synergie, et d'atteindre rapidement un niveau d'excellence important.
Conclusion
Les plus observateurs d'entre vous auront noté qu'en anglais le manifeste utilise "YOU" alors que j'ai choisi d'utiliser "NOUS" dans ma "traduction".J'ai fait cela à dessein, pour éviter notre tendance à penser "l'enfer c'est les autres".
Si, après avoir lu cet article, vous vous dites : "Trop bien cet article ! C'est vrai que Gérard devrait le lire pour progresser" c'est que j'aurais échoué à vous transmettre ce que je pense.
Il n'est pas question de changer les autres mais de prendre conscience de toutes ces choses qui nous empêche de progresser dans notre boulot (notre vie ?), d'être effectivement professionnel.
Aucun commentaire:
Enregistrer un commentaire