È tempo che la nostra organizzazione di sviluppo lasci andare Scrum?

Question

È tempo che la nostra organizzazione di sviluppo lasci andare Scrum?

#1 da (7 voti)
#2 da (4 voti)
#3 da (2 voti)

6

Io faccio parte di un'organizzazione di sviluppo che ha sempre utilizzato i principi Scrum. Abbiamo uno sprint di 3 settimane, al termine del quale produciamo un artefatto software che i nostri clienti installano su premise ea loro discrezione. La maggior parte dei clienti ha scelto di saltare ogni sprint dispari e quindi installa solo ogni 6 settimane.

Ora abbiamo un nuovo cliente di grandi dimensioni, con diverse filiali che, o già, utilizzeranno il nostro software. Ogni filiale ha requisiti leggermente diversi e un programma stretto per la produzione.

Quello che stiamo vedendo da alcuni mesi:

Il nostro team di sviluppo spende meno del 50% delle attività di backlog
Le attività quotidiane sono strongmente influenzate da ticket di supporto ad hoc (che possono riguardare difetti, pulizia del database, formazione degli utenti o analisi di cause semplici)
Ogni settimana costruiamo service pack per le versioni già consegnate. Quindi un difetto è impegnato a padroneggiare, ma poi la ciliegia ha scelto uno o più rami più vecchi.
Il tempo richiesto per i ticket di supporto e i service pack sopra indicati aumenterà nei prossimi 2 anni, dopodiché si spera che diminuirà di nuovo
I nostri clienti tendono a non a darci un feedback rapido, abbiamo un ritardo di ciclo di feedback di qualche mese

- Modifica reg. filiali -

Sviluppiamo su origine / master. Ma diciamo che stiamo attualmente sviluppando la versione 5.0.12 e abbiamo una correzione di bug o funzionalità che il cliente desidera urgentemente su 5.0.10. In questo caso selezioniamo le patch su 5.0.10.1 e 5.0.11.1. Non ci sono rami specifici del cliente, ognuno riceve lo stesso software.

- Fine modifica -

Sono abbastanza sicuro che Scrum non è più adatto per questo tipo di lavoro. Non sono abile con DevOps, ma la mia comprensione è che è strongmente basata su una distribuzione rapida e frequente. Se la mia comprensione è corretta, anche questo non andrebbe bene.

Ci sono delle migliori pratiche su come affrontarlo? Dovremmo:

Dividere il supporto e lo sviluppo e mantenere Scrum per lo sviluppo? (è previsto un team di supporto dedicato)
Passare a Kanban (ma mantenere il supporto e lo sviluppo ad-hoc misti)?

organization scrum support kanban

posta Simon 30.07.2018 - 09:13

fonte

3 risposte

4

Non sono sicuro di aver esattamente messo esattamente il dito su quale sia il problema, soprattutto perché ha assunto il nuovo grande cliente. Stai iniziando a perdere gli obiettivi di sprint / le scadenze? Stai vedendo soffrire la qualità? Stai vedendo il throughput / calo di velocità? Stai perdendo nuovi potenziali clienti rispetto alla concorrenza perché non lavori più tanto nelle tue attività di backlog (che presumo siano correlate alla tua roadmap)? Cosa è cambiato, a parte il fatto che, a causa del nuovo cliente, il tuo mix di lavoro è cambiato in più tipi di manutenzione / bug-fix? E che sei preoccupato che il tuo tempo di consegna per risolvere i problemi potrebbe aumentare nel prossimo futuro?

Avere un gran numero di clienti che ti stanno dando un feedback è una buona cosa! E non essere in grado di - almeno temporaneamente - lavorare sulla roadmap dei prodotti non è una cosa negativa. Forse, questo è il momento di mettere ordine nella tua casa, conoscere e implementare DevOps, ottenere l'automazione del test in atto, riqualificare alcuni membri del tuo team.

Qui, Kanban può aiutarti a farlo. Non devi rinunciare a Scrum, ma usa Kanban in cima a quello (Scrumban come molti chiamano), per aiutarti a migliorare e risolvere i problemi. Kanban può aiutare in diversi modi:

Può aiutare a visualizzare il tuo processo - e lavorare - su una scheda Kanban in modo più dettagliato di quanto sia attualmente in corso, per aiutarti a evidenziare quali passaggi del tuo processo di sviluppo e implementazione potrebbero essere i colli di bottiglia.

