L’agilité / Scrum dans le quotidien du développeur

Aujourd’hui beaucoup de personnes se sont frottées à l’agilité dans le milieu de la tech. On en a tous plus ou moins entendu parler, de près ou de loin. Mais au delà de coller des post-it et faire des daily meeting, l’agilité a un certain impact chez les développeurs. Après plus de deux ans passé dans le domaine industriel, j’ai intégré le monde du web au sein d’une équipe agile (pour de vrai) et j’ai pu constater un certain nombre de changements dans mon métier.

Quels impacts l’agilité peut-elle avoir dans le quotidien du développeur ?

Des cycles de développement plus courts

C’est une des principales différences : on passe d’un cycle de plusieurs mois à quelques semaines. D’une part, cela donne un aspect “flux tendu” : cela force le développeur à se concentrer sur l’essentiel et surtout sur ce qui va apporter le plus de valeur au produit. On a toujours des choses à implémenter, à améliorer, mais ici on devra d’abord s’occuper de ce qui donne la plus grosse valeur ajoutée.

Le fait de ne se concentrer que sur le besoin courant fait qu’on va éviter d’ajouter du code inutile : le produit est construit de manière itérative et incrémentale. C’est également ce qui va faire que l’architecture va se faire petit à petit, au fur et à mesure que les besoins vont émerger. Attention, ce n’est pas parce qu’on doit aller à l’essentiel que cela doit nous empêcher de coder proprement. On peut très bien faire du refactoring, régler de la dette technique, etc. Il faut juste avoir conscience que ce genre de tâche impactera le livrable du cycle actuel.

Opter pour des cycles de développement plus courts permet également d’impliquer plus souvent les parties prenantes et donc de s’assurer que le produit reste en adéquation avec leurs attentes (plutôt que de constater 6 mois après qu’en fait le client ne voulait pas de ceci mais plutôt de cela).

Le Product Owner est votre meilleur ami

Ce qu’on cherche c’est coller au mieux au produit souhaité par les parties prenantes, et la personne qui sait cela, c’est votre Product Owner (PO). C’est la personne qui connaît le mieux le produit et ce qui lui octroiera de la valeur. Vu que le PO est la principale source d’alimentation des différentes tâches à réaliser, il ne faut pas hésiter à le consulter le plus souvent possible. Cela permet d’être raccord entre ce que vous êtes en train d’implémenter et ce qui est demandé. Echanger sur une tâche / un item vous permettra de mieux comprendre le besoin.

Si on comprend ce qu’on doit faire, on l’implémente mieux.

C’est une réflexion simple mais il faut toujours la garder en tête et ne pas hésiter à solliciter ceux qui pourraient vous apporter des réponses.

… Mais il n’est pas dans l’équipe de dev

Un PO avec un passé technique peut, en suggérant des solutions techniques, ancrer un développeur sur ses choix de conception. Il faut rester ouvert d’esprit et accepter l’idée si elle semble pertinente. Cependant, il vaut mieux l’évaluer avant de l’accepter. Si l’idée est mauvaise, ce n’est pas parce que c’est votre PO que vous devez adopter sa solution (sauf si le besoin métier le requiert). Vous êtes membre de l’équipe de dev, qui est auto-organisée, c’est donc à vous de faire les choix techniques et conceptuels. D’ailleurs…

L’auto-organisation

C’est selon moi un des points les plus bénéfiques à une équipe de dev. Nul n’est censé vous imposer quelconque façon de faire, comment vous organiser, comment coder, etc. L’équipe est censée se gérer toute seule, accompagnée par le Scrum Master ou un rôle de “facilitateur” équivalent. L’idée derrière cette notion est que pour avoir l’équipe la plus efficace possible, il faut la laisser s’organiser comme elle le souhaite car tous les ajustement ou bonnes pratiques se décideront en son sein. Vous pouvez donc oublier le chef qui va imposer telle façon de coder, ou telle librairie. Attention cependant, ce n’est pas parce que l’équipe est auto-organisée qu’elle doit refuser tout conseil venant de l’extérieur. Il faut prendre en compte l’expérience de chacun et rester ouvert d’esprit.

Préparez votre stock de post-it

Eh oui, les post-it, souvent perçus comme un cliché de l’agilité, permettent de garder une trace de l’avancement du Sprint en cours (à faire, fait, etc.) et de synthétiser des idées lors des Sprint retrospectives. Cela peut sembler stupide, mais que vous utilisiez du vrai papier ou un site Internet, cela permet de concrétiser des tâches et actions.

Des experts avant tout

Je ne suis pas développeur senior, et il est vrai que dans l’agilité on considère souvent une équipe de dev comme étant composée uniquement d’experts. Alors à défaut d’en être un, il vaut mieux en avoir un, sans quoi la vélocité de l’équipe risquera d’en pâtir. En effet, il vous tirera la plupart du temps vers le haut et vous apportera des solutions efficaces. Il ne faut pas pour autant négliger votre propre capacité d’innovation : vous devez développer votre propre intelligence (professionnelle) afin de gagner en efficacité et en force de proposition, sans quoi vous manquerez d’autonomie.

“C’est évident”.

Pour terminer, on dit souvent que dans l’agilité il y a beaucoup de bon sens, il y a une part de vrai. Elle permet selon moi de mieux diriger le processus de développement en recentrant les besoins sur ce qu’ils sont réellement et ainsi s’assurer que la portée des actions faites correspond bien à celle attendue par les parties prenantes.

TL;DR

Pratiquer l’agilité en tant que développeur a pour conséquence… l’agilité : elle permet de s’adapter plus facilement aux besoins, prioriser les tâches, et s’améliorer au quotidien.

--

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jimmy Audebert

Jimmy Audebert

More from Medium

What software can learn from moving 11,500 miles of 1880’s railroad

Windows -Azure Enrollment to Workspace ONE UEM for Organization using Okta as IdP

Agile — Why, When and How to Estimate

What Does It Take to Have a Great Agile Team?