Questa domanda contiene davvero due domande, che devono essere affrontate separatamente:
Perché alcuni team hanno un rigoroso processo di sviluppo?
La semplice risposta è perché se non lo fanno, gli errori accadono. Errori costosi. Questo vale per lo sviluppo ed è vero anche per il resto del campo IT (amministratori di sistema, amministratori di database, ecc.).
Questo è molto difficile da comprendere per molti sviluppatori e lavoratori IT perché la maggior parte di noi ha sempre lavorato solo in uno degli "estremi" - grandi aziende in stile Fortune con almeno una dozzina di sviluppatori e processi rigorosi da seguire, oppure piccoli, micro-ISV o anche freelance in cui le persone non si sbagliano male o il costo di un errore è basso.
Ma se hai mai visto un'azienda tra queste fasi - persino un'azienda con personale IT brillante e di talento - capirai i pericoli di non avere alcun processo o di avere un processo a metà. Vedete, la comunicazione tra il personale soffre di un problema di esplosione combinatoria ; una volta raggiunto il livello di circa 6-10 sviluppatori in un singolo team, la causa principale di difetti importanti o critici non è la mancanza di talento o di know-how, ma piuttosto una mancanza di comunicazione.
Alice chiede in giro lunedì mattina e decide che va bene fare un intervento chirurgico ricostruttivo nel bagagliaio perché nessun altro sta lavorando su quella parte. Bob arriva un'ora dopo, tornato dalle sue vacanze e pieno di energia e decide che implementerà una nuova caratteristica importante in quella stessa area esatta, e perché preoccuparsi di un ramo perché nessuno tocca mai quel codice comunque? Quindi Alice ripaga quel "debito tecnico", Bob implementa la sua caratteristica killer che è stata sul back-burner per 6 mesi, e quando finalmente entrambi controllano il loro codice (subito prima della chiusura di venerdì, ovviamente!), L'intero il team deve rimanere indietro e cercare di superare l'inferno da incubo di conflitti che continuano a sopravvivere come bug e regressioni per le prossime due settimane.
Sia Alice che Bob hanno fatto un ottimo lavoro nelle attività di codifica, ma entrambi hanno iniziato con una decisione sbagliata ("qual è il peggio che potrebbe succedere?"). Il responsabile del team o il project manager li guida attraverso un post-mortem e crea una lista di controllo per evitare che ciò accada di nuovo:
- I check-in devono essere giornalieri per ridurre al minimo l'impatto dei conflitti;
- Le modifiche che richiederanno significativamente più di 1 giorno devono essere fatte sulle filiali;
- Tutte le attività significative (incluso il lavoro non relativo alle funzioni come il refactoring) devono essere adeguatamente monitorate e assegnate nel bug tracker.
Scommetto che, per molti di noi, questo "processo" sembra solo buon senso. È un vecchio cappello. Ma sapevi che molte squadre più piccole non lo fanno? Una squadra di due uomini potrebbe non preoccuparsi nemmeno del controllo del codice sorgente. Che importa? Onestamente non è necessario. I problemi iniziano a verificarsi solo quando il team cresce, ma il processo no.
Naturalmente, l'ottimizzazione del processo è come l'ottimizzazione delle prestazioni; segue una curva esponenziale inversa. L'elenco di controllo sopra riportato può eliminare l'80% dei difetti, ma dopo averlo implementato, scopri che un'altra cosa rappresenta il restante 80% dei difetti. Nel nostro esempio fittizio ma familiare potrebbero essere errori di compilazione dovuti alla presenza di ambienti di compilazione diversi, a sua volta dovuti al fatto che non esiste un hardware standard e che gli sviluppatori utilizzano librerie open source che vengono aggiornate ogni 2 settimane.
Quindi hai tre opzioni: (a) standardizzare l'hardware e limitare gravemente l'utilizzo della libreria di terze parti, che è costoso e potrebbe danneggiare significativamente la produttività, oppure (b) impostare un server di build, che richiede la cooperazione del gruppo sysadmin e un sviluppatore a tempo pieno per mantenerlo, o (c) lasciare che gli sviluppatori lo facciano da soli distribuendo una macchina virtuale standard e dicendo agli sviluppatori di basarsi su quello. Chiaramente (b) è la migliore soluzione a lungo termine ma (c) ha un migliore equilibrio a breve termine di affidabilità e convenienza.
Il ciclo continua all'infinito. Ogni "politica" che vedi è stata generalmente istituita per risolvere un problema reale. Come ha scritto Joel Spolsky nel 2000 (su un argomento completamente diverso, attenzione, ma rilevante):
Quando vai in un ristorante e vedi un'insegna che dice "Non sono ammessi cani", potresti pensare che quell'insegna sia puramente proscriptiva: al signor Ristorante non piacciono i cani in giro, quindi quando ha costruito il ristorante ha messo quell'insegna.
Se questo fosse tutto ciò che accadrebbe, ci sarebbe anche un cartello "No Snakes"; dopo tutto, a nessuno piacciono i serpenti. E un cartello "No Elephants", perché si rompono le sedie quando si siedono.
La vera ragione per cui il segno è lì è storica: è un indicatore storico che indica che le persone erano solite provare a portare i loro cani nel ristorante.
È lo stesso nella maggior parte dei team di software (non dirò tutto): politiche come "È necessario aggiungere un caso di test per ogni correzione di bug" indicano quasi invariabilmente che il team ha storicamente avuto problemi con le regressioni. Le regressioni sono un altro di quei problemi che sono spesso dovuti alla rottura della comunicazione piuttosto che all'incompetenza. Finché capisci la politica, potresti essere in grado di prendere scorciatoie legittime (ad esempio, ho dovuto correggere 6 piccoli bug ma erano tutti nella stessa funzione, quindi posso effettivamente scrivere un solo test per tutti e 9).
Questo spiega perché i processi ci sono, ma non è l'intera storia. L'altra metà è:
Perché il processo è così difficile da seguire?
Questa è in realtà la domanda più semplice a cui rispondere: è perché il team (o la sua gestione) è focalizzato su risultati ripetibili e minimizzando i difetti (come sopra) ma non ha prestato sufficiente attenzione all'ottimizzazione e all'automazione di quel processo.
Ad esempio, nella domanda originale, vedo diversi problemi:
Il sistema di controllo delle revisioni (CVS) è ereditato dagli standard odierni. Per i nuovi progetti, è stato sostituito quasi interamente dalla sovversione (SVN), che a sua volta viene rapidamente eclissata da sistemi distribuiti come Mercurial (Hg). Passare a Hg renderebbe la ramificazione e la fusione molto più semplici e, anche nel mio esempio ipotetico sopra, il requisito di impegno giornaliero diventerebbe molto meno doloroso. Il codice non deve nemmeno essere compilato, perché il repository è locale; - in effetti, gli sviluppatori più pigri potrebbero anche automatizzare questo passaggio se lo desiderano, impostando uno script di disconnessione per eseguire automaticamente il commit delle modifiche al repository locale.
Non è stato impiegato tempo per automatizzare il processo della macchina virtuale. L'intero processo di acquisizione, configurazione e download di sorgenti / librerie su una macchina virtuale potrebbe essere automatizzato al 100%. Potrebbe essere un processo automatico che si esegue su un server centrale da qualche parte mentre si lavora sulla correzione di errori sul proprio computer locale (e si utilizza solo la VM per garantire una build pulita).
D'altra parte, a una certa scala la soluzione VM-per-developer inizia a diventare sciocca e dovresti avere solo un server di integrazione continua. È qui che arrivano i vantaggi della produttività reale, perché (principalmente) libera i singoli sviluppatori dal doversi preoccupare delle build. Non è necessario preoccuparsi di configurare macchine virtuali pulite perché il server di build è sempre pulito.
La formulazione della domanda ("caso di test con tutti i passaggi") implica che sono in corso alcuni test manuali . Questo, ancora una volta, può funzionare per piccoli team con un carico di lavoro relativamente basso, ma non ha alcun senso su larga scala. I test di regressione possono e devono essere automatizzati; non ci sono "passaggi", solo una classe o un metodo aggiunto alla suite di test unità / integrazione.
Inutile dire che passare da Bugzilla a un nuovo (migliore) sistema di tracciamento dei bug renderebbe questa parte dell'esperienza molto meno dolorosa.
Le aziende non sono necessariamente economiche o stupide solo perché non hanno risolto questi problemi. Tutto quello che sanno è che l'attuale processo funziona e in alcuni casi sono avversi al rischio e riluttanti a cambiare qualcosa al riguardo. Ma in realtà devono solo essere convinti dei benefici .
Se gli sviluppatori trascorressero una settimana a monitorare il loro tempo su tutte le attività non di codifica, allora potresti facilmente aggiungerlo, mostrare alla direzione che (ad esempio) un investimento a capitale zero, di 100 ore umane in un aggiornamento a Mercurial sarebbe elimina fino a 10 ore-uomo a settimana sulla risoluzione dei conflitti di unione, quindi questo è un payoff di 10 settimane e quasi sicuramente accetteranno. Stessa idea con build server (CI) o migliore tracciamento dei bug.
Ricapitolando: i team non hanno ancora fatto queste cose perché nessuno ha convinto il management che oggi è abbastanza importante farlo . Quindi prendi l'iniziativa e trasformala in un'equazione costi-benefici; scoprire quanto tempo viene dedicato alle attività che potrebbero essere semplificate / automatizzate con un rischio minimo e calcolare il punto di pareggio e l'eventuale payoff di un nuovo strumento o tecnica. Se ancora non ascoltano, allora sai già quali sono le opzioni rimanenti.
Se gli sviluppatori trascorrono una settimana a monitorare il loro tempo su tutte le attività non di codifica, allora potresti facilmente aggiungerlo, mostrare la gestione ... e trasformarlo in un'equazione costi-benefici ecc ...
La parte sopra sembra essere ulteriormente ampliata.
Posso confermare che funziona. I programmatori lo hanno usato poche volte in uno dei progetti a cui ho lavorato e ogni volta ha portato a cambiamenti desiderati.
La mia impressione generale è stata che, se fatto bene, questo trucco può prevalere su quantità piuttosto elevate di ignoranza e inerzia del management.
Vorrei sottolineare, tuttavia, che la società in cui noi (sviluppatori) abbiamo dovuto ricorrere a questo tipo di approccio fai -da- te era molto acerba per quanto riguarda l'IT. In venditori di software più esperti ho visto cose del genere per lo più fatte dai gestori stessi. E di regola erano più produttivi di noi programmatori. Molto più produttivo.