Inizierà a fornirti dati sulle tue prestazioni attuali per aiutarti a confrontare parametri importanti come il lead time e il throughput e aiutarti a impostare gli obiettivi di miglioramento. Ulteriori informazioni sulle metriche Kanban qui .

Se sei preoccupato per l'aumento dei tempi di consegna, a causa di un eccessivo lavoro, Kanban consiglia di implementare limiti WIP (work-in-progress) che è possibile implementare in ogni fase del flusso di lavoro, per incoraggiare i membri del team a completare ciò che già sul piatto prima di riprendere il successivo oggetto di lavoro. Limitare il WIP ti aiuterà a migliorare il throughput e ridurre i tempi di ciclo.

Kanban ti dà anche la possibilità di visualizzare e gestire diversi tipi di lavoro - lavoro del cliente, lavoro arretrato o roadmap, debito tecnico, ecc. - utilizzando diversi swimlane su una scheda Kanban. In questo modo, sia il team che i tuoi stakeholder, ottieni un quadro completo di quanto lavoro ci sia in queste diverse categorie, che il team può occupare quando hanno capacità di riserva. La categorizzazione di "classe di servizio" di Kanban in Expedited, Standard, Fixed Date e Intangible aiuta tutti a capire quale potrebbe essere il costo del ritardo associato a ciascuno degli elementi di lavoro che il team dovrebbe fare, e forse scartare roba che ha basso o nessun costo di ritardo.

Datalacomplessitàdellasituazioneattuale,èpossibileimplementareilimitiWIPsiaalivellodicolonnacheperspecifichecorsiedinuoto.

Prima di fare tutto ciò, è necessario, ovviamente, una discussione, magari più discussioni, con i team di sviluppo e le parti interessate per capire quali sono e dove sono i problemi e cosa è necessario fare per risolverli. Questi dovrebbero aiutarti a elaborare politiche esplicite - altro che il Metodo Kanban consiglia - per gestire le attività del backlog e il feedback dei clienti, magari cambiando gli sprint ogni 2 settimane e facendo rilasciare un cliente solo ogni 3 sprint, aumentando la capacità assegnazione a ciascun tipo di lavoro, dando uno sguardo regolare al tuo arretrato generale e dando la priorità ai 5 o 10 elementi principali da raccogliere successivamente, ecc.

Non c'è dubbio che Kanban possa aiutarti ad analizzare e migliorare le tue attuali pratiche di gestione degli sviluppatori. Non è necessario necessariamente rinunciare a Scrum per questo. Se vuoi saperne di più su Scrumban, puoi cercare qui .

HTH: tutto il meglio!

risposta data 30.07.2018 - 18:31

fonte

2

Ci sono alcune cose nella tua domanda che mi fanno pensare che questo sia più di un problema di processo. Ci sono già alcune ottime risposte sulla gestione degli oggetti di lavoro.

Sono d'accordo sul fatto che misurare i tempi di Lead / Cycle è il modo migliore per analizzare l'efficienza del supporto, ma assicurati di misurare questi tempi da quando il cliente ha aperto il ticket fino a quando non viene chiuso nell'ambiente del cliente. Le metriche sullo sviluppo della vanità non significano nulla, tutto ciò che faranno è fare in modo che l'aspetto dello sviluppo diventi buono a spese del cliente.

Sono d'accordo che gli sprint sono il modo migliore per risolvere il lavoro e permetterti di orientarti. Non sono completamente venduto durante il suggerimento di sprint di una settimana, che dipende da quanto sforzo è richiesto per distribuire alla fine (potresti voler controllare l'automatizzazione delle distribuzioni attraverso qualcosa come Octopus).

Tuttavia, il punto principale che volevo sollevare e che nessun altro ha il tuo commento su più rami.

Da ciò che descrivi hai più rami della tua base di codice che eventuali correzioni devono essere unite tra i due. Stai andando nella direzione sbagliata, cosa succede se hai bisogno di un nuovo sapore del tuo software? Cosa succede se assumi un nuovo cliente? Il tuo controllo del codice sorgente crescerà e crescerà e lo renderà sempre meno gestibile.

Devi muoverti verso lo sviluppo basato su tronco (o almeno rami di funzionalità di breve durata). È possibile utilizzare i commutatori / ruoli / configurazione delle funzioni per personalizzare il software per ciascun cliente / progetto.

Questo farà:

