Quand nous construisons quelque chose, aucune journée ne se ressemble, mais la forme reste généralement la même. Il faut :
analyser de façon détaillée les besoins fonctionnels et techniques du client, grâce à des réunions et des recherches ;
imaginer et structurer la solution, puis la faire valider par le client ;
implémenter (créer) la solution, la tester et rédiger la documentation associée, pour faciliter la compréhension de chacun ;
mettre la solution en production (en ligne), puis la maintenir et la faire évoluer.
Le développeur peut également :
rencontrer directement le(s) client(s) pour leur poser des questions et les inclure le plus possible au cœur du projet ;
former les utilisateurs et/ou le client à utiliser correctement la solution ;
former d’autres développeurs à intervenir sur la solution.
La compréhension du besoin
Avant d’implémenter une solution, il faut y réfléchir. Il est primordial de comprendre le besoin de son utilisateur pour y répondre de la meilleure façon possible. Être développeur, c’est avant tout être créatif. L’entreprise vous paie pour résoudre ses propres problèmes ou ceux de ses utilisateurs.
Un besoin peut être exprimé sous forme de cahier des charges, de user story ou de backlog.
Un cahier des charges permet au client d’indiquer au développeur ce qu’il attend de lui. C’est un document contractuel à respecter.
Une user story est une demande de fonctionnalité à réaliser, basée sur un besoin utilisateur.
Un backlog est une liste, ordonnée par priorité, de toutes les fonctionnalités d’un projet à réaliser par une équipe.
La base de tout projet commence par une bonne compréhension des besoins. Il faut ensuite imaginer une solution en répondant à tous les problèmes avant même de se mettre à coder.
Mettez-vous à la place de l’utilisateur final, discutez et échangez au maximum.
Une fois la solution en tête, il faut la découper en plusieurs phases puis créer un planning précis comprenant une date de début et de fin du projet et de chacune des phases, les dates de revue, de test et de mise en production. Tout doit être pris en compte, même le moment où vous risquez de bloquer toute une après-midi sur un problème bateau (cela arrive souvent).
Votre plan est validé et le projet est cadré. Découpez chaque phase en plusieurs issues (tâches) à réaliser.
En fonction de votre statut et de votre expérience, il se peut que quelqu’un d’autre effectue ce travail et qu’il vous attribue directement des issues à réaliser. Il se peut également que vous soyez à l’origine de tout ce processus (Cf. partie Freelance).
Vous êtes prêt à attaquer.
Les méthodes agiles
Parmi toutes les méthodes de gestion de projet en entreprise, la plupart des projets qui concernent un développeur utilisent les méthodes agiles, dont une méthode plus particulière et très populaire actuellement : la méthode Scrum.
Pour faire simple, en méthode agile on développe une version simpliste de l’application, on vérifie que ça plaît à tout le monde, puis on l’améliore en ajoutant des fonctionnalités ; et on recommence autant de fois que nécessaire.
Ces méthodes sont tirées du Manifeste Agile. Elles reposent sur quelques valeurs fondamentales :
l’équipe et l’échange : "Personnes et interaction plutôt que processus et outils" ;
le bon fonctionnement : "Logiciel fonctionnel plutôt que documentation complète" ;
l’implication du demandeur : "Collaboration avec le client plutôt que négociation de contrat" ;
la souplesse : "Réagir au changement plutôt que suivre un plan".
Chaque tâche à réaliser est listée par ordre de priorité dans un backlog.
Toutes les phases du projet sont regroupées en plusieurs itérations de développement appelées “sprints”.
À chaque fin de sprint, une fonctionnalité importante doit être terminée puis présentée au demandeur. Si elle est validée, elle sera alors considérée comme faite et plus à faire. Puis un autre sprint commencera, jusqu’au moment ou le produit fini collera exactement aux attentes du demandeur.
Rentrons dans le cœur de la méthode Scrum en analysant une journée type d’un développeur en sprint.
Une journée type dans la peau d’un développeur
Des issues à résoudre vous seront assignées régulièrement.
La journée commence par la prise en compte des nouvelles issues, de vos e-mails et des potentielles mises à jour effectuées par les autres développeurs (vos collègues).
Plusieurs réunions vont avoir lieu pendant le sprint, dont une réunion quotidienne : le daily scrum. Cette réunion lance votre journée de travail, elle ne doit pas durer plus de 15 minutes et se déroule debout pour être le plus efficace possible.
Le but est de tenir toute l’équipe informée sur l’avancement du projet dans sa globalité. Un par un, chacun des acteurs va expliquer ce qu’il a réalisé la veille, quels problèmes il a rencontrés, et ce qu’il fera aujourd'hui.
Le daily scrum permet d’identifier rapidement chaque retard ou problème pour prendre les mesures nécessaires.
Toute la journée, un développeur peut jongler entre plusieurs tâches, comme collaborer avec un designer avant de se lancer dans le code.
Votre chef de projet vous assignera une tâche, et le designer (si votre équipe dispose d’un designer) vous dira à quoi elle doit ressembler une fois terminée. Le rôle du designer est de penser à la place de l’utilisateur final. Il imaginera le rendu le plus simple et efficace pour ce dernier. Vous n’aurez plus qu’à le traduire.
Répondre aux mails
Qu'ils viennent de votre boss, de votre chef de projet, des clients ou des utilisateurs, il faut traiter les mails à un moment. Certains mails feront parfois passer une tâche en priorité. Soyez agile !🏌️♂️
Débloquer un collègue dans son code
Vous, comme vos collègues, allez vous retrouver bloqué à un moment. Pendant plusieurs heures et parfois même quelques jours. Vous serez souvent seul sur une tâche, mais rarement seul sur un projet. Développez votre esprit d’équipe 👨👨👦👦.
Lorsque nous bloquons sur un problème sans trouver notre réponse sur Internet, avoir un autre œil qui se penche sur notre code aide souvent à trouver une solution.
Il m’est arrivé de rester bloqué sur un problème pendant plus de 2 heures en regardant au mauvais endroit, en ayant scruté tous les forums possibles, pour qu’un collègue arrive derrière moi et me dise en moins d’une minute : “Ajoute un point virgule à la ligne 202” 🤷♂️. Tellement persuadé que cette erreur venait d’ailleurs, j’avais oublié de regarder la base.
Consulter les logs
C'est dans les logs que le développeur trouvera exactement d’où peut venir une erreur.
Coder… il faut
Vous l’avez sûrement compris : le métier de développeur, ce n’est pas que d’écrire des lignes de code dans son coin. Il faut aussi savoir être autonome et concentré lorsque nous réalisons une tâche.
Tester son code
Cela peut paraître évident, mais le code que nous créons doit fonctionner ! Pour cela, il est recommandé de le tester régulièrement. Un bon développeur passe au moins autant de temps à tester qu’à coder. Il est donc primordial de tester son code au fur et à mesure, une fois la tâche terminée, et une fois la tâche intégrée dans l’intégralité du projet.
Être autonome, c’est savoir se débrouiller seul : chaque membre de votre équipe sera en train d’effectuer une des tâches citées plus haut. Vous ne devez les déranger que si vous n’avez pas d’autres solution. Si vous ne respectez pas cette règle, vos collègues vous enverront un lien Google vers votre réponse, ou pire.
Plusieurs fois, mes collègues m’ont envoyé des liens “LET ME GOOGLE THAT FOR YOU” ("Laisse-moi chercher sur Google pour toi") pour me faire comprendre que je leur faisais perdre leur temps. Ils ne faisaient que recopier ma question mot pour mot, et il faut avouer que cela marche bien. Au bout de 2 ou 3 fois, on ne pose plus aucune question sans être sûr que la réponse n’est pas sur Google !
En résumé
Dans ce chapitre, nous avons vu que :
le développeur doit avant tout comprendre le besoin au mieux pour réfléchir à la meilleure solution possible ;
pour chaque étape de réalisation d’un projet, il faut se mettre à la place de l’utilisateur final au maximum ;
la méthode de gestion de projet la plus utilisée en entreprise s’appelle la méthode Scrum. Elle provient des méthodes agiles ;
les méthodes agiles sont tirées du Manifeste Agile qui repose sur 4 valeurs fondamentales : l’équipe et l’échange, le bon fonctionnement, l'implication du demandeur, la souplesse ;
chaque projet est découpé en plusieurs grandes phases appelées sprints ;
chaque sprint est composé de plusieurs tâches à réaliser, aussi appelées issues ;
chacun des développeurs du projet se voit assigner plusieurs issues à résoudre ;
tous les matins, lors d’une réunion appelée daily scrum, chaque développeur explique ce qu’il a fait la veille, ainsi que ses points bloquants, pour identifier rapidement chaque retard ou problème ;
toute la journée, le développeur jongle entre plusieurs tâches : répondre aux e-mails, venir en aide à un collègue, consulter l’historique des opérations (logs) pour trouver la source d’erreurs, coder et tester son code.
Dans le prochain chapitre, nous verrons quelles sont les soft skills (compétences transversales) et les hard skills (compétences techniques) des développeurs.
