Une entreprise de logiciels devrait-elle avoir une équipe dédiée à la recherche et / ou aux bibliothèques utilitaires?

Je travaille dans une entreprise qui fait des applications Web pour diverses banques et quelques petites boutiques en ligne. Nous employons environ 20 développeurs et avons 4 à 5 projets en développement à tout moment. Nos équipes de développement n'interagissent pas beaucoup et beaucoup des mêmes problèmes se font de différentes manières (bonnes à mauvaises).

Je me demandais si ce serait une bonne idée pour une entreprise d'avoir une équipe de programmeurs qui effectuent des recherches sur les cadres actuels et améliorent continuellement une bibliothèque commune de fonctions et un cadre commun pour construire des projets actuels et futurs beaucoup plus rapidement et plus efficacement.

Quelle devrait être la taille d'une équipe comme celle-ci?

Doit-il également avoir des membres permanents qui forment d'autres personnes ou doit-il faire tourner les gens?

Mise à jour: je pensais à un projet commun sur lequel les gens peuvent travailler pour le plaisir et qui pourraient susciter un certain intérêt. Il semble que lorsque les gens subissent des pressions sur l'emploi, les solutions qu'ils trouvent ne sont pas les meilleures.

Un point important est qu'il est impossible de développer un bon cadre dans un isolement total. De bons cadres sont organiquement développés : quand un programmeur remarque qu'il a besoin de fonctionnalités spécifiques, il les ajoute au cadre, et ainsi le cadre grandit petit à petit - par opposition à l'architecture d'un "cadre parfait" à l'avant, qui ne fonctionne jamais, parce que l'architecte ne peut pas être au courant de tous les cas d'utilisation.

Bien sûr, la croissance organique du cadre présente l'inconvénient que son intégrité interne n'est peut-être pas trop bonne, et il se transforme en spaghetti. Si votre équipe maintient une bonne communication interne, alors vous pourriez être en mesure de combiner le meilleur des deux mondes: une équipe d'architectes distincte préservant l'intégrité du cadre, mais construisant pour les besoins réels des utilisateurs finaux (développeurs).

Mon sentiment est non.

Ce que je soupçonne que vous trouveriez si vous faisiez cela, c'est qu'au lieu d'avoir des équipes individuelles produisant des bibliothèques que personne en dehors de cette équipe n'utilisait, vous auriez une équipe spécialisée produisant des bibliothèques que personne en dehors de l'équipe n'utilisait (et ce faisant à un coût supplémentaire considérable).

Il y a divers problèmes avec le type d'équipe que vous décrivez, mais pour moi, l'essentiel est qu'il ne résout pas le problème que vous avez réellement.

Le problème que vous avez n'est pas de savoir qui produit les bibliothèques (par le son des choses, vous avez déjà de nombreuses solutions à ces problèmes, alors comment une autre va-t-elle aider?), C'est que les équipes ne parlent pas et n'interagissent pas.

Il y a de bonnes raisons pour lesquelles les équipes ne réutilisent pas le code des autres (par exemple, les problèmes tout en étant superficiellement similaires sont subtilement différents, ou que le calendrier du projet ne permet tout simplement pas la dépendance supplémentaire de développer quelque chose ensemble), mais vous devez regardez comment vous pouvez les amener à interagir lorsque cela est possible.

Je suggère:

• faire tourner les équipes entre les projets
• organiser des déjeuners inter-équipes et des groupes de discussion
• revues de projet après avoir passé en revue la façon dont les problèmes ont été résolus (en présence des autres équipes)
• mettre en place une zone du code du wiki qui pourrait être réutilisable (et à qui en parler)
• pensez à encourager une bonne réutilisation - payez sérieusement les gens pour le faire. Si la réutilisation d'un composant permet d'économiser 5 jours et 2000 $ de coûts, pourquoi ne pas donner 200 $ de ce qui est maintenant un bénéfice supplémentaire à l'équipe pour une soirée à la fin du projet (lorsque vous avez validé que l'économie était authentique)

Une équipe de bibliothèques serait, je suppose, des frais généraux sans aucun avantage.

En ce qu'il s'agit d'un projet commun sur lequel les développeurs travaillent pour le plaisir - aucune entreprise ne devrait compter sur des programmeurs travaillant sur des choses à leur propre rythme. Ce ne sont que des heures supplémentaires non rémunérées et, en tout cas, ce n'est pas fiable, car il y aura probablement de grandes périodes où personne ne voudra travailler.

