Una società di software dovrebbe avere un team dedicato per le biblioteche di ricerca e / o di utilità?

Lavoro in un'azienda che realizza applicazioni web per varie banche e alcuni negozi elettronici di piccole dimensioni. Impieghiamo circa 20 sviluppatori e abbiamo 4-5 progetti in fase di sviluppo contemporaneamente. I nostri team di sviluppo non interagiscono molto e molti degli stessi problemi vengono fatti in vari modi (da buono a cattivo).

Mi chiedevo se sarebbe una buona idea per un'azienda avere un team di programmatori che fa ricerche sui framework attuali e migliora continuamente una libreria comune di funzioni e un framework comune per costruire progetti attuali e futuri molto più velocemente ed efficientemente.

Quanto dovrebbe essere grande una squadra come questa?

Inoltre dovrebbe avere membri permanenti che addestrano gli altri o dovrebbe ruotare le persone?

Aggiornamento: stavo pensando a un progetto comune su cui le persone possono lavorare per divertimento che potrebbe suscitare un certo interesse. Sembra che quando le persone hanno una pressione lavorativa le soluzioni che escono non sono le migliori.

Un punto importante è che è impossibile sviluppare un buon quadro in totale isolamento. Le buone strutture sono organicamente sviluppate : quando un programmatore nota che ha bisogno di alcune funzionalità specifiche, le aggiunge alla struttura, e quindi la struttura cresce poco a poco - al contrario dell'architettura di un "quadro perfetto" che non funziona mai, perché l'architetto non può essere a conoscenza di tutti i casi di utilizzo.

Naturalmente, la crescita organica del framework ha il rovescio della medaglia che la sua integrità interna potrebbe non essere troppo buona e si trasforma in spaghetti. Se il tuo team mantiene una buona comunicazione interna, potresti essere in grado di combinare il meglio di entrambi i mondi: un team di architetti separato mantenendo l'integrità del framework, ma costruendo per le reali esigenze degli utenti finali (sviluppatori).

La mia sensazione è no.

Ciò che sospetto che scopriresti se lo facessi è che invece di avere singoli team che producono librerie che nessuno al di fuori di quel team ha usato, avresti un team specializzato che produce librerie che nessuno al di fuori del team ha usato (e farlo a costi aggiuntivi considerevoli).

Ci sono diversi problemi con il tipo di squadra che descrivi, ma per me il principale è che non affronta il problema che hai effettivamente.

Il problema che hai non è chi produce le librerie (dal suono delle cose hai già molte soluzioni a questi problemi, quindi come si può aiutare ancora una volta?), È che i team non stanno parlando e interagendo.

