情境的劃分-Backlog切割的基本原則
明確的需求，踏實的結果
很多開發團隊有時最怕的不是前方路有多難，而是怕前面的方向不明確，這種不確定性，最直接的就是反映在待辦項目(Backlogs)中，尤其敏捷是一種迭代式的價值累積活動，最需要處理的便是因為市場、時程、人力等因素所引發的不確定性，因此如何有效地管理團隊和產品負責人(Product Owner)的預期，就顯得至關重要。
想當然，一個具有明確邊際的待辦項目就能夠讓開發團隊更有施力點，也能讓老闆在初期雛型不明時有一個判斷的依據，在衝刺計畫(Sprint Planning)中，我初步提到了描繪Backlog的基本說明方式，但對於一個尚未成熟的敏捷團隊而言，如何準備好的Backlogs就可以讓整個團隊絞盡腦汁。
水平切割 vs 垂直切割
理想的狀態中，在衝刺計畫的期間，一個成熟的敏捷團隊有能力依據現有的資源條件劃分情境的需求，並產出可行的執行計畫(Actionable Plan)和衝刺目標(Sprint Goal)。實際上，對於一個尚未成熟的團隊而言，過去的開發經驗在敏捷的實施上容易形成包袱，進一步影響準備待辦項目的粒度與方向。
在說明標題前，我想先定義水平切割與垂直切割這兩個名詞。
- 水平切割: 團隊會依據情境所涵蓋的的功能性對待辦項目做切割
在一般公司內部，常有功能性團隊(component team)的劃分，以軟體開發而言，我們常聽到前端、後端、資料庫、測試等團隊，因此當採納敏捷做為開發方式時，問題就來了。由各團隊抽出來的成員，其所組織的敏捷團隊一開始並不具備所謂跨職能團隊(cross-functional team)的意識，因此在切分需求時仍會依循過往功能性切割的方式處理待辦項目。
舉例來說，假設團隊目標是要實現一項報名查詢系統的待辦項目如下:
As a customer, I want to check if my name is listed on the website, so that I can certain my registration is successful.
在切分任務(tasks)時可能會出現以下項目，而這些項目分別由原本不同團隊的人各自負責，同時依附於同一個待辦項目。
- 使用者查詢介面
- 資料庫查詢
- 使用者操作測試
- 垂直切割: 團隊會考慮情境的邊際大小(Boundary)，將情境分割成讓用戶或利益關係人更容易理解的小情境，並迭代下去。
敏捷開發是一種迭代式增量的設計活動，因此待辦項目能否反映出商業價值(Business Value)決定了它被領取的優先權，每完成一個項目就能夠替衝刺目標帶來可展示的價值。這樣的情境切割方式對許多已經習慣依據功能單元做開發的人而言會變得不適應，卻是敏捷團隊走自我管理非常重要的一條路。
