it-swarm.it

Come posso convincere il management a gestire il debito tecnico?

Questa è una domanda che mi pongo spesso quando lavoro con gli sviluppatori. Finora ho lavorato in quattro aziende e sono venuto a conoscenza della mancanza di attenzione nel mantenere pulito il codice e gestire il debito tecnico che ostacola i progressi futuri in un'app software. Ad esempio, la prima azienda per cui ho lavorato aveva scritto un database da zero anziché utilizzare qualcosa come MySQL e questo ha creato l'inferno per il team durante il refactoring o l'estensione dell'applicazione. Ho sempre cercato di essere onesto e chiaro con il mio manager quando discute delle proiezioni, ma il management non sembra interessato a sistemare ciò che è già lì ed è orribile vedere l'impatto che ha sul morale della squadra.

Cosa ne pensi del modo migliore per affrontare questo problema? Quello che ho visto è la gente che fa i bagagli e se ne va. La società diventa quindi una porta girevole con gli sviluppatori che entrano ed escono e peggiorano il codice. Come lo comunichi alla direzione per renderli interessati a risolvere debito tecnico ?

164
Desolate Planet

Quando ho incontrato il mio capo per discuterne, ha detto che avrei dovuto includere il refactoring in tutte le mie stime. Ha detto che non è un problema a cui vuole pensare. Invece, dovrei gestirlo.

Questo non è un problema a cui la direzione in generale vuole pensare. Non sono gli ingegneri, lo sei. Rendi solo questa una parte inespressa di tutte le tue stime e scoprirai che il debito tecnico diminuisce.

Non sarà mai perfetto però. Il debito tecnico, come il debito della carta di credito, è un investimento per rendere i clienti più veloci e guadagnare più rapidamente la quota di mercato rispetto ai concorrenti. Come il credito, se gestito correttamente, può farti abbastanza successo.

194
jmort253

È come ha detto Gandhi quando gli è stato chiesto se la sua tattica avrebbe funzionato con qualcuno come Hitler. Disse: "Sarebbe difficile". Ma penso che ci sia una buona argomentazione secondo cui la risposta è davvero "No". Purtroppo, non penso che ciò che stai cercando di fare possa essere fatto. Non è che sto cercando di essere pessimista, ma piuttosto sto cercando di essere onesto.

Il problema per me non è che i manager debbano convincere. I migliori comprendono già che il debito può essere un killer se non gestito. Ma che lo capiscano o no, che siano bravi manager o cattivi, tutti affrontano la pressione di consegnare e quella consegna viene giudicata dai loro capi in base a una data. La qualità conta solo se è estremamente negativa, nel qual caso è colpa degli sviluppatori, o estremamente buona, nel qual caso è la genialità del management che l'ha resa possibile. La qualità deve solo essere "abbastanza buona".

Penso che mi piace quello che ha detto Renesis nella sua risposta, perché è uno dei pochi a capire che il management pensa in modo molto diverso dall'ingegneria. E penso che tutti noi abbiamo visto la progressione delle aziende diventare orientate alla data e più gestite dal progetto rispetto al cliente e alla qualità. Con questo intendo le aziende tipiche, non quelle veramente stalward che hanno il coraggio di dire "Sarà fatto quando sarà fatto" (come Apple Computer o software ID - e sì, io capire che a volte le persone non sono libere di adottare questo approccio).

