Come gestite i costi di un cambiamento troppo rapido?


11

Come la maggior parte degli sviluppatori moderni, apprezzo i principali Agile come la collaborazione dei clienti e la risposta ai cambiamenti, ma cosa succede quando un proprietario del prodotto (o chiunque determina requisiti e priorità) cambia requisiti e priorità troppo spesso? Come più volte al giorno?

Di recente ho ereditato una piccola base di codice che era buggy, incompleta e non poteva nemmeno gestire lo scenario più semplice che avrebbe dovuto. Riesco a gestire i problemi tecnici ma ricevo diverse e-mail, messaggi o telefonate al giorno che dicono "OMG, DEVI lavorare su questo GIUSTO ADESSO! PRIMA PRIORITÀ! Questo è un MUST !!! oneone" (è solo una leggera esagerazione) Ciò che rende ancora peggio è che la maggior parte delle cose sono dettagli minori che non sono nemmeno rilevanti per ciò che il software dovrebbe effettivamente fare e richiederebbero comunque giorni per implementarlo. Ho provato a spiegare che c'è solo così tanto tempo e che dovremmo prima concentrarci sulle cose più importanti, ma qualcosa sembra perdersi nella traduzione perché la stessa cosa accade un giorno o due dopo.

Esiste una sorta di ruolo Product-Owner-Handler, studio approfondito, metafora o citazione che può aiutarmi a ridurre la quantità di sforzi sprecati o almeno spiegare i costi di questo comportamento caotico?


Il tuo team sta seguendo una sorta di metodologia agile?
Aaron Kurtzhals,

Direi che siamo agili, ma non seguiamo una metodologia agile specifica diversa da quella che gli strumenti (PivotalTracker, Jenkins, ecc.) Impongono o supportano.
Trystan Spangler,

Dici agile, direi agile ma;)
Marcin Sanecki

Risposte:


12

Questo è lo scopo del backlog. Le nuove richieste vengono inserite nel backlog e le priorità possono cambiare solo sui confini dell'iterazione. Una media di un ritardo di una settimana (metà di uno sprint di due settimane) è abbastanza agile da gestire tutte le emergenze tranne quelle più terribili.


5
+1 per quella che è l'unica e l'unica risposta corretta. Come si dice: "Una volta avviata un'iterazione, non è possibile modificarla". Quale parte di "CANNOT" non capisci?
mattnz,

+1 alla risposta e al commento di Mattnz ("Quale parte di" CANNOT "non capisci?"): Ho avuto un problema simile: tre settimane di iterazione e durante la terza settimana un collega inizia a essere estremamente creativo e a cambiare / spostare le cose in giro. Agile significa molta flessibilità ma ci sono alcuni limiti inferiori: dopo aver fissato alcune unità minime di lavoro, dovresti concentrarti su di esse senza essere distratto.
Giorgio,

Concordo sul fatto che questo è l'arretrato, tuttavia, è possibile eliminare elementi da un'iterazione o persino scambiarli con elementi di uguale sforzo, purché non si sia ancora iniziato a lavorare sugli elementi rilasciati / scambiati.
Joshua Drake,

Concordo sul fatto che il team dovrebbe essere in grado di scegliere se consentire o meno le modifiche a metà sprint. Troppe modifiche imposte esternamente sono dirompenti, che tu abbia iniziato o no. Spetta ai singoli team decidere quanto sono "troppi". A volte devi impostare quel numero su zero per consentire alle persone di ottenere l'immagine.
Karl Bielefeldt,

9

Ecco come ho affrontato un problema simile .. Ai tempi in cui eravamo agili prima di Agile.

