Come trattare le attività che probabilmente non sono storie degli utenti, ma devono ancora essere eseguite?

4

Abbiamo un numero di attività che devono essere completate, ma probabilmente non sono storie di utenti reali, o se lo sono, sono storie di utenti molto incentrate sugli sviluppatori che non saranno mai visibili agli utenti finali. Il problema è che non vengono valutati come parte di uno sprint e vengono eseguiti pochissimo. Alla fine, diventa abbastanza di un problema che qualcuno si prende da uno sprint per occuparsi di loro, ma questo influenza i progressi sul lavoro "ufficiale" di sprint, cosa che rende alcune persone un po 'infelici.

Ho insistito perché facessi questi compiti in storie di utenti ufficiali, ma a nessun altro sembra piacere questo. In quale altro modo potrei richiedere il riconoscimento ufficiale per questi compiti, quindi posso dedicare loro giorni interi senza sentire che sto influenzando il resto dello sprint?

Alcuni esempi di attività, solo per darti un'idea:

  • Scrivi plug-in maven personalizzati e di piccole dimensioni per semplificare configurazioni di build specifiche (e ampiamente utilizzate all'interno dell'organizzazione).
  • Rif. vecchi progetti da costruire con Maven e set di strumenti più recenti.
  • Refactor ridondante (su più progetti) codice in librerie indipendenti - potrebbe potenzialmente essere utilizzato da molti progetti.
posta FrustratedWithFormsDesigner 18.02.2014 - 18:16
fonte

3 risposte

5

I've been pushing for making these tasks into official user stories, but no one else seems to like this.

Una domanda importante da porre / rispondere è: queste attività devono essere storie degli utenti o devono semplicemente essere nel backlog , data la stessa considerazione delle storie degli utenti? Non sono un fan della scrittura di un compito come una storia solo per coerenza, in quanto (imo) lo scopo di una user story è focalizzato sulla fornitura di valore al cliente sviluppando l'azione di un cliente. Alla fine, il cliente può testare la storia dell'utente.

Al contrario, un'attività dello sviluppatore spesso non ha bisogno di un'azione dell'utente da testare (es. refactoring di file di grandi dimensioni in più file di classi più piccole), e non deve necessariamente trovarsi in una user story per essere capita da sviluppatori. IMO, mantenendo indipendenti le storie degli utenti e le attività dello sviluppatore ti consente di monitorare quanto tempo spendi per fornire diretto valore del cliente .

Ma probabilmente è questo il punto, e chiederei se il vero problema è ottenere la gestione da parte delle attività di manutenzione / miglioramento del progetto ? In tal caso, potrebbe essere necessario modificare leggermente la messa a fuoco.

How else could I request official recognition for these tasks, so I can allocate full days on them without feeling like I'm affecting the rest of the sprint?

La chiave qui è giustificare il loro bisogno . Avere un processo di compilazione centralizzato e accettato è una pratica Agile molto standard con benefici molto evidenti. Migliorerà la produttività e l'impegno degli sviluppatori e ridurrà i costi di integrazione.

Al contrario,

Refactor redundant (across multiple projects) code into independent libraries - could potentially be used by many projects.

richiede qualche giustificazione sul suo valore (buzzword c'era potenzialmente ). Se c'è un uso reale - ad es. c'è una duplicazione tra i progetti: mostrala. Mostra i commit che sono stati fatti. Mostra le storie a cui erano legati, e come dover scrivere una routine per moltiplicare, mantenerla moltiplicata, ecc. - porta direttamente a un aumento del tempo di produzione .

Il refactoring è una parte importante del codice di gestione professionale. Se non riesco a regolarmente spendere (piccole quantità di) refactoring del tempo, allora il codice è in una spirale discendente, e sto cercando un altro lavoro. In parole semplici, quando non puoi aspettarti un codice refactoring, sei costretto a dedicare troppo tempo con considerazioni sull'architettura up-front (interrompi regola YAGNI ). Se mi fido possiamo rivedere i moduli in futuro per migliorarli, posso concentrarmi sulla consegna della soluzione di lavoro più semplice possibile e ottenere un feedback immediato da parte degli utenti.

Le "storie" dello sviluppatore sono importanti e meritano un posto nel flusso di lavoro. Il fatto di formularli o meno come una User story è soggettivo, ma non lasciare che sia l'obiettivo della discussione . Inseriscili nel flusso di lavoro, quindi preoccupati di come etichettarli.

    
risposta data 18.02.2014 - 19:15
fonte
2

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.

    
risposta data 19.02.2014 - 00:49
fonte
1

Il modo in cui ho risolto questo problema in passato è quello di divertirmi. Fagli storie per gli utenti. Chi può dire che utente è effettivamente definito come in quel senso?

As an old-timer project, I want to build with Maven, so that I can be built in a single step and better manage my dependencies.

Penso che questo sia il modo migliore per risolverli. Un enorme vantaggio è che in questo modo ti viene ancora chiesto, perché?

Perché hai bisogno di rifattorizzare quei vecchi progetti?

Il perché è importante per gli OP / PM per giustificare effettivamente queste attività e, a mio parere, offre al tuo team una preziosa panoramica di queste attività.

YMMV, ma mi piace questo approccio e ha funzionato con i miei team precedenti.

    
risposta data 18.02.2014 - 18:37
fonte

Leggi altre domande sui tag