Ma ecco il punto: le aziende che adottano il primo approccio di qualità ... cosa noti di loro? Esatto, sono gestiti da ingegneri, non da venditori, esperti di marketing, project manager o commercialisti. Pensa a HP, Apple, id, Google, Microsoft e IBM. Tutto è iniziato e realizzato con successo dagli ingegneri, non dai venditori, anche se i venditori hanno sicuramente giocato un ruolo, e sono sicuro che molti avrebbero discusso del fatto che Microsoft fosse associata alla qualità :). E di quelli, quelli che sono andati in discesa si sono allontanati dalla leadership guidata dall'ingegneria. Tuttavia, ci sono molti argomenti in quella dichiarazione, poiché ci sono molte aziende tecniche che alla fine hanno fallito a causa dell'incapacità di adattarsi ai tempi che cambiano e gestire la propria crescita. Non vedo la leadership basata sull'ingegneria come la causa di questi fallimenti, per me questo è un problema di capacità e acume aziendale che sono indipendenti da qualcuno che è uno sviluppatore o un contabile. Penso in generale, tuttavia, che ci sia una dedizione in ingegneria ai rigori della responsabilità e della disciplina che avvantaggia le aziende in cui l'ingegneria è una componente.

Seriamente, guardati intorno. La leadership IT è gravemente carente. L'attenzione è sempre sui costi e sui tempi, e raramente sulla qualità, purché sia ​​abbastanza buona. I leader IT raramente riferiscono più al CEO, ora è sempre il CFO. L'IT è bloccato nel supportare la produzione e sempre più guardato ai project manager che si concentrano su blocchi più piccoli, più digeribili e misurabili, non cambiamenti significativi di valore rivoluzionario (non che ciò sia necessariamente sbagliato; dividere e conquistare è una buona cosa, ma la visione deve essere lì per il quadro generale).

Mi spiace occuparmi così tanto di questo post, ma alla fine penso che la tua domanda, su come fare in modo che il management gestisca il debito tecnico, sia spesso risolta meglio trovando il leader giusto, piuttosto che cambiare quello esistente. Spiegare il debito tecnico verso i pensatori standard significa cambiare l'attenzione su denaro e costi, come ha detto Renesis, e penso che perda molto nella traduzione; anche se ci riuscissi, importerebbe solo se lo acquistasse il miglior leader dell'azienda. Convincere il tuo middle manager a fare la cosa giusta probabilmente lo farà licenziare.

48
Bernard Dy

La prima cosa da fare è cambiare il testo. Chiamarlo "debito tecnico" dà al management l'idea che permetterlo sia un investimento di qualche tipo, quando in realtà lo è più come un virus. (Sono come il Dave Ramsey del debito tecnico.)

Permetterlo di non essere pagato ha un costo enorme che non può essere visto o facilmente quantificato.

