Produzione vs sviluppo software [chiuso]

Si dice spesso che l'industria del software sia immatura rispetto alla produzione. In particolare per quanto riguarda il processo guidato.

Domanda : Come sviluppatori possiamo imparare dai processi dell'industria manifatturiera? L'adozione dei loro processi può aumentare il tasso di successo dello sviluppo del software?

La mia opinione : nella produzione la creazione di un prodotto è fortemente guidata dal processo. Puoi avere una fabbrica in cui ogni persona ha una serie specifica di compiti che segue. Un lavoratore (o robot) può stringere una vite per tutto il giorno. Quindi l'attività successiva nel processo viene eseguita dal prossimo specialista. I lavoratori (e i robot) non dissuadono dal processo o inventano qualcosa "al volo". Le parti cambiano attraverso il processo e l'output è un prodotto finito. Funziona bene e le aziende ottengono prodotti privi di difetti al 99,99966%. Le aziende risolvono le inefficienze nel tempo. Questo è impressionante e molto bene potrebbe essere il segno di un'industria matura.

Nella produzione un processo definito può letteralmente creare il prodotto finito. Non credo sia il caso del software. Potremmo avere processi per il controllo del codice sorgente, la revisione del codice, i fogli di controllo, la raccolta dei requisiti, l'SDLC, ecc. Ma l'esecuzione di tali processi non crea di per sé un prodotto finito. Questi processi possono essere utili, ma sono ortogonali alla creazione effettiva.

Supponiamo che la tua azienda sia contratta per creare software che cercherà milioni di immagini per trovare i volti di un criminale. Nonostante l'ambiente pesante guidato dai processi, lo sviluppatore deve impegnarsi a creare cose "al volo". Fare le cose al volo è contro lo spirito di produzione. Un buon processo di fabbricazione può essere eseguito senza pensare da un robot.

Per la creazione di algoritmi complessi che devono ancora essere immaginati nella mente di un essere umano, è necessario creare cose al volo. Lo sviluppo del software non è il seguito di un processo, ma la creazione di un processo che deve essere spiegato da un computer. Questa è una differenza fondamentale. Indipendentemente da quanti processi ortogonali mettiamo in atto per lo sviluppo, ricorreremo sempre a farlo "al volo" quando si tratta di creazione.

Tutti quelli con cui parlo sembrano essere d'accordo con la mentalità manifatturiera. Sono solo nei miei pensieri?

La differenza fondamentale tra lo sviluppo del software e la produzione è che per il software, la fase di progettazione è praticamente l'intera cosa. La produzione effettiva (parte della catena di montaggio nella produzione tradizionale) consiste nel copiare alcuni file in giro. Nel software, il design del prodotto è il prodotto.

Quindi sì, possiamo imparare dai processi di produzione, ma solo se teniamo presente che dobbiamo guardare alla fase di progettazione, non alla fase di produzione e che molti processi di produzione sono costruiti per far fronte ai limiti specifici di una costosa catena di produzione , che semplicemente non si applica al software.

Un esempio di un modello di processo che funziona molto bene nel software, ma spesso fallisce in modo orribile nella progettazione del prodotto, è il design iterativo: inizi con un prototipo minimo e aggiungi funzionalità ad ogni iterazione. Costruire un'auto prototipo per vedere come appare il nuovo design della manopola del lunotto posteriore è ridicolo, ma nel software ha senso (basta premere F5 e attendere qualche secondo: voilà, pronto per il test drive).

Se guardiamo ai processi di progettazione dei prodotti, i migliori settori da considerare rientrano in due categorie:

• quelli in cui la produzione può essere realizzata a prezzi delle materie prime; ad es. l'industria discografica (l'1% o meno del prezzo di un CD è per la cottura e la stampa), supporti grafici, ecc.
• quelli in cui le quantità sono così basse che la fase di progettazione è il fattore di costo più rilevante (articoli di lusso, prodotti altamente personalizzati, mercati di nicchia ...)

