Ho appena iniziato un lavoro con Scrum e sembra che manchi qualcosa. Sono nuovo di Scrum

Il codice è un casino completo di una combinazione di ASP / ASP.NET classico. La mischia consiste nel rattoppare il grande pasticcio o fare aggiunte ad esso. Siamo tutti troppo impegnati a farlo per iniziare una riscrittura, quindi mi chiedo ..

Dov'è la parte in Scrum in cui gli sviluppatori possono avere il potere di dire che basta e chiedere loro di avere il tempo di iniziare la grande riscrittura? Sembriamo in un ciclo infinito di patch del vecchio codice con "Stories".

Quindi le cose non sono gestite da persone non tecniche che sembrano non avere alcuna voglia di spingere per una riscrittura perché non capiscono quanto male sia la base di codice.

Quindi chi è incaricato di realizzare questo grande cambiamento di riscrittura? Gli sviluppatori? Lo Scrum Master?

La strategia attuale è solo trovare il tempo e farlo da soli, senza il più alto-up coinvolte dal momento che sono in gran parte da biasimare per l'attuale caos ci troviamo .. <-inserto rant su persone non tecniche dire alla gente tecniche cosa fare qui ->.

Non sono sicuro del perché sia ​​così difficile per le persone. Il suo caso aziendale è proprio qui:

We seem in an endless loop of just patching old code with 'Stories'.

Il tempo degli sviluppatori è denaro. Un sacco di soldi. Ho lasciato un'azienda che aveva pianificato di rinnovare la propria interfaccia utente più di un anno fa e speravo che l'adozione della mischia li avrebbe aiutati a smettere di girare le ruote. Quello che è successo? Lo stesso vecchio 'stesso vecchio'. Hanno continuato a sfruttare nuove funzionalità e il "debito tecnico" non ha avuto alcun caso commerciale anche se metà del codice che abbiamo scritto è diventato insignificante con ogni iterazione a causa del fatto che la base di codice sottostante è un disastro completamente obsoleto. Non è cambiato nulla sul loro front-end da quando me ne sono andato, e sono stato portato al solo scopo di rinnovarlo completamente. Nei due mesi in cui ero lì, non ho toccato una leccata di CSS o JavaScript. Stavo solo scherzando con HTML e alcuni antichi sistemi di template Java alla fine degli anni '90.

La mia risposta? Fai quello che puoi, ma se gli altri sviluppatori hanno già rinunciato e lavorano in ritardo per raggiungere gli obiettivi dello sprint piuttosto che affermare scadenze più pratiche e insistendo sul fatto che il debito tecnologico è in realtà un problema di blocco, prendi il peggio e inizia a cercare un nuovo lavoro adesso. I tuoi sviluppatori non sono in grado o non sono autorizzati a comunicare le loro preoccupazioni o gli affari sono troppo! @ # $ Ing miopi per capire quanti soldi stanno incazzando.

Ignorare questi problemi SEMPRE costa di più a lungo termine. E non un po 'di più, ma MOLTO di più. Non è solo una ferita al torace che riguarda i tempi di sviluppo, ma inevitabilmente ridurrà i livelli di talento in quanto gli sviluppatori che conoscono meglio e hanno altre opzioni eviteranno la tua azienda come la peste. Il mio attuale capo è uno sviluppatore E il proprietario dell'azienda. Ci sono cose che non riscriveremo per concentrarci su altre priorità, ma quando qualcosa ha davvero bisogno di un refactoring a causa della coerenza dei tempi, ottiene un refactoring adeguato. E i risultati sono ovvi. La modifica e l'aggiunta di nuovi elementi diventa più facile e veloce per molteplici fattori. Ciò che una volta può aver impiegato ore può richiedere minuti con un'architettura adeguata. Alle imprese non piace ascoltarlo, ma vale la pena mettere le cose in sospeso per quello.

Scrum è un fallimento in ambienti in cui gli sviluppatori non hanno molta influenza, IMO, perché è troppo facile per i tipi di business voler ignorare la manutenzione e gli aggiornamenti a favore dei punti elenco che possono inserire nelle loro liste di "iniziative di successo" quando arriva il tempo di valutazione. Favoriranno sempre le loro pelli e il potenziale di promozione a favore del lungo termine, anche quando le morde costantemente nel culo per ignorare anche questi problemi.