Elencare i problemi come i seguenti per la gestione:

  • Le stime delle nuove funzionalità sono molto più elevate di quanto debbano essere. O, impossibile del tutto.
  • Il codice errato genera altro codice errato
  • L'elenco dei bug cresce anche se gli sviluppatori li risolvono sempre
  • I membri del team se ne stanno andando (questo stesso può mostrare che c'è un problema, come spiegato in questa eccellente risposta )
43
Nicole

Il mio management ha effettivamente iniziato a fare uno sforzo serio per affrontare il debito tecnico, che è uno dei motivi per cui mi piace lavorare lì, ma è uno sforzo a lungo termine e non fa mai male ricordare loro perché lo sforzo vale la pena.

Un modo per mantenere la pressione è quando mi viene chiesto un preventivo, e il tempo potrebbe essere risparmiato se non avessi dovuto affrontare specifici problemi di debito tecnico, lo includo nel mio preventivo. Ad esempio, " Questo bug impiegherà 2-3 giorni per rintracciarlo, ma se avessimo già risolto questi altri 2 bug" a bassa priorità "che sono stati in coda per sempre, sarebbe probabilmente ne prenderà meno di uno. "Spesso, la risposta sarà quella di andare avanti e sistemare gli altri mentre ci sei.

Concordo anche con altre risposte riguardo al considerare i miglioramenti come parte del tuo lavoro e a farli come fai se non sono troppo distruttivi. Il mio compito attuale prevede l'aggiunta di alcuni codici molto mal progettati. Invece di aggiungere al caos scrivendo il mio nuovo codice per abbinarlo, sto impiegando un po 'di tempo a consolidare le funzionalità comuni, quindi l'invio di un pacchetto diventa una chiamata di funzione a una riga invece di ripetere costantemente 15 righe di copia e modifica leggermente modificate incolla il boilerplate.

So per certo che salverà ulteriormente la sanità mentale di un manutentore lungo la strada. Lo so perché sono quel manutentore oggi. Tuttavia, credo anche che acceleri il mio compito attuale di far funzionare questa funzionalità e eseguire il debug ora.

Un'altra tecnica che ho usato in passato e che dovrei ripetere è mantenere un ramo DVCS refactoring in un albero di lavoro separato per i tempi di inattività durante la compilazione, in attesa di un lungo test, oppure ho solo bisogno di cambiare ritmo per un po 'quando sei stanco di un bug. Fintanto che occasionalmente ti unisci a monte in modo da non divergere troppo lontano, puoi impiegare tutto il tempo che desideri sul refactoring delle modifiche con un minimo sforzo marginale. 15 minuti qua e là al giorno possono davvero aumentare nel tempo.

30
Karl Bielefeldt

Potresti provare l'analogia con la carta di credito. Chiedi loro "ti senti a tuo agio a lasciare gli estratti conto della tua carta di credito non pagati per un lungo periodo di tempo?"

I gestori comprendono costi e benefici, ma (di solito) non i termini tecnici utilizzati da noi sviluppatori. Il termine "debito tecnico" è già stato inventato per aiutare a superare questa barriera di comunicazione, ma potrebbe essere necessario articolarlo più chiaramente. La maggior parte dei gestori sa molto bene (spesso per esperienza personale) che i pagamenti scaduti con carta di credito crescono con un orribile tasso di interesse, quindi fa male lasciarli non pagati. Questo può aiutarli a ottenere la gravità del problema relativo all'entropia del software.

Ma se ciò non li convince, prova a raccogliere prove concrete e fai dei calcoli. Per esempio. quanto costa per l'azienda, sia in termini di liquidità che di perdita di tempo, sostituire un dipendente uscente.

20
Péter Török

Nessuno darà soldi per sostituire qualcosa che funziona con qualcos'altro che (con un po 'di fortuna) funziona anche.

Quello che puoi fare è proporre di sostituirlo con qualcosa che fa di più, ovvero raggruppare il servizio del debito tecnologico in un aggiornamento che porta vantaggi aziendali immediati e tangibili.

Ovviamente dovresti essere aperto al riguardo, non stiamo parlando di "intrufolarlo" in un nuovo progetto qui.

Trovo l'altro lato, quello degli sviluppatori più difficile da gestire. Fondamentalmente si riduce a questo: per alcuni sviluppatori, assicurarsi che il proprio codice sia il miglior codice possibile è una questione di orgoglio professionale. Per altri, questo è solo un altro lavoro e l'obiettivo è farlo in fretta e tornare a casa.

Nessun dato convincente cambierà questa situazione e, se introduci uno standard di qualità del codice obbligatorio, i tuoi sviluppatori da nove a cinque troveranno un modo per far funzionare il sistema, mentre i tuoi sviluppatori dedicati saranno inevitabilmente infastiditi dall'intera procedura (che non è non sono rivolti a loro, ma non puoi dire che lo sviluppatore X deve obbedire alle regole, mentre Y può fare quello che vuole).

Ciò che funziona, ma può ancora essere molto frustrante, è far sì che i tuoi sviluppatori più dedicati e competenti supervisionino la base di codice, probabilmente un buon compromesso tra andare avanti e riordinare ciò che è alradie lì.

12
biziclop

Il fatto è che in molte aziende, in particolare data l'attuale situazione economica, ogni ora deve essere fatturata a qualcuno.

Oppure scendono, veloce.

