Perché separare i lavori di manutenzione dai lavori di sviluppo?

Question

Lavoro in un'azienda in cui la manutenzione viene eseguita dallo stesso team che dà vita a un software.

Molto spesso sento parlare di organizzazioni che hanno un team di manutenzione separato o un programmatore di manutenzione. Quello che mi chiedo è - qual è - il ragionamento che sta dietro questo?

Oltre a abbandonare il "vecchio codice" per i mortali minori, ce n'è?

Le lezioni apprese mantenendo il tuo "junk" personale hanno un valore molto più alto? La correzione dei difetti non è molto più efficace se eseguita da coloro che li hanno provocati?

Mi sto perdendo qualche vero motivo per cui potrebbe essere utile avere un team di manutenzione separato?

Answer 1

Il concetto che viene in mente per descriverlo al meglio è " thrashing . " Questo è essenzialmente il costo di commutazione che hai associato con i lavori di manutenzione e sviluppo. Questo è probabilmente il motivo principale per separare le responsabilità. Altri includono consentire ai programmatori junior o entry level l'opportunità di bagnarsi i piedi e mantenere gli sviluppatori più esperti che producono articoli di valore più elevato.

Ora, allo stesso tempo, penso che ci sia un valore in uno sviluppatore che ha scritto un'app che deve supportarla. In primo luogo, troveranno molto rapidamente problemi nel loro codice da cui possono imparare. In secondo luogo, penseranno alla manutenibilità e qualità del codice poiché devono supportarlo.

Esempio di schiacciamento nella vita reale:

Ti è stato assegnato un progetto di sviluppo di 1500 ore e sei anche responsabile della manutenzione dei sistemi e del supporto per le tue ultime 3 applicazioni. Durante questo nuovo progetto, in media sei interrotto 7 volte a settimana per supportare queste 3 app. Ogni volta che inizi a lavorare sulle altre 3 app, trascorri 20 minuti a concentrarti sul problema. Dopo aver risolto il problema, trascorri 20 minuti a rimettere a posto il codice che hai toccato l'ultima volta nella nuova app. Questo è un costo totale di 40 minuti per interruzione o 280 minuti a settimana. Ciò significa che durante la settimana hai perso 2,67 ore di produttività solo passando a supportare queste app.

Answer 2

Lavoro in un team agile da oltre un anno. Penso che non abbia importanza nel caso di un prodotto live (con questo intendo i clienti che utilizzano solo le ultime versioni). Supponiamo che tu abbia diverse versioni del tuo prodotto sul mercato e devi supportare ognuna di esse.

Prendi ad esempio la Microstation di Bentley. È un'applicazione di progettazione per 3d (architettura, progettazione di impianti, ponti stradali, ecc.). Ora diciamo che abbiamo v8, v9, v10 sul mercato. Hanno caratteristiche diverse e il formato del file è cambiato in modo significativo rispetto alle versioni. Ma i progetti sono così grandi (o i clienti sono così importanti) che devi supportare i client v8 e client v9 mentre sviluppi anche roba v10. Pertanto è necessario che la società disponga di un team di manutenzione (o tempo) assegnato alle versioni precedenti. Inoltre, in genere questi team vengono chiamati team di personalizzazione se il prodotto supporta la personalizzazione e lo scenario sopra menzionato.

Answer 3

Il problema è più pratico immagino:

• il vecchio codice è stato scritto da persone non più presenti nella società o nel team;
• il vecchio codice è stato scritto da sviluppatori esterni;

È molto comune in molte aziende avere una base di codice che non è più gestita dai programmatori originali perché non ci sono più. Se la base di codice è abbastanza grande, qualcuno deve tenerlo aggiornato in modo da essere chiamato manutentori.

Se puoi evitare questo caso, bene per te, ma assicurati che sia sempre temporaneo.

Answer 4

Non dirò di essere d'accordo con la pratica, ma in molte organizzazioni i consulenti sono stati ingaggiati per scrivere software in breve tempo, sforzi affrettati dopo i quali i progetti vengono consegnati ai programmatori interni per "mantenere". La logica è che puoi attirare qualcuno che è più abile senza formazione e quindi includerlo "trasferimento di conoscenze" alle persone che lavoreranno per mantenere intatto un software.

In breve, il più delle volte viene fatto per motivi politici / impraticabili.

Answer 5

Penso che la motivazione alla base della divisione dei team di manutenzione e sviluppo delle funzionalità sia quella di mantenere le cose senza intoppi: se il team di sviluppo delle funzionalità continua a dover interrompere ciò che stanno facendo per gestire una correzione di bug, il progetto si bloccherà. Avere un team di manutenzione separato libererebbe il resto degli sviluppatori per far andare avanti il ??progetto / prodotto in questione.

Answer 6

Il mio primo lavoro consisteva nel mantenere alcuni moduli software, i cui sviluppatori originali erano passati a qualche nuovo progetto.

Immagino:

• Rende il nuovo sviluppo più prevedibile, più facile da pianificare: poiché gli sviluppatori non vengono richiamati per risolvere un numero sconosciuto di problemi di manutenzione

• Opportunità di formare nuovi sviluppatori (ad es. me)

Inoltre, il codice che stavo mantenendo non era " junk " - era un software Telco, una prima rete a commutazione di pacchetto, che era stata distribuita a clienti come Bell, ecc. Era ben progettato, ben scritto, testabile (suite di casi di test automatizzati), mantenibile, molti file di log, alcuni design documentazione ...

... il sottotitolo del tuo OP sembra essere, " Amico, questo codice puzza! Vorrei poter ottenere lo sviluppatore originale e strofinare il suo naso: che lo imparerebbe! & Quot;

Quindi, quando il codice è già ben scritto, quell'argomento (insegnare agli sviluppatori originali) non è applicabile.

Quando dico che stavo facendo " manutenzione " è stato un po 'come lo sviluppo di nuove funzionalità ma di funzionalità molto minori ... ad esempio, interagire con i nuovi dispositivi dei clienti che hanno interpretato le specifiche del protocollo in un modo leggermente insolito.

[Analizzerei e diagnosticherei il problema e codificherei una correzione; e un addetto al controllo qualità aggiungerebbe un nuovo caso di test corrispondente alla suite di test automatizzata.]

Answer 7

Un vantaggio che posso vedere è che nell'organizzazione c'è almeno un'altra persona che è responsabile della comprensione del codice abbastanza bene da risolverlo. Inoltre, questa persona avrà in mente un'agenda diversa e potrà rivedere il codice dal punto di vista della manutenzione, se viene coinvolto in revisioni di progettazione / sviluppo (che dovrebbe essere).

Inoltre, " manutenzione " può fare riferimento a una serie di attività come la distribuzione, la configurazione, il backup, ecc. che dovrebbero essere sicuramente gestite da un team diverso.