Grazie per una domanda informativa - per uno come me che non ha mai usato formalmente Scrum come metodo per lo sviluppo di software. Faccio parte di un'azienda di prodotti e passiamo dalla cascata tradizionale a quella itterativa a ciò che può essere meglio descritto come Kanban - altho 'Kanban di per sé non è un metodo di sviluppo software.
Non sto cercando di "vendere" Kanban a te - essendo in giro da oltre 25 anni nel settore del software, conosco bene le sfide legate al cambiamento dei processi in un'organizzazione di software! Ma ho pensato di condividere le idee di Kanban che potresti avere la flessibilità di provare nella tua squadra.
I punti chiave di Kanban sono quelli di visualizzare il tuo processo esistente , limitare i work-in-progress ( limiti WIP ), imposta Pull e migliora gradualmente ( cambiamento evolutivo piuttosto che rivoluzionario). Dato che stai già praticando alcuni di questi, il resto potrebbe essere facile da adottare.
Abbiamo - e abbiamo avuto - una situazione molto simile alla tua - molte delle regolari attività di sviluppo di feature e di correzione dei difetti come parte dei normali miglioramenti del prodotto, che dovevano uscire in una release; intervallati dal refactoring del codice e da altri compiti legati all'Ingegneria - e la nostra sfida è stata visualizzarla per tutti i membri dell'azienda, così il CEO e il Sales and Marketing sapevano esattamente quanto lavoro stava gestendo l'Engineering e permettevano loro di valutare le priorità di tutto il lavoro .
Quando passavamo da un processo iterativo a Kanban, entro un paio di iterazioni, la nostra scheda appariva come mostrato nelle immagini mostrate sotto -
Il nostro processo Dev è stato mappato nella corsia Dev della scheda Kanban -
LanostraschedaKanbancomplessivasembravacosì,conl'ultimacorsiariservataailavoridiingegneriaealtrilavoridi"igiene" -
Comepuoivedere,nonabbiamosolounacorsiaDeveunacorsiaGlobal/Engineering,maanchealcuneinterruzionidelclienteeunacorsiadipianificazione.Ognicorsiaspecificavaanchelaquantitàtotaledilavorochepotevaesistereinciascunacorsia:illimiteWIPperquellacorsia.Glisviluppatoriavrebberodovutooccupare(tirare)illavoronellacorsiaoperativaglobaleognivoltacheavevanounacapacitàinutilizzata.Unavoltachel'hannotirato,ingenereloavrebberoterminatoprimadiaffrontareunanuovauserstory.
Questocihapermessodimappareevisualizzarelanostrasituazioneesattamentecom'era-secipiacesseono,uninterruptclienteadaltaprioritàharitardatoospostatoillavorosualtrielementi.Invecediprovareamapparlicomestoriedegliutenti,abbiamomappatoognitipodilavorocosìcom'è-eabbiamospintoalavoraresuStagingandProductionnonappenaèpronto.Ilnormaleprocessocheabbiamoutilizzatoèstatoquellodiincluderealcunedellestorie/attivitàdiingegneriainqualsiasiterzaversioneogiùdilì.
Labellezzadiquestosistemaèchecihaaiutatoastudiareilvolumedilavoroinognicategoria(Kanbanlochiama"classe di servizio") e riorganizzare il nostro consiglio, il nostro processo e il team mentre procedevamo. Nell'arco di un anno dall'adozione di Kanban, abbiamo realizzato un rilascio di produzione quasi ogni mese, cosa che ha reso felici le nostre vendite e il nostro CEO e, naturalmente, i nostri clienti! E, naturalmente, facendo questo significava che avremmo automaticamente ricevuto una "sanzione ufficiale" da parte del CEO e della gestione dei prodotti - il riconoscimento che questo lavoro era importante (ma non necessariamente urgente) - e doveva essere fatto ogni volta che c'era una capacità disponibile per farlo. Certo, ci sono stati momenti in cui, con l'aiuto di Prod Mgt, alcuni di questi lavori sono stati specificatamente assegnati per priorità a causa della sua urgenza.
Quindi, se possibile nel tuo ambiente, ti suggerirei di avere una discussione sincera all'interno del team - e con tutte le parti interessate che devono essere coinvolte - e trovare un metodo che ti aiuti a mappare il tuo lavoro e processo attuale - e ti aiuta ad arrivare ad un accordo per dare la priorità ad alcuni di questi lavori su base regolare e li impacchetta nel primo possibile sprint / rilascio che puoi. Durante il processo, potresti trovarti a fare cose che non sono necessariamente "fedeli a Scrum", ma potrebbero aiutarti ad evolvere verso un processo migliore che permetta al team di lavorare molto più facilmente di quanto potrebbe fare oggi.
Chiedo scusa per una lunga risposta, ma spero che aiuti. E ancora, questa potrebbe non essere una risposta diretta alla tua domanda - ma spero che alcuni di questi concetti possano essere utili per la tua situazione.