如何確保taksboard中的task是否真的做完和做好
1. Task 要切得很小
- 1-2天的大小比較合適, 這樣幾乎每天engineer可以移動他們的task, 會比較有成就感.
- 並且manager可以確認他們真的是有進度
- 大的task你不容易知道是否有些細節有被處理到, 較細的task比較可以知道engineer如何處理這個feature.
2. 定義每個task做完的定義為何
- 讓engineer知道manager對你的期待是甚麼, 避免做完後讓雙方落差很大
- 讓engineer在估算時, 會依據做完的定義來考量要多少時間
3. 定義一些milestone或是check point之類的task
- 有時候engineer拆解出的task, 很難實際上知道他到底做了哪些事情, 或是到底做完了沒有. 因此需要有些特別的task來讓你清楚實際的狀態
- 像是開立測試個案, engineer一開始通常只有test case creation這個task, 但是你很難知道他到底做得如何, 所以你可以要求加上test case review, check-in test case to test case management tool等tasks. 這樣你可以藉由review 來知道它的品質, 並且check-in這個task來確保他有做到你想要的做完的定義.
- 對於RD開發某項功能時, 一開始也只會寫implement XXX. 可是這樣你也很難知道他到底做得如何. 所以要請他加上, design review for XXX, code review for XXX, integrate with CI for XXX, defin demo scenario for XXX, demo for XXX 等等. 這樣你就不用有太大的落差.
4. 確切檢查每天的進度
- 在會議前先檢查task的狀況, 確認那些已經落後, 那些項目編排的很奇怪
- 在會議過程中, 針對這些有問題的task多加關注, 傾聽其報到結果
- 在會議後和這些task的owner討論, 是否需要一些協助, 或者如何補救
5. 從daily standup的過程中給於建議
- 在會議中會聽一些他決定如何優先順序的事情時, 須注意他是否做了正確的決定, 若不是的話, 在會後需要加以提醒
- 或者engineer有發現任何問題, 也需要會後立即加以處理, 讓所有會block的事情能夠降到最低
6. 安排demo
- 在sprint結束時, 安排engineer展示他所做的功能.
- 通常為了自己的名聲, engineer會讓成果維持一定的品質, 並且加快其處理的腳步
7. 安排developer執行基本功能的測試
- RD和QA討論出一組測試個案, 來當作驗收測試, 以檢查主要功能是否正確
留言列表