A meno che i clienti esistenti non siano disposti a pagare per il refactoring, il che è profondamente improbabile a meno che non si tratti di prestazioni o funzionalità notevolmente aggiornate. Quindi non accadrà sulle basi di codice più vecchie. Potresti essere in grado di intrufolarlo nel budget per i progetti più recenti, se i clienti hanno tasche profonde, ma a meno che non sia necessario modificare le API nel refactoring, non sarà utile ai progetti più vecchi e potrebbe anche introdurre un situazione in cui la società supporta due basi di codice, che provoca ulteriori mal di testa e costi.

Come ingegnere, mi piacerebbe riformattare il vecchio codice, che non è più veramente adatto allo scopo, ogni volta che qualcosa diventa obsoleto o deprecato. Ma come i miei MD in tutte le aziende in cui ho mai lavorato mi hanno detto: "Chi pagherà?"

12
Orbling

Cerco sempre di pulire mentre vado. Non ho finito finché il codice non è pulito. Il problema con il debito tecnico è che la maggior parte delle persone non lo capisce. Il modo migliore per affrontarlo è non accumularne nulla. Se i tuoi manager si affidano ai tuoi sviluppatori per decidere come risolvere un problema, puoi rendere l'igiene del codice parte di ogni attività di programmazione. Se non si verifica mai un codice errato, non si accumula debito. Se segui anche Boy Scout Rule (lascia sempre il codice più pulito di quello che hai trovato) il tuo debito esistente svanirà lentamente.

Non vedo il refactoring come un'attività separata dall'implementazione delle funzionalità. È parte integrante di esso.

12
EricSchaefer

Se hai a che fare con manager non tecnici, sarebbe di aiuto se riesci a trasformare la tua discussione in termini comprensibili. Se riesci a costruire un caso realistico per un ROI positivo sul lavoro speso per estinguere il debito tecnico, potresti arrivare da qualche parte. L'esercizio dipenderà dalle tue circostanze, ma un esempio potrebbe essere qualcosa del genere:

Analizzare il tempo che gli sviluppatori sono costretti a dedicare per aiutare il supporto con problemi di produzione, quindi ipotizzare che la correzione del vecchio codice scadente A. ridurrebbe il numero di problemi di supporto, B. renderebbe più semplice per il supporto risolvere i problemi senza passare allo sviluppo e C. ridurre il tempo che lo sviluppo dedica ai problemi di produzione quando si presentano. Detto in termini di dollari risparmiati dal fatto che gli sviluppatori non siano collegati per fare il lavoro di supporto. Sottolinea inoltre che ogni ora che uno sviluppatore spende facendo il supporto è un "doppio scemo" perché non solo stai pagando uno sviluppatore per fare il supporto, ma stai bruciando il costo opportunità di ciò che potrebbe fare lo sviluppatore (aggiungendo nuove funzionalità, ecc. .)

Sì, alcuni dei numeri saranno voodoo/fumo-e-specchi ... va bene, il sporco segreto del management è che lo so che la maggior parte dei numeri che circolano sono in totale B.S. Fintanto che darai loro qualcosa di apparentemente concreto con cui lavorare, in modo che possano metterlo in testa, hai una possibilità di combattere.

7
mindcrime

Dopo questa spiegazione del debito tecnico, la tua direzione dovrebbe essere convinta a ripagarlo:

Immagina di avere una cucina molto sporca piena di merda. Prima di preparare un pasto, devi prima passare un'ora a pulire. Ed è così ogni volta che vuoi mangiare. Inoltre, quando prepari un pasto, devi essere molto attento, per assicurarti che la merda non cada nel tuo pasto.

La cucina è il tuo codice, il pasto è il tuo prodotto e mangiare è vendere il tuo prodotto.

Se possono permettersi di attendere più a lungo per l'implementazione di una modifica, senza una rete sicura di unit test, allora c'è qualcosa che non va nella tua azienda.

6
BЈовић

Deve essere un argomento molto convincente, in termini di prodotto originale e business case, che non potrei usare quei soldi ora per fare qualcosa di più importante per me. Piaccia o no, la tua direzione o i tuoi clienti pagano per questo e devi essere in grado di vendere per convincerli.

