Troppo controllo della versione e sovraccarico di tracciamento dei bug per modifica?


50

Lavoro in un posto che è CVS-crazy e Bugzilla-nuts.

  1. Ci sono così tanti rami fuori da ogni versione che non si possono contare. Tutti si fondono costantemente automaticamente.

  2. Non c'è fluidità in questo lavoro. Tutto sembra un passo avanti . Bastano 25 passaggi anche per una cosa semplice. Non è come essere su una linea di produzione in fabbrica: è come creare una fabbrica da solo ogni giorno.

Esempio di situazione:

Per correggere un singolo bug, per prima cosa ottengo una nuova macchina virtuale pulita. Quindi creo un ramo per quella singola correzione di bug, basato su un altro ramo descritto nel rapporto Bugzilla. Installo il ramo sulla macchina, lo configuro. Risolvo il bug. Lo controllo, lasciandolo e la macchina su cui gli altri potranno testare. Quindi devo andare nel software di controllo dei bug e spiegare cosa ho fatto e scrivere un caso di test, con tutti i passaggi. Alla fine qualcun altro lo unisce a una versione.

Non importa quanto sia piccolo il bug, devo fare tutte queste cose. A volte le persone combinano il lavoro su più bug, ma come ho detto ci sono così tanti rami che questo è quasi impossibile.

In qualsiasi altro lavoro, andrei semplicemente a riparare il bug. Mi ricordo a malapena di aver usato SCM, anche se ogni lavoro che ho avuto lo ha usato: questo perché in ogni altro lavoro, in qualche modo lo hanno tenuto fuori dai piedi .

C'è un punto in cui il processo si mette in mezzo e diventa fine a se stesso? È persino ingegneria?


