Il codice di refactoring è casuale consentito nella mischia

Non intendo davvero attaccare altre risposte, ma nessun altro sta scrivendo test automatici qui? Qui è una lettura divertente di Martin Fowler per chiunque stia facendo Scrum senza le corrette pratiche di ingegneria del software. Robert C. Martin dice anche molto su questo qui .

Quindi, alla mia risposta ... In breve, va così:

Sì, il codice di refactoring "randomly" è consentito in Scrum , a condizione che il team decida che è necessario farlo. (Dopotutto, è auto-organizzante)

E ora per la risposta lunga:

È evidente che lasciare sempre più debito tecnico dopo ogni Sprint è una ricetta per il disastro. Presto, tutti rallenteranno mentre il codice diventa più disordinato; ogni cambiamento sarà più difficile da realizzare perché il codice è così aggrovigliato e disordinato da richiedere più tempo per trovare i punti da cambiare piuttosto che per apportare il cambiamento effettivo. Diventa ancora peggio se devi apportare un cambiamento in un modulo grande e disordinato di cui non sai nulla, diventa impossibile guadagnare / mantenere la produttività quando aggiungi / cambia le persone nel progetto, e così via.

Se una squadra vuole mantenere la sua velocità costante, deve essere in grado di mantenere pulito il codice base al fine di incrementare continuamente il software. Il refactoring è una pratica obbligatoria se vuoi mantenere la tua velocità durante tutto il ciclo di vita del progetto e se vuoi ridurre il rischio di aggiungere / cambiare le persone nel progetto e se vuoi essere in grado di apportare modifiche nei moduli di cui non si sa nulla e così via.

Tuttavia, il refactoring è un'attività molto pericolosa. Ripeto: è un'attività molto pericolosa . Cioè, a meno che non si disponga di una copertura sufficiente per poter modificare in modo sicuro e sicuro il codice base. Se riesci a premere un pulsante per controllare se non si è rotto nulla, il refactoring diventa un'attività molto sicura; così sicuro, infatti, che fa parte del ciclo di TDD , che è la pratica che ti permette di creare una tale suite di test in primo luogo.

Tuttavia, poiché i team di Scrum si stanno auto-organizzando, alla fine la tua squadra deve decidere qual è la cosa giusta da fare. Spero di avervi dato degli argomenti nel caso in cui dovete convincere qualcuno. (Prestare particolare attenzione ai collegamenti nel primo paragrafo e ogni altro articolo a cui si riferiscono)

Scrum in realtà non dice nulla sul refactoring.

Quello che Scrum dice è che se non hai nessuna attività nello sprint su cui lavorare, dovresti supportare il resto della tua squadra per raggiungere l'obiettivo dello sprint. Anche se questo significa andare a prendere un caffè per loro.
Se il tuo team è d'accordo sul fatto che il refactoring del codice è il modo migliore per supportarlo (e questo include avere l'infrastruttura in atto per garantire che il refactoring non introduca troppi nuovi bug), quindi con tutti i mezzi.

Direi di no, non lo è. Questo è indipendentemente dal tipo di lavoro (refactoring, ecc.)

Al minimo, le attività dovrebbero essere create e inserite nello sprint corrente. Lo scopo del monitoraggio del tempo è quello di catturare la velocità per poter essere in grado di tracciare gli sprint futuri. Se stai lavorando su cose senza averle tracciate, inciderai sulla velocità e non migliorerà nel tempo come previsto con il tracciamento corretto (probabilmente non avrai abbastanza lavoro perché la velocità proiettata è inferiore alla tua velocità reale ).

Per quanto riguarda il refactoring di per sé, posso fare una tirata a riguardo, ma non lo farò perché non penso che sia la domanda principale a cui stai cercando di avere una risposta.

Sto andando a dire di no pure. Il ri-factoring porta spesso a bug non intenzionali se non viene gestito nel modo giusto.

Come GM, periodicamente metterei tutti su un altro progetto e passare una settimana a fare revisioni del codice / ricodificare / rinominare e far rispettare le convenzioni su un progetto. Questi sprint di ri-factoring sarebbero quasi sempre di natura estetica. Qualsiasi rielaborazione funzionale sarà pianificata in anticipo e coinvolgerà lo sviluppatore originale.

Il risanamento funzionale dovrebbe sempre essere pianificato e coordinato come parte del processo di scrum in modo da poter tenere traccia del tempo e tutti i membri del team necessari sono disponibili per convalidare il processo. Uno sviluppatore non dovrebbe smettere di cambiare il codice scritto da un altro fuori pista perché molto probabilmente rovinerà lo sprint attuale per tutti. Soprattutto quando si tratta di code merge time.

Se si tratta di un progetto di cui sei l'unico manutentore e che è il tuo tempo libero, allora può essere diverso ipotizzando che tu prenda provvedimenti per assicurarti di non causare inutili ritardi nello sprint attuale.

In caso di dubbi, chiedi al tuo manager.

EDIT: Voglio anche menzionare che un dato pezzo di codice che non ti piace potrebbe avere un certo target di prestazioni ad esso associato. Potrebbe non piacerti, ma potrebbe essere più veloce di qualsiasi cosa tu possa costruire per adattarsi al modo in cui vuoi usarlo. Un altro motivo per cui il ri-factoring funzionale dovrebbe sempre essere un processo gestito.

Scrum non dice nulla sul refactoring (vedi una conferenza di Robert C. Martin, "La terra che scrum ha dimenticato").

In Scrum le attività sono funzionalità di targeting del software specificate dal cliente, non i debiti tecnici da rimborsare tramite refactoring. Questi sono livelli di astrazione totalmente diversi. Il cliente per lo più non è in grado di valutare la necessità.

