我認爲JIRA提供To Do,In Progress和Done的原因之一是它們可以應用於任何事物。你要麼沒有做,要麼做,或者完成。該集合可以適用於任何類型的項目。
這就是說,我覺得你的痛苦是想更好地瞭解問題的真實狀態。我們已經發現,我們用我們的按需靈活的電路板是建立類似如下:
- 待辦事項
- 在進步
- 準備審查
- 在評論
- 完成
對於大多數類型的問題,這可以工作。它增加了一點額外的層次,以便能夠識別準備好測試的內容。
棘手的事情之一是依賴任務。例如,我注意到你提到「設計」是一個階段,我不確定這是否有敏捷意義。如果設計是從開發中產生的,那麼允許設計/開發在開發團隊中流動可能會更好。但是,我們都知道,在開始之前,有時候你需要弄清楚一些細節,或者在開發人員可以開始之前可能會有一些人需要參與。我們犯了一個錯誤,試圖把它變成一個階段,但我們發現,這實際上或者是部分團隊的一項子任務,或者是一個障礙(阻擋者)。通過標記故事,您可以確定故事需要在開發團隊進行之前完成。
如果您使用看板,而不是Scrum板,子任務方法將不適合您。在這些情況下,您只需要確保您的階段對於您創建的所有問題都有意義。階段必須相當「通用」。這聽起來很糟糕。
但它不是!
我相信球隊一般使用階段的幾個原因:
- 檢查上的迭代
- 狀態通知其他隊員,他們可以拿起一個項目
- 試圖讓視覺估計離完成問題有多近。
更多的階段並不一定會給迭代帶來更好的狀態,因爲您只需要查看已關閉了多少點以及正在進行多少點。所以,至少對於這個目標來說,一個更通用的階段應該起作用。
至於通知團隊成員,我經常看到團隊撤回到數字板來取代彼此之間的溝通。你擁有的階段越少,你就越可以強迫你的團隊相互交流,並共同努力完成一個故事。事情會更好地工作,我保證!如果你一次處理很多項目,或者讓分佈式團隊在不同的時區工作,但保持簡單通常更好,那麼分解有點幫助。
跟蹤「完成度如何」是最難的通用階段。但是,多個階段可能會產生誤導。幾乎所有的項目都可能有一個嚴重的錯誤,但尚未發現,所以無論您對該項目有多少階段的看法都不比單個「正在進行」更準確,階段。直到它完成後才完成:)
這對我來說建議保持簡單的工作流程並讓團隊使用通信保持最佳狀態是一個很長的路要走。也許我應該剛剛開始!
退一步,考慮如何用白板來處理這個問題。您可能會減少顯示的列數,並收集不同的問題類型。也許你可能會針對不同的問題類型使用不同的彩色postit筆記。我會在這裏做同樣的事情,只在板上使用三到四列。您還可以使用其他顯示與不同列相同問題的主板 – mdoar
也可以爲問題類型使用卡片顏色。 – mdoar