Riduce il bug fixing / overhead dell'implementazione delle feature
Consentono di consolidare i test su un singolo ramo (rendendo il test più efficiente)
Consentono di costruire una pipeline CI adeguata dove OGNI build è stata testata dalla regressione
Consentono di sviluppare un processo di distribuzione appropriato senza stranezze dei singoli rami

Più è facile spingere il codice, più è facile sviluppare funzionalità. Ma anche più facile è la distribuzione delle correzioni. Ciò significa che il supporto che il tuo team sta attualmente affrontando diventa più facile. Non sai cosa sta succedendo, distribuisci più logging. Hai trovato un bug che deve essere risolto oggi, non applicarlo alla patch DLL, basta distribuire una nuova versione.

Un ultimo punto. Sei preoccupato per la quantità di tempo che trascorri nel lavoro di supporto, dovresti essere, è molto e ogni interruzione ti costa tempo. Definisci i criteri per il lavoro da portare nello sprint e, se lo è, spinga fuori un oggetto di lavoro equivalente. Il mio suggerimento sarebbe quello di avere i tuoi "criteri P1" uguali ai tuoi criteri di callout di 24 ore. Dopotutto, se non è abbastanza importante che un analista esca dal letto alle 2 del mattino, probabilmente non è abbastanza importante da sacrificare il lavoro più importante sul backlog.

Durante la misurazione, registra gli SP del lavoro che hai pianificato ed è stato completato. Lo spazio mancante rappresenta il lavoro di supporto interrotto. La tua preoccupazione dovrebbe essere "quanto del lavoro pianificato abbiamo consegnato?", I problemi di supporto che non hai lasciato cadere tutto da risolvere possono essere pianificati, ma fallo contro gli elementi del tuo backlog.

TLDR

Misura il tempo che intercorre tra un cliente che genera un problema e il quale lo chiude
Spostati verso un modello di sviluppo basato sul tronco
Considera l'automazione delle distribuzioni
Accetta i criteri P1 con il business, ecco cosa interrompe lo sprint

risposta data 31.07.2018 - 10:58

fonte

Leggi altre domande sui tag organization scrum support kanban

Ottenere i diplomati fino alla velocità? Esiste un certo numero di righe di codice da seguire / mantenere?

score 7 · Accepted Answer

No. Scrum è progettato per combattere esattamente i problemi che stai vivendo.

Potresti passare a un approccio reattivo che corregge i bug non appena vengono segnalati il più rapidamente possibile, ma a costo di date di completamento prevedibili e spesso della stabilità del tuo software.

Direi che dovresti respingere, accertarti che tutte le richieste vadano nel backlog e siano prioritarie. Aumentare la quantità di tempo trascorso test, assicurarsi che ciò che si rilascia è esattamente quello che è stato chiesto e non ha bug. È meglio fare una singola versione mensile con zero difetti, rispetto a 4 versioni settimanali buggy.

Tuttavia, direi anche che 3 settimane sono troppo lunghe per uno sprint. Passa a scatti di 1 settimana.

Stop Cherry Picking! Unisci correzioni di bug alle filiali. Cerca di spostarti verso un singolo codice base, non lontano da esso.

Assumi più persone. qualunque metodo tu scelga ci sono solo tante ore al giorno. Se hai più lavoro, hai bisogno di più persone.

Re: lunghezza sprint

Con qualsiasi sistema di sprint il tempo di giro come minimo tre sprint, ovvero il cliente vede il risultato dello sprint 1, ha una giocata, suggerisce cambiamenti che vanno sul backlog durante lo sprint 2, che possono forse essere completati nello sprint 3 .

In questo caso specifico i clienti non installano sempre ogni sprint e non tornano prontamente in modo che guardino all'installazione dopo 6 settimane, segnalando problemi nelle settimane 9-11 per l'implementazione entro la settimana 15 e poi l'installazione di la correzione alla settimana 21. È quasi un ciclo di 6 mesi.

Se hai uno sprint di una settimana, un cliente può installarsi nella settimana 6, ricevere le richieste per la settimana 9-11 e installare le correzioni nel ciclo successivo di 6 settimane della settimana 12. Un ciclo molto più veloce.

L'esperienza di sprint più breve di una settimana non è pratica nella mia esperienza. Solo in termini di cadenza degli affari e di settimana lavorativa. 'fatto entro la prossima settimana' è accettabile, 'fatto in due settimane, perché stiamo lavorando su altre tue cose' è comprensibile ritardo. 'fatto in 4 settimane, perché SCRUM' è inaccettabile.