Si vous dites que ce serait des gens qui travailleraient en entreprise entre les projets, alors peut-être que cela pourrait fonctionner, mais je ne pense toujours pas que ce soit le vrai problème. Vous devez encore déterminer comment vous allez amener les gens à utiliser les bibliothèques. Comme je l'ai dit, vous avez déjà des solutions à ces problèmes qui sont développées sur chaque projet, votre problème est pourquoi ne sont-ils pas partagés.

C'est le travail d'un architecte .

Les principales responsabilités d'un architecte logiciel comprennent:

• Limiter les choix disponibles pendant le développement en choisissant un moyen standard de poursuivre le développement d'applications
• créer, définir ou choisir un cadre d'application pour l'application
• Reconnaître la réutilisation potentielle dans l'organisation ou dans l'application en observant et en comprenant l'environnement système plus large
• Création de la conception des composants Connaissance des autres applications de l'organisation

En savoir plus sur: - Architecte logiciel - Architecte de solutions - Architecte d' entreprise .

Le dicton « Manger votre propre nourriture pour chien » résout ce problème. Si votre codeur rockstar top-cool donne naissance à une bibliothèque qu'il n'a jamais utilisée dans la pratique, comment peut-il dire qu'elle est bonne?

Les principales raisons de développer des fonctionnalités dans le cadre sont

1.Il est utile au développeur
2.Il y a quelques cas où il a été utile
3.Il pourrait être utile à d'autres

Lorsque vous avez atteint 2, la fonctionnalité est déjà là, comment pouvez-vous la transmettre à quelqu'un d'autre?

Je suis un peu en retard dans le jeu, mais je sentais que personne ne parlait de cela:

Vos équipes individuelles qui résolvent différents problèmes de différentes manières bénéficieraient certainement de fonctionnalités partagées, et il existe une variété de façons d'obtenir cela d'une manière qui ne consacre pas une seule équipe au développement, mais j'ai vu beaucoup des endroits qui le font.

Dans la plupart des cas, je considère cela comme un «noyau» de votre gamme de produits, et parfois il y a une équipe chargée de la maintenir, dirigée par (comme Amir l'a suggéré) un architecte. C'est généralement ainsi que vous seriez en mesure de trouver des moyens de tirer parti ou de créer un cadre qui suit les normes les plus strictes que vous définissez dans votre organisation, mais ne fournit que les fonctionnalités les plus nues qui peuvent ou non avoir besoin d'être étendues aux applications à part entière que vos équipes produit individuelles proposent. Cela vous permet d'avoir l'avantage de "dogfooding" votre code de base en l'implémentant dans chaque endroit individuel que vous l'utilisez, puis de vous diversifier sur différents produits qui peuvent avoir des implémentations complètement différentes. Cela permet à toutes vos équipes de contribuer aux bibliothèques de base mais pas de l'enliser avec des fonctionnalités dont elles seules ont besoin.

Je pense que ce n'est PAS UNE BONNE IDÉE , car pour que les bibliothèques soient utiles, elles doivent vous aider à résoudre de vrais problèmes de projet, et vous ne les connaissez qu'en, eh bien ... en travaillant dans de vrais projets.

Sinon, vous pouvez terminer avec une très bonne bibliothèque "théoriquement"!

Dans la seule entreprise où je travaillais qui avait vraiment une chose similaire, cela ne semblait pas bien fonctionner. Les gens de l'équipe interne trouveraient une idée géniale et proposeraient un prototype qui a fonctionné principalement, puis il a dépassé le mur et nous devions le transformer en produit.

Ce à quoi je m'attendrais, c'est que le groupe d'outils finirait par utiliser son propre petit programme, produisant des fonctions qui n'étaient pas vraiment très utiles, mais qui encombraient l'API et s'utilisaient suffisamment pour ne pas être facilement supprimé. Ils ne documenteraient pas adéquatement.

Si le groupe d'outils était suffisamment sous la responsabilité d'un architecte système qui était en contact permanent avec les personnes qui utilisent réellement les outils, cela pourrait fonctionner. Si le groupe d'outils tournait fréquemment (ce qui gênerait beaucoup de recherches extérieures), cela pourrait fonctionner. Cependant, j'aurais peur de perdre le contact avec les gens qui font le travail rémunéré.

Combien de temps allez-vous consacrer à débattre de l'utilisation ou non du cadre dans tous les cas? Un projet est-il retardé en attendant que le cadre soit mis à niveau? À un moment donné, l'utilisation du cadre doit être requise pour justifier son existence.