Scrum è anche un settore motivato dal profitto e poi alcuni. Le aziende pagano molti soldi per l'addestramento alla mischia. Le persone in cerca di adozione dovrebbero prestare attenzione a chi viene commercializzato e quanto realistico sarà davvero all'interno della propria cultura.

Indipendentemente da ciò, se ti interessa davvero dello sviluppo, una base di codice schifosa, la gestione con la cera nelle orecchie e gli sviluppatori senza spine è una ricetta per la miseria e un ambiente che farà molto poco per migliorare la tua abilità in qualsiasi aspetto utile. Non esitate a iniziare a mettere in moto GTFO prima di aver effettivamente scoperto se i vostri sforzi per risolvere il problema stanno effettivamente ripagando.

Se dovessi davvero fare Scrum, di cui dubito, il Product Owner sarebbe responsabile di decidere in merito a una riscrittura. Il più delle volte una riscrittura non è una buona idea, tra l'altro, perché non produce nuove funzionalità, introduce solo nuovi bug.

http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky
http://www.joelonsoftware.com/articles/fog0000000069.html

Espandere "riscrivere non è una buona idea":

È quasi sempre meglio provare un miglioramento graduale. Come Jarrod Robertson ha scritto in un commento, trova un modulo che necessita di miglioramenti diventa l'esperto per quel modulo e scrivi una storia per il prossimo sprint per migliorare quel particolare modulo. Spiega al proprietario del prodotto perché quel modulo ha bisogno di lavoro.

Sarò davvero schietto ...

• Sei responsabile degli sviluppatori in questo lavoro?
• Sei il capo progetto?
• Quanta "partecipazione" detengono gli sviluppatori nel progetto?
• Qual è la tua giustificazione commerciale per una riscrittura?
• Cosa c'è nella base di codice che la rende del tutto inutile e irrecuperabile?

Hai dichiarato di aver appena iniziato un lavoro, eppure sembra che tu sia già un maestro della situazione lì. Forse ho frainteso l'intento della tua domanda, ma ho l'impressione che tu abbia inserito un lavoro in cui riscontri una serie di problemi e sei passato alla conclusione più semplice in cui il codice è rotto e l'unica via da percorrere è una riscrittura, ma hai davvero considerato il costo per il tuo datore di lavoro per farlo?

Con qualsiasi base di codice esistente, indipendentemente dallo stato in cui si trova, il proprietario avrà di solito un investimento considerevole nei prodotti rappresentati dal codice. Ci sono costi sia diretti che indiretti associati alla base di codice e una riscrittura è spesso l'ultima cosa che vuoi fare come sviluppatore di software, poiché rischi di svalutare le tue risorse di codice e ottenere così un rendimento inferiore su tutti i tuoi precedenti sforzi.

Prendi il sistema operativo di Windows come esempio. Con ogni nuova versione creata, c'è stato un grosso pezzo di codice portato avanti dalla versione precedente. A volte, intere librerie e API vengono trascinate in avanti attraverso diverse generazioni di SO. Perché? Perché gli sviluppatori sanno che questi elementi funzionano, sono stati testati, sono stati riparati e riparati per prevenire problemi di sicurezza e memoria e perché sono costati un sacco di soldi per entrare in quello stato. Nessuno vuole buttare via il codice di lavoro quando li guadagna, anche se i costi di manutenzione sono relativamente alti, i costi per iniziare da zero saranno sempre più alti e, in un'azienda come il caso di Microsoft, hanno miliardi in banca che consentire loro di iniziare dall'inizio se lo desiderano, ma non t perché vogliono massimizzare il loro ritorno dal loro investimento. Il tuo datore di lavoro non è diverso da Microsoft, tranne per il fatto di avere miliardi in contanti da lanciare a un progetto.

Quindi il codice è un disastro e sembra che ci siano problemi di comunicazione e di confine tra le varie aree dell'azienda. Cosa puoi fare tu o i tuoi colleghi al riguardo?

Un'opzione è semplicemente continuare come è stata la squadra e sperare in un miracolo in futuro. Probabilmente non è una buona idea e probabilmente aumenterà solo la tua frustrazione e stress.

Un'opzione migliore è semplicemente fare una pausa e svolgere il proprio lavoro, ma come parte di questa ricerca di opportunità per aggiungere test per supportare quelle aree di codice che sembrano essere le più fragili, quindi rifattorizzarle fino a renderle più stabili. Avrai un momento più facile nel formulare un argomento convincente per migliorare gli investimenti dell'azienda invece di discutere semplicemente per buttare via tutto.

