Una grande azienda dovrebbe standardizzare gli strumenti di ingegneria in tutti i team a livello internazionale? [chiuso]

Sì, ma deve essere eseguito in modo sensato e non influisce sulla produttività degli sviluppatori a fini di processo.

Esiste sicuramente un caso per la standardizzazione del monitoraggio dei bug / del controllo del codice sorgente in quanto un gran numero di IT aziendali è alquanto isolato e distribuito. Ad esempio, i consulenti potrebbero essere assunti per creare qualcosa per una business unit, il personale interno potrebbe mantenere un sistema legacy e oltre nel quartier generale della Repubblica di Elbonia, un altro team interno sta lavorando qualcos'altro.

Comuni sistemi di controllo dei sorgenti e di tracciamento dei bug, mettono tutti in condizioni di parità e rendono più facile gestire più sistemi. Immagina che il tuo personale di supporto debba imparare 3 diversi sistemi di tracciamento dei bug perché ogni team ha preferito una soluzione diversa. Senza la standardizzazione puoi anche ritrovarti con la situazione dei consulenti che usa il sistema di controllo del codice sorgente X e in-house usando il sistema di controllo del codice sorgente Y (o peggio, nessun SC), che porterà a tutti i tipi di divertimento quando il software sarà completato e la consulenza si muove o fallisce.

Questo non significa sempre che si finirà per standardizzare sul miglior software disponibile, anche se spesso il software scelto si basa su compromessi e praticità piuttosto che avere tutte le funzionalità più recenti e migliori.

La standardizzazione richiede anche buon senso. C'è un livello in cui devi solo consentire allo sviluppatore di andare avanti con il lavoro senza indebite interferenze. Dove risiede questa linea dipende dalla cultura dell'organizzazione, dal tipo di prodotti su cui si lavora e dai fattori normativi.

Il software offre molto più del semplice codice.

Direi nella situazione descritta di seguito.

La mia azienda ha un reparto IT relativamente piccolo che mira a supportare il software utilizzato per gestire la società. L'applicazione è scritta in due lingue, Java e RPG. Usiamo Rational Application Developer (basato su Eclipse) come nostro unico IDE. Ci sono anche altri programmi minori che usiamo, ma quelli sono principalmente la scelta dello sviluppatore se vuole usarli.

I motivi per cui vedo che questo è buono sono, in nessun ordine particolare:

1. Progetti facilmente condivisi. Possiamo salvare tutte le impostazioni del progetto in un file zip e chiunque altro può vederlo senza problemi tra gli IDE.
2. Aggiornamenti IT più semplici. Sì, penso che questo sia un argomento valido - entro la ragione! se questo argomento di "standardizzazione" limita gli sforzi di sviluppo limitando quale software può utilizzare uno sviluppatore quando ne ha assolutamente bisogno, è cattivo. Non è un problema sul mio posto di lavoro perché lavoriamo solo con un paio di basi di codice, quindi le esigenze di tutti sono sostanzialmente le stesse.
3. Il lavoro di squadra è ottimizzato. Se tutti usano strumenti simili, è più facile per chiunque di venire a guardare il tuo codice senza doversi orientare sul tuo IDE. Con la maggior parte degli IDE ora puoi personalizzarli in uno spazio di lavoro che ti piace senza perdere il quadro di riferimento. Tutte le schede della console sembrano uguali indipendentemente dallo schermo sullo schermo.
4. Il passaggio al progetto è più semplice. Qualsiasi sviluppatore può passare a qualsiasi progetto senza dover imparare nuovi metodi per eseguire la metamorfosi come il controllo della versione. Le stesse procedure e software utilizzati ovunque riducono i tempi di cambio di contesto.

In generale, direi che avere tutti gli stessi IDE, controllo delle versioni e software di tracciamento dei bug è una buona cosa e aiuta i team a lavorare meglio. Al di sotto di questo però lo sviluppatore dovrebbe essere libero di usare gli strumenti di cui ha bisogno. Se preferisce TextEdit a Notepad ++, lascia che lo usi - non costerà più. Oppure non costringerlo a utilizzare gli strumenti di query se preferisce connettersi direttamente al database per query semplici.

Devi piuttosto pensare che il tuo processo di sviluppo dovrebbe rendere facile l'uso di qualsiasi strumento disponibile per il tuo progetto.

I motivi sono semplici:

• Devi essere in grado di creare e testare il tuo software automaticamente al di fuori di un IDE.
• Potresti avere una funzione in IDE X che ti serve ma non puoi usare se sei legato a IDE Y. Esempi: editor GUI in NetBeans. Swing debugger in JDeveloper.
• Le procedure acquisite nei file (in modo che possano essere automatizzate) possono essere archiviate in un repository di origine e ricontrollate altrove. Ciò significa che viene acquisita una conoscenza più precisa.
• Lo sviluppo e il test possono avvenire su più piattaforme, consentendo un facile test della compatibilità della piattaforma.

Pensando in questo modo, sei il migliore assicurato contro i venditori che chiudono i prodotti o altri disastri naturali.

C'è un sacco di sforzi sprecati nelle guerre degli strumenti. In un'azienda molto grande, nessuno può mai "vincere" e non vedo alcun vantaggio nel provare veramente.

"Semplifica lo scambio di risorse". Non l'ho mai visto accadere una volta nella mia azienda. Le persone fanno questo argomento, ma i benefici reali realizzati sono molto, molto piccoli. Di solito le risorse non vengono "scambiate" e, se lo sono, non ci vuole molto per imparare la maggior parte di questi sistemi.

"Più facile per l'IT" Non riesco più a vedere questo argomento, dal momento che disponiamo di un team di strumenti SDLC relativamente piccolo che supporta praticamente tutti i principali prodotti del fornitore per decine di migliaia di utenti (su tutti gli strumenti).

Molti singoli team sono più produttivi rispetto a pochi anni fa quando esistevano meno catene di strumenti e molti di essi erano ottimizzati per piattaforme diverse da quello che ogni specifico team stava effettivamente utilizzando; o l'infrastruttura doveva essere locale ( tosse ClearCase tosse ) e la maggior parte della compagnia non poteva nemmeno usarli.

All'interno di un dipartimento posso vedere questo ha un senso. Ci dovrebbe essere un negozio centrale piuttosto che un mucchio di sistemi diversi per cercare bug o codice. Aiuta a cercare in una manciata di diversi sistemi di tracciamento dei bug per trovare problemi? Io non la penso così, ma non penso che tutti i reparti debbano essere forzati sullo stesso sistema che potrebbe non avere senso.

Allo stesso tempo, direi che i dipartimenti sono una soglia ragionevole per la misura in cui un insieme di strumenti dovrebbe andare. Ad esempio, ho lavorato dove l'IT aveva un sistema di tracciamento dei bug e lo sviluppo prodotto aveva qualcos'altro. Lo stesso vale per il controllo del codice sorgente e le lingue.