Come gestire la gestione spingendo i sistemi legacy?

Attualmente sto svolgendo uno stage retribuito e mi è stato affidato il compito di mantenere un sistema obsoleto che è stato sviluppato da più sviluppatori (in momenti diversi) nel corso degli ultimi 5 anni. La direzione concorda sul fatto che "il sistema è in supporto vitale" e ricevo una fornitura abbastanza regolare di segnalazioni di bug dagli utenti finali che attualmente utilizzano il sistema.

Il management ora vuole estendere il progetto per un altro anno e nel processo quasi triplicare la base di utenti.

Come stagista (o qualsiasi posizione entry level) come posso "respingere"? Ho già scritto un rapporto affermando le mie preoccupazioni, anche se in un documento aperto. Esiste un protocollo o un tipo di documento per suggerire modifiche? Sono in grado di dare suggerimenti o devo semplicemente continuare a supportare il vecchio sistema?

• Per chiarire, lo sviluppo del software non è il business principale della mia azienda. Pertanto non esistono protocolli interni. Inoltre, il progetto non ha alcuna documentazione formale né documenti sui requisiti. Lo sviluppo è molto ad hoc.

Attualmente sto svolgendo uno stage retribuito e mi è stato affidato il compito di mantenere un sistema obsoleto che è stato sviluppato da più sviluppatori (in momenti diversi) nel corso degli ultimi 5 anni. La direzione concorda sul fatto che "il sistema è in supporto vitale" e ricevo una fornitura abbastanza regolare di segnalazioni di bug dagli utenti finali che attualmente utilizzano il sistema.

Il sistema non è obsoleto se le persone lo utilizzano ancora e supporta le attività aziendali. Dal momento che è ancora in uso, l'azienda non può semplicemente buttarlo via: deve essere supportato fino a quando non è più necessario il sistema. Potrebbe essere un cambiamento negli obiettivi aziendali o un nuovo sistema è stato sviluppato, testato e distribuito con successo agli utenti finali.

In realtà, 5 anni non sono così lunghi. Ho lavorato con un codice che aveva 10 anni prima. Se continua a soddisfare le esigenze dell'utente, perché buttarlo via? Questo sta buttando via un sacco di soldi spesi per svilupparlo. Fino a quando diventa impossibile mantenere a causa dell'aumento dei costi o dei requisiti che cambiano drasticamente, non c'è motivo commerciale per buttarlo via.

Il management ora vuole estendere il progetto per un altro anno e nel processo quasi triplicare la base di utenti.

Se la direzione afferma che questo sistema è "in supporto vitale", perché stanno cercando di implementarlo ulteriormente? È comune che le attività di manutenzione continuino su un sistema legacy fino a quando non viene sostituito, ma se un sistema è in esaurimento, in genere non viene distribuito a più persone. L'estensione della manutenzione è una cosa, ma aggiungere utenti che si affidano al sistema è una situazione completamente diversa.

A me sembra che in realtà non sia la fine della vita, ma piuttosto in una fase di manutenzione e continuerà ad essere lì fino a quando il sistema non soddisfa più le esigenze degli utenti.

Come stagista (o qualsiasi posizione entry level) come posso "respingere"? Ho già scritto un rapporto affermando le mie preoccupazioni, anche se in un documento aperto. Esiste un protocollo o un tipo di documento per suggerire modifiche? Sono in grado di dare suggerimenti o devo semplicemente continuare a supportare il vecchio sistema?

Devi continuare a supportare il vecchio sistema. Successivamente, accenni al fatto che il software non è l'attività principale della vostra azienda. In tale ambiente, il compito dei team di software è supportare l'attività principale dell'azienda. Tuttavia, i team del software devono anche tenere a mente gli obiettivi aziendali.

Nel frattempo, acquisisci i tuoi suggerimenti in modo non invadente. Indicare altre tecnologie o tecniche che potrebbero essere integrate con il sistema o utilizzate se / quando viene creato un nuovo sistema e i loro pro / contro. Il modo in cui lo fai dipende dalla compagnia, ma considerando alcuni punti successivi, potrebbe essere utile stabilire una wiki o un altro sito collaborativo.

In un settore non software, il software è un costo e i team del software (in particolare i responsabili del progetto / programma software) dovrebbero lavorare per ridurre al minimo i costi di costruzione e manutenzione dei sistemi software, supportando nel contempo le esigenze degli utenti finali . Gettare via software che (per quanto posso dire, dal tuo post, comunque) soddisfa le esigenze degli utenti va contro ciò che è nel migliore interesse del team del software.

* Per chiarire, lo sviluppo del software non è il business principale della mia azienda. Pertanto non esistono protocolli interni. Inoltre, il progetto non ha alcuna documentazione formale, nessun documento sui requisiti. Lo sviluppo è molto ad hoc.

Per me questo è il problema. Non produrre documentazione, non sviluppare secondo una specifica e una mancanza di coerenza tende ad aumentare i costi di sviluppo del software. Lavorare per risolvere questo sarebbe la mia massima priorità, e lo farei lavorando su cose come uno standard di codifica, il controllo della versione, producendo codice autocompattante e documenti di progettazione, rilevamento dei difetti e specifiche dei requisiti.