Un'opzione ancora migliore è quella di essere organizzati come una squadra, e per assicurarsi che qualcuno si schieri dalla parte dell'anzianità sufficiente da poter fare un buon caso per consentire alla squadra una maggiore flessibilità per pianificare il tempo per migliorare la base di codice. Non mi interessa quanto sia impegnata un'azienda o quanto rigido sia il programma, ci sono sempre occasionali "pause" nell'attività che possono essere utilizzate per spremere in un miglioramento o due. È ancora meglio, tuttavia, se è possibile apportare miglioramenti durante il completamento di altre attività. Se fossi in me, mi sarei avvicinato a un manager e li avrei introdotti ai concetti in alcuni dei libri canonici che gli sviluppatori di software leggono. Codice pulitoè probabilmente quello di cui la tua squadra ha più bisogno. Pianta alcuni semi su come migliorare il codice e fornisci alcuni esempi di cosa intendi. Un buon manager vedrà il valore di aggiungere miglioramenti incrementali al codice, specialmente se sei in grado di descrivere il concetto di debito tecnico . Aiuta il tuo team leader o manager a creare un buon business case per migliorare il codice e avranno una motivazione migliore per agire su di esso.

Inoltre, non è sufficiente dire "il codice è disordinato". Devi incoraggiare i tuoi colleghi a esercitarsi sempre nella pulizia del codice e a utilizzare una tecnica di codifica pulita per incoraggiare un po 'di riordino mentre procedi. Ho un piccolo poster che stampo e appendo al muro del mio ufficio ogni volta che intraprendo un nuovo lavoro. Dice "Cerca sempre di lasciare il codice un po 'più bello di quello che hai trovato". Accanto ad esso ne aggiungo un altro che dice "I gigli non hanno bisogno di essere dorati". Entrambi servono a ricordarmi che dovrei sempre cercare di migliorare ciò che trovo, ma evitare semplicemente di placcare in oro un problema con un altro. Le riscritture di massa sono spesso il peggior tipo di "doratura", perché spesso vengono eseguite per ragioni sbagliate. Sicuramente una versione del prodotto completamente nuova potrebbe essere giustificabile ad un certo punto,

Ecco la definizione ufficiale dello Scrum Development Team dalla Scrum Guide ufficiale . Metto l'accento sulle parti che ti riguardano direttamente:

Il team di sviluppo è composto da professionisti che svolgono il lavoro di fornitura di un incremento potenzialmente rilasciabile del prodotto "Fatto" alla fine di ogni Sprint. Solo i membri del team di sviluppo creano l'incremento. I team di sviluppo sono strutturati e abilitati dall'organizzazione per organizzare e gestire il proprio lavoro . La sinergia risultante ottimizza l'efficienza e l'efficacia complessive del team di sviluppo. I team di sviluppo hanno le seguenti caratteristiche:

• Si auto-organizzano. Nessuno (nemmeno Scrum Master) dice al team di sviluppo come trasformare il portafoglio ordini in incrementi di funzionalità potenzialmente rilasciabili;

• I team di sviluppo sono interfunzionali, con tutte le competenze in team necessarie per creare un incremento del prodotto;

• Scrum non riconosce titoli per i membri del team di sviluppo diversi dallo sviluppatore, indipendentemente dal lavoro svolto dalla persona; Non ci sono eccezioni a questa regola;

• I singoli membri del Team di sviluppo possono avere competenze specializzate e aree di interesse, ma la responsabilità appartiene al Team di sviluppo nel suo insieme; e,

• I team di sviluppo non contengono sotto-team dedicati a domini particolari come test o analisi di business.

Il team di sviluppo è quindi responsabile del proprio disordine e dovrebbe affrontarlo da solo, senza dover chiedere a nessuno al di fuori del team.

Includi un tempo tecnico di correzione del debito in ciascuna delle tue stime future e assicurati che la qualità del software che fornisci sia di prim'ordine.

Se devi davvero eseguire una riscrittura completa, devi affrontare il problema in Scrum Restrospective. Il Product Owner può eventualmente annullare il progetto e avviarne uno nuovo. Il Product Owner è anche l'unico in grado di annullare uno sprint.

