Répartition du développement verticale ou horizontale ?
Lorsqu’un projet a une taille conséquente, il est nécessaire de répartir les tâches de développement entre les développeurs. Avec le développement multi-couche, cette répartition peut se faire de deux façon différentes :
- L’approche horizontale
- L’approche verticale
Selon Mastering EJB 3rd Edition[1], l’approche horizontale permet d’avoir des personnes ultra-spécialisées dans un domaine technologique correspondant à la couche sur laquelle ils ont l’habitude de travailler. Alors que l’approche verticale permet aux personnes d’obtenir une excellente maîtrise du fonctionnel lié au métier.
La première approche donne naissance à des experts dans des domaines spécifiques. Et avec le second point de vue les intervenants sont des généralistes et progressent dans tous les domaines technologiques.
Par expérience :
- L’approche horizontale :
- rallonge les temps de développements (à cause des problèmes d’intégrations)[2]
- réduit les retours lors de la recette (grâce aux contrôles des n développeurs travaillant sur le même use case et qui confrontent leur avis)
- le planning est plus difficile à organiser et maintenir à cause des dépendances (avec la pyramide des composants, il faut être capable d’ordonnancer correctement les développements) à moins de faire de l’IoC (par exemple avec Spring)
- risque d’ennui des développeurs s’ils sont toujours sur la même couche logicielle
- L’approche verticale :
- optimise les temps de développements
- les développeurs ont une vue d’ensemble du service
- la planification est beaucoup plus simple (grâce au découpage par use case)
- les développeurs progressent dans plusieurs domaines technologiques simultanément[3]
Aucune des deux approches ne semble surpasser l’autre. Personnellement[4], je préfère la répartition horizontale car elle permet d’obtenir une meilleure qualité des développements (d’un point de vue fonctionnel).
Et vous, comment faites-vous ? Quelle approche préférez-vous ?
Notes
[1] Voir le chapitre 20 page 603.
[2] Si les développeurs travaillent toujours sur la même couche, la tendance peut s’inverser (au détriment d’une certain monotonie).
[3] C’est un facteur de motivation non négligeable qui joue également sur la qualité des développements.
[4] Pour avoir expérimenté les deux méthodes.
Sur un projet conséquent, moi je préfère les deux!
Des délégations verticales pour responsabiliser et donner de l’agilité et de la dynamique à l’ensemble.
Un support horizontal (transversal) qui définit le cadre, se focalise sur les points chauds et reste au service du premier, pour garantir la maîtrise d’ensemble.
Je n’ai jamais vu un grand projet réussir sans mener ses deux démarches en parallèle. Par expérience :
– Une approche uniquement horizontale privilégie la qualité mais elle donne de beaux projets technocratiques aux résultats aléatoires quand aux délais (effet tunnel).
– Une approche uniquement verticale privilégie l’aspect fonctionnel. Elle peut éventuellement permettre de délivrer la V1 dans les délais mais laisse généralement un magnifique champ de mines derrière elle pour la V2.
Effectivement Laurent, je partage tes impressions sur tes retours d’expérience. Ton approche qui consiste à mixer la délégation verticale et horizontale est séduisante. Je vais réfléchir à la mise en pratique de ta vision… Mais la taille des projets sur lesquels je travaille actuellement risque d’être bloquante : ils ne sont pas assez important en nombre de ressource.
L’effet tunnel dont tu parles a-t-il un rapport avec la mécanique quantique ?
Non, aucun rapport avec la mécanique quantique. L’effet tunnel est une image utilisée pour désigner le manque de visibilité sur un projet. Par exemple, avec une approche purement horizontale, on peut très bien avoir l’impression d’avoir pratiquement terminé et avoir ensuite de sérieuses déconvenues lors de l’intégration des différentes couches malgré que la qualité individuelle des composants ai été testée et soit irréprochable. On voit toujours le bout du tunnel mais on est incapable de mesurer avec certitude la distance qu’il reste à parcourir pour l’atteindre. C’est ça que j’appelle l’effet tunnel sur un projet.
D’accord, je comprends mieux. Il y a toujours un facteur risque lors de l’intégratrion qu’il ne faut pas négliger avec l’approche horizontale. Et même avec meilleures spécifications interfaces, on est jamais à l’abri d’une mauvaise surprise.