一次敏捷workshop上，有同學問：“敏捷軟體開發中，團隊成員自己主動認領的，是使用者故事還是被分解成的任務？”同學們一時討論熱烈。

稍具敏捷開發實踐經驗的同學都應該知道，答案是——任務（Task）。

但我們不想就此打住。讓我們從以下幾個方面來探討一下這背後的原因。

使用者故事和任務

敏捷團隊

敏捷需求估算

敏捷迭代的跟蹤與管理

使用者故事和任務

使用者故事（User Story）和任務（Task）[1]是敏捷開發中管理和跟蹤使用者需求的主要工具。使用者故事是首創於極限程式設計（XP）的管理使用者需求的基本方法，目前已廣為各個敏捷實踐方法和技術所借鑑和使用。Scrum將使用者故事作為最基本的需求管理工具，組成了稱之為產品待辦事項列表

使用者故事從使用者的角度描述使用者渴望得到的功能和實現的價值。一個好的使用者故事包括三個基本要素：
　　角色：誰要使用這個功能。
　　活動：需要完成什麼樣的功能。
　　商業價值：為什麼需要這個功能以及這個功能帶來什麼樣的價值。

使用者故事關注的是交付給客戶的最終價值，也就是能給客戶帶來什麼樣的最終效益。換句話說，使用者故事面向的是具體客戶的需求，而不太關心開發團隊要怎樣才能實現這個需求。使用者故事不關心具體實現，使得它不關注具體的細節，因而有時候一個使用者故事的粒度很大，甚至會有史詩故事（epic）；有時候一個使用者故事的粒度有很小，可能一個小的軟體缺陷（defect）也能作為一個使用者故事。

而軟體團隊最終需要把承諾的使用者故事，轉變為可工作的軟體，即使用具體的開發語言和工具，實現使用者故事。可工作的軟體才是敏捷開發真正關注的核心。軟體團隊需要和產品負責人（Product Owner）及Scrum Master一起，分析、評估具體的使用者故事，詳細、深入地瞭解使用者故事所傳達的使用者價值，討論該使用者故事的故事點數（Story Point）以及具體的工作量，實現該使用者故事所要做的事情，把這些事情分解為具體的任務，比如邏輯設計、資料庫設計、介面設計、編碼、測試（或自動化測試）、整合、驗收測試、部署等工作。

由使用者故事分解而來的具體任務，關注於該如何實現該使用者故事而必須完成的工作，關注的是具體的技術細節和實現方法。不同的任務具有不同的技術要求，比如開發任務要求的是更加專業和高效的程式碼實現能力，而測試工作則專注於如何測試該實現以確保最終交付的可工作軟體真正實現使用者故事所體現的客戶價值。因而每個任務的具體技術要求可能都不一樣。

由此可見，團隊成員更傾向於專注於具體的工作任務和自己專長的領域，而任務則正好適合團隊成員專注於某個具體領域並培養自己在該領域的專長。團隊成員主動認領自己擅長的任務並高效、高質量地完成之，也是符合敏捷開發原則的最佳做法。

敏捷團隊

通常意義上，敏捷軟體團隊是指遵循敏捷宣言的精神和敏捷實踐的具體原則，運用敏捷軟體開發相關的技術、方法、工具和流程，從事軟體開發和交付的自組織、跨功能團隊。《Scrum Guide》[1]指出，Scrum團隊包含產品負責人、開發團隊和Scrum Master。Scrum團隊是自組織且跨功能的。自組織團隊選擇如何最好地完成他們的工作，而不是由團隊外的其他人來指使他們。而跨功能團隊擁有完成工作所需要的全部技能，不需要依賴團隊外部的人員即可完成開發和交付軟體所需要的全部工作。Scrum團隊模式的目的是最大限度地優化適應性、創造性和生產力。

由此我們知道，跨功能團隊包括了完成軟體開發和交付工作所需要的全部技能類別，開發、測試、QA、需求、設計、使用者體驗、資料庫等。雖然當前“全棧工程師”的概念頗為流行，但隨著現代軟體工程向著更加精細的專業化、分工化發展，每一個細分的專業方向都差別巨大。後臺資料庫的設計和開發與前端介面的美醜、佈局是否合理等，不僅僅體現在使用者能接觸到的多少。一個工程師不可能瞭解和掌握開發和交付軟體所需要的全部技能。因而團隊必然是各種技能工程師的組合，大家每人專注於開發和交付高客戶價值軟體所需要的各個方面，需求、編碼、測試、設計、介面優化、使用者體驗等人員的工作緊密配合、相互協作才能交付高質量的軟體。

