In che modo un grande numero di sviluppatori può scrivere software insieme senza un processo ingombrante o software di scarsa qualità?

Question

Lavoro in un'azienda con centinaia di persone che scrivono software essenzialmente per lo stesso prodotto. La qualità del software deve essere elevata perché così tante persone dipendono da esso (non da ultimo gli sviluppatori stessi). Per questo motivo, ogni problema principale ha portato a un nuovo controllo, automatizzato o manuale.

Di conseguenza il processo di consegna del software sta diventando sempre più gravoso. Ciò richiede più sviluppatori che ... beh, puoi vedere che è un circolo vizioso.

Ora abbiamo un problema con il rilascio del software rapidamente - il tempo di consegna anche per cambiare una riga di codice per un problema molto serio è almeno un giorno.

Quali tecniche utilizzate per accelerare la consegna del software in una grande organizzazione, pur mantenendo la qualità del software?

Answer 1

Io lavoro anche in un'organizzazione grande e ingombrante. Ho avuto successo nell'implementare diverse metodologie agile software development, ma in particolare ne ho trovate due particolarmente preziose.

Sviluppo iterativo e incrementale - Mantenere il ciclo di rilascio breve e serrato. In una squadra numerosa, se vengono apportate numerose modifiche tra una pubblicazione e l'altra, puoi trovarti in un incubo di integrazione.

Le grandi organizzazioni si appoggiano a piani di progetto di grandi dimensioni con tempi di sviluppo lunghi. Combatti questo Pianificare un progetto per un intero anno non ha senso quando l'intera percezione potrebbe cambiare dopo le prime due settimane di sviluppo. Condizionate le vostre parti interessate ad abituarsi all'idea di realizzare piccole versioni incrementali e adattarle a requisiti in continua evoluzione.

Test unità automatizzate - Questo è un ottimo modo per assicurare che si sta rilasciando software di qualità. I peggiori bug sono causati da modifiche apparentemente innocenti del codice che hanno conseguenze non intenzionali altrove. Test unitari completi sono forse il modo migliore per catturare questo tipo di errore. Se puoi passare a test driven development o behavior driven development, ancora meglio.

Qualsiasi organizzazione di grandi dimensioni avrà alcuni sviluppatori mediocri. È un dato di fatto. I test automatizzati delle unità sono un ottimo modo per tenerli d'occhio. Chiedi a uno dei tuoi migliori sviluppatori di scrivere i loro test unitari per loro. Avrai la certezza che almeno il loro codice funziona (anche se è brutto).

Answer 2

Vedi Continuous-Integration

E prega di leggere The Joel Test: 12 Steps to Better Code.

Answer 3

Esistono molti modi per migliorare il processo, ma il componente chiave è modularity. Separando chiaramente le responsabilità (sia nel codice che nell'organizzazione) e definendo interfacce chiare e coerenti, una grande squadra può lavorare con tutti i piccoli team legati tra loro.

Answer 4

Wise ma lugubri parole:

• Fred Brooks: Adding programmers to a late project makes it later.

• Gerry Sussman: i programmatori combinano come resistori in parallelo.

• Qualcun altro: il costo di un progetto è il numero di programmatori moltiplicato per la durata del programma.

Qualcosa che potrebbe funzionare:

organizzare il progetto in modo che ci sia un'applicazione di base costruito da una o due persone, preferibilmente gestite tramite un linguaggio. Quindi lascia che tutti i programmatori siano effettivamente utenti del codice , codificando in quella lingua.

sto pensando di prodotti basate sul linguaggio: SAS, S/R, MATLAB, ecc