Segnala come catturare lo scorrimento dell'ambito in iterazione

2

Sto cercando un report per catturare "Scope Creep" all'interno di un'iterazione. Stiamo utilizzando Scrum su TFS 2013 in sede.

Ci viene costantemente chiesto dal management di portare il lavoro in una iterazione, ma siamo ancora sotto pressione per rispettare gli impegni presi nelle riunioni di pianificazione. Sfortunatamente capita spesso che non si tratta di tracciare manualmente 1 o 2 elementi di lavoro per ogni iterazione.

Anche a volte abbiamo appena sottovalutato il lavoro e ci vuole più tempo di quanto avevamo programmato.

Vorrei estrarre un rapporto da TFS o dal magazzino / cubo che mostra quando il lavoro viene portato in una iterazione (vale a dire nuovo PBI / Bug aggiunto) o il lavoro su un elemento esistente aumenta.

Desidero utilizzare questo rapporto per mostrare alla direzione l'impatto dell'inserimento nel lavoro non pianificato e / o utilizzare il rapporto come dati per migliorare le nostre stime.

    
posta Squid 07.04.2015 - 02:00
fonte

2 risposte

7

La risposta ufficiale Agile è che semplicemente non dovrebbe essere permesso. Sfortunatamente, come stai vivendo, la realtà è che questo spesso accade. A volte ciò è dovuto al fatto che le esigenze aziendali cambiano troppo rapidamente anche per sprint brevi. A volte ciò accade a causa della pessima pianificazione da parte del proprietario del prodotto. E sfortunatamente a volte questo accade perché la gestione non ha veramente acquistato in agile e quindi ritiene di avere il diritto di dirti di fare qualsiasi compito ogni volta. Quest'ultimo caso è il più difficile da affrontare.

In primo luogo, quando si accetta una nuova storia in uno sprint, dovrebbe essere indicata come qualsiasi altra storia. Tutto il lavoro deve essere tracciato indipendentemente dal fatto che sia stato aggiunto allo sprint nel modo giusto (in fase di pianificazione) o nel modo sbagliato (a caso durante lo sprint). Dovresti conoscere la tua velocità. Dovresti ora quanti punti hai accettato di fare nella pianificazione. Se punti nuove storie, dovresti essere in grado di dire esattamente quanti punti extra devi fare. È quindi possibile segnalare durante ogni sprint quanti punti rispetto alla velocità è stato chiesto di fare. Alla fine di ogni sprint, puoi quindi dimostrare di essere in ritardo su X, Y, Z perché ti è stato chiesto di fare nuove storie con numeri di punti che ti mettono sopra la tua velocità.

La seconda cosa che puoi fare è tracciare quanti punti di storie correttamente pianificate al momento che sei in grado di completare e usare che come velocità durante la pianificazione. Sii molto trasparente su questo. Fai capire alla direzione che non sei in grado di prendere quante storie vuoi altrimenti perché sei costretto a fare un lavoro inaspettato e in più.

È una sfortunata verità che, per far funzionare tutto questo, dovrai difendere la direzione e spiegare che, per poter lavorare agilmente, è necessario seguire regole agili. Questo può essere difficile o impossibile da fare se la gestione è scarsa. Ma deve essere chiaramente spiegato ogni volta che le storie vengono aggiunte a metà sprint che non si possono ottenere i benefici dell'agile senza seguire le regole dell'agile ed evitare che il lavoro di metà sprint sia uno dei più importanti.

    
risposta data 07.04.2015 - 02:25
fonte
0

Ecco uno script che ho preparato che esaminerà la vista workitemhistory per capire quando una iterazione cambia in una data che si trova tra la data di inizio e di fine dell'iterazione.

È un work in progress, ma dimostra che la risposta è lì se ne hai bisogno.

DECLARE @iteration VARCHAR(300)
DECLARE @startDate DATETIME
DECLARE @endDate DATETIME

SELECT @iteration = '\TeamProject\Team\Sprint 4';

SELECT @startDate = startdate, @endDate = finishDate
FROM DimIteration
WHERE iterationpath = @iteration;

WITH CTE_ALLWorkItemsInIteration
AS (
    SELECT DISTINCT system_id
    FROM WorkItemHistoryView
    WHERE IterationPath = @Iteration
    )
,CTE_WorkItemHistory
AS (
    SELECT *
        ,ROW_NUMBER() OVER (
            PARTITION BY System_Id ORDER BY [System_ChangedDate] ASC
            ) AS Recency
    FROM WorkItemHistoryView
    WHERE system_id IN (
            SELECT system_id
            FROM CTE_ALLWorkItemsInIteration
            )
    )
SELECT CurrentWI.System_id
    ,CurrentWI.System_WorkItemType
    ,CurrentWI.IterationPath AS currentIteration
    ,PreviousWI.IterationPath AS previousIteration
    ,currentwi.system_changeddate
    ,CurrentWI.System_ChangedBy
    ,CurrentWI.System_Title
    ,(
        CASE 
            WHEN CurrentWI.IterationPath = @iteration
                THEN 1
            ELSE 0
            END
        ) AS AddedToIteration
    ,(
        CASE 
            WHEN PreviousWI.IterationPath = @iteration
                THEN 1
            ELSE 0
            END
        ) AS RemovedFromIteration
FROM CTE_WorkItemHistory CurrentWI
LEFT JOIN CTE_WorkItemHistory PreviousWI ON CurrentWI.System_id = PreviousWI.System_id AND CurrentWI.Recency - 1 = PreviousWI.Recency
WHERE (
        CurrentWI.IterationPath <> PreviousWI.IterationPath
        OR PreviousWI.IterationPath IS NULL
        )
    AND (
        CurrentWI.IterationPath = @iteration
        OR PreviousWI.IterationPath = @iteration
        )
    AND (CurrentWI.System_ChangedDate BETWEEN @startDate
         AND @endDate)
    
risposta data 08.04.2015 - 08:32
fonte

Leggi altre domande sui tag