8
Ti senti male per te :( La compagnia in cui lavori ha CMMI 3 e versioni successive?
artjom

6
Sembra che l'organizzazione sia stata gravemente morsa in precedenza e abbia sviluppato difese. Forse dovresti chiedere della storia di questo?

1
E poiché i supervisori incoraggiano continue distrazioni, il tuo lavoro deve essere un vero inferno ...
viti

57
È una domanda o un post sul blog?
Rei Miyasaka,

31
Se il software fosse il sistema di controllo di una centrale nucleare, ciò non sembra irragionevole. Se per una fan page di Facebook sembra estremamente eccessivo. Senza il contesto è difficile dire se questo sia irragionevole o no: ci sono certamente progetti per i quali non lo è, e altri dove certamente lo è.
edA-qa mort-ora-y

Risposte:


89

C'è un punto in cui il processo si mette in mezzo e diventa fine a se stesso?

I processi pesanti sono comuni, sfortunatamente. Alcune persone - specialmente i dirigenti - immaginano religiosamente che i processi producano prodotti. Quindi esagerano con i processi e dimenticano che è davvero una manciata di persone laboriose e intelligenti che creano effettivamente i prodotti. Per i vertici, è spaventoso persino pensare che i loro affari siano nelle mani di pochi geek, e quindi chiudere gli occhi dalla realtà e pensare invece al loro caro "processo", che dà loro l'illusione del controllo.

Ecco perché le startup agili con una manciata di bravi ingegneri possono battere grandi aziende affermate, i cui lavoratori spendono il 95% della loro energia per processi e reportistica. Alcuni esempi di startup una volta piccole che una volta hanno battuto i loro concorrenti e / o creato mercati completamente nuovi:

  • Apple (Apple I è stata creata da 1 ingegnere; all'epoca c'erano 3 uomini nell'azienda).
  • Google (creato originariamente da 2 programmatori).
  • Facebook ( sforzo di 1 uomo in origine).
  • Microsoft ( società di 2 uomini nel 1975).

Si potrebbe facilmente dire che questi sono solo valori anomali, eccezioni estreme e, per fare qualcosa di serio, è meglio essere una grande azienda affermata. Ma l'elenco potrebbe continuare. E via. È imbarazzantemente lungo. Quasi ogni grande azienda odierna ha iniziato come un negozio di garage, il che ha fatto qualcosa di insolito. Qualcosa di strano. Lo stavano facendo male. Pensi che lo stessero facendo secondo il processo?


19
Mi chiedo, ci sono prove per qualcuno dei reclami che presenti qui? Sei una fonte primaria (es. Gestione esecutiva)? Hai condotto o letto interviste con loro? È molto interessante il modo in cui ogni sorta di risposta dice "SÌ! DIRITTO SU!" sembrano provenire da persone che non sono mai state in procinto di dare e quindi non possono garantire la precisione. Penso che sia importante per noi distinguere le risposte che sono effettivamente vere da quelle a cui gli sviluppatori (che sono notoriamente anti-gestionali) vorrebbero semplicemente credere .
Aaronaught,

6
Non credo davvero che l'onere debba essere su me stesso o su chiunque altro per fornire "migliori informazioni supportate" quando si critica una risposta come questa; hai fatto un'affermazione molto forte, ampia e radicale e hai presentato prove zero - nemmeno prove aneddotiche - a sostegno. È un peccato che una comunità apparentemente professionale sia così facilmente influenzata da questo tipo di sciocchezze populiste.
Aaronaught,

11
Cosa, davvero, non pensi che sia facile ottenere voti dicendo alla gente cosa vogliono sentire? Sì, per dirla senza mezzi termini, non ho molto rispetto per la folla che vota queste risposte immeritevoli. Immagino di non poter incolpare le persone come te per aver fatto il minimo assoluto quando la comunità premia quel comportamento, ma tuttavia, vorrei che le persone almeno provassero a migliorare le loro risposte quando criticate invece di indicare ostinatamente i voti come giustificazione.
Aaronaught il

8
L'intera cosa? "Alcune persone" - quali persone? "Soprattutto gestione" - perché presumere che abbiano maggiori probabilità di crederci? "Immagina religiosamente" - come sei sicuro che le loro convinzioni non abbiano basi nei fatti o nella logica? "I processi producono prodotti?" - chi ha fatto esattamente tale richiesta specifica e in quale contesto? "Esagerare con i processi" - cosa significa esattamente? "Gli affari sono nelle mani di pochi fanatici" - in che misura e in che modo? "chiudi gli occhi / illusione di controllo" - spiega? "startup agili ... possono battere grandi società affermate" - affermi che questi non sono valori anomali?
Aaronaught,

7
@Aaronaught: questo forum non è un documento scientifico. Nessuno, né tu né io, forniremo una spiegazione per ogni singola frase che scrive. Stai solo chiedendo questa risposta perché non ti piace. Apparentemente colpisce il nervo, ma che ne dici di non essere d'accordo in modo civile? Per quanto riguarda le startup che battono grandi aziende, leggi ad esempio solo le prime due frasi di descrizione del prodotto da questo: amazon.com/Radical-Innovation-Companies-Outsmart-Upstarts/dp/…
Joonas Pulakka

21

Le aziende in genere soffrono di quello che vorrei chiamare il dilemma controllo-flessibilità. Meno regole, strutture e spese burocratiche sono più facili e veloci da compiere (è anche più divertente). Tuttavia, è altrettanto facile fare cose "cattive" come cose "buone". Ciò significa che stai bene solo con dipendenti qualificati che commettono pochi errori non critici.

D'altra parte, se ci sono molti dipendenti da bassi a semiqualificati e / o i costi per commettere errori sono troppo alti (come il rischio di detriti della navetta spaziale nell'emisfero settentrionale) le aziende tendono ad accumulare sempre più "regole "e" processi "per cercare di minimizzarli.

L'unico problema è che il sovraccarico cumulativo di questi processi rende difficile realizzare qualsiasi cosa che comporti la perdita dei dipendenti di talento dall'azienda. Ciò si traduce in una riduzione dell'abilità media, che richiede ancora più processi e burocrazia. Quindi la spirale della morte continua fino a quando non accade qualcosa di radicale o la compagnia non va a gonfie vele.

Se ti trovi in ​​una società che sembra aver superato il punto di non ritorno in questo aspetto, puoi decidere di "non preoccuparti" del tuo lavoro (che è quello che la maggior parte di quelli che sono rimasti hanno fatto) o di cavarsela al diavolo di lì con la tua anima intatta :)

Se la compagnia non è andata troppo lontano e hai i mezzi per provare a invertire la rotta con determinazione e forza di volontà. Attenzione però che può richiedere un'enorme quantità di lavoro ed energia personale senza alcuna garanzia di successo, quindi assicurati che ne valga la pena. A volte è meglio tagliare la perdita e contare un'esperienza più ricca.


