Limiter le rework quand on code

« Je ne t’ai jamais demandé ça ! » vous dit la personne qui vous a demandé un développement suite à une spécification sur un post-it. Qui ne l’a pas entendue ? En fait il existe des techniques permettant de limiter fortement ce genre d’attitude, ce qu’on va voir ici.

Débloque les + belles offres tech en 10 mins

Le péché originel

Alors certes vous pouvez être énervé contre votre donneur d’ordres lorsqu’il a une telle attitude, mais en fait en acceptant une spécification sur un post-it vous êtes vous-même largement coupable ! En faisant ceci vous envoyez un signal clair à votre interlocuteur : il peut dicter n’importe quoi et n’a aucun compte à vous rendre. Et si ce que vous avez implémenté ne correspond pas, c’est de votre faute.

Alors certes les méthodes Agile recommandent d’alléger fortement les spécifications techniques, mais ça ne signifie pas non plus faire n’importe quoi ! En fait par « allègement » il faut plutôt comprendre :

• Des screenshots pour la maquette
• Des cas d’utilisation sous la forme given / when / then

La règle : obligez votre interlocuteur à s’engager

En fait le meilleur moyen d’éviter une telle déconvenue est d’obliger votre interlocuteur à s’engager. L’idée derrière tout ça est qu’une fois qu’il s’est engagé il ne peut plus se dédire aussi facilement. N’entreprenez rien sans un tel engagement, ça se retournera contre vous nécessairement !

Autrement dit votre interlocuteur doit avoir écrit, avec ou sans votre aide, ce qu’il attend. Dans le cas d’un rendu visuel il doit vous fournir une maquette a minima. Des outils tels que Balsamiq permettent de le faire facilement. Il doit aussi vous fournir des spécifications sous forme de given / when / then, du type « Je suis sur tel écran, quand je clique ici il doit se passer cela ».

Il est évident que vous devez être partie intégrante du processus de spécification, notamment pour guider la personne, mais également avoir une meilleure compréhension de son métier. Par la suite ça permettra aussi d’avoir une application qui colle au plus près de métier, ce qui rendra sa compréhension nettement plus aisée par toutes les parties. Ceci permettra aussi de mettre par la suite en application la méthode Domain Driven Design qui est très utile sur le long terme.

Alors oui cet exercice peut prendre du temps mais il n’est en aucun cas incompatible avec les méthodologies Agile. Au contraire celles-ci cherchent à encourager un meilleur dialogue entre les différentes équipes. Le tout est de ne pas chercher à tout spécifier dès le départ ! Il faut avoir une idée générale de ce qu’on cherche à faire, la spécifier très grossièrement pour avoir une ligne directrice, mais ça ne sert à rien d’aller au-delà. Ensuite on fait les spécifications suivant les besoins des différents sprints.

Le code : à faire le plus tard possible

Évidemment à un moment il faut se mettre à coder. Cela dit cette phase doit être entamée le plus tard possible, uniquement quand votre interlocuteur a une vision précise de ce qu’il veut et que celle-ci est partagée. Par ailleurs votre interlocuteur se doit d’être disponible à tout moment pour répondre à vos questions, ou que vous lui fassiez des « démos intermédiaires » pour avoir son avis. L’idée est que vous évitiez de devoir faire des hypothèses sur ce que veut votre donneur d’ordres. En effet dans un cas sur deux au minimum celles-ci seront fausses.

Cela dit ce n’est pas parce que vous ne codez pas que vous ne devez pas réfléchir rapidement à comment vous allez faire telle ou telle chose. En fait il faut réfléchir petit à petit à l’implémentation pendant que vous voyez la spécification se faire, pour avoir rapidement les meilleures stratégies de design. Il n’y a rien de pire que de se lancer tête baissée dans le code et se rendre compte qu’on va dans le mur. En procédant de la sorte vous chercherez à un moment ou à l’autre à récupérer le maximum de ce que vous avez fait, et le résultat sera pire. En fait l’idée est de bien réfléchir à la manière dont vous allez coder, car une fois cette étape passer les choses vont dans les faits très vite.

Faites du code facile à refactorer !

Ce n’est pas parce que vous avez un maximum d’informations sur ce que vous devez faire que des changements ne vont pas intervenir. C’est aussi comme ça que fonctionnent les méthodes Agile. Tout ça pour dire qu’il faut bien réfléchir à des moyens de limiter les impacts sur le code en cas de changement, en écrivant du code facile à refactorer ou faire évoluer. Voici un exemple pour faire du filtrage et de la validation avec Spring tout en ayant un code testable et maintenable dans le temps.

Pour vous donner une idée il m’arrive des fois d’arrêter de coder pendant une heure quand je vois que ce que je fais risque de ne pas être maintenable. L’idée est de réfléchir a priori pour gagner du temps par la suite. On m’a demandé il n’y a pas si longtemps de faire de la sérialisation XML et en procédant de la sorte j’ai pu implémenter celle-ci sous la forme d’une suite de one liners, en passant par des méthodes annexes partagées par tout le monde. Bon d’accord Java 8 et ses lambdas m’ont aussi bien aidé. 🙂

En bref

Ne foncez jamais tête baissée dans le code après avoir vu une spécification sur un post-it. C’est une lapalissade, mais je connais bien trop de personnes qui le font encore pour ne pas le répéter.

Quand votre interlocuteur vous demande un développement, forcez-le à s’engager, d’autant plus s’il vous dit que ça ne va pas. D’une ça l’empêchera d’être dans la position facile de la personne qui n’assume rien, mais ensuite ça limitera les tensions de chaque côté du type il n’est jamais content ou encore il fait n’importe quoi. Enfin c’est aussi la garantie d’un code plus maintenable en sortie tout en gagnant du temps au final.

Alors bien sûr quand votre interlocuteur est votre hiérarque ceci peut être un peu plus difficile à tenir, mais dans les faits c’est bien plus important. Vous passerez peut-être au départ pour le c****r de service mais au final quand vous aurez produit exactement ce qui est demandé sans trop d’aller-retours vous donnerez l’image de quelqu’un de fiable sur qui on peut compter.

Débloque les + belles offres tech en 10 mins

Cet article vous a plu ? Vous aimerez sûrement aussi :

• Soyez (vraiment…) agiles
• Quelques règles de survie en SSII en régie
• La démarche DevOps

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.

Son Twitter – Son LinkedIn