C'est en fait assez penible a appliquer completement. Autant il est possible de s'arranger pour qu'une majorite des equipes ne voit de la solution adoptee que l'interface du coeur de cette appli. Autant il est quasiment impossible de "modulariser" le coeur, car c'est generalement un bloc monolithique.
En d'autres termes le dev du GUI ou du plugin Oracle peuvent se faire sans rien connaitre de la solution, mais pour le gros morceau il faut qu'il y est communication(sinon on joue a un jeu qui s'apelle l'interface du jour, ou tous les jours suite a une demande minime du groupe d'a cote on se retrouve a reecrire tous les headers et toutes les interfaces de sa partie).
De plus les projets les plus demandeurs de R&D ne sont pas forcement tous de gros projets, bien au contraire. Une micro appli pour plateforme embarquee, un codec, un repartiteur dynamique de flux necessitent souvent des annees/hommes de tests pour au final arriver avec un produit qui prend moins de 2Mo en memoire. Su run programme aussi physiquement petit, une repartition en sous equipes et sous-sous equipes n'aurait aucun sens
[^] # Re: Droit d'auteur et travailleurs
Posté par Jerome Herman . En réponse à la dépêche Droit d'auteur et travailleurs. Évalué à 2.
En d'autres termes le dev du GUI ou du plugin Oracle peuvent se faire sans rien connaitre de la solution, mais pour le gros morceau il faut qu'il y est communication(sinon on joue a un jeu qui s'apelle l'interface du jour, ou tous les jours suite a une demande minime du groupe d'a cote on se retrouve a reecrire tous les headers et toutes les interfaces de sa partie).
De plus les projets les plus demandeurs de R&D ne sont pas forcement tous de gros projets, bien au contraire. Une micro appli pour plateforme embarquee, un codec, un repartiteur dynamique de flux necessitent souvent des annees/hommes de tests pour au final arriver avec un produit qui prend moins de 2Mo en memoire. Su run programme aussi physiquement petit, une repartition en sous equipes et sous-sous equipes n'aurait aucun sens
Kha