17

Esiste solo un motivo valido per tale stile di sviluppo: il software sviluppato è assolutamente mission-critical e non deve in alcun caso contenere bug. Pensa al firmware di iniezione del carburante del motore a reazione negli aerei passeggeri, o al firmware del pacemaker cardiaco o al sistema di lancio di missili nucleari.

In tutte le altre situazioni, i costi generali uccideranno l'azienda. Ora di andare avanti.


2
Sostengono che è fondamentale, ma si può dire questo su qualsiasi software; dipende da quanto il cliente sta accettando i difetti. E se fosse una missione critica, dovrei chiedermi perché, ad esempio, sembrano davvero non gradire l'idea di dare la proprietà di qualsiasi progetto a nessuno. Recentemente mi è stato chiesto di un software complesso che ho scritto 3 mesi fa, e non sono stato in grado di fornire un indizio, perché mi avevano spostato bruscamente da quel lavoro una volta che l'ho fatto funzionare. Queste persone sono idioti. Considerano tutti disponibili, e le opinioni di chiunque tranne le loro sono inutili.
Ponk,

1
@Ponk, tutti sono usa e getta però. Quando i processi definiscono il lavoro e il cliente accetta già il software e il denaro scorre, allora tutto e niente è più fondamentale. Perché preoccuparsi dell'innovazione a questo punto? Il cliente probabilmente si preoccupa solo del fatto che, in un attimo, il proprio fornitore ha un team di sviluppo software addestrato e pronto a lavorare che può ottenere le nuove funzionalità in meno di un anno. Nel frattempo non è importante che tu e il tuo team realizziate qualcosa di secondario diverso dall'illusione che state lavorando.
maple_shaft

1
@maple: una cosa sta diventando ridondante. Un altro è se la gente muore a causa di un piccolo errore di battitura e, oltre a perdere il lavoro, si accusa di omicidio colposo con diversi anni di prigione. QUESTO è ciò che chiamo mission-critical e non ci sono molti software in cui ti trovi ad affrontare questo rischio.
SF.

3
Non è solo uno dei motivi per cui lo fanno nel modo in cui lo fanno. E dire che un processo di sviluppo è migliore dell'altro è come dire che l'arancia è meglio della banana. Se sono redditizi e possono pagare lo stipendio, questo processo funziona meglio di qualche azienda agile. Da ciò che è stato scritto posso solo vedere che questa persona ha un lavoro sbagliato. C'è molta compagnia che offre più libertà agli sviluppatori.
Dainius,

+1 per sottolineare che ci sono situazioni (anche nel software) in cui questo livello di controllo è necessario.
riwalk

15

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.


9

Se stai lavorando in un settore fortemente regolamentato, potrebbe esserci qualche motivo per quel processo ingombrante: un giorno potresti essere controllato e dovrai mostrare tutti i tuoi record per spiegare chi ha risolto quel bug, come, chi lo ha esaminato, chi ha testato esso, ecc ...

Quindi potrebbe essere un male necessario.

D'altra parte, se non esiste alcuna giustificazione per tale processo, a parte forse una mancanza di fiducia da parte della direzione, dovresti provare a parlare con il tuo manager e dirgli come potresti risparmiare tempo (e quindi denaro) per l'azienda.

Nessuno nella sua mente giusta che rifiuta un processo più rapido e migliore se viene spiegato correttamente.

Ma sii pronto a difendere il tuo argomento per giustificare il cambiamento.


4
Ho intervistato per un lavoro del genere una volta, era legato all'assistenza sanitaria e hanno descritto il processo come un inferno vivente. Gentile da parte loro, a dire il vero.
Ponk,

2
Tali processi presuppongono tuttavia che l'attuale implementazione sia incontaminata e priva di difetti. Avere un tale processo essenzialmente bloccare un prodotto rotto è un vero pericolo.
edA-qa mort-ora-y

1
"Nessuno nella sua mente giusta che rifiuta un processo più rapido e migliore se viene spiegato correttamente." --- Mi viene in mente un sacco di ordini del giorno che un decisore potrebbe seguire dove questa affermazione non è vera.

