在傳統的專案開發中，都有一個角色負責分配工作，常常是由PM（專案經理）或是Team Lead（組長）來擔任。分配工作這回事非常吃力不討好，既要了解每件工作的急迫性和複雜度，還要考量每個人的能力，平衡每個人的工作量。
這角色常常會成為團隊的瓶頸，因為每件事情都要經過他來分析、排程、驗收、忙著開會，常發生團隊成員空等他來分派工作。更別提如果工作項目比既定時程提早做完、或延遲完成所需要的協調工作。這也是最容易被上下壓力夾殺，很快Burnout陣亡的苦主。
Scrum沒有人負責工作分派！
在我深入了解Scrum之前，我會以為是由 ScrumMaster 來扮演這個角色。
後來才知道跑敏捷或Scrum中有一個大原則，就是工作是由每個人自己認領的。在 Sprint Planning 中開發團隊選擇拿多少個Item，沒有人可以要求開發團隊要拿多少工作，在Sprint進行中也是每個人自行選工作Task。
乍聽之下是非常天方夜譚的事情，人都嘛是被動的，閑著沒事最好，怎麼有可能主動去找事情做？神奇的是在我們實踐過程中，發現發現團隊會主動自己找出方法。
有些團隊做完的人就自己挑下一個，所以想儘快做完手上的搶挑自己喜歡的做。
有些團隊協議挑自己最沒把握的，學自己不熟的東西。
有些團隊挑自己最有把握的，因為想儘快讓產品加值上線。
有些團隊選擇Commit少一點，因為想花多點時間還技術債。
重點是，這些都是由個個團隊依照現在情形，來決定最適合的方式，而且會隨著時間環境推移改變。
沒人想做的工作怎麼辦？
這是個經常出現的疑問，在臺科大分享時也有同學提出來。有一個過度解釋的迷思是，團隊要做什麼完全由自己決定，其實不是這樣的。
工作事項是經過Product Owner 排序過的，開發團隊認領工作的原則是由優先級從高到低認領，所以工作還是都會被處理。
我觀察一開始時開發團隊不太會提到工作想不想做，因為能自己選擇要做幾個Item，已經是非常大的衝擊和超大自由度（跟傳統的方法相比）。團隊通常把注意力放在需不需要做，而非想不想做。
有一個好現象是開發團隊開始質疑工作的價值和優先順序時，這代表對產品有想法和認同，也是Product Owner闡述價值和溝通的好機會。如果Product Owner能提出論述也虛心接受建議，可以經由討論讓產品的工作項目更有品質。
如果團隊拿太少工作怎麼辦？
在我印象中，在開始跑Scrum時大都是Commit的東西做不完。而且太多、太少非常主觀，也沒有比較基礎和意義。
相比多少工作量，我更想問的是，團隊做的工作對產品的表現有什麼影響？
有人擺爛不做事怎麼辦？
很幸運的，我們沒有遇到過。我也相信知識工作者不需要人盯著才願意工作。
但如果真的有這種現象發生，我相信由Scrum讓事情曝露出來，好過在傳統的方式中被隱藏起來。
那Product Owner不就很倒楣，只能接受事情做不完？
是也不是。
Product Owner要相信團隊已經盡了目前的能力去做，與其計較做多少工作、花多少時間，不如考慮團隊是不是在做目前最有價值的事情？
至於之前為什麼可以做那麼多，現在那麼少？用Hard Coded、Copy&Paste、不寫測試等等的暗黑工具箱，都可以讓工作很快看起來做完了，但是埋一堆地雷以後來踩。
重要的是Product Owner也是團隊的一份子，可以把自己的期待跟困難點跟團隊說明，一起找出方法。有不滿也可以說出來，敏捷說的透明度不止是工作事項的透明度，還有包含想法和心情的透明度。
圖片來源：http://www.tinypm.com/blog/are-you-brave-enough-to-let-go/
很赞，学习了。
謝謝！