Riformuliamolo per posizionarti come cliente. Buon vecchio gioco di ruolo.

Supponiamo che tu stia comprando un frigorifero. E potresti comprare un frigorifero per $ 1000 che funzionava bene da Acme Corp. O un frigorifero per $ 2000 da Acme Deluxe Fridges che sembrava lo stesso all'esterno e aveva le stesse specifiche tecniche, ma aveva costi di manutenzione inferiori a causa di un'architettura interna più pulita.

Come cliente, quale compreresti tu stesso?

E cosa pensano gli ingegneri di Acme Deluxe la risposta migliore?

4
jasonk

" Debito tecnico " può essere un argomento complicato da presentare alla direzione in quanto potrebbe non vederne la necessità. La domanda potrebbe essere formulata come se nella società ci sia o meno un campione che affermi "Guarda, stiamo impiegando il X% del tempo per lavorare sul debito tecnico qui. Dacci 3 mesi per mostrarti che funziona bene" o qualcosa del genere simile. C'è una pretesa di autonomia lì, ma anche un lasso di tempo, altrimenti il ​​management potrebbe chiedersi per quanto tempo prima di vedere alcuni risultati che è piuttosto pericoloso.

Il primo punto è se vedono o no questo come un problema. Se la persona con problemi di vista non sa nulla degli occhiali e quali tipi di cambiamenti possono apportare, come possono capire perché un esame della vista potrebbe essere prezioso? Stessa idea qui in cui l'argomento è piuttosto tecnico e purtroppo non facilmente quantificabile.

3
JB King

Dovresti smettere di lamentarti.

Ecco perché:

  1. Non prevedono mai di utilizzare il software per più di un anno
  2. è solo una perdita di tempo modificarlo se il loro piano è quello di scaricarlo in seguito
  3. ci sono alcuni problemi reali che devono essere risolti ora
  4. i programmatori devono solo imparare a gestire la manutenzione, anche se non è sempre divertente
  5. lamentarsi di sapere meglio cosa deve essere fatto è arrogante: qualcun altro prende la decisione e dovresti esserne felice
  6. Si fidano comunque che tu scriva un buon codice

Quindi il modo migliore per procedere è:

  1. Quando ti danno una nuova attività, prova a implementarla nel miglior tempo possibile
  2. Scrivilo perfettamente la prima volta. Se in seguito è necessario modificarlo, si è commesso un errore la prima volta e ogni cambiamento va sempre nella direzione sbagliata - ed è un'opportunità di apprendimento per i programmatori quando si commettono errori.
  3. Non chiedere altro tempo, non lo capirai, ci sono delle scadenze che conosci.
2
tp1

Presumo che tu non sia mai stato coinvolto in un progetto di riscrittura/sostituzione o persino aggiornamento e sistema esistente.

Questi sono alcuni dei progetti più difficili da completare con successo. Alcuni dei problemi che incontrerai sono:

  1. Le regole aziendali si perdono nel tempo.
  2. La documentazione e l'implementazione sono totalmente fuori sincrono.
  3. Quello che vedi come un bug gli utenti vedono come una funzionalità.
  4. Al contrario, molte "funzioni" verranno visualizzate come difetti dagli utenti.
  5. Non otterrai acquisti da parte degli utenti - considereranno la tua "scoperta di fatti" come "secchioni che fanno domande stupide", considereranno lo sforzo di test come una perdita di tempo, insisteranno nell'aggiungere nuove funzionalità in modo da allungare un progetto essere già in ritardo.
  6. È probabile che il codice sorgente non corrisponda al 100% con l'eseguibile in esecuzione.
  7. Mentre il tuo dipartimento si sta occupando dello sviluppo del refactoring, il business che in realtà vuole non viene svolto.
  8. È probabile che il tuo re-factoring comporterà "interfacce migliorate più pulite", trascinando così altri progetti nel tuo pantano di consegna ritardata e test falliti.
  9. Dopo che il progetto è stato fissato (ben oltre il 50% di questi sforzi fallisce completamente) avrai perso tutta la credibilità - dovrai trasferirti in un'altra società in un'altra città per trovare qualcuno disposto ad ascoltare anche te.
  10. Se il progetto "avrà successo" tutti ricorderanno che incubo è stato - lo farai .......