@kekekela, dipende da come definisci un processo "migliore". Come ingegnere del software posso definirlo più efficiente, un Project Manager lo definirà come un maggiore controllo.
maple_shaft

Potrebbe dipendere da quello. Limitare te stesso al pensiero che tutti vogliono davvero il processo "migliore" secondo la propria metrica ben intenzionata, tuttavia, ti fa perdere uno spettro molto ampio di cause alla radice per lo status quo.

8

La metà del problema è che stai usando strumenti obsoleti in un processo, per i quali non sono stati progettati. Quello che descrivi è molto facile da avere nei moderni DVCS, senza il noioso compito di creare branch per bug.

Un altro problema è che chiaramente non sei nella linea di lavoro che ti piace. Lavori in manutenzione, mentre desideri lo sviluppo. C'è poco che si può fare al riguardo oltre a cambiare lavoro.


8

La disciplina dell'ingegneria del software è intrinsecamente "tutto incentrata sul processo", quindi chiedersi se "sia diventato" in quel modo è un po 'mancante.

Mentre la maggior parte dei programmatori preferisce essere infastiditi dal minimo assoluto di processo, nella misura in cui alcuni promuoveranno metodologie agili anche quando non risolvono i problemi che la loro organizzazione sta affrontando, è del tutto possibile per un'azienda decidere di utilizzare " "processi pesanti per validi motivi commerciali, come" il cliente lo richiede ". Questo è comune se i tuoi clienti sono aziende, università o agenzie governative di Fortune 500. I vantaggi della vendita a questi clienti possono essere sufficientemente grandi da giustificare il sovraccarico del processo aggiunto.

La tua azienda è un punto dati ed è impossibile generalizzare la tua esperienza in una tendenza a livello industriale verso o lontano da processi più pesanti. La vera domanda è: quale equilibrio funziona meglio per la tua azienda, i tuoi prodotti, i tuoi clienti e tu, personalmente, come programmatore? Se non ti piace lavorare per quella società, istigare il cambiamento o ottenere un altro lavoro.


1
+1 per "la disciplina dell'ingegneria del software". Si tratta di una disciplina, in tutti i sensi della parola.
Dan Ray,

6

Dall'altra domanda che ti ho visto oggi, sembri piuttosto insoddisfatto del tuo lavoro. Non ci sei stato a lungo, puoi semplicemente dire al tuo supervisore che pensi di aver fatto un errore, ed è tempo che tu ti separi prima del previsto.

Se sei bravo nel tuo lavoro, non avrai davvero difficoltà a trovarne uno nuovo e, onestamente, se non ci sono buone ragioni per l'esistenza di questo processo, probabilmente prenderei in considerazione di trasferirmi anch'io. L'uso del CVS sarebbe davvero un problema per me, ma faccio sempre la domanda sul controllo del codice sorgente durante l'intervista. Ovviamente, non posso conoscere la tua situazione e potrebbe essere impossibile lasciare un lavoro se hai altri obblighi.


Osservazione acuta :) Sto intervistando.
Ponk,

CVS Con cui posso convivere, alcune aziende con cui ho lavorato per LIED TO ME sull'intervista che avrei fatto servizi web WCF / RIA con Silverlight e invece mi avrei messo su un'antica applicazione Powerbuilder e stavo ancora usando VSS 6.
maple_shaft

1
ahhh ahi @maple_shaft, questo è duro. Pensa ancora a cosa puoi dire ai grand kiddies ... Ho lavorato sulle app di powerbuilder ...: D # life-fail
Anonimo Tipo

3

Stavo per parlare di come l'ingegneria del software sia invasa da programmatori pessimi, ma la situazione che descrivi è terribile.

Nella mia esperienza personale, parte di questo "processo" che descrivi è accompagnato dal fatto che la gestione e l'amministrazione del sistema sono completamente inconsapevoli delle inefficienze dei sistemi che stanno imponendo ai programmatori. Gli esempi includono la limitazione della scelta del sistema operativo, la limitazione del software utilizzato, l'accesso a Internet, i privilegi di amministratore del desktop personale; tutte queste cose sono essenziali per un buon sviluppo.

Inoltre, i requisiti di compatibilità tra le "soluzioni magiche" utilizzate da diversi rami di aziende. Gli esempi includono sedi centrali che impongono il controllo centralizzato del codice sorgente, server Outlook fuori sede e linee guida o linguaggi di codifica che potrebbero non essere appropriati per ogni problema.