Mentre lo descrivi, devo dire che non vedo nulla che abbia a che fare con SCRUM, o che il tuo team di sviluppo prodotto sia attualmente un problema .

E 'normale

Quello che descrivi è l' entropia normale di una base di codice. Nel tuo caso, la squadra probabilmente è partita più lontano dall'ideale, ma ogni base di codice alla fine diventa una grande palla di fango .

In uno scenario greenfield completamente perfetto , tutto ciò che puoi fare è iniziare più lontano dall'entropia assoluta e avanzare più lentamente.

Sono d'accordo con gli altri, il disordine della base di codice è a causa degli sviluppatori. Sono sicuro che precede l'adozione di SCRUM da molti anni.

Questa non è una decisione tecnica o di sviluppo da riscrivere, è una decisione aziendale.

Non sei al corrente del motivo per cui i proprietari dei prodotti non vogliono una riscrittura. Come sviluppatore pensi che sia necessario, ma c'è davvero qualche caso aziendale per questo?

Se c'è un vero caso aziendale , non solo un gesto della mano; "il codice è un pasticcio legacy che voglio avviare greenfield perché è quello che voglio" , quindi il management dovrebbe sostenere le spese di una riscrittura, considerata la redditività dell'investimento.

Non hai dato un solido business case per una ri-scrittura, solo un rant circa la vostra opinione su come tutti gli altri ha causato questo pasticcio e si non si vuole fare con esso.

Dimostrazione - Il profitto guida le decisioni di business a lanciare software funzionante, non è necessario un certo disturbo ossessivo compulsivo per una base di codice pulita

Se puoi davvero dimostrare la prova , non solo la teoria, ma la prova concreta che spendere Xdollari per una riscrittura greenfield sarà garantito per FARE X * N dollari per il business in Ytempi brevi (dove Nè alto ed Yè breve), potresti ottenere una certa trazione dalla direzione . Questo è un caso altamente improbabile che puoi presentare e dimostrare.

Altrimenti devi solo affrontarlo, questa è la realtà. Contrariamente alle tue affermazioni irremovibili secondo cui non c'è assolutamente modo di andare avanti senza questa grande immacolata riscrittura, scommetterei che tra più di 5 anni la base di codice di cui ti stai lamentando funzionerà e funzionerà da qualche parte fornendo funzionalità e valore a qualcuno molto tempo dopo hai lasciato la compagnia.

Di solito sono scettico quando le persone spingono per "grandi riscritture". Ci sono alcuni casi in cui ha sicuramente senso, ma la maggior parte delle volte, quel codice legacy ha valore (in quanto è già in produzione e utilizzato per gli scopi che hanno ispirato la sua creazione). Eseguire una grande riscrittura è in molti casi l'opposto di agile. Quanto tempo ci vorrebbe per portare la nuova versione dell'applicazione a un punto in cui può sostituire in modo sostenibile l'applicazione esistente.

L'approccio che preferirei è quello che Martin Fowler chiama la vite strangolata . Implementare nuove funzionalità (comprese le modifiche alle funzionalità esistenti) utilizzando il nuovo approccio ma utilizzare l'applicazione esistente come traliccio su cui la nuova funzionalità può crescere. Questo ti dà il meglio di entrambi i mondi, non devi fermare tutto mentre la grande riscrittura viene accennata, ma ottieni il vantaggio di scrivere nuovo codice che sfrutta i framework aggiornati. È sicuramente un approccio più difficile rispetto all'avvio pulito e potrebbe non essere così sexy, ma fornisce più valore all'azienda rispetto al dumping di tutto ciò che è lì perché è obsoleto.

Dove sono e come lavoriamo questo è ciò che faremmo: scrivere una nuova storia e consegnarla al proprietario del prodotto, che deciderà quindi come stabilire le priorità. Un esempio potrebbe essere: "Come sviluppatore del prodotto X, vorrei riscrivere il codice in quest'area in modo che lo sviluppo futuro sia più efficiente" I criteri di accettazione dovrebbero quindi essere sulla falsariga di: Ri-scrivere / refactoring x in modo che sia meglio in questo modo.

Non conosco la situazione in cui ti trovi, ma qui se volessimo ricominciare da capo sarebbe un caso di sederci con il proprietario del prodotto e convincerli perché e poi scrivere una pila di storie per ricreare esistenti funzionalità.