Ho già scritto un rapporto affermando le mie preoccupazioni

Buona. Questo è circa l'estensione di ciò che puoi fare come stagista. Per riferimento futuro quando scrivo tali rapporti, sottolineo di presentare fatti concreti in modo imparziale e professionale privo di pregiudizi emotivi. Non sai chi leggerà il rapporto, forse qualcuno che potrebbe aver causato o meno alcuni dei problemi che stai descrivendo o che abbia preso decisioni che hanno portato a questi problemi. Qualunque cosa diversa dai fatti freddi potrebbe essere presa da persone come un affronto o un'offesa e causerà loro che non ti piacciono e forse non ne prendono sul serio.

Il management ora vuole estendere il progetto per un altro anno e nel processo quasi triplicare la base di utenti

Tieni presente che le decisioni aziendali come questa vengono prese perché stanno cercando di prendere le risorse a loro disposizione. Sono certo che il management è probabilmente a conoscenza dei problemi con il software legacy e probabilmente dei reclami degli utenti, ma hanno le risorse di sviluppo software disponibili per gestire il refactoring o una riscrittura?

Il più delle volte non lo fanno, soprattutto se il software non è il pane e il burro dell'azienda e la qualità e la soddisfazione dell'utente con il software non influiranno direttamente sulla linea di fondo. Prendere questo tipo di decisioni a volte è il motivo per cui fare il manager fa schifo perché spesso ti trovi in ​​una situazione di perdita o sconfitta, qualunque cosa tu faccia.

mantenere un sistema obsoleto che è stato sviluppato da più sviluppatori (in momenti diversi) nel corso degli ultimi 5 anni

Nel corso del progetto sono stati commessi errori che lo hanno portato a questo punto. La mancanza di solidi input o requisiti degli utenti, la mancanza di un'adeguata gestione del prodotto e il controllo delle modifiche per gestire i mutevoli requisiti e necessità e la mancanza di risorse tecniche adeguate da implementare hanno causato i problemi come esistono oggi. Non so se obsoleto sia la parola giusta però. La tecnologia di base si basa su strutture e tecnologie desupportate o non è proprio all'avanguardia o tecnologie ideali?

Come stagista (o qualsiasi posizione entry level) come posso "respingere"?

Sei in una posizione di minor potere e sei temporaneo in questo. Non importa se hai ragione, non mi aspetterei che uno stagista mi "respingerà" mai. Mi aspetto che imparino, discutano dei problemi quando li vedono e seguono gli ordini. Questo è tutto. Una volta che un ordine viene dato, mi aspetto che venga eseguito al meglio delle loro capacità, perché a quel punto il tempo per la discussione è finito.

Sei uno stagista. Dubito fortemente che tu sia anche lontanamente alla larga con gli imperativi aziendali quotidiani nel loro complesso e come altri hanno notato, una base di codice di 5 anni non è poi così vecchia.

Le decisioni sulla sostituzione dei sistemi legacy non sono sempre guidate tecnicamente; sono guidati dal cambiamento dei requisiti aziendali. L'input a questi può essere difficoltà relative al mantenimento; ma alla fine della giornata, devi riconoscere che la tua posizione non significa necessariamente che hai tutte le conoscenze disponibili e richieste. Vorrei arrivare al punto di dire che in realtà hai pochissime delle conoscenze necessarie per effettuare la chiamata su quale sia la mossa migliore al momento.

Il mio consiglio per te è questo: impara dall'esperienza e smetti di presumere che le tue conoscenze prevalgano su quelle delle persone che devono gestire l'attività quotidianamente.

Il tuo compito è mantenere il sistema funzionante, non suggerire una nuova brillante sostituzione.

Mi sembra che molti giovani programmatori non si rendano conto che la manutenzione dei sistemi più vecchi è una parte più grande del lavoro di programmazione rispetto alla progettazione di nuovi sistemi brillanti /

Non respingere. L'unica cosa che dovresti fare è esprimere le tue preoccupazioni in modo chiaro e conciso. Il fatto è che la maggior parte delle aziende in cui lavorerai in futuro avranno sistemi legacy. Tali sistemi legacy devono essere mantenuti perché in molti casi sono troppo costosi per essere sostituiti.

In molti casi potresti anche avere le migliori intenzioni di sostituire il sistema attuale con un sistema migliore, tuttavia, potresti semplicemente introdurre nuovi e diversi bug ... quando lasci il sistema si trasformerà rapidamente in un sistema legacy di nuovo e la società lo farà essere nello stesso punto in cui era prima. Nulla è obsoleto fino a quando non serve più al suo scopo o è completamente incompatibile con i sistemi moderni. La mia azienda ha un sistema di oltre 20 anni che stiamo convertendo in ASP.NET. Il sistema funziona ancora, ma il supporto per la vecchia tecnologia sta diminuendo e farlo funzionare con i moderni browser Web sta diventando sempre più tempo.

