Come gestisci i costi di un cambiamento troppo rapido?

Questo è il backlog. Nuove richieste vengono inserite nel backlog e le priorità possono cambiare solo sui limiti di iterazione. Una media di un ritardo di una settimana (metà di uno sprint di due settimane) è abbastanza agile da gestire tutte le emergenze più gravi.

Ecco come ho affrontato un problema simile. Nei giorni in cui eravamo agili prima di Agile.

Per ogni richiesta di modifica, il cliente imposta la priorità. Lo sviluppatore può solo e deve interrompere il lavoro su un'attività per lavorare su un'attività con priorità più alta. I compiti con priorità uguale sono gli orari in ordine di arrivo. (La priorità del compito non può essere modificata una volta iniziato il lavoro.)

Farà male quando dirai al cliente che non puoi lavorare sulla sua attività perché stai lavorando su un'attività non importante X che ha la stessa priorità della sua ultima richiesta. Poi gli dici che a quel livello di priorità ci sono 50 compiti banali e poco importanti prima della sua ultima richiesta. Ora la vera presa - tutti questi compiti sono al livello di priorità 1 (il più alto), impostati da ... LUI ... Quindi lui non può buttarti fuori dal compito che stai facendo. Ora, quando hai finito di spostare il riquadro della finestra di 3 pixel a sinistra per fare spazio alla parola più lunga nella traduzione islandese sull'opzione di configurazione usata raramente ...

Ho anche chiuso la porta dell'ufficio SD, l'ho bloccato e ho tolto i telefoni. Le e-mail sono state ignorate fino alle 10:00, alle 12:00 e alle 14:00. Nonostante ciò che la gente pensava e sentiva, il mondo girava ancora intorno al sole, abbiamo fatto il nostro lavoro e i "Clienti" hanno ricevuto il software in modo più rapido e migliore di qualsiasi altra volta in passato.

Ci sono volute alcune settimane perché le priorità si stabilizzassero in qualcosa di più realistico, siamo stati in grado di sbloccare la porta, ecc ... Ma il sistema è rimasto per un periodo piuttosto lungo. Potrebbe non essere necessario essere così estremi (lo abbiamo fatto) e sarà necessario il supporto del Senior management. Ma funzionerà ....

SOP. Procedura operativa standard (o almeno un protocollo libero che viene firmato dal team di gestione). Il tuo dipartimento deve svilupparne uno o lavorare con il tuo team di gestione per svilupparne uno. Le persone con cui devi parlare sono al di sopra del proprietario del prodotto / account manager.

Alcuni esempi di ciò che il tuo SOP dovrebbe definire.

• Quali procedure devono essere seguite quando un cliente o un'entità interna richiede una modifica
• Quali sono le implicazioni e / o l'impatto sul controllo qualità o sulla verifica di questo prodotto?
• Qual è il metodo per determinare ragionevolmente un intervallo di tempo per la consegna? Questa iterazione? La prossima versione?

Senza queste procedure, tutti correranno verso di te come se fossero inseguiti dagli zombi e si aspettino tutto ADESSO ORA ORA. Persone come queste non rispetteranno il tuo educato "no" o "per favore aspetta". Con una solida politica in atto, questi mutanti assetati di codice capiranno di essere nel torto quando chiederanno le cose su basi così sciolte.

Il risultato finale è infelice, e questo non è nell'interesse della tua azienda.

Da una nota a margine, potresti aver ereditato un pasticcio di qualcuno causato da una palese mancanza di rispetto per la sua posizione e il suo dovere. Le persone in quella situazione tendono a trovare difficoltà nel produrre prodotti di qualità. C'è da meravigliarsi? Ingegneria del software 101.

È molto difficile lavorare in queste condizioni di "pronto, fuoco, mira". Mi sembra che tu stia ricevendo le richieste da una persona molto insicura, la cui opinione cambia ogni volta che una persona più in alto suggerisce un'idea concettuale.

In questo tipo di situazioni, ho trovato utile attendere almeno un'ora prima di rispondere alle e-mail. (Ignorerei i testi, a meno che l'invio di messaggi di testo abbia ampiamente sostituito l'e-mail dalla tua organizzazione nel suo insieme.) Leggi, forse, ma non rispondere. In questo modo puoi dedicare il tuo tempo concentrandoti sul lavoro effettivo che devi svolgere, non sulla discussione di urgenze casuali che potrebbero diventare irrilevanti domani, o anche due o tre email in un secondo momento. Nel mio ultimo lavoro, se qualcosa fosse DAVVERO urgente, qualcuno sarebbe venuto a parlarmi di persona, supponendo che non avessi ancora visto le e-mail (se lavori in remoto, una telefonata con una conversazione a doppio senso potrebbe essere la equivalente).