Non è molto divertente far girare le ruote dei juggernaut aziendali, ma ho scoperto che in alcune aziende esistono piccole bolle di innovazione, creatività e brillantezza.


+1 per aver cercato di trovare lo scintillio in uno scenario terribile.
Tipo anonimo

3

Probabilmente lavori in un'azienda orientata al processo . Proverei invece a trovare un'azienda orientata ai risultati , dove importa cosa fai e non come lo fai.

Nella mia azienda abbiamo anche un "processo" (ma è molto semplice) .. Ma quando si frappone infrange le regole e salto i passaggi. Nessuno mi dirà mai nulla finché non rompo nulla prendendo scorciatoie perché ottengo risultati.


2

C'è un punto in cui il processo si mette in mezzo e diventa fine a se stesso? È persino ingegneria?

Letteralmente, la maggior parte dell'ingegneria sta mettendo insieme pezzi ben consolidati in un ordine stabilito in risposta a un problema particolare. Questo è più ovvio se chiedi a un ME cosa fanno tutto il giorno. Stai confondendo l'ingegneria con l'architettura o lo sviluppo del prodotto nella fase iniziale (in qualsiasi campo). Ho due osservazioni sulla tua domanda.

  1. Sembra che tu sia stato assegnato al lavoro di correzione dei bug, non all'architettura o al lavoro di progettazione.
  2. I tuoi colleghi sembrano aver escogitato un numero limitato di soluzioni alternative (combinando VM con correzione di bug) per renderle più efficienti, non sembra che tu stia seguendo il loro esempio ragionevole.

È semplicemente un dato di fatto che in ogni sforzo costruttivo che richiede un gran numero di persone, alcune persone riescono a fare la progettazione e un gruppo più grande "riesce" a fare l'implementazione. Scusa, ma sei in quel secondo gruppo.

Come hanno notato altri commentatori, CVS non è lo strumento migliore per il lavoro per un modello di sviluppo altamente ramificato, ma noto anche che non sei responsabile della fusione ... quindi non preoccuparti.

La maggior parte delle tue lamentele sembrano essenzialmente "Non voglio testare, prima, durante o dopo lo sviluppo!" Analizziamo i passaggi, punto per punto.

  • Per correggere un singolo bug, per prima cosa ottengo una nuova macchina virtuale pulita. Un ambiente di prova
  • Quindi creo un ramo per quella singola correzione di bug, basato su un altro ramo descritto nel rapporto Bugzilla. - Duplica l'ambiente in cui è stato trovato il bug ... come è irragionevole?
  • Installo il ramo sulla macchina, lo configuro. Risolvo il bug. Lo controllo - Il processo di sviluppo di base
  • ... lasciandolo e la macchina su cui altri possono testare. - Il tuo team di merge probabilmente vuole che questo sia in grado di verificare la correzione se l'unione va a sud.
  • Quindi devo andare nel software di controllo dei bug e spiegare cosa ho fatto - Se sei in un negozio che non lo fa ... perché stai monitorando i bug?
  • e scrivere un test case con tutti i passaggi. - Potrei sbagliarmi, ma questa sembra essere la direzione in cui vanno tutti i "ragazzi fighi"
  • Alla fine qualcun altro lo unisce a una versione. - E molti dei passaggi precedenti servono a semplificare il lavoro

Qualcun altro di fronte a te ovviamente esegue il triage di bug per assicurarsi che un bug che viene trovato non venga riparato in un'altra versione o rotto in una versione successiva (ecco a cosa servono i casi di test).

L'unica cosa anche insolitamente remota o troppo zelante in questo processo è la cosa della VM. C'è una buona probabilità che sarebbe considerata ragionevole se sapessimo in quale dominio stavi lavorando.


2

Interessante. Hai tester? Dovrebbero farlo. Sono uno e dove lavoro abbiamo una soluzione decente.

