Produzione vs Sviluppo software [chiuso]

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, la progettazione 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 un catena di produzione costosa, che semplicemente non si applica al software.

Un esempio di un modello di processo che funziona molto bene nel software, ma che spesso fallisce in modo orribile nella progettazione del prodotto, è un design iterativo: si inizia con un prototipo minimo e si aggiungono funzionalità a ogni iterazione. Costruire un prototipo di auto per vedere come appare il nuovo design del pomello del finestrino posteriore è ridicolo, ma nel software ha senso (basta premere F5 e attendere alcuni secondi - voilà, pronto a testare il disco).

Se guardiamo ai processi di progettazione del prodotto, i migliori settori da considerare si dividono in due categorie:

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

È un errore fondamentale provare e applicare i processi dalla produzione fisica allo sviluppo del software: lo sviluppo del software non è ripetitivo (se è nel tuo lavoro, trova un altro lavoro), è solo parzialmente prevedibile, ci sono pochissimi limitazioni fisiche (la velocità dell'hardware è una), e sia l'approccio adottato che i risultati possono essere altamente personali. Applicare le 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 sempre lo stesso software esatto (anziché semplicemente copiarlo), è possibile farlo in modo molto efficiente tramite una linea di assemblaggio.

Ma la creazione di software non è un'attività ripetitiva, ogni modulo è uniqe. Questo è il motivo per cui 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 fino ad essere più simili all'industria manifatturiera. Penso invece che la vera domanda sia: "Conoscendo ciò che la produzione e le altre industrie fanno per costruire prodotti di qualità, cosa possiamo imparare?" o "Cosa può fare l'industria del software per migliorare la qualità?"

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

• Le recensioni dei codici sono eccellenti e mostrano di trovare la maggior parte dei bug, ma l'efficacia di una recensione si riduce drasticamente 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 rompere le modifiche in parti più piccole.
• Più tempo ci vuole per trovare un bug più costoso (tempo e denaro) sarà per risolverlo. Quindi, se uno sviluppatore lo trova mentre scrive il 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.
• Ci sono alcune prove che suggeriscono che più i requisiti sono complessi, più la soluzione è complessa e più complessa è la soluzione, più probabile saranno i bug.

C'è un uomo di nome Greg Wilson che ha fatto un eccellente discorso su alcuni di questo alcuni anni fa. Ecco un link al talk: Greg Wilson Talk

In aggiunta a ciò direi ripensare al proprio lavoro e trovare i temi con i tipi di errori che si presentano e con quali parti si lotta. Compilare questi risultati e quindi creare una checklist da inserire nel processo in punti diversi per aiutarti a fare un lavoro migliore. Personalmente ho ripensato agli ultimi anni del mio lavoro e ho scoperto che ci sono alcuni temi comuni ai problemi che ho presentato. Nello specifico ho trovato che

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

Poiché ho trovato alcuni temi per i miei errori, ho creato liste di controllo che uso automaticamente, a causa dell'inserimento nei miei script, che mi aiutano a risolvere questi problemi. C'era un libro scritto su questa chiamata, il "Manifesto della lista di controllo" che spiega come possono essere utilizzati. Personalmente l'ho trovato molto perspicace.

Non si tratta di adottare i "loro" processi. Si tratta di adottare "alcuni" processi, che non hanno i soliti e ben apprezzati detrimenti nell'utilizzare i processi di catena di montaggio per gli sforzi creativi. 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 per questo, sono quelli che si adattano allo scenario di utilizzo previsto come un guanto. La cosa a cui pensare è che la parte di scrittura del codice reale è l'unica che è, almeno a livello macroscopico, non ripetitiva. Tutti gli altri aspetti, come il controllo della versione, la tracciabilità dei bug, la pianificazione, le stime, le misurazioni ecc., E l'uso di un processo standard, su misura e comprovato, possono aiutarti almeno in queste aree.

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

Question: Can we as developers learn from the processes of the manufacturing industry? Can adopting their processes increase the success rate of software development?

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. Quanto più è possibile definire e controllare tali processi, tanto migliore è possibile controllare il processo di sviluppo del software in generale. Ciò non significa che dovresti prescrivere ogni tasto premuto da uno sviluppatore; significa semplicemente che come sviluppatore, esegui le attività in un determinato ordine, e quelle attività spesso possono essere gestite. Ecco alcuni esempi:

• rilevamento dei difetti: quando un bug viene osservato o segnalato, che cosa succede? Lo scrivi su un pezzo di carta e lo appiccichi su un picco "investigare"? In un secondo momento rimuovi quegli scarti uno alla volta, li indaga e alla fine li sposti al punto "risolto"? Se lo fai senza errori 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 dei difetti sofisticato e ad alta tecnologia che è così oneroso che alcuni membri del team tracciano bug in altri modi, o non lo fanno affatto.

• controllo della versione: ci sono buone probabilità che tu usi il controllo della versione su cui lavori, e il controllo della versione è ovviamente molto più utile quando tutti lo usano allo stesso modo.

• design del prodotto: decidi quali funzionalità implementare lanciando le freccette su un muro coperto da post-it? Se è così, hai un processo. Non credo che nessuno possa obiettare che è un grande processo, ma almeno è un punto di partenza. Se modifichi il processo, come puoi sapere con certezza che il tuo cambiamento è stato effettivamente un miglioramento a meno che non misuri prima e dopo? Non puoi.

• recensioni del codice: una revisione del codice sarebbe utile se il processo di revisione ei criteri di codifica fossero cambiati per ogni revisione? Certo che no.

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

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

Esiste un intero campo dedicato alla definizione e al miglioramento dei processi utilizzati per creare e mantenere il software; si chiama ingegneria del software . Non sorprende che abbiate domande sul processo di sviluppo durante la lettura di CMMI - CMMI è un prodotto del Istituto di Ingegneria del Software .

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

• È difficile non vedere l'influenza delle parti intercambiabili di Eli Whitney su OOP e sviluppo basato sui 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, il mondo del software ha adottato solo di recente il concetto Kanban che è stato sviluppato decenni fa su Toyota, e i diagrammi di Gantt sono stati utilizzati nella produzione molto prima che fosse costruito il primo computer elettronico.

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

Despite the heavy process driven environment, the developer must engage in creating things "on the fly".

Mi stai dicendo che qualcuno deciderà da solo di aggiungere una patch al pacchetto di riconoscimento facciale, e lo aggiungeranno alla build di produzione senza prima creare un problema nel sistema di tracciamento, avendo il il design rivisto, il controllo del codice nel controllo della versione o la verifica da parte degli utenti? Il nostro processo richiede quelle cose per delle ottime ragioni. Se con "al volo" intendi "al di fuori del processo", è inaccettabile.

Doing things on the fly is against the spirit of manufacturing.

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