Le altre cose che abbiamo fatto per provare a gestire codici errati e / o legacy sono state quelle di includere le attività di rielaborazione quando si assegnano le storie degli utenti.

Decidere su grandi riscritture è una decisione commerciale. Puoi provare a influenzare le decisioni aziendali vendendo dal tuo punto di vista alle persone responsabili della parte aziendale delle cose.

Tuttavia; il cambiamento nella qualità del codice da una iterazione alla successiva è una decisione dello sviluppatore. Se permetti alla qualità del codice di diminuire, stai aggiungendo un debito tecnico per soddisfare ora le aspettative del proprietario del prodotto. Quello che puoi fare è iniziare a prenderti la responsabilità del codice che scrivi e assicurarti che migliori la base di codice, non viceversa. Ora questo significa che perderai velocità, poiché stai diminuendo continuamente la quantità di debito tecnico e il proprietario del prodotto rimarrà sicuramente deluso. Puoi provare a spiegare che, nel tuo entusiasmo per favore, hai lasciato degradare la qualità del codice e ora stai prendendo provvedimenti per correggere questo problema.

Ora, mi rendo conto che è un passo terrificante da fare e potrebbe essere tentato di ritardarlo di un altro sprint in modo da poter uscire dalla funzione X prima di una scadenza importante. Sfortunatamente, diventerà più difficile man mano che aspetti.

A proposito, questo non è strettamente un problema di Scrum, né sto suggerendo una soluzione specifica per Scrum. Si tratta di sviluppatori che assumono la proprietà del codice.

Gli sviluppatori sono responsabili di avvisare il mondo sullo stato corrente della base di codice. Questo può accadere durante una mischia quotidiana, una retrospettiva o semplicemente in modo informale. Può sembrare ovvio ma se non esprimi chiaramente che casino è e quanto tempo perdi a causa sua, nessuno se ne accorgerà mai. Lo Scrum Master sarà in genere responsabile della trasmissione delle informazioni all'OP e alle persone incaricate del progetto e di persuaderle a fare qualcosa, facilitando quindi l'implementazione di una soluzione da parte del team.

Come nota a margine, una riscrittura del big bang è che l'IMO non è necessariamente la risposta giusta a questo tipo di problema. Comunque stufo che gli sviluppatori siano con l'attuale base di codice, fare piccoli passi misurabili verso un'architettura più pulita è spesso un'idea migliore poiché puoi vedere i progressi, giustificare il tuo lavoro mostrando regolarmente all'OP i risultati e continua il flusso di implementazione di un nuovo utente storie in parallelo invece di perdersi in un rinnovamento senza fine e monopolizzante delle risorse.

Hai chiesto:

Dov'è la parte in Scrum in cui gli sviluppatori possono avere il potere di dire che è abbastanza e chiedere loro di avere il tempo di iniziare la grande riscrittura? Sembriamo in un ciclo infinito di patch del vecchio codice con "Stories". Quindi le cose non sono gestite da persone non tecniche che sembrano non avere alcuna voglia di spingere per una riscrittura perché non capiscono quanto male sia la base di codice.

Come persona che è sia un manager che uno sviluppatore, la risposta più semplice alla tua domanda è che non c'è parte in Scrum, o in qualsiasi altra metodologia o in qualsiasi scenario aziendale, in cui lo sviluppatore ha il potere di dire abbastanza è sufficiente e richiede un riscrivere. Molte persone qui hanno avanzato argomentazioni valide e valide per spiegare perché le riscritture sono spesso cattive idee e per spiegare come il cambiamento può e deve essere prodotto in modo incrementale e agile. E sono d'accordo con tutti loro.

Ma la linea di fondo è ancora più semplice. Non puoi prendere quella decisione, MAI. Sei il dipendente e l'unica decisione che prendi davvero è "continuerò a lavorare per questi asshat o troverò un nuovo lavoro che teme la mia folle abilità". Il tuo nuovo lavoro non ti permetterà nemmeno di prendere quella decisione, ma almeno ti sentirai come se avessi il controllo del tuo destino mentre salti da un lavoro all'altro.

Sento il tuo dolore, ma non sono sicuro di cosa abbia a che fare con Scrum. La decisione di riscrivere il codice non dipende dal processo di sviluppo.

Aspetta cosa?

Stai rattoppando ? Dovresti essere refactoring . Attenersi a valori agili. Usa TDD e pratiche appropriate e la situazione alla fine migliorerà.