Le sujet rejoint celui sur le silo dev/test à mon avis (par rapport à la partie mobile vs web).
Dans le fond, est-ce que vous faite un produit ou deux ?
Si la réponse n’est pas la même sur la plan technique et produit, alors il y a un problème. En application de la loi de Conway, si l’équipe est organisée d’une certaine manière, alors cette organisation finira inévitablement par s’appliquer à l’architecture technique de la solution. Si on fait 4 équipes, on fera un compilateur à 4 passes.
Donc si on fait un seul produit (approche back-for-front), on peut avoir une seule équipe, mais l’architecture technique devrait s’aligner. Il serait donc pertinent d’adopter une approche par un développement fullstack. Ainsi il n’y a pas lieu d’élaborer une boundary, le front et le back sont dans la même application et la modification des 2 aspects est atomique du point de vue organisationnel. En plus de résoudre le problème de la synchronisation des membres de l’équipe, ça simplifie la matrice de compétences et ça réduit la complexité technique du produit à fabriquer.
Mais l’inconvénient de l’approche fullstack, c’est qu’elle ferme des opportunités en terme d’intégration. Si on est partis sur une architecture client-serveur, c’est parce qu’on a la (secrète) intention que le back ne soit pas exclusivement appelé par le client. Ainsi, le back mérite son propre design, avec un PO et sa roadmap, et sa propre équipe de développement. Tôt ou tard, les besoins venant du client actuel finiront par devenir les besoins d’un client parmi tant d’autres et il faut s’organiser à l’échelle. En revanche, il faut être clair avec le fait que cette approche coûte beaucoup plus cher car on doit monter 2 équipes.