È un errore fondamentale tentare di applicare i processi dalla produzione fisica allo sviluppo del software: lo sviluppo del software non è ripetitivo (se è nel tuo lavoro, vai a cercare un altro lavoro), è solo parzialmente prevedibile, ci sono solo pochissime limitazioni fisiche ( la velocità dell'hardware è una) e sia l'approccio adottato che i risultati possono essere altamente personali. L'applicazione delle filosofie della catena di montaggio a ciò che è fondamentalmente una questione di pensiero analitico e creativo può (e spesso ha) effetti devastanti.

Se si desidera scrivere più volte lo stesso software esatto (anziché semplicemente copiarlo), è possibile farlo in modo molto efficiente tramite una catena di montaggio.

Ma la creazione di software non è un'attività ripetitiva, ogni modulo è uniqe. Ecco perché il confronto con la produzione non è valido.

Penso che la risposta che stai cercando sia applicabile o realistica qui. Quello che sento di voler sapere è come possiamo impostare i nostri processi in modo che siano più simili al settore manifatturiero. Invece penso che la vera domanda diventi "Conoscere cosa fanno la manifattura e le altre industrie per costruire prodotti di qualità che cosa possiamo imparare?" o "Cosa può fare l'industria del software per migliorare la qualità?"

Sfortunatamente la risposta a questa domanda non è chiara perché l'industria del software stessa non conosce ancora la risposta. Per poter rispondere a questo, l'industria del software deve fare ricerche su cosa funziona e perché? Ad esempio, ci sono stati studi che dimostrano che Test Drive Design (TDD) porta a un miglioramento della qualità. Anche se la questione della produttività sembra ancora essere senza risposta o almeno non ancora completamente compresa. Per quanto riguarda ciò che l'evidenza mostra finora:

• Le revisioni del codice sono eccellenti e hanno dimostrato di trovare il maggior numero di bug, ma l'efficacia di una revisione diminuisce in modo piuttosto netto dopo la prima ora di revisione. Dato che la persona media può leggere solo poche centinaia di righe di codice all'ora, suggerisce che gli sviluppatori dovrebbero suddividere le modifiche in pezzi più piccoli.
• Più tempo ci vorrà per trovare un bug, più costoso (tempo e denaro) sarà per risolverlo. Quindi, se uno sviluppatore lo trova durante la scrittura del codice, diciamo che il costo è 1. Se un unittest lo trova in seguito, il costo è 10, se EVT lo trova, il costo è 100 e così via.
• Vi sono alcune prove che suggeriscono che più i requisiti sono complessi, più la soluzione è complessa e più complessa è la soluzione, più è probabile che si verifichino dei bug.

C'è un uomo di nome Greg Wilson che ha parlato in modo eccellente di questo alcuni anni fa. Ecco un link al discorso: Greg Wilson Talk

Inoltre, direi di guardare indietro al tuo lavoro e di trovare i temi con i tipi di errori che introduci e con quali parti stai lottando. Compila questi risultati e quindi crea un elenco di controllo da inserire nel tuo processo in punti diversi per aiutarti a fare un lavoro migliore. Personalmente ho guardato indietro negli ultimi anni del mio lavoro e ho scoperto che ci sono alcuni temi comuni ai problemi che presento. Nello specifico l'ho scoperto

• Non ricordo spesso di creare tutte le varianti che mi hanno portato a interrompere la creazione.
• Molte volte non penso a quanto segue per ogni modifica. Il caso buono, il caso cattivo e i casi eccezionali.
• Tutti i possibili scenari che potrebbero accadere. Nota che questo è davvero difficile perché ce ne sono molti.

Da quando ho trovato alcuni temi per i miei errori, ho creato liste di controllo che utilizzo automaticamente, a causa dell'inserimento nei miei script, che mi aiutano a risolvere questi problemi. Su questo invito è stato scritto un libro, il "Manifesto della lista di controllo", che illustra in dettaglio come possono essere sfruttate. Personalmente l'ho trovato molto penetrante.

Non si tratta di adottare i "loro" processi. Si tratta di adottare "alcuni" processi, che non hanno i soliti e apprezzati svantaggi dell'utilizzo dei processi della catena di montaggio per attività creative. La cosa più importante da notare qui è l'idea che la qualità dei processi si traduca direttamente nella qualità del prodotto.

I migliori processi, o prodotti del caso, sono quelli che si adattano allo scenario d'uso previsto come una mano nella mano. La cosa a cui pensare è che la parte di scrittura del codice reale riguarda l'unica che è, almeno a livello macroscopico, non ripetitiva. Tutte le altre sfaccettature, come il controllo della versione, il tracciamento dei bug, la pianificazione, le stime, le misurazioni, ecc. E l'uso di un processo standard, su misura e collaudato possono aiutarti almeno in queste aree.

Quindi no, il processo di sviluppo del software non può essere paragonato alla produzione in catena di montaggio e come tale "i loro processi" non sono OK, ma la fase di progettazione / progettazione del prodotto in un settore manifatturiero può essere quella da cui trarre ispirazione.

Domanda: Come sviluppatori possiamo imparare dai processi dell'industria manifatturiera? L'adozione dei loro processi può aumentare il tasso di successo dello sviluppo del software?

Risposta: Sì, certo. Ci sono molte lezioni che gli sviluppatori di software possono imparare dalla produzione nonostante il fatto che lo sviluppo del software sia un processo creativo. Lo sviluppo del software è esso stesso un processo e include molti altri processi. Migliore è la definizione e il controllo di tali processi, migliore è il controllo complessivo del processo di sviluppo del software. Ciò non significa che dovresti prescrivere ogni sequenza di tasti eseguita da uno sviluppatore; significa solo che come sviluppatore, esegui naturalmente le attività in un certo ordine e tali attività possono spesso essere gestite. Ecco alcuni esempi:

• rilevamento dei difetti: quando viene rilevato o segnalato un bug, cosa succede? Lo scrivi su un pezzo di carta e lo attacchi su un picco di "investigazione"? Successivamente rimuovi quei frammenti uno alla volta, li indaga e alla fine li sposti sul picco "risolto"? Se lo fai senza fallo ogni volta che ricevi una segnalazione di bug, hai un processo ben definito e misurabile e probabilmente stai molto meglio di qualcuno che ha un sistema di tracciamento di difetti sofisticato e altamente tecnologico che è così oneroso che alcuni membri del team tengono traccia dei bug in altri modi o per niente.

• controllo versione: c'è una buona probabilità che tu usi il controllo versione dove lavori, e il controllo versione è ovviamente molto più utile quando tutti lo usano allo stesso modo.

• design del prodotto: decidi quali funzioni implementare lanciando le freccette contro un muro coperto di post-it? Se è così, hai un processo. Non penso che qualcuno sosterrebbe che è un ottimo processo, ma almeno è un punto di partenza. Se si modifica il processo, come è possibile sapere con certezza che il cambiamento è stato effettivamente un miglioramento a meno che non si misuri prima e dopo? Non puoi.

• revisioni del codice: una revisione del codice sarebbe utile se il processo di revisione e i criteri di codifica cambiassero per ogni revisione? Ovviamente no.

• ciclo di vita dello sviluppo software: l'intera analisi -> progettazione -> implementazione -> test -> ciclo di manutenzione è un processo che dovrebbe essere definito chiaramente.

In ciascuno di questi casi, disporre di un processo consente di misurare input e output e determinare se le modifiche apportate producono l'effetto desiderato. Non avere processi in atto significa che stai solo indovinando quando cerchi di migliorare il tuo modo di lavorare. Questo è veramente ciò che riguarda la produzione e ha senso prendere in prestito i successivi strumenti di perfezionamento della produzione solo quando sono appropriati.

C'è un intero campo dedicato alla definizione e al miglioramento dei processi utilizzati per creare e mantenere software; si chiama ingegneria del software . Non sorprende che tu abbia domande sul processo di sviluppo durante la lettura di CMMI - CMMI è un prodotto del Software Engineering Institute .

Lo sviluppo del software ha già adottato molti concetti di produzione:

• È difficile non vedere l'influenza delle parti intercambiabili di Eli Whitney sia sullo sviluppo OOP che su quello basato su componenti .

• Le tecniche di gestione del progetto utilizzate nello sviluppo del software non sono molto diverse da quelle sviluppate per la produzione. Come solo due esempi, solo recentemente il mondo del software ha adottato il concetto Kanban che è stato sviluppato decenni fa alla Toyota, e le carte Gantt sono state utilizzate nella produzione molto prima che il primo computer elettronico fosse costruito.

• Metodologie di gestione della qualità come Six Sigma sviluppate per la produzione sono state adattate allo sviluppo del software.

Nonostante l'ambiente pesante guidato dai processi, lo sviluppatore deve impegnarsi a creare cose "al volo".

Mi stai dicendo che qualcuno deciderà da solo di aggiungere una patch al pacchetto di riconoscimento facciale e lo aggiungerà alla build di produzione senza prima creare un problema nel sistema di tracciamento, dopo aver rivisto il design, controllando il codice nel controllo della versione, o facendo in modo che gli addetti ai test lo guardino prima? Il nostro processo richiede queste cose per delle ottime ragioni. Se per "al volo" intendi "al di fuori del processo", è inaccettabile.

Fare le cose al volo è contro lo spirito di produzione.

Ancora una volta, se "al volo" significa "al di fuori del processo", hai ragione. Ma se pensi che la produzione non richieda rapidità di pensiero e sviluppo di soluzioni creative ai problemi, ti sbagli. Tutti i tipi di problemi sorgono nel processo di produzione: i cupcake non hanno abbastanza riempimento di crema, le superfici verniciate smettono improvvisamente di superare il test antigraffio del QA, il 20% delle parti finite manca un importante anello di ritenzione, il sistema di miscelazione dell'impasto ha rotto un parte critica ...