Lorsque nous demandons à un développeur s’il est full stack, sa réponse est généralement “Oui ! Mais… plutôt spécialisé dans … telle partie”.
Dans le cadre d’un projet informatique Agile, nous recherchons souvent des développeurs full stack. Mais, que signifie ce terme et que peut-il apporter au projet ?
Nous allons voir dans un premier temps ce que signifie stack et les raisons mises en avant pour la composition d’une équipe de personnes full stack. Puis, nous verrons sa mise en place dans le cadre d’un projet informatique au travers d’un exemple.
Qu’est ce qu’une “Stack” ?
Une “stack” est une pile comprenant l’ensemble des couches nécessaires à la réalisation d’un projet informatique. Chacun de ces éléments ou couche constitue donc la “stack”. On peut par exemple parler de stack technique, si nous ne faisons référence qu’aux couches techniques d’un projet.
Très souvent, quand nous parlons de développeur full stack, nous sommes tentés de privilégier uniquement les couches techniques et notamment les couches “front” et “back”. Mais il serait dommage de se limiter aux seuls aspects techniques. En effet, les compétences dites “soft skills” sont également importantes et particulièrement en milieu agile.
Une liste (non exhaustive) d’éléments composant une “stack” pourrait être :
L’idée d’une équipe full stack est donc que chaque membre de l’équipe de développement puisse intervenir sur chaque couche de la “stack” au sein d’un projet informatique. En conséquence, dans le cas d’un projet Agile (où les développeurs sont auto-organisés et ont une responsabilité plus large que sur un projet cycle en V), un développeur peut donc :
- traiter une User Story de bout en bout en cours de sprint (compréhension fonctionnelle, développement des différentes parties techniques, etc.) ;
- relire et valider le travail d’un autre développeur.
- intervenir sur les sujets fonctionnels
Avantages supposés d’une équipe full stack
Maintenant que nous avons défini les éléments, essayons de comprendre les raisons de ce choix.
Sur le papier, cette méthode offre beaucoup d’avantages dont les principaux sont :
- la simplification de l’organisation, car chaque développeur peut intervenir sur chacun des sujets ;
- la possibilité d’accroître simplement la charge de développement en augmentant le nombre de développeurs ;
- une meilleure implication des développeurs qui auront en charge des User Stories complètes, permettant ainsi une meilleure visibilité fonctionnelle grâce à la réalisation de tâches techniques dans des domaines différents (et non pas un seul).
Mais tout cela est-il si simple ? Qu’en est-il en pratique ?
Pour répondre à ces questions, il est nécessaire d’aborder ce qu’on entend par “intervenir sur chaque couche”.
Un développeur full stack doit pouvoir intervenir sur chacune des couches d’une “stack” ?
Qu’entendons-nous par cette assertion ? Un développeur doit-il travailler sur chaque sujet ? Si oui, doit-il avoir un niveau de compétence équivalent sur chaque couche ?
La réponse est non. Il est très compliqué pour un développeur d’être compétent et autonome sur chaque couche.
Quand nous parlons de profil full stack, cela signifie que le développeur est spécialisé dans certains domaines, tout en ayant des connaissances sur d’autres sujets. En général, nous considérons un développeur full stack comme maîtrisant au moins 3-4 sujets. Mais cela ne couvre pas l’ensemble des besoins.
Après avoir analysé ces points, nous comprenons bien les réticences des développeurs à se considérer full stack car chacun a ses préférences, ses domaines de prédilection et peut difficilement maîtriser toutes les couches d’un projet informatique.
Prenons un exemple
Maintenant que nous avons passé en revue ces différents éléments, intéressons-nous à sa mise en place dans un projet informatique.
Pour illustrer ces propos, prenons l’exemple d’un projet informatique qui démarre avec la même stack que précédemment :
Le schéma ci-dessous permet de visualiser les compétences d’un développeur sur l’ensemble de cette stack :
Dans cette situation, nous voyons bien que le développeur est full stack car il a des connaissances dans 90% des sujets et en maîtrise au moins 4.
Cependant, cela ne permet aucunement d’en conclure qu’il est capable d’intervenir sur des sujets pointus dans chaque domaine. Par exemple, il ne sera pas en mesure – ou éprouvera des difficultés – à répondre à une demande complexe concernant la partie front.
Maintenant, imaginons que l’équipe soit composée de deux développeurs et que nous souhaitons couvrir, au mieux, tous les sujets du projet. Nous obtiendrions, par exemple, le schéma suivant (en bleu, le premier développeur et en jaune le second) :
Dans cette hypothèse, les deux développeurs full stack se complètent et la combinaison de leurs compétences permet de couvrir l’ensemble des besoins du projet. De plus, ces deux développeurs ont la capacité de revoir leurs codes respectifs et de monter en compétence sur des sujets qu’ils maîtrisent moins.
Si nous nous projetons sur une équipe plus importante, quel serait le résultat attendu ?
Nous pouvons résumer cela par cette phrase : “Pour chaque couche de la stack, avoir au moins deux personnes qui la maîtrisent”
Pourquoi deux développeurs ? Tout simplement pour que l’équipe ne soit pas bloquée lorsque l’un des deux est absent (congés, arrêt, maladie…).
Une digression reste cependant possible. En effet, les besoins existants dans chaque projet informatique n’impliquent pas le même niveau de complexité sur chaque couche. Nous pouvons imaginer dans notre exemple que la partie “API” est très légère et “standard”, donc qu’elle n’aura pas besoin de fortes compétences. On sera donc moins exigeant vis à vis de l’équipe sur ce point (en terme de niveau de compétence ou de backup).
Résumé
Comme nous venons de le voir, la composition d’une équipe full stack est plus complexe qu’associer uniquement des développeurs dits full stack. Il est nécessaire d’analyser les spécialités de chaque développeur qui constitue l’équipe afin d’avoir une cohérence face aux challenges du projet.
Le risque de n’avoir pas une équipe aux compétences suffisamment variées, est que la réponse technique sera potentiellement le fruit de l’expérience des membres plutôt que la meilleure réponse possible. Par exemple, s’il manque un expert UX, les développeurs pourraient être tentés de trouver des solutions techniques à un problème d’ergonomie.
Une autre remarque importante : il est difficile d’avoir une organisation idéale dès les premières itérations du projet. N’avoir qu’une personne maîtrisant un sujet au début peut être un risque accepté si des montées en compétences sont prévues au sein de l’équipe.
Conclusion
Notons également que les dernières années montrent une explosion des nouvelles technologies / librairies et qu’il devient de plus en plus difficile pour un développeur d’être full stack. C’est le cas sur la partie front qui évolue rapidement, mais aussi avec les problématiques spécifiques du Big Data qui nécessite une connaissance pointue sur les outils du domaine et les bonnes pratiques. La spécialisation sera donc toujours nécessaire et devrait s’accentuer à l’avenir.
Quant au mot full stack, il serait alors utilisé comme un terme marketing auquel le développeur essaie de se conformer. En d’autres termes, un développeur se déclarant full stack le fait-il plus par obligation ou par choix ?