純理論上的跨功能團隊有時也要求團隊成員彼此在技能上儘量縮小差距，不同角色的成員瞭解和掌握其他角色成員所具備的技能，以便在需要的時候能夠擔負相應的職責。但從具體實踐來講，團隊成員可以瞭解別的角色的技能，比如開發瞭解測試，測試工程師學習開發技術等，但精通掌握另一個角色的技能還是有比較大難度的。要想交付高質量軟體，每個團隊成員必須在自己最擅長的領域做出最可靠和最高效的貢獻。專注於某一個具體技術領域，專注才能達到專業，專業才能高質量和高效。所以，敏捷團隊必須能夠讓每個成員都能夠在自己專長的工作上發揮最大功效，才能真正成為高效的自組織團隊。因此，編碼的Task不太可能由測試人員負責，而前端設計類任務也最好由擅長前端設計的人員來負責。

使用者故事專注於交付給客戶的具體價值，也就是該使用者故事能夠幫助客戶實現什麼樣的功能和成就。而為實現使用者故事，通常會把使用者故事分解為一系列要完成的任務，比如最常見的設計、編碼、測試、整合、部署等。所以不同角色的團隊成員主動認領自己最擅長的任務並高效完成之，是最合理和高效的做法。

敏捷需求估算

產品負責人（Product Owner）根據來自各渠道收集到的資訊，整理並創建出稱之為產品待辦事項的使用者故事列表。而開發團隊則負責將經過產品負責人整理和按照優先順序排序了的使用者故事轉變為最終的可工作軟體。在這個過程中，軟體團隊需要和產品負責人一道，分析具體的使用者故事，評估實現該使用者故事所需要完成的工作，估算具體的工作量。而後軟體團隊需要在每個迭代開始時，將承諾的使用者故事分解為具體的任務。因而該過程需要完成2件事情：1）估算使用者故事的故事點；2）將使用者故事分解為任務。

“豬”類角色將使用者故事估算完畢，所有的使用者故事在經過Product Owner的排序之後，組成了產品待辦事項列表。在每個Sprint的Sprint計劃中，包括“雞”類角色在內的團隊針對優先順序最高的使用者故事，進行討論、分析，並將之分解為一個個的任務，這些任務細化到實現和交付使用者故事所需要採取的每一個步驟。不同的團隊角色都要對使用者故事的實現和交付做出必要的貢獻。這個時候，每個角色根據自己的能力和優勢，認領相應的任務，並估計自己所認領任務的工作時間。這就是“誰承諾任務，誰負責任務，誰估算任務”，因為“做這個事情的那個人是最瞭解那個任務的人，也是最適合對之做出估計的人”。

敏捷迭代的跟蹤與管理

敏捷開發中，通常使用任務板來視覺化地展示各個使用者故事和相應任務的進展情況，並據此畫出相應的Sprint 燃盡圖（Burndown chart）[3]。作為敏捷開發中任務完成情況的視覺化展示，任務板和燃盡圖直觀而生動地展示出了專案團隊在目前工作上的進展情況和預期進展。

有些團隊的任務板包括使用者故事、任務列表、未開始的任務、已開始的任務（WIP）、完成的任務等。有些團隊為了突出彰顯任務的承諾者，還會在每個任務上寫上認領者的名字，甚至貼上認領者的照片。

從迭代計劃的跟蹤和管理的角度看，敏捷團隊需要跟蹤和度量每個任務的完成情況。只有在按照團隊“完成”（DoD， Definition of Done）要求，完成了DoD中所要求的全部任務時，一個使用者故事才算完成。在IBM RTC裡面，度量每個任務的完成時間。而每個任務是跟蹤到團隊角色的。所以，每個團隊角色所認領的，也只是由使用者故事分解而來的任務，而不是使用者故事。

總結

使用者故事專注於團隊需要交付給客戶的使用者價值，而任務則關注於實現和交付由使用者故事所體現出的客戶價值的技術和底層細節。為實現和交付使用者價值，敏捷團隊角色需要主動認領屬於自己職責和專業領域的工作，完成相應的任務。

當然，在某些情況下，為了更加明確專案產品待辦事項的職責，會指定某個人負責跟蹤和協調某個使用者故事的所有任務，以確保在Sprint裡面所承諾的所有使用者故事需要的任務都能如期完成。但這種使用者故事的負責人，不過是專案管理和專案工作跟蹤與原理的一種方式，與敏捷開發中自組織、跨功能團隊成員主動認領的需要承諾完成的工作是不同的範疇。

參考文獻： 

[1] 使用者故事與敏捷方法，[美] 科恩 著； 石永超，張博超 譯； 李國彪，滕振宇 校，清華大學出版社2010年4月出版。

[2] Scrum Guide， http://www.scrumguides.org/。 （中文版 http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-CN.pdf#zoom=100 ）

[3]  敏捷估計與規劃，[美] 柯恩 著； 宋銳 譯，清華大學出版社2007年7月出版。