Per qualsiasi 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. Le attività con priorità uguale sono programmate in ordine di arrivo. (La priorità dell'attività non può essere modificata una volta avviato il lavoro.)

Ti farà male quando dici 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. Quindi gli dici che a quel livello di priorità ci sono 50 compiti banali e non importanti prima della sua ultima richiesta. Ora il vero problema - tutti questi compiti sono al livello di priorità 1 (il più alto), impostato da ... LUI ... Quindi non può cancellarti dal compito che stai facendo. Ora, quando hai finito di spostare la cornice della finestra di 3 pixel a sinistra per fare spazio alla parola più lunga nella traduzione islandese sull'opzione di configurazione usata raramente .....

Chiudo anche la porta dell'ufficio SD, la chiudo a chiave e tolgo 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 continuava a girare intorno al sole, abbiamo fatto il nostro lavoro e ai "Clienti" è stato consegnato loro software più veloce e migliore di qualsiasi altro tempo in passato.

Ci sono volute alcune settimane perché le priorità si assestassero a qualcosa di più realistico, siamo riusciti a sbloccare la porta ecc. Ma il sistema è rimasto per un bel po 'di tempo. Potrebbe non essere necessario essere così estremi (lo abbiamo fatto) e avrai bisogno del supporto del senior management. Ma funzionerà ....


+1 "La priorità dell'attività non può essere modificata una volta avviato il lavoro." Agile consente solo a uno sviluppatore di eliminare elementi da un'iterazione su cui non hanno iniziato a lavorare.
Joshua Drake,

Mi piace l'idea che il cliente stabilisca la priorità, la parte difficile è stabilire la legge e dire 'Ho iniziato con l'attività X, no, non puoi cambiare la priorità adesso'
sevenseacat,

2

SOP. Procedura operativa standard (o almeno un protocollo sciolto che è stato firmato dal team di gestione). Il tuo dipartimento deve svilupparne uno o collaborare con il team di gestione per svilupparne uno. Le persone con cui devi parlare sono al di sopra del product owner / 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 di qualità o sulla verifica di questo prodotto?
  • Qual è il metodo per determinare ragionevolmente un termine per la consegna? Questa iterazione? La prossima versione?

Senza tali procedure, tutti ti correranno incontro come se fossero inseguiti dagli zombi e si aspettassero tutto ORA ORA ORA. Persone del genere non rispetteranno il tuo educato "no" o "per favore, aspetta. Con una solida politica in atto, questi mutanti assetati di codice capiranno che hanno torto quando chiedono cose su una base così libera.

Il risultato finale è infelice e questo non è nell'interesse delle vostre aziende.

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


2

È molto difficile lavorare in queste condizioni "pronto, fuoco, mira". Mi sembra che tu stia ricevendo requisiti da una persona molto insicura, la cui opinione cambia ogni volta che una persona più alta 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 i messaggi di testo non abbiano ampiamente sostituito la posta elettronica dalla tua organizzazione nel suo insieme.) Leggili, forse, ma non rispondi. In questo modo puoi dedicare il tuo tempo a concentrarti sul lavoro effettivo che devi svolgere, non sulla discussione di urgenze casuali che potrebbero diventare irrilevanti domani, o anche due o tre e-mail in seguito. 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 vera conversazione a due vie potrebbe essere la equivalente).

