Gestione delle funzionalità inaspettate durante lo sprint

Naviga le tue risposte
6

Il nostro team adotterà mischia e tecnologia agile. Abbiamo un prodotto, che sviluppiamo per più clienti. Questo cliente ci ha fornito i requisiti necessari, quindi tutto sommato va bene per adottare tecniche agili.

Ma ad un certo momento (ad esempio durante lo sprint), il nuovo cliente appare, e vuole ottenere una demo del prodotto leggermente diversa da quella che abbiamo ora. Questo potrebbe essere alcune nuove funzionalità o piccole differenze nel comportamento. E vuole ottenere questa demo per esempio durante la settimana. È molto importante dimostrare che il nostro prodotto supporta queste funzionalità (perché altrimenti si rivolgerà ai nostri concorrenti), quindi dobbiamo sviluppare queste funzionalità (potrebbe essere parzialmente) durante la settimana.

Come dobbiamo gestire questo tipo di funzionalità con agilità? Spostali nell'attuale backlog di sprint? O dividi una squadra a due e crei un altro sprint? O potrebbe esserci un altro modo?

    
posta andrey 05.01.2013 - 22:56
fonte

3 risposte

10

Se stai facendo scrum, dovresti avere un Product Owner, no? È compito suo dare la priorità alle cose che arrivano e gestire la relazione con i clienti. Detto questo, il proprietario del prodotto non dovrebbe aggiungere elementi a uno sprint a meno che il team non accetti il problema e che ci siano elementi che non sono ancora stati avviati e che possono essere esclusi dallo sprint per compensare.

Se il nuovo cliente risulta in un secondo proprietario del prodotto, ciò costituisce un secondo progetto. In tal caso dovresti formare un secondo team e creare un backlog prioritario per il nuovo progetto.

Se stai affrontando molto di questo, potresti considerare kanban come un'alternativa alla mischia.

    
risposta data 06.01.2013 - 09:19
fonte
5

Nessun cliente che meriti di aver desiderato meno di una settimana di programmazione.

Mostra loro ciò che puoi fare e di 'che puoi modificarlo per fare ciò che vogliono una volta firmato l'accordo. Quindi pianificalo per uno sprint futuro e completalo.

    
risposta data 05.01.2013 - 23:08
fonte
4

Ci sono momenti in cui il marketing promette a un potenziale cliente che ha una caratteristica che non è ancora implementata: - (

Dal punto di vista della gestione la "nuova funzionalità o il cliente non comprerà" è simile a un "bug di produzione critico che deve essere risolto e consegnato il prima possibile".

Per questa situazione di emergenza suggerisco

  • interrompi lo sprint e
  • smetti di lavorare sul ramo di sviluppo attuale e
  • crea un nuovo bando di emergenza che proviene dall'ultimo rilascio -statest -test-production-branch e
  • correggi il bug (o nel tuo caso crea la funzione "nuovo cliente")
  • esegui test, distribuzione, crea patch, ... (solo per la correzione di bug)
  • se tutto funziona bene, questa correzione / funzione viene unita al ramo di sviluppo interrotto e lo sprint viene ripreso o canceld_with_new_sprint_planning.

La tua gestione dovrebbe essere consapevole che questo flusso di lavoro è costoso e dovrebbe essere utilizzato solo in situazioni di emergenza reali.

    
risposta data 06.01.2013 - 10:14
fonte

Leggi altre domande sui tag

Clean, Modular Code vs MV * Frameworks [closed] Perché alcuni linguaggi orientati agli oggetti consentono al programmatore di utilizzare tipi primitivi?