Per un difetto funzionale, come stai spiegando, il nostro processo va in questo modo:

  1. Ho verificato il difetto in una macchina virtuale (segnalato da un cliente o durante i miei test esplorativi o w / e)
  2. Il bug è stato trovato / riproposto.
  3. Creo il bug. I bug includono:
    • Riproduzione completa, dal punto di installazione al punto di vedere il bug.
    • Un collegamento a un'istantanea della VM (se penso che lo sviluppatore ne avrà bisogno ... L'ho istantanea comunque, nel caso in cui lo richiedano).
    • Informazioni di sistema, eventuali impostazioni speciali che dovevo effettuare.
  4. Quel bug viene assegnato allo sviluppatore. Mentre stanno lavorando su una correzione I:
    • Crea un caso di prova
    • Scrivi (o converti) il test manuale in un test automatizzato

Quindi aspetto una soluzione e aiuto lo sviluppatore in qualsiasi modo di cui abbia bisogno. Quando torna risolto, io:

  1. Esegui il test case automatizzato e una versione manuale (a volte) per confermare la correzione.
  2. Chiudi il bug.

TL; DR: se non hai tester, allora ne hai bisogno. Se ne hai qualcuno, allora non "fanno la loro parte".


2

Tom DeMarco:

... Il mio primo libro di metriche ... la riga più citata è la sua prima frase: "Non puoi controllare ciò che non puoi misurare". Questa riga contiene una vera verità, ma mi sono sempre più sentito a disagio con il mio uso. Implicito nella citazione (e in effetti nel titolo del libro) è che il controllo è un aspetto importante, forse il più importante, di qualsiasi progetto software. Ma non lo è.

... più ti concentri sul controllo, più è probabile che tu stia lavorando a un progetto che sta cercando di fornire qualcosa di valore relativamente minore.

A mio avviso, la domanda che è molto più importante di come controllare un progetto software è: perché mai stiamo facendo così tanti progetti che offrono un valore così marginale? ...

Ingegneria del software: un'idea di chi è giunto il momento?


Non è ovvio? Fare soldi. Soldi sexy sporchi.
maple_shaft

1

"Quindi creo un ramo per quella singola correzione di bug",

Non è necessario creare un ramo per la correzione di singoli bug. Per prima cosa crea il bug in bugzilla. Dai un'occhiata al ramo di rilascio. Fai la correzione. Eseguire il commit con il messaggio di commit contenente il numero del bug, che aggiorna il bug e lo contrassegna "corretto, necessita test" o "corretto, testato, necessita di unire" in modo appropriato, a seconda delle parole chiave di testo scritte nel messaggio di commit. Il database dei bug è il meccanismo di tracciamento perfetto per tutte le modifiche apportate e perché sono state apportate; i report possono essere eseguiti dal database dei bug per estrarre queste informazioni.


1

Penso che la maggior parte del processo possa essere automatizzata , in modo che la creazione della macchina virtuale e del ramo (incluso il codice di compilazione, l'impostazione dei debugger ecc.) Sia stata eseguita per te prima di iniziare a lavorare sul bug.

Descrivere cosa hai fatto e come dovrebbe essere testato vale la pena per tutte le correzioni di bug. Ho scoperto che solo scrivere il testo può rilevare problemi , poiché mi fa pensare al rischio, ecc.

Quindi penso che il processo possa essere un po '"esagerato", ma che il vero problema è la mancanza di strumenti automatici personalizzati per supportare il processo.


0

Amico, il tuo processo di pensiero è giusto in quanto ciò che hai descritto è assolutamente scadente e una vera dimostrazione di come nel software possano esserci cose sbagliate. Ecco la buona notizia, però, ci sono così tante aziende là fuori che praticano Agile con il vero spirito. La società per cui lavoro è una di queste. Ci sono molti in questi giorni e thatz davvero buone notizie.

Nel momento in cui senti che le cose non sono proprio nel posto di lavoro, ci sono due cose che puoi fare: o puoi influenzare il cambiamento positivo o lasciare quel posto e unirti a uno migliore.

CVS o qualsiasi sistema di gestione della configurazione non è male. Sfortunatamente il modo in cui viene utilizzato, senza conoscerne lo scopo, provoca questo tipo di dolore in! @ # $ Per l'intera organizzazione.

Per avere una rapida comprensione di cosa sia realmente Agile, consultare il libro "Pratiche di uno sviluppatore Agile" di Venkata Subramaniam. È ben scritto in un linguaggio facilmente comprensibile.

Ti auguro buona fortuna!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.