Quando hai una conversazione faccia a faccia o telefonica, è utile ripetere ciò che la persona sta chiedendo con parole tue e poi porre le tue domande sui nuovi requisiti e priorità. "Se ho capito bene, stai dicendo che dovremmo smettere di lavorare su Current Top X e ora concentrarti sulla priorità del minuto Y. Questo è un grande cambiamento. Puoi spiegare il cambiamento nel business? Potrei aver bisogno di fare più background lavoro piuttosto che cambiare l'interfaccia utente. Ci saranno cambiamenti in altri processi aziendali, come la fatturazione o l'inventario (ad esempio)? Si prevede che questi nuovi elementi di dati vengano visualizzati su tutti i report mensili? " È anche utile dire qualcosa all'effetto di "Capisci che se procediamo con questo nuovo sforzo, ritarderà il rilascio della priorità Top corrente X di almeno una (settimana, mese, compila qui la stima del tempo WAG), giusto? "

Se si tratta di un'emergenza reale, il richiedente dovrebbe essere in grado di rispondere a questo tipo di domande o immediatamente indirizzarti a qualcuno che potrebbe farlo. Se non è una vera emergenza, questo tipo di conversazione costringerà il richiedente a rallentare e determinare quanto sia importante il cambiamento, dato che hanno bisogno di ottenere maggiori informazioni. Spesso vedono che ciò che è già nella pipe è più importante, o almeno non vale la pena fermarsi, e la nuova richiesta può andare sulla lista.

Se si ritiene che le modifiche siano necessarie, ho trovato utile annotare ciò che è stato richiesto e la comprensione delle modifiche in una e-mail, e inviarlo al richiedente originale, chiedendo se sono d'accordo sulla portata di il cambiamento, ancora una volta, come chiarimento. In questo modo hai scritto la documentazione di ciò che è necessario fare e perché è stato richiesto, nel caso in cui si verificasse un problema in base al quale non stai più lavorando su Current Top Priority X, o hai bisogno di spiegare perché le scadenze originali non stanno andando da soddisfare.

Questo dovrebbe migliorare il rapporto con il richiedente, dal momento che stai dimostrando le tue conoscenze e assicurandoti che stai lavorando su ciò che vogliono, ma sei onesto riguardo a ciò che serve per apportare modifiche. Chiedendo la richiesta in dettaglio, vedono che pensi in anticipo e considerano le cose che potrebbero non avere in origine.

Sembra che nessuno lo abbia ancora menzionato, Sprint e le sue user story ideally should be locked till the next sprint (lo sprint tipico richiede 2-4 settimane). Bloccando, intendo che non è necessario aggiungere ulteriori attività nello Sprint già avviato.

Se la storia dell'utente è abbastanza grande da non adattarsi allo sprint, frenarla in compiti più piccoli e raggiungibili durante lo sprint. Inoltre, come menzionato, le attività prioritarie devono essere conservate in backlog e durante la successiva pianificazione a sprint con priorità alta una volta ottenuto il flag in alto:)

Modifica: solo le modifiche minori possono essere introdotte durante la primavera. se portano lo stato di emergenza. Tuttavia, se durante lo sprint ci sono sempre delle emergenze, allora qualcosa deve essere modificato nella pianificazione di Sprint stessa.

Scrum ha il ruolo di Scrum Master, che sarebbe la persona che dovrebbe affrontare i problemi che hai citato.

Se c'è qualcuno come il caposquadra, il project manager, il mischia, ecc. chi è il responsabile, vorrei parlare con quella persona.

I've tried explaining that there's only so much time and that we should focus on the most important things first, but something seems to get lost in translation because the same thing happens a day or two later.

Penso che dovrai continuare a spiegarlo ancora e ancora e ancora. Sembra che tu possa dover accettare che alcune persone con cui lavori hanno abitudini inutili. Se sei fortunato, alla fine vedrai un cambiamento.

Agile Manifesto afferma che uno dei principi fondamentali è:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Tuttavia, non credo che intendessero il cambiamento su base giornaliera. Potrebbe essere necessario modificare il prezzo di base di un prodotto più volte al giorno, ma non modificare il modo in cui quel prodotto potrebbe essere venduto più volte al giorno. Piuttosto, il flusso di lavoro delle vendite di un prodotto potrebbe cambiare su base settimanale (in attività altamente reattive e dinamiche).

Anche in questo caso, mentre il flusso di lavoro delle vendite di un prodotto potrebbe cambiare ogni settimana, penso che il prodotto complessivo non verrà modificato ogni settimana. Non riesco a immaginare una Microsoft che oggi ci regala Office, ma domani ci darà Offooose, e una settimana dopo, Offasooooooooooos.

No, non è quello che agile significa per cambiamento. Credo che provenga da visioni scadenti e da un profondo profondo fraintendimento del concetto di cambiamento.

Per non parlare del fatto che il cambiamento non è accolto in uno sprint, dove gli sviluppatori vanno nelle loro caverne e hanno bisogno di concentrarsi su ciò che fanno. Piuttosto, le modifiche devono essere aggiunte al Product Backlog e devono essere analizzate e classificate in ordine di priorità prima di essere consegnate alle mani del team di Scrum. In altre parole, uno Sprint Backlog non è immutabile. È necessario cercare più agilità utilizzando sprint più brevi, non iniettando direttamente le modifiche nelle stanze degli sviluppatori, molte volte al giorno.