http://www.danielteng.com/2013/10/03/optional-scope-thinking/
過去的半年多一直在一個客戶那裏輔導PO和團隊。相對於那種比較傳統的“國際”“大”公司客戶，這個客戶的接受程度以及對於市場的響應程度要高很多。可是儘管客戶公司內不同團隊的業務不同，有的是面向大衆的網站、手機App，有的是主要針對公司後臺和運營客戶，大家的思維模式十分類似。具體表現是做一件事情，總想一下子全部做完、做全。但是我認爲這樣的做法是很危險而且不負責任的。導致的結果是加班多、質量降低、士氣降低。
爲了讓大家更清楚的理解問題，先從一個具體的事例開始。兩個月前，我聽說以前輔導過的一個團隊在那一段時間總是週末加班，想到一定是有交付壓力，另外我也想看一下如何能夠幫到團隊，所以就和該團隊的PO和ScrumMaster坐在了一起。爲了近期的業務目標，團隊正在忙於一個合同變更審批的功能，其實做的事情就是在客戶要求合同變更的時候，實現自動的審批流程，讓相關人等能夠看到變更的內容以及能夠自動上線。涉及的修改還是比較多，而且由於有業務目標的壓力，團隊“必須”要全部完成。
問題搞明白後，接下來看看團隊的實現方案，大吃一驚，儘管已經做過MVP了，團隊還是決定要一個工作流引擎，而且要實現一個類似於版本管理系統的內容比較系統（工程師總是喜歡引擎、框架、系統）。設想一下，工作流引擎光測試用例就會有很多種，如果像Git那樣的版本管理實現和測試起來也不會特別快。但是這麼多功能對於我們的業務來說需要麼？團隊是否有可能在幾個sprint（每個sprint一個星期）內完成所有功能麼？我們設想的這個方案能夠解決業務目標的所有問題麼？怎樣能讓我們的PO、客戶以及團隊感知到我們正在逐步解決問題而不是一口吃一個胖子？
有了大的業務目標，因此必須要把這個大的目標切分成幾天可以完成的小目標就變得十分必要。下面是我們花了幾分鐘大體列出來的幾天可以實現的目標。
- 合同變更直接上線（無任何審批流程；顯示所有最新內容）
- 合同修改後只有一個審批節點，變更自動上線
- 只針對一個字段（比如合同延期）顯示變更信息 （其實從業務角度來講，90%的合同變更只涉及三五個字段）
- 實現兩個審批節點、無分支的變更自動上線 （審批節點太多以及分支太多本身可能說明公司的業務流程出現了問題，太過於官僚）
- 針對第二個字段顯示變更信息
- 如果實在有必要，根據一個字段（比如只針對於合同延期），實現工作流審批分支跳轉 （當然也有可能不需要事先工作流分支）
這樣看下來，每個功能只要幾天就能完成，而且如果時間緊，我們甚至可以選擇只實現1、2，讓客戶先用着，然後跟客戶說下個星期就能實現3（也就是顯示合同變更內容）。這樣看來加班也變得沒有必要了。
另外還有一個例子，另外一個功能，是把很多數據從數據倉庫中讀出，然後顯示成表格，最後在顯示成線圖。工作量大約是四個星期。而且裏面有一些技術難點，比如實現數據推送、大量數據的持久化以及複雜的圖表。整個一個需求的工作量是四個星期，肯定很水，如何能讓進度變得可見，而不是一個黑洞。最終大的業務目標被切分成如下的小目標。
- 用表格方式展示一個字段（比如是訪問數），數據是hard code的 -> 主要目的是證明能夠用表格方式顯示數據
- 能把Hard code點評數，按照點的方式，暫時不用曲線的方式去展示1天的數據 -> 主要是證明能夠把數據展示成圖
- 能把Hard code點評數，按照點的方式，暫時不用曲線的方式去展示2天到7天的數據 -> 主要是證明能夠把展示多個點，但是不要求連成線
- 能從數據庫中讀取點評數，並展示成表格和圖表 -> 這時候數據已經不是Hard code的，而是動態的了
- 能從數據倉庫中讀取這個字段的內容，導入到數據庫，並展示成表格和圖表 -> 打穿了從數據倉庫到圖標的通路，系統基本框架已經成型
- 能把點圖變成線圖
- 把一個字段擴充成兩個字段，能夠展示表格
- 把一個字段擴充成兩個字段，能夠根據表格展示點圖
- 兩個字段用不同顏色展示線圖
- 把7天擴充到30天，根據時間段不同顯示不同的數據
- 數據持久化技術方案確定
- 大數據量推送、同步方案確定
說到這裏，大家可能想到了，這個blog其實是關於需求切分的。我想強調的是，所謂需求切分其實更重要的是業務目標的切分。目標切分是敏捷團隊和個人所必須具有的核心技能之一。幾個月前我在微博上分享過，我們四個pair在5個小時內有過130次提交代碼，很多人不理解，覺得是不是修改一個字母就提交了。其實背後隱含了絕大多數程序員缺乏切分目標、切分需求的能力。如何把一個比較大的目標變成一系列SMART(Specific, Measurable, Achievable, Relevant, Time)的小目標，從而從一開始就知道我們在哪裏、我們的方向是哪裏、我們的速度如何。。。對於業務成功十分關鍵。推薦一篇XP創始人Kent
Beck的文章Optional Scope Contract。
更深一步，有可能我們一開始的方向是錯的，我們解決的是錯誤的問題，我們也就沒有必要把問題完全解決，關鍵是做完一部分，扔到客戶那裏，然後跟着客戶的反饋走。
突然想到敏捷宣言第四條其實很有道理：“相應變化 高於 遵循計劃”。