Cosa puoi fare:

Lascia le cose più pulite

Quando mantieni qualcosa, lascialo più pulito di quando hai iniziato. fai la tua correzione, ma pulisci anche le cose, quindi la prossima volta che qualcuno ha bisogno di fare una modifica è più facile da capire.

Crea documentazione

Se la mancanza di documentazione è un problema, creare la documentazione. Quando lavori su una parte particolare del sistema, documentalo.

Renderlo meno doloroso

Come ho affermato, puoi esprimere le tue preoccupazioni, ma il meglio è semplicemente lavorare diligentemente sul sistema e renderlo migliore su cui lavorare dopo quelli che ti seguono. Correggi i bug correttamente. Documento. Elimina gli odori del codice. Rendilo migliore. E quando fai queste cose, fai sapere ai tuoi superiori. Di 'loro che stai facendo X, Y e Z per migliorare il processo di sviluppo. Ciò crea credibilità e, a lungo termine, aiuterà te e la tua azienda più di ogni altra cosa.

NON !!! Questa è un'ottima opportunità!

Sei uno stage da imparare! Questo progetto è un mondo reale come si arriva.

Sei molto fortunato ad averlo. Il fatto di non essere qualificato non è motivo di preoccupazione. (Se \ quando il management se ne rendesse conto, avrai guadagnato molto)

Sarai qualificato una volta terminato questo stage, e questa è una grande notizia.

PS: esegui i backup religiosamente, assicurati che TUTTO ciò che fai possa essere ripristinato. Inizia con i problemi che sono "Correzioni facili", ma grandi punti di dolore per gli utenti. Fai piccoli passi.

Immagino, in senso molto teorico, non esiste una cosa chiamata sistema Legacy . Ho un telefono molto vecchio (un sistema legacy) e in questi giorni ci sono buoni telefoni Android (piattaforme moderne), ma il mio telefono funziona e fa quello che mi serve. Perché dovrei buttarlo via?

Tutti i sistemi che oggi definisci "legacy", erano un giorno all'avanguardia. È solo il tempo di cui abbiamo bisogno. Inoltre, quando è in atto un lavoro considerevole, non è che rifare tutto di nuovo nelle piattaforme moderne, significa che sarà automaticamente privo di bug (o indolore).

Ecco cosa ti consiglio di fare:

1. Lascia prima la tua antipatia per il "sistema legacy". Questo ti renderà molto controproducente.

2. Inizia a documentare cosa fai ora e cosa pensi. Anche se in modo graduale. Non c'è momento migliore per fare la documentazione di quello in cui ti rendi conto di averne bisogno.

3. Invece di provare a respingere la promozione del "sistema legacy", prova a definire il percorso per la sua uscita senza problemi. Prova a vedere che puoi convincere il management che lo sviluppo più recente che può essere isolato, può essere fatto passo dopo passo nelle forme plat più recenti senza interrompere l'interoperabilità con i vecchi sistemi. Lentamente (e questo sarà molto lentamente) man mano che le cose evolvono, la necessità di mantenere il sistema legacy svanirebbe. Questo è l'unico modo per salutare qualsiasi vecchio sistema.

Dipan.

La verità è che nessuno offre agli stagisti il ​​lavoro che vogliono fare. Quando sei la persona più giovane, ottieni il lavoro meno entusiasmante. Quanto bene gestisci personalmente ciò che dice molto all'organizzazione sul fatto che possano fidarsi di te per fare di più l'eccitante lavoro.

Quindi ecco un'opportunità inestimabile per dimostrare che è possibile fornire eseguendo le correzioni di bug, che è possibile effettuare il refactoring rendendo ogni parte del codice che si tocca un po 'più bella, che è possibile creare unit test, iniziando a crearli per questo sistema e che puoi documentare creando la documentazione per la prossima povera anima che è bloccata con questo sistema. Ti dà anche la possibilità di dimostrare che puoi trattare efficacemente con gli utenti (per avere maggiori dettagli sui bug segnalati) e soddisfare le loro esigenze. Se il progetto non è ora nel controllo del codice sorgente, inseriscilo e se i bug non vengono tracciati in un tracker bug, quindi avviane uno. Questi tipi di azioni ti mostreranno come lavorare in modo professionale.

Oppure potresti prendere la strada opposta e lamentarti di quanto sia brutto il progetto e quanto sarebbe bello sostituirlo. In tal caso, quasi sicuramente non ti verrà offerto un lavoro presso quella società dopo il tuo internato.

Probabilmente non hai abbastanza informazioni per determinare se è conveniente andare un altro anno o no. Sarebbe interessante capire l'azienda e perché stanno aggiungendo utenti. Sembra che ci sia un po 'di crescita in corso e non possono permettersi di fare un passo indietro finanziariamente o con determinati vincoli di tempo per costruire un'altra app. Costruire una nuova app è raramente la scelta migliore comunque. 5 anni non sono così vecchi a meno che non lo abbiano costruito sulla vecchia tecnologia per cominciare.