Ci sono buoni motivi per cui i team non riutilizzano il codice a vicenda (ad esempio che i problemi, seppur superficialmente simili, sono leggermente diversi, o che i tempi del progetto non consentono l'ulteriore dipendenza di sviluppare qualcosa insieme), ma è necessario guarda come puoi farli interagire quando è possibile.

Suggerirei:

• ruotare i team tra i progetti
• tenere pranzi inter team e gruppi di discussione
• dopo la revisione del progetto, esaminando come i problemi sono stati risolti (frequentato dagli altri team)
• impostare un'area del codice delineamento della wiki che potrebbe essere riutilizzabile (e con chi parlarne)
• pensa a incentivare un buon riutilizzo - in realtà paga davvero le persone extra per farlo. Se il riutilizzo di un componente fa risparmiare 5 giorni e $ 2000 di costi, perché non dare $ 200 di quello che ora è un profitto extra al team per una serata fuori alla fine del progetto (quando hai convalidato il risparmio è stato autentico)

Un team di biblioteche sarebbe, sospetto, sovraccarico senza alcun vantaggio.

Dal momento che si tratta di un progetto comune su cui gli sviluppatori lavorano per divertimento - nessuna azienda dovrebbe fare affidamento sui programmatori che lavorano sulle cose nel proprio tempo. Questo è solo un lavoro straordinario non retribuito e, in ogni caso, non è affidabile in quanto vi saranno probabilmente periodi estesi in cui nessuno vuole lavorare sulle cose.

Se stai dicendo che sarebbero le persone che lavorano nel tempo aziendale tra i progetti, allora forse può funzionare, ma continuo a non pensare che sia il vero problema. Devi ancora capire come convincerai le persone a usare le librerie. Come ho già detto, hai già soluzioni a questi problemi che vengono sviluppati su ogni progetto, il tuo problema è perché non vengono condivisi.

Questo è il lavoro di un architetto .

Le principali responsabilità di un architetto del software includono:

• Limitare le scelte disponibili durante lo sviluppo scegliendo un modo standard di perseguire lo sviluppo di applicazioni
• creare, definire o scegliere un framework di applicazione per l'applicazione
• Riconoscere il potenziale riutilizzo nell'organizzazione o nell'applicazione osservando e comprendendo l'ambiente di sistema più ampio
• Creazione del design del componente Conoscenza di altre applicazioni nell'organizzazione

Ulteriori informazioni su: - Architetto software - Architetto soluzioni - Architetto aziendale .

Il detto " Mangia il tuo cibo per cani " risolve questo problema. Se il tuo fantastico programmatore rockstar dà alla luce una libreria che non ha mai usato in pratica, come può dire che è buona?

Le ragioni principali per sviluppare funzionalità in framework sono

1. È utile per lo sviluppatore
2. Ci sono alcuni casi in cui è stato utile
3. Potrebbe essere utile ad altri

Quando hai colpito 2, la funzionalità è già lì, come puoi passarla a qualcun altro?

Sono un po 'in ritardo al gioco ma mi sembrava che nessuno si stesse occupando di questo:

I tuoi singoli team che stanno risolvendo problemi diversi in modi diversi trarrebbero sicuramente vantaggio dalla funzionalità condivisa e ci sono una varietà di modi per ottenerlo in un modo che non dedichi un singolo team allo sviluppo, ma ho visto molto dei luoghi che lo fanno.

Nella maggior parte dei casi, vedo questo definito come un "nucleo" della tua linea di prodotti, e talvolta c'è un team incaricato di mantenerlo, guidato da (come suggerito da Amir) un architetto. Questo è in genere il modo in cui saresti in grado di trovare modi per sfruttare o creare un framework che segua gli standard più rigorosi che imposti nella tua organizzazione ma fornisca solo le funzionalità più nette che potrebbero o non potrebbero essere estese nelle applicazioni complete che offrono i singoli team di prodotto. Ciò ti consente di avere il vantaggio di "dogfooding" il tuo codice di base implementandolo in ogni singolo posto in cui lo usi, e quindi di diramare a diversi prodotti che possono avere implementazioni completamente diverse. Ciò consente a tutti i tuoi team di contribuire alle librerie principali ma non di impantanarsi con funzionalità di cui solo loro hanno bisogno.

Penso che NON sia UNA BUONA IDEA , perché per essere utili le biblioteche devono aiutarti a risolvere i problemi di progetto reali e puoi conoscerli solo lavorando bene in progetti reali.

Altrimenti puoi finire con una libreria "teoricamente" molto buona!

Nell'unica società in cui ho lavorato che aveva una cosa simile, non sembrava funzionare bene. Le persone nel team interno avrebbero avuto un'idea chiara e avrebbero avuto un prototipo che ha funzionato per lo più, quindi è andato oltre il muro e ci aspettavamo di trasformarlo in un prodotto.

Quello che mi aspetto che accada è che il gruppo di strumenti sarebbe finito andando sul suo piccolo programma, producendo funzioni che non erano poi così utili, ma che ingombravano l'API e si usavano abbastanza da non poter essere facilmente rimosso. Non documenterebbero adeguatamente.

Se il gruppo di strumenti fosse sufficientemente sotto un architetto di sistema che era in continuo contatto con le persone che effettivamente utilizzavano gli strumenti, potrebbe funzionare. Se il gruppo di utensili ruotasse frequentemente (il che ostacolerebbe fare molte ricerche esterne) potrebbe funzionare. Tuttavia, avrei paura di perdere il contatto con le persone che svolgono il lavoro retribuito.

Quanto tempo passerai a discutere se l'utilizzo del framework sarà o meno un vantaggio in tutti i casi? Un progetto viene ritardato aspettando l'aggiornamento del framework? Ad un certo punto l'uso del framework deve essere richiesto per giustificare la sua esistenza.