Une croyance qu’on trouve encore parmi de nombreux grands chefs est qu’on peut paralléliser n’importe quelle tâche, quelle qu’elle soit. Il est vrai que neuf femmes ne mettront qu’un mois pour faire un bébé, c’est bien connu non ? En informatique c’est un peu la même chose : il y a la notion de chemin critique et certaines tâches ne peuvent être parallélisées. Par contre il est vrai qu’augmenter la taille des équipes peut être très positif… si c’est bien fait, et nous allons voir comment.
Débloque les + belles offres tech en 10 mins
Mythe : si je suis à la bourre et que je rajoute des gens dans mon équipe, je tiendrai les délais
Le mythe d’ajouter des gens dans une équipe pour tenir les délais quand on est à la bourre a la vie dure… et pourtant rien n’est plus faux. En effet il faut former les nouvelles personnes qui arrivent sur le projet, et ça prend du temps. Bref si de nouvelles personnes arrivent alors qu’un projet connaît du retard, cela risque paradoxalement de ralentir davantage le projet. Un des gros challenges des équipes de taille importante est la communication. Ca peut fonctionner quand les gens maîtrisent bien leur sujet, mais s’ils ne sont pas formés ils ne comprendront pas ce qu’on dit, et donc on aboutira sur du travail mal fait qu’il faudra refaire.
Vous remarquerez au passage que la même chose se produit avec les équipes en offshore, quand les entreprises ne daignent pas mettre en place une rotation de personnes entre le site en offshore et le siège.
L’importance du recrutement
Une bonne équipe se doit d’être homogène. On peut avoir des juniors et des seniors, sans problème. Ce qui importe par contre est que les gens aient globalement un niveau homogène, sinon les meilleurs devront en permanence passer après les moins bons. Et comme souvent dans ce cas les premiers cités s’enfuiront très rapidement, et donc il ne vous restera que les « mauvais ».
Par ailleurs il faut savoir que les bons développeurs coûtent cher. En l’occurrence on obtiendra de bien meilleurs résultats avec dix rockstars du développement qu’avec une centaine de personnes « moyennes », parce que justement les premiers feront bien plus attention au design de leur solution et feront en sorte que celle-ci tienne la route. Par personne « moyenne » je n’entends pas quelqu’un qui ait des connaissances techniques très moyennes, mais plutôt quelqu’un qui n’est pas très rigoureux, du style à dire « bon je corrigerai ça plus tard ». Or on sait bien que dans ces cas-là la correction n’arrive jamais et donc que le projet voit son état se dégrader au fil de l’eau.
Avoir des chiens de garde
Nous l’avons évoqué dans un précédent article mais il est capital d’avoir des chiens de garde dans un projet, dont le rôle est justement de surveiller les commits ainsi que tout ce qui a trait à la qualité du code produit. Ce rôle doit d’ailleurs changer régulièrement afin d’impliquer tout le monde.
Ceux-ci ne devront pas hésiter à « mordre » les personnes qui violeraient les règles et à être fermes, quitte de temps en temps à annuler certains commits. C’est certes désagréable quand ça arrive mais si une personne subit ça deux ou trois fois vous pouvez être sûr qu’ensuite elle fera attention.
Par ailleurs une partie de ce travail peut et doit être automatisée. Ca passe notamment par des tests automatisés, et il sera du travail du chien de garde de vérifier que la couverture ne baisse pas. On peut aussi mettre des points de contrôle au niveau du gestionnaire de version ou encore du serveur d’intégration continue, et faire échouer les builds si la couverture en tests baisse.
Bref tout ça pour dire que sans discipline, le projet deviendra vite ingérable et ce sera pire si la taille d’une équipe augmente.
Le cas des équipes subdivisées
Dans le cas où les équipes sont subdivisées, chaque sous équipe doit avoir un chien de garde intermédiaire, dont le rôle est tournant. Par ailleurs il est bon d’avoir une équipe transverse qui est garante de la cohésion des bonnes pratiques techniques entre équipes, et à laquelle les « chiens de garde » iront se référer en cas de doute. D’autre part cette équipe transverse devra de temps à autres « faire des descentes » sur le code, et contrôler des fichiers pris au hasard, pour vérifier que tout va dans la bonne direction.
Cette équipe aura aussi l’oeil sur tous les témoins de la qualité d’un projet, comme les tests automatisés ou encore les analyses automatiques de code.
L’importance de la documentation
De nombreux projets ne sont pas documentés. Et avec le jeu du turn-over, la raison pour laquelle telle ou telle chose a été faite disparaît et plus personne n’ose toucher au code. Et justement si le projet était correctement documenté, ce genre de point arriverait beaucoup moins.
Alors certaines organisations mettent leur documentation, quand elle existe, sous forme de fichiers Word ou d’un Wiki. C’est une erreur. En effet la documentation vit en même temps que le projet, et rien n’est pire qu’une documentation pas tenue à jour. Par conséquent les informations devraient être mises au plus près de l’implémentation, c’est à dire dans le code lui-même.
Dans les faits les seules documentations devant être sorties du code sont :
- Les spécifications purement fonctionnelles. Pour celles-ci un Wiki paraît être le support idéal, car au moins il sera un minimum versionné.
- Les documents expliquant par où un nouveau développeur doit commencer à mettre le nez dans le projet.
Tout le reste doit être généré à partir du code avec des outils tels que la Javadoc ou Doxygen, et surtout tenu à jour. D’ailleurs dans les checks automatisés sur le gestionnaire de version il est tout à fait raisonnable de contrôler que les classes et méthodes faisant partie de l’API sont documentées. Le contrôle changera suivant la version mais l’idée est là.
Dernier point : agrandir très progressivement les équipes
L’augmentation de la taille des équipes doit être très progressive au cours du temps. Idéalement on ne devrait pas prendre un nouveau développeur tant que le dernier arrivé n’est pas opérationnel. Alors évidemment, dans le cas où un projet est divisé en différentes sous-équipes, ce point s’applique à chaque sous-groupe pris individuellement, et pas à l’ensemble des sous-groupes d’un coup.
Dans le cas contraire les nouveaux venus monopoliseraient le temps des développeurs, et le projet marquerait le pas. Bref si vous êtes vraiment à la bourre vous risquez surtout d’empirer la situation en rajoutant dix personnes d’un coup en renfort…
En bref
Une augmentation d’équipe n’est viable que si la discipline au sein du personnel travaillant sur le projet est forte et garantie. Autrement laissez tomber, l’effet sera contre productif.
Par conséquent soyez très vigilant sur le recrutement, et ne prenez pas quelqu’un simplement parce qu’il n’est pas cher. Un proverbe américain dit d’ailleurs if you pay peanuts, you get monkeys. Ne perdez pas de vue que les bons développeurs coûtent (parfois très) cher. La personne doit adhérer à la discipline en cours, sinon le projet ira mal à terme.
Et dernier point très important : ne faites pas d’augmentation brutale des effectifs. L’appel d’air ainsi créé serait catastrophique à court terme sur les développements, et pourrait avoir d’importantes répercussions à long terme telles que des gens moins bien formés au projet.
Débloque les + belles offres tech en 10 mins
Cet article vous a plu ? Vous aimerez sûrement aussi :
- Développeurs, managers, clients : voici comment mener à bien un projet IT en 4 points clefs
- Les tests automatisés
- Comment un manager peut-il (bien) challenger un développeur ?
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.
