前面的文章討論過估點與專案管理、風險控管的高度相關性。對於較年輕的工程師來說，估點是一個容易產生挫折感的活動。有關工程的實踐方式，有很多的參考資料，但對於估點，可搜尋到的資料多半是概念性的說明，較少介紹實踐的細節。今天我來分享一些，由我的團隊成員自行發展，並且落地於日常開發的估點實務經驗。

根據設計模式

這個方法主要針對用戶端開發。目前主流的設計模式大概是 MVC，MVP，MVVM 等，其中心思想都是將畫面，業務邏輯與模型分開，以達成解藕合的目的。以 MVVM 的架構來說，我們可以先將 User Story 分拆成 View，View Model， Model 三種不同類型的 Task。 如下圖，一個假想的畫面，就可以細折成不同的任務。拆 Task 可以幫助工程師思考，尋找問題。而點數是用來溝通的工具，例如，在下面的例子中，動畫設計需要 9 點，此時 PO 就可以思考，在 MVP 的精神下，動畫是否為高商業價值的特徵 (feature)。

根據正／負向流程

通常，產品專案會包含多個畫面，在每個單一畫面的估點完成後，就可以針對流使者流程進行下一步的估點。所謂正向流程，是指用戶不經歷錯誤到達操作目的的流程，其中可能包含畫面切換，非同步事件處理，資料傳遞等。分析後，若中間有較複雜的邏輯需要特別設計，就可以給予點數。通常正向流程不會產生太多額外的點數。

所謂負向流程，是指每個使用者交互或資料流動可能造成的錯誤。負向流程通常需要較多的關注，因為很多開發品質的爭論都與它相關。負向流程的 Refine ，最好有 QA 的加入，在規畫期中，多方就可以針對錯誤處理的原則，訊息，畫面等進行討論。比如當伺服器回傳錯誤碼時，該出現什麼畫面，使用者該回到什麼狀態，這些都可能造成額外的工程需求，都必須給予點數。忽略這個步驟的代價，就是在 Sprint 進行中，會需要大量的多方（ 用戶端、後端、 QA、設計師、PO) 進行討論，打亂開發步驟。

文件閱讀

將新技術導入開發，難免需要研究技術文件。這個活動的時間成本，有時容易被上層主管或專案經理忽略。在沒有健康的 Refinement 文化的團隊中，對看似簡單的任務，卻有很大的時間估計，通常就是工程師在技術掌握度低時的自保策略。我的建議是，需要讀書的時間，就給個點數，提升透明度。接下來，常被問到的問題是：我們怎麼知道需要多久時間才能讀完？　根據幾個團隊運行的經驗，我建議與技術文件閱讀相關的任數，先給予 1~2 天的點數，重點不在完成，而在「推進」。在站立會議中，必須很明確的回報進度，如果需要更多時間，就以 1 天為單位延展點數。一個運行了一陣子的團隊，對於非創新性的技術研究，最終會有一個估點平均值出現，可當作末來的基準參考值。

維護性質的任務

有負責維運性質工作的團隊成員曾經反應過，工作較難拆分，估點對他們來說是一件困擾的事情。顯然，估點在這個情境中成了維運團隊的內部張力。對於有類似困擾的朋友，我還是強調點數是溝通工具，目的是讓規畫資源的同仁可以保護團隊不會負載過重。不能拆分的任務就不要硬拆，給一個整體需要花費的時間平均值，相信不會很難。

剛入行時，我也沒有「拆分」、「估點」的概念，工作一下來，就是埋頭做，衝出來為止。但能力再強，最終都很容易讓自己成為團隊的瓶頸。改變自己習慣的結構會有點阻力，但出發就會到達終點。希望今天的文章能幫助到大家，明天見！