Ero solito credere che i metodi di sviluppo del software "buoni" tendano a produrre un prodotto migliore nel lungo periodo. Tuttavia, ho visto alcuni casi in cui la programmazione "copia-incolla" "bruta-forza" "rapida e sporca" sembrava dare risultati decenti più rapidi e meno costosi. Ciò si verifica soprattutto nei casi in cui il time to market è più critico dei costi di manutenzione.
Esiste una correlazione tra la qualità del processo di sviluppo e le tecniche e la qualità del prodotto?
Un processo di sviluppo software (SDP) è semplicemente il modo in cui il tuo team crea software. Un buon processo ti consentirà di ripetere il progetto dei risultati dopo il progetto. NOTA: questo non dice nulla sulla qualità, solo che puoi ripetere ciò che hai fatto l'ultima volta. Si tratta del lavoro quotidiano di scrivere software e assicurarsi che tutto ciò che deve essere fatto sia fatto.
Process Improvement è qualcosa che dovrebbe far parte dell'SDP di tutti. In sostanza dovresti tenere d'occhio le inefficienze / i punti di strozzatura e i luoghi in cui il tuo processo sta funzionando contro qualità. Vuoi cambiare il tuo processo nel momento in cui identifica il problema in modo da poterlo risolvere. Un cambiamento alla volta, fino a quando non stai solo ripetendo i risultati, ma ripetendo i risultati di qualità in modo efficiente.
Riguardo al tuo esempio
Una squadra che usa il codice "forza bruta" o "copia-incolla" ha un SDP. Non è elegante, ma esiste. È il modo in cui si stanno avvicinando al problema. Tuttavia, non è un processo sostenibile . Può funzionare solo per le applicazioni banali e non importanti . Queste app esistono (come l'app per iPod "E 'leggero fuori?"), Ma sono molto piccole (per esempio banali) e molto veloci (cioè meno di un mese per la compilazione).
Ogni volta che hai un'app considerevole, o l'applicazione è importante per un'azienda, non puoi lesinare sulla qualità. I guadagni a breve termine che avevi all'inizio saranno rapidamente persi mentre la squadra trascorre tutte le loro ore di veglia in un debugger. O forse tracciando per trovare il bug relativo al codice copia-incolla che è stato modificato in una posizione ma non in un'altra.
Sapendo che il team che usa la forza bruta ha un SDP, può iniziare a cambiare il proprio processo per costringerli a migliorare la propria qualità nel tempo. La chiave è quella di correggere una parte del processo alla volta fino a quando il processo è abbastanza efficiente.
Per quanto riguarda il miglioramento del processo
Ogni volta che ho il compito di migliorare i processi, sto esaminando un paio di cose:
Troverai un paio di cose quando adotterai la filosofia del miglioramento continuo dei processi. In primo luogo, potrebbe essere necessario introdurre alcuni processi (come una revisione tra pari) per risolvere un problema di qualità. In secondo luogo, il processo che hai introdotto (come una peer review) potrebbe non più aggiungere valore una volta che il team non sta più riproducendo tali errori. Oppure potresti riuscire a cogliere quegli errori in altri modi (come programmi di analisi statica, test di unità, ecc.). Basta non chiuderti in un "Processo" (nota la P maiuscola) e adorarlo. Piccole correzioni nel tempo sempre producono risultati migliori rispetto al cambio all'ingrosso.
Puoi solo sapere se il miglioramento ha effettivamente migliorato il processo quando osservi i suoi affetti isolatamente. Quando cambi tutto, non hai imparato nessuna lezione e sei destinato a imparare nuove dolorose lezioni che non hai visto prima.
La domanda fondamentale dietro la tua è come definisci il "buon" metodo di sviluppo del software? Tante metodologie sono state propagandate per essere Silver Bullets e fallite miseramente, quindi si dovrebbe avere un modo per valutare e misurare cose. Ci sono, ad es. organizzazioni che affermano di essere al CMM di livello 5 e che stanno ancora fornendo ... beh ... soluzioni subottimali .
Per me, l'unico modo significativo è di vedere effettivamente l'output del processo, vale a dire il software consegnato (più documentazione, ecc. se applicabile). E la qualità della soluzione consegnata non può essere interpretata senza contesto. Naturalmente ti aspetti un livello di qualità molto diverso da un'app sperimentale in-house, che dal software di controllo della navicella NASA.
Per un prototipo unidirezionale, può essere perfettamente OK gettare qualcosa insieme rapidamente, senza documentazione, progettazione, test ecc. Se OTOH intende mantenere il prodotto per anni, è necessario investire in tutti questi , che in effetti richiede buoni processi. (Nota comunque che c'è sempre il rischio che la tua soluzione usa e getta venga utilizzata, quindi all'improvviso hai un problema di manutenzione - il software tende a sopravvivere alla sua durata prevista , quindi è meglio pianificare per questo in anticipo).
Credo che tutti noi vogliamo lavorare su progetti di sviluppo software di qualità e le persone che si preoccupano di più dei processi tenderanno a rispondere a domande come questa.
C'è un posto per una soluzione software veloce-economica-sporca - ed è qui che la vita del software è molto breve - diciamo meno di un anno.
Penso che se il software in questione deve funzionare per almeno 3 anni, una soluzione rapida e sporca sarà più costosa di uno sviluppo ben pianificato, a causa degli errori e delle rielaborazioni che inevitabilmente seguiranno.
Esempi
Ma se un progetto ha una durata inferiore a un anno, immagino che un approccio rapido e sporco sarà più economico da implementare, e correggere bug e aggiungere nuove funzionalità potrebbe essere inutile.
Esempi
La qualità del software di solito non diminuisce o aumenta gradualmente, ma piuttosto in modo discreto e incostante. Lo sviluppo di software di bassa qualità non comprometterà necessariamente l'esperienza dell'utente immediatamente, ma è probabile che aumenti improvvisamente e apparentemente dal nulla il tuo problema con un bug o una serie di bug correlati che non verranno sistemati facilmente.
The quality of the construction substantially affects the quality of the software.
e
... your understanding of how to do construction determines how good a programmer you are ...
Dice Steve McConnell in Codice Completa 2a edizione , a pagina 8. Ti consiglio vivamente di leggere Codice completo per le risposte su questo argomento.
L'unica correlazione che mi viene in mente è che l'SDP di bassa qualità può causare più bug, che a loro volta riducono la qualità generale del prodotto. Oltre a questo, non esiste una vera correlazione, es. Ho visto applicazioni mal progettate che sono percepite come ottimi prodotti e applicazioni solide che sono considerate prodotti di merda estrema.
Qui c'è una correlazione zero, come si nota nella tua domanda.
Il processo di sviluppo del software ha lo scopo di risolvere i problemi di gestione e di progetto - assicurandosi che il progetto sia completato nei tempi e nel budget, i requisiti vengono identificati e riconsegnati al team, i bug identificati in anticipo e così via.
Come si dice, scegli due: "Costo, velocità, qualità".
L'utilizzo di un processo di sviluppo del software di qualità riguarda la gestione dei costi e dei tempi (nota: non specificamente riducendo al minimo, ma assicurando la prevedibilità). Molti progetti a basso processo offrono un ottimo software e molti progetti ad alto processo forniscono un cane.
Penso che tu stia mescolando fondi "Buono" con Soluzione "lavorabile" .
Un "rapido e sporco" copia e incolla fornisce effettivamente una soluzione funzionante, ma il suo guadagno è solo a breve termine .
Nel corso del tempo questo porta a complessità ed efficacemente a un codice "palla di fango".
D'altro canto, il software che viene creato seguendo le best practice, inizialmente è più lungo da sviluppare, ma a lungo termine è più facile mantenere e aggiungere nuove funzionalità.
Its the old story of the Turtle and Hare Race
Quick-and-Dirty tende a creare prodotti che si attardano nel limbo "finito al 95%". Non è raro vedere un progetto "quasi fatto" in pochi mesi, ma poi lottare letteralmente per anni per renderlo pronto all'uso produttivo. Questo è particolarmente importante dal momento che la data del go-live viene posticipata di nuovo e di nuovo, mese dopo mese, causando tutti i tipi di problemi organizzativi e finanziari.
Oppure, nel caso di software in scatola, il prodotto viene spedito comunque, ma l'azienda perde molta reputazione e deve consegnare patch dopo patch ai clienti arrabbiati. In questi giorni, quando puoi sempre trovare recensioni di qualsiasi prodotto in pochi secondi su Internet, questa è diventata una strategia molto pericolosa. "Time to market" non vale niente se il prodotto non viene accettato dal mercato a causa delle recensioni negative.
Prendi in considerazione il concorrente iPad "WeTab". Erano mesi in anticipo rispetto alla maggior parte degli altri tablet, caratterizzati da un hardware più potente e versatile rispetto all'iPad, ma tutti sapevano che il prodotto semplicemente non era pronto per il prime time, quindi AFAIK non ha venduto bene.
Dipende da chi sta facendo l'edificio.
Se è una piccola azienda che cerca di costruire 1 cosa che è il punto cruciale della loro attività e vogliono essere i primi a farlo, allora il momento del mercato è la cosa più importante.
Detto questo, se il software è davvero pessimo, potresti essere il primo e poi perdere la base di clienti.
Quindi la risposta è .... dipende.
Capisco il punto di arrivare al mercato. Devi iniziare a pagare le bollette. Il vero vantaggio è arrivare sul mercato E essere in grado di adattarsi alle caratteristiche e alle funzionalità che il mercato vuole davvero. Ad un certo punto vorrai refactoring il codice veloce e sporco.
In base alla tua logica, non c'è motivo di interrompere questa pratica. Tutti vogliono sempre tutto prima, ma questo non significa che dovresti farlo. Alla fine, la tua app rallenterà, non sarai in grado di tenere il passo con le modifiche e continuerai a introdurre bug nel sistema. Gli utenti presumeranno che se esaudisci i loro desideri, queste conseguenze non si verificheranno.
Modifica: Correlazione / Causale: forse quelli che seguono un processo software di qualità sanno solo come fare un buon software. Se non sai cosa stai facendo, seguire i buoni metodi ti porterà solo lontano.
Leggi altre domande sui tag development-process quality