Quando hai il faccia a faccia o la conversazione telefonica, è utile ripetere ciò che la persona chiede con le tue parole e quindi porre le tue domande sui nuovi requisiti e priorità. "Se ho capito bene, stai dicendo che dovremmo smettere di lavorare sull'attuale massima priorità X e ora concentrarci sulla priorità del minuto Y. È un grande cambiamento. Puoi spiegare il cambiamento nel business? Potrei aver bisogno di fare più background funziona piuttosto che cambiare l'interfaccia utente. Ci saranno cambiamenti in altri processi aziendali, come fatturazione o inventario (ad esempio)? Ti aspetti che questi nuovi elementi di dati vengano visualizzati in tutti i rapporti mensili? " È anche utile dire qualcosa sull'effetto di "Comprendi che se procediamo con questo nuovo sforzo, ritarderà il rilascio dell'attuale priorità massima X di almeno una (settimana, mese,

Se si tratta di una vera emergenza, il richiedente dovrebbe essere in grado di rispondere a questo tipo di domande o indirizzarti immediatamente a qualcuno che potrebbe. Se non si tratta di una vera emergenza, questo tipo di conversazione costringerà il richiedente a rallentare e determinare quanto sia importante il cambiamento, dato che devono ottenere maggiori informazioni. Spesso vedranno 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 tua comprensione delle modifiche in una e-mail e inviarlo al richiedente originale, chiedendo se concordano sull'ambito della modifica, di nuovo, come chiarimento. In questo modo hai scritto la documentazione di ciò che deve essere fatto e del motivo per cui è stato richiesto, nel caso in cui ci sia qualche soffocamento sul perché non stai più lavorando su Current Top Priority X o devi spiegare perché le scadenze originali non stanno andando essere incontrato.

Si spera che questo possa migliorare il rapporto con il richiedente, dal momento che stai dimostrando le tue conoscenze e assicurandoti di lavorare su ciò che vogliono, ma sei onesto su ciò che serve per apportare modifiche. Chiedendo in dettaglio la richiesta, vedono che pensi in anticipo e considerano cose che potrebbero non avere originariamente.


0

Sembra che nessuno lo abbia ancora menzionato, Sprint e le sue storie utente ideally should be locked till the next sprint(lo sprint tipico dura 2-4 settimane). Bloccando - intendo dire che nessuna attività aggiuntiva dovrebbe essere aggiunta a Sprint già avviato.

Se la storia dell'utente è abbastanza grande da non adattarsi allo sprint, frenalo per compiti più piccoli e realizzabili durante lo sprint. Inoltre, come accennato, anche le attività prioritarie devono essere trattenute nel backlog e durante il prossimo sprint la pianificazione ad alta priorità una volta alzata la bandiera :)

Modifica: solo piccole modifiche possono essere introdotte in primavera. se portano lo stato di emergenza. Tuttavia, se ci sono sempre emergenze di coppia durante lo sprint, allora qualcosa deve essere cambiato nella pianificazione dello Sprint stesso.


0

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

Se c'è qualcuno come un caposquadra, un project manager, uno scrum master, ecc. Che è responsabile, parlerei con quella persona.

Ho provato a spiegare che c'è solo così tanto tempo e che dovremmo prima concentrarci sulle cose più importanti, ma qualcosa sembra perdersi nella traduzione perché la stessa cosa accade un giorno o due dopo.

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


0

Il Manifesto Agile afferma che uno dei principi fondamentali è:

Benvenuti a cambiare i requisiti, anche in ritardo di sviluppo. I processi agili sfruttano il cambiamento per il vantaggio competitivo del cliente.

Tuttavia, non credo che significassero un cambiamento su base giornaliera. Potrebbe essere necessario modificare il prezzo di base di un prodotto più volte al giorno, ma non cambiare la modalità di vendita di tale prodotto più volte al giorno. Piuttosto, il flusso di lavoro delle vendite di un prodotto potrebbe cambiare su base settimanale (in aziende altamente reattive e dinamiche).

Ancora una volta, 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 offre Office, ma domani ci darà Offooose e una settimana dopo Offasooooooooooos.

No, non è questo che agile significa cambiamento. Credo che provenga da cattive visioni e da un grande profondo fraintendimento del concetto di cambiamento.

Per non parlare del fatto che il cambiamento non è accolto in uno sprint, in cui gli sviluppatori vanno nelle loro caverne e devono concentrarsi su ciò che stanno facendo. Piuttosto, le modifiche dovrebbero essere aggiunte al Product Backlog, e dovrebbero essere analizzate e assegnate le priorità prima che vengano consegnate alle mani del team di Scrum. In altre parole, uno Sprint Backlog non è immutabile. Si dovrebbe cercare maggiore agilità utilizzando sprint più brevi, non iniettando i cambiamenti direttamente nelle stanze degli sviluppatori, più volte al giorno.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.