Vi esorto a evitare eventuali riscritture/progetti di refactoring come la peste, possono essere alcune delle esperienze più scoraggianti nella carriera di qualsiasi professionista.

C'è molta saggezza nella frase "Se non è rotto non aggiustarlo".

2
James Anderson

Essendo già stato coinvolto in un'importante riscrittura, (non solo refactor), posso essere d'accordo sul fatto che convincere i ragazzi finanziari ad accettare il progetto sia stato uno dei maggiori ostacoli. Superare quell'ostacolo mi ha richiesto di scrivere, presentare e difendere un rapporto che evidenziava una serie di problemi che indicavano che l'attività delle aziende sarebbe stata interrotta nell'acqua nel breve e medio termine.

Fattori chiave per ottenere l'accordo per andare avanti:

  • Il codice esistente era in una catena di strumenti non più supportata (MicroPower Pascal), che funzionava solo su una piattaforma di sviluppo quasi insopportabile (PDP11-23).
  • Trovare sviluppatori in grado di lavorare su strumenti e obiettivi stava diventando quasi impossibile.
  • L'hardware di destinazione non era più disponibile se fossero necessari ricambi e il produttore stava diventando sempre più riluttante a fornire un servizio di riparazione.
  • I problemi del codice causavano insoddisfazione del cliente e costi di manutenzione diretta facilmente identificabili.
  • L'aggiunta di nuove funzionalità o persino la correzione di bug stava diventando quasi impossibile a causa delle limitazioni dell'hardware di destinazione, con la conseguente necessità di riformattare altre aree in modo da fornire spazio quando si affrontano i problemi.
  • Con un tempo di costruzione di 8 ore lo sviluppo e il test di eventuali modifiche sono stati costosi.

Il rapporto ha dettagliato i problemi, con stime dei costi in corso, e ha offerto 3 opzioni:

  1. Congelati dove probabilmente non avremmo nemmeno risolto i bug nel prossimo futuro.
  2. Ottimizza il codice solo per lo spazio, senza riguardo alla manutenibilità, sottolineando che chiunque tenti di mantenere il codice ottimizzato dovrebbe essere più intelligente di chiunque abbia fatto l'ottimizzazione.
  3. Reimplementare, con testabilità e manutenibilità come fattori elevati, in uno standard industriale, ampiamente insegnati, linguaggio (ANSI C), su hardware COTS nuovo, a basso costo, (PC-104), con più fornitori disponibili con un servizio interno scheda di interfaccia progettata per consentirne il funzionamento con l'hardware esistente rimanente. Aggiunta di una serie limitata di nuove funzionalità come parte dello sviluppo come l'archiviazione non volatile, un timer watchdog per fornire il riavvio automatico in una condizione di errore alcune unità si arrestavano in modo anomalo più volte al giorno e richiedevano una chiamata di assistenza di £ 40 per ripristinare, migliore diagnostica nel processo.

Avendo ottenuto il via libera per la terza opzione, il mio contratto di 3 mesi si è trasformato in 3 anni di duro lavoro, sia nello sviluppo del nuovo software che dell'hardware, ma con un ottimo risultato.

Per i casi con debito tecnico meno estremo tendo ad adottare quello che chiamo refactoring di guerriglia:

In caso di problemi con un modulo specifico:

  1. Scrivi una serie di test che dimostrano il problema che probabilmente falliranno anche senza refactoring
  2. Refactor come parte dello sviluppo sottolineando che i test continuano a fallire.
2
Steve Barnes

