使用雲效公有雲版本三個多月，對于任務拆分的一點心得，現在這裡分享一下。
任務的定義
任務是從産品到開發到測試一個可以貫穿的概念，在Jira、github 等項目管理軟體中，叫做 Issue，Issue 在不同的項目、項目中不同的環節都不太一樣。稱之為任務的确也沒啥太多問題。
開發中過的任務，簡單的來說，要完成的一個定義明确的功能項，不依賴内部别的功能，需要的時間根據難易度在兩小時到一天左右，且一個人可以獨立完成。
我們看到有些項目組的任務會定義為一個人完成的一個大的功能點，可能需要 2-3 天完成，這也是可以的。任務的重要邊界是完成本身不依賴其他任務 ( 和定義好的接口通訊不屬于此 )。
在開發過程中的任務大部分就是從産品需求而來，
下面這些都可以是一個獨立的任務：
- 一個 40 行代碼左右的函數
- 一個有三個方法的獨立的類的定義和實作
- 一個 3 螢幕高的網頁視覺設計
- 5 個表，每個表大約 20 個字段的資料庫設計
- 增加一個接口函數
- 為了測試一個接口準備 50 個 test case
- 某種 SAAS 服務的一種功能的接口對接
開發任務的詳細設計具體怎麼進行，這裡就不展開了，因事而異。
任務的基本屬性
在雲效中建立一個任務會看到下面這些屬性，有很多。
建議下面這些屬性是必須要輸入的，如下圖中藍色框出的：
- 标題
- 描述
- 指派給
- 優先級
- 疊代
- 歸屬項目
- 版本
- 标簽
- 預計工時
- 實際工時
任務标題和描述
任務的标題非常重要，我們建議任務标題按照如下規則來進行：
- 顆粒度一緻
- 字數不要太多
- 句式盡量一緻
- 不要有歧義
好的任務标題如下：
- 機具底層，回寫發夾行腳本
- 刷卡收款，完成交易輪詢
- 外部調用，提供擷取商戶的收款方式接口
- SDK 初始化，完成統一初始化入口
寫的不太好的任務标題如下：
- 建立 jsp
- 使用者資訊查詢（商戶）
- 控台功能修複-交易查詢
- 單筆交易查詢接口傳回狀态優化
推薦使用在以一個項目中： AAA，BBBBB。這樣的句式。其中AAA 是某個大子產品的名稱，一個項目中的子產品劃分可以由項目經理确認，一般也不會超過5個，如果每個标題中的 AAA 都不太相關，說明顆粒度太細了。這樣的描述還有個好處就是視覺上比較整齊。在有的項目中我也會建議 AAA 這裡試用新增、修改、删除這樣的描述，特别是一些底層的支援類的項目，變化也比較頻繁的，可以用這類描述方式。
任務描述是對這個任務的較長的描述，可以對這個任務更好的了解。很多程式員不太願意寫文檔，經常看到一些程式員詳細設計寫的簡單，項目評審流于形式，有些程式員急于想編碼。這樣的風險很大，使用盡量标準的項目開發流程可以限制這樣的行為。任務的描述并不能替代詳細設計，但是也是不可缺少的，因為對任務的标題的字數等有一定要求，不能太啰嗦，是以在描述這裡可以盡量将目前任務的内容描述清楚，解決什麼問題，可能會碰到的技術問題，包括一些業務和程式流程，甚至是僞代碼。
雲效系統的描述是支援 Markdown 格式的，是以在表現形式上完全不用擔心，可以節約很多排版時間。
任務标簽
任務标簽也是重要的，對比 jira 這樣強大的自定義工作流來說，基于公有雲的雲效的項目體系相對比較簡單，狀态有限（私有雲版本的雲效也可以做比較複雜的定義），至少我們可以通過标簽來區分任務的屬性。另外目前也是在嘗試從産品需求到開發測試的全流程管理，是以用标簽可以來區分不同的種類。
任務标簽會顯示在：
- 疊代管理的任務項
- 任務管理的任務項
- 任務明細頁
我們建議在開發項目的時候用下面這些标簽，标簽在一個項目或者最好在一個公司的所有項目中，保持一緻，标簽不要顆粒度太小：
- 資料庫
- 控台
- server
- api
- h5
- app
任務的完成時間
任務的屬性中有一個任務時間，有如下建議：
- 一般情況下，不要小于兩小時，或者大于三天，這個和前面說的任務的分拆原則要一緻
- 一天按照六小時有效開發時間計算，如果是加班的話，可以增加三小時左右；時間不要排的太滿，因為一天之中總會有些開會、電子郵件回複、各種局部讨論等，時間排得太滿，會影響項目進度控制
拆分任務的顆粒度一緻性
分拆任務時候并不是顆粒度越小越好，在一個項目中，注意顆粒度的一緻性非常重要。
在一個純開發的項目裡，可以把任務分拆成都是需要 20-80 行代碼實作，按照一個函數一個類為最小顆粒度，也可以是按照源檔案，比如所有的基于一個源檔案的增加修改代碼，還可以按照産品功能點來拆分，或許一個功能點也會涉及到好幾個源檔案，這種拆法在有些項目中也會有好處。
相對來說，建議按照下面方式來拆分：
- 按照技術的詳細設計的功能劃分，基本基于單個檔案的修改，由一個人完成
- 更細顆粒度的，可以按照一個函數的拆分
淺談雲效中的開發任務拆分
任務顆粒度和合并代碼的複雜度
對于目前大部分項目基于版本代碼分支的管理來說，任務的顆粒度到一個源檔案，在代碼合并時候比較容易，相對沖突會比較少。
如果任務影響到幾個檔案，并且這幾個檔案同時也被别人編輯的話，我們是推薦使用 git ，并進行每日合并，這樣包括代碼評審的過程一并進行，這部分在 git flow 流程中進行詳細解釋。
任務的生命周期
任務從建立開始，有一個生命周期，并且任務在這個生命周期裡面，内容是可以修改的，有些屬性是可以變化的。這也是我們強烈推薦使用系統來進行任務管理的原因之一，要達到同樣的效果，可以減少大量的人工工作量。
任務的生命周期分為：
- 待處理
- 進行中
- 已完成
- 已取消
在看闆中，可以通過拖放來調整任務所處的生命周期，并且雲效工具支援對看闆進行配置。
看闆
看闆管理是一個從工業管理中移植過來的管理名詞：
來自于維基百科的定義：看闆管理，常作“Kanban管理”（來自日語“看闆”，カンバン，日語羅馬拼寫：Kanban），是豐田生産模式中的重要概念，指為了達到及時生産（JIT）方式控制現場生産流程的工具。及時生産方式中的拉式生産系統可以使資訊的流程縮短，并配合定量、固定裝貨容器等方式，而使生産過程中的物料流動順暢。
在看闆标示系統中常将塑膠或紙制成薄闆，将産品名稱及數量寫于其上，故此得名。及時生産方式的看闆在生産線上分為兩類：領取看闆和生産看闆，旨在傳達的資訊是：“何物，何時，生産多少數量，以何方式生産、搬運”。
靈活中的看闆管理大家都熟悉了，現在已經不需要小貼紙在白闆上了。非常建議使用本文中的看闆模式，雖然看闆模式從顯示資訊數量來說并不太有效率，但是對于産品經理、項目經理等來說，對于進度的控制的一目了然是最重要的。
圖表
圖表可以給團隊和管理層提供一個可視化工具，有助于定義過程中的障礙，并且讓每個人持續關注傳遞有價值的産品。
圖表的作用：
- 資訊傳遞可視化
- 真實反映（或者至少部分反映）團隊正在進行的過程
- 描述工作過程的情況
- 用于控制工作過程
- 任何人均可檢視
任務的評論功能
我們覺得這是現代項目管理軟體非常有特色一個地方，不管是 jira、github 以及雲效，都可以很容易的進行對任務的評論。有時候我們在詳細設計的時候，并不能真正的考慮周全，或者因為時間的關系，有些内容先簡單的寫一下。項目開發的組長、其他開發人員、在準備測試的測試同僚以及産品經理，都可以在一個任務下面進行評論，提出自己的問題。開發人員可以在這個小小的讨論區進行針對性的讨論。我們稱這樣的過程可以看到一些變化的過程，對于項目後期評審以及其他新加入項目組的同僚學習有很大的好處，你看到的不光是結果，還有所有相關人讨論的過程。
雲效的任務評論功能可以像微信等，用@符号在評論中指定需要額外看到的人，除了任務的建立者以外。并且通過郵件來發送到和這個任務相關的同僚。
任務拆分的注意事項
不要把任務拆分為：立項、詳細設計、開發、測試等這樣，這是項目的流程環節，而不是項目中的任務。
需求中的任務可以是任務的功能，有點像我們平時說的 feature list 中的項目。
開發中的任務就是技術的詳細設計的拆分，有些比如時序圖等文檔可以以附件形式存放。
每個任務有一個 ID，就像是 Issue number，這是一個唯一的 ID。
需求池管理
在靈活開發中，我們稱之為 Backlog，我們觀察到，大部分項目其實開發總是來不及在指定的版本完成的，而需求每天會因為各種情況層出不窮，是以需要一個需求池來存放這些不能馬上開發的需求。
需求池中的需求的走向：
- 因為緊急程度，成為目前版本中需要開發的需求；這樣的話，需要重新評估需求影響、開發、測試等細節，這也是會造成項目延誤的原因；
- 需求池中的需求最好的走向是成為之後上線版本的需求，這樣既不影響這個版本的開發，也可以讓各方面同僚對整個項目有更好的了解，比如為某些優化、某些分級在設計資料表、設計類結構等的時候留好足夠的餘地；
- 需求取消；
- 需求合并，不管是産品需求、功能優化等都可以在需求池中先列出來，然後産品經理、項目經理等經常檢查審視的話，就可以進行一些合并，抽象出一些共通的内容等，是以這也是我們一直覺得要有一個需求池的好處；
既然是需求池，是以其中的任務可以是比較簡單的，前面說過，在任務的标題這裡需要說明清楚，但是具體的詳細設計、關聯影響等可以暫且省略。