Domanda

Potrebbe essere soggettivo e / o discussione .. ma qui va.

Mi è stato chiesto di stimare una funzione per la prossima grande cosa al lavoro. Lo scompongo .. uso i punti della storia per ottenere una stima. Tuttavia, la funzione richiede di interfacciare con GoDiagrams un componente di diagrammi di terze parti oltre a varie altre iniziative aziendali .. (un intero set di framework / servizi 2008_Limited_Edition :). Mi sono monitorato usando un grafico di burn-up e trovo che non sono in grado di sostenere il mio ritmo principalmente a causa di "spikes". Definizione

Stimo per 2 punti a settimana e poi mi ritrovo a lavorare nei fine settimana (bene provando a ... non finire né qui né lì) perché non riesco a capire dove collegarmi in modo da poter visualizzare in anteprima le azioni dell'utente, mostra un menu contestuale, ecc. Alla fine passo il tempo a fare picchi che gettano il mio programma fuori pista ... e ne riducono il valore .. non danno l'immagine giusta.

I picchi sono necessari per guidare i chiodi attraverso le assi dell'ignoranza. Ma come vengono presi in considerazione nell'equazione di stima? Fare tutti i picchi richiesti prima che la funzione sembri sbagliata .. (potrebbe rivelarsi YAGNI) Farlo tra interrompe il mio flusso. In questo momento è durante la pianificazione della pre-iterazione ... ma questo sta spingendo il touchline su base settimanale.

È stato utile?

Soluzione

Immagino che tu stia costantemente sottovalutando

  • quello che sai già sul componente di terze parti
  • quanto tempo impieghi a creare picchi utilizzabili / utili per aree sconosciute

1. Migliora la stima di queste due cose.

Quindi, si tratta solo di esperienza. Indipendentemente dalla metodologia utilizzata, ti aiuteranno a utilizzare meglio la tua esperienza, non a sostituirla.

2. Cerca di non perdere le tracce quando lavori su questi picchi.

Dovrebbero essere brevi sessioni a tempo. Non si tratta di giocare con tutte le possibili funzionalità elencate nelle diapositive di marketing. Dai loro la concentrazione, due o tre opzioni da esplorare. Aspettatevi che producano un risultato concreto.

Aggiornamento (Gishu): per riassumere

  • I picchi devono essere attività esplicite definite nella fase di pianificazione dell'iterazione.
  • Se i picchi superano il periodo di timebox, smettere di lavorarci sopra. Evita l'attività associata. Completa le altre attività nel bucket di iterazione corrente. Tornare all'attività archiviata o aggiungere un picco più elaborato / suddiviso alla successiva iterazione insieme all'attività associata. Taggare una stima più conservativa al picco della generazione 1 la prossima volta.

Altri suggerimenti

Se si esaurisce il tempo nel picco di timebox, è comunque necessario interrompere e completare le altre attività impegnate. Dovresti quindi aggiungere un altro picco alla prossima iterazione per completare il lavoro necessario che devi completare per stimare con precisione l'attività risultante dal picco.

Se c'è la preoccupazione di aggiungere cose troppo a lungo e questo diventa un problema - questa è una delle ragioni per cui mi piacciono le iterazioni di una settimana. : -)

@pointernil .. Non è più una stima unita a un approccio Head-First Indy-Jones per affrontare una storia. Stimo le storie in base al loro contenuto .. al momento non prendo in considerazione il tempo necessario per trovare il giusto incantesimo affinché la libreria di controllo funzioni bene. A volte questo richiede più tempo della mia logica applicativa. Quindi, per riformulare la domanda originale, i picchi dovrebbero essere compiti separati nel piano di iterazione, aggiunti su base JIT prima di iniziare a lavorare su una storia particolare?

I miei picchi sono estremamente focalizzati .. Non vedo l'ora di tornare al "vero" i problemi. per esempio. "Come faccio a mostrare un menu di scelta rapida da questo controllo?" Potrei essere colpevole di non leggere l'intero manuale di oltre 150 pagine o esempi di codice .. ma poi il tempo è scarso. La prima soluzione che risolve il problema ottiene il cenno del capo e vado avanti. Ma quando non riesci a trovare quell'evento sfuggente o il modello di notifica NIH utilizzato dal componente, i picchi possono richiedere molto tempo. Come posso impostare il timebox di qualcosa di sconosciuto? ad es. Il mio timebox è scaduto e non ho ancora idea di collegare il mio menu di scelta rapida personalizzato. Come procedo? Continuare ad hackerare?

Forse questo è presente nell'incertezza di buffering " schema di cose .. Vedrò se trovo qualcosa di utile nel libro di Mike Cohn.

Sono d'accordo con pointernil. L'unico problema è che le stime non sono corrette. Il che non è un grande dramma, a meno che tu non abbia appena lanciato un progetto da 3 milioni di dollari :-)

Se succede una volta, è un'esperienza di apprendimento. Se succede di nuovo e il risultato è migliore, allora hai un'altra esperienza di apprendimento sotto la cintura. Se stai costantemente sottovalutando e le tue percentuali stanno peggiorando, devi fare un po 'di rialzo. Nessuna metodologia ti tirerà fuori da questo.

I picchi devono solo avere il tempo di cui hanno bisogno. L'unica cosa che ho visto accadere ripetutamente nella mia esperienza è che le persone si aspettano di essere in grado di inchiodare una tecnologia entro un paio d'ore o un giorno. Questo non succede nella vita reale. Il problema più semplice, anche un bug causato da un errore di battitura, può avere uno sviluppatore che ci tira i capelli per enormi pezzi di tempo. Sii onesto su quanto tu o il tuo staff sia veramente competente e mettetelo nel budget.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top