敏捷，這個詞彙越來越熱，越來越多的團隊“敏捷”起來，但隨著敏捷的應用到不同的場景，很多之前駕輕就熟的實踐，就顯現出諸多不適。

在敏捷開發中，最常用來管理需求的方法是User Story。Story除了捕獲需求之外，還有一個很重要的角色，就是劃分任務，這也符合人們解決問題時通常分而治之的習慣。Story劃分有一個重要的原則：INVEST，其中的S，是Small。Story太大，人們是無法看清的，無法估計，即便可以開發，程序員也要花費大量的精力瞭解這個Story。

我們在公司內部做項目時，User Story屢試不爽。所以，當我們扮演諮詢師時，我們自然會引導客戶以同樣的方式管理需求。根據我們劃分Story的理念，我們要找一個端到端的交互，結果，我們發現，無論我們怎麼劃分Story，每個Story都無法滿足Small的要求，隨便一個Story就會有幾十個點。

本著分而治之的理念，我們會把這個Story劃分為一個個Task。直到每個Task都小到可以開發的程度。在當時的環境下，這種做法得到了大家的接受。但是，這種做法是有悖於我們對Story的理解，而且從實施的效果上來看，經常出現很長時間無法完成一個Story，所以，項目組內的測試人員無事可做。問題究竟出在哪呢？

我們使用User Story處理的系統，大部分是存在大量交互的系統。而我們客戶是一個通信系統，按照交互來看，可能並不多，但每次交互內部都要進行一大堆處理，這也是為什麼Story都很大的原因。

對於這樣的系統，使用我們理解的Story是不是合適，就成了一個問題。不過，換個思路，我們就會發現，在這個情況下，我們真正需要的是分解問題，分解到可以由程序員可以進行開發，就像我們前面提到的Task。至於到底分解的結果還叫不叫Story就不那麼重要了。當然，隨著分解的結果的改變，還會引發很多問題，比如，怎樣衡量工作是否完成，項目組內的測試人員應該做怎樣的工作等等。

這只是一個例子。