Per la mia vita non riesco a capire perché alcune persone abbiano così ciecamente paura del cambiamento - sa di mancanza di fiducia nelle tue capacità.

Ho visto uno spettacolo ieri sera sul Parco Nazionale di Yosemite ed è stato osservato che dal 1940 alla fine degli anni '90 non è spuntato un nuovo albero di Sequoia. È stato scoperto che il motivo era che esisteva una rigida politica contro la combustione degli incendi boschivi e che le pigne di sequoia avevano bisogno del calore del fuoco per aprire e rilasciare i loro semi.

Vedi, un incendio ogni dieci anni circa era salutare. Ha eliminato tutto il deadwood e il rovo accumulati per mantenere in salute gli alberi (processi) esistenti e fare spazio a quelli nuovi (caratteristiche).

Sono su un progetto in questo momento che ha un chiaro caso da ricostruire: il software legacy è stato scritto interamente utilizzando i moduli web .NET. Quasi tutta la logica aziendale è combinata con la logica di visualizzazione tag HTML/server e non può essere estesa ad altre applicazioni ora che l'azienda è cresciuta.

La gestione è alla base del compito perché hanno un'adeguata fiducia nei loro sviluppatori che, mi rendo conto, è un lusso raro.

Sì, chiediti se una ricostruzione è veramente necessaria. Fai del tuo meglio per riutilizzare il codice esistente che funziona dove puoi. Integrare quel codice nella ricostruzione, se necessario. Non permettere a nessuno di convincerti che avere paura di apportare modifiche audaci sia l'unico modo per esistere come sviluppatore di software.

In bocca al lupo!

1
Matt Cashatt

È necessario fornire alla propria direzione un motivo finanziario per far fronte al debito tecnico e un quadro per la gestione della riduzione di tale debito tecnico.

Mantenere una roadmap tecnologica è uno di questi quadri. Iniziare con una tabella di marcia ti aiuterà a impedirti di accumulare debito tecnico e può anche aiutarti a ridurre il debito esistente.

Molti progetti a lungo termine di successo hanno associato comitati direttivi e tabelle di marcia per guidare lo sviluppo. Questi sono particolarmente utili quando sono coinvolti più team di sviluppo e parti interessate.

Il mio suggerimento è di discutere questa strategia con i vostri manager (e, se possibile, con quelli che prendono decisioni su dove vengono spesi i soldi).

L'approccio generale alla creazione e alla gestione di una tabella di marcia è semplice, ma richiede il supporto del team di gestione. Innanzitutto, definisci un obiettivo. Definire gli elementi del debito tecnico e sviluppare un'architettura di sistema target che riduca gli elementi del debito tecnico. Ricorda, non deve essere perfetto, realizzabile e migliore di quello che sei attualmente. Prendi in considerazione software, strumenti di sviluppo, piattaforme hardware, nuove importanti funzionalità che possono essere aggiunte al sistema. Fai un'analisi dei costi. Se si dispone dell'architettura desiderata, quali sono i vantaggi tangibili dell'esecuzione del refactoring? (I vantaggi includono tempi di test ridotti, prodotti software più affidabili, cicli di sviluppo più prevedibili, ecc.) Se si possono dimostrare abbastanza benefici nell'esecuzione del refactoring, è possibile ottenere supporto gestionale.

Una volta che hai una roadmap e un supporto gestionale, sviluppa una serie di passaggi (chiamati anche un piano) che devi prendere per raggiungere lo stato desiderato. Potrebbe essere una buona idea mettere insieme un comitato direttivo che mantenga la tabella di marcia, formi ed educi i team di sviluppo sulla tabella di marcia e riveda periodicamente le modifiche per l'integrità dell'architettura.

Le tabelle di marcia sono davvero utili e forse la tredicesima domanda sul test Joel dovrebbe essere "Hai una tabella di marcia?"

Ecco un video della prima ora di una recente sessione della roadmap di Red Hat Linux .

1
Jay Elston