Scrum è la gestione statistica dei progetti. Per ottenere misure significative di "quanto tempo ci vuole" devi conoscere la performance (output per sprint). Confrontate la stima e la durata reale di una funzionalità per almeno più di 1 sprint per entrare nella statistica. Raccomando 5 sprint. Ma dipende dalla tua squadra.

La cosa principale è mantenere le misure significative e comparabili per rendere possibile qualsiasi previsione. Ciò non avverrà se le prestazioni diminuiscono a causa dei debiti tecnici.

Se ora pensi ancora alle attività di refactoring hai due problemi: 1. Un cliente, che non capisce, perché deve accettare un'attività che non produrrà una nuova funzionalità 2. Disturbi totalmente le tue statistiche e quindi la tua capacità di previsione quando cambi improvvisamente una variabile diversa che non è stata considerata negli sprint precedenti

In entrambi i casi si compromette l'idea di scrum in quanto si vuole parlare di funzionalità con il cliente e di fare previsioni affidabili per "Quanto tempo ci vuole?" in un modo statistico. Per sicurezza, devi mantenere il tuo codice base in una qualità costante (forse alta).

Il refactoring è per lo più un'attività sotterranea. I "grandi" refactoring significano che i "piccoli" refactoring non sono stati elaborati in passato.

Un'ultima nota: se fai refactoring assicurati di avere il componente sotto test che stai rifacendo. Ohh, non hai test? Fai un compito per scrivere test. Il tuo cliente sarà felice di sapere che il software che sta attualmente utilizzando non ha una copertura di test sufficiente ...

Tieni le cose tecniche lontane dal cliente e fai il tuo lavoro come sviluppatore professionista.

Ecco un approccio: fai entrambe le cose!

Il refactoring è spesso soggetto a errori o richiede più tempo che inizialmente stimato come @misterbiscuit.

Quindi considera un tentativo di fare una bozza o un picco. Non sei obbligato a chiedere l'approvazione o fare pubblicità se in questa fase.

Quindi, cerca di includerlo attraverso uno dei due canali:

• un biglietto esistente che tocchi lo stesso codice / funzionalità in cui puoi ragionevolmente racchiuderlo. Ragionevolmente come concordato con altri membri del team.
• intero biglietto per la revisione al prossimo grooming del biglietto (o riunione settimanale, ecc. se cascata). In quel momento puoi dimostrarlo.

Una volta ottenuto il buy-in effettivo, puoi cercare di applicare o ripetere il tuo picco e far sì che il codice venga fuso nel ramo principale (principale, ecc.).

Questo avrà diversi vantaggi:

• Tutti i codici di codice attraverso lo stesso processo, vengono testati, QA, nella pipeline di rilascio, ecc.
• Ottieni un buy-in formale, anche da parte del product manager, che il refactoring fa parte del mestiere e non qualcosa che deve essere "nascosto" durante una vacanza. Chiediti perché non stai "intromettendoti" in una funzione reale per la prospettiva.
• Puoi chiedere l'abbinamento, la revisione del codice, qa, devops e tutto l'altro supporto che potrebbe essere necessario per la modifica del codice di factoring. Sarà tutto ufficiale, secondo la Politica e la Procedura e in alto.
• Se sei una società quotata in borsa con conformità SOX, probabilmente vuoi / devi fare questo tipo di processo formale (ad esempio, documentalo e poi seguilo).
• Ottieni una reputazione migliore sia con il product manager (la modifica è stata eseguita rapidamente) che con il team di sviluppo (il codebase è stato migliorato).
• L'organizzazione sta cercando di preoccuparsi della qualità del codice, utile per la produttività, il morale, la fidelizzazione dei dipendenti e molti altri motivi.
• L'effetto sulla velocità del progetto può essere tracciato più facilmente quando tutto il lavoro è incluso. Può essere ok non nominare alcun punto in quanto la presenza stessa può essere utilizzata per influenzare la velocità.
• Gli sviluppatori probabilmente vedranno strumenti che incoraggiano revisioni più semplici del codice come Fisheye, Github, ecc.
• Gli sviluppatori hanno maggiori probabilità di vedere alcuni standard di base (a volte documentati, a volte no) che rendono più semplice la condivisione del codice e quindi il refactoring. A volte una parte importante del refactoring è scegliere uno stile e poi applicarlo a grandi linee (sostituendo una combinazione di approcci con uno).

Un commento finale: evitare che il product manager senta la parola "casuale". Potrebbero rispondere in modo più favorevole con l'aggiornamento del codice "mirato, strategico, che migliora le prestazioni". O il service pack dell'applicazione. O qualunque altra lingua ti dia copertura.

Il refactoring casuale non ha senso. Ciò che ha senso è il refactoring di un codice che introdurrà la maggior parte dei benefici. Ciò significa:

• risoluzione di un problema di progettazione o architettura
• miglioramento dell'implementazione

Is it OK in Scrum if I start randomly refactoring code that I have and have not written that always bother me but don't have time other days to fix it because of other days assignments?

Da questa risposta :

Keeping code maintainable needs to be an item on your burn-down list (if you use a Scrum). It is just as important as new development. While it may not seem like something that is "visible to the user", ignoring it increases your technical debt. Down the road when the technical debt piles up enough that your code's lack of maintainability slows down development, the delays in new feature development will be visible to customers.

Nel mio precedente lavoro, abbiamo avuto una sorta di mischia, con sprint più grandi (2-3 mesi). Poiché abbiamo avuto alcuni ritardi tra gli sprint (1 mese), abbiamo utilizzato questo tempo per analizzare il software e rifattorizzare il codice.