[[186936]]

再論需求

在前面幾篇文章出去后，遇到不少同學問，到底我的團隊是否合適走Scrum模式開發呢?其實我個人的建議首先是看需求管理的主導權是否在團隊手里，也就是產品經理是否是緊密和團隊在一起，并且有能力拒絕不合時宜的需求，特別是來自領導、市場的壓力而來的倒排的需求。但是我們更多遇到的情況是，產品總是游離在團隊之外，總是以項目/市場的目的要挾開發一定要在什么時間點做到什么。同時更多的業務型公司的產品對于技術的理解總是不到位，或者說沒有任何技術功底，從畢業開始就在做產品的事，所以無法融合到開發團隊中。如果是這種情況，是否走Scrum需要商榷。

需求的來源

通常來講，需求來源于產品經理，但是不要過于局限。從掌控角度看，產品只需要掌握大的產品特性方向以及一個迭代的關鍵需求要點就可，其它的需求細節應該交由團隊成員去發揮，讓所有人真正有對產品的歸屬感。特別是對于開發而言，他們有某些“需求”是心理性的，或者是“癖好”的如代碼的重構或者某些細節的雕琢，這些不要一味的否定，而是做適當的控制排下優先級就可。很多時候一個產品的優勢往往來源于整個團隊的“腦洞大開”，當然也不是隨意引入這些需求，適當很重要。不能沒有，又不能過度。好像說的有點啰嗦。 ：)

工作量的評估

在Planning game中，重要的一個環節就是對每一個工作項做工作量的評估，理論的做法是使用Planning game紙牌，用斐波那契數列數值(1 1 2 3 5 8 13 …)來給每個工作項做出個人的獨立估算，然后一起亮牌，如果差異比較大，則由大數值和小數值的人來說明各自的理由，然后再出牌估算。如此多輪***得出每個工作項的工作量。一般理論的建議是不要將一個做工作項估算超過2天，如果超過則需要繼續分解。實踐中，這個卻是不難么容易操作。原因主要有幾個方面：

• 因為對于新產品的理解或新技術等經驗不足，對于工作項的分拆比較難，造成工作量估算比較大，***難以操作
• 團隊成員的工作經驗不足特別是團隊成員本身水平不一致的團隊，估計離實際偏離很大，***做planning game 費時費力，執行困難。

我們也實踐過程也遇到了這些問題，***大家對于planning game的估算環節總是意見頗多，為了后續真的確保能完成，總是人為的往估算中注入水分，從而每個任務都是需要很多時間哪怕再小的任務。綜合后一個迭代能做的事情有限。多次惡性循環后，有些管理者自然就認為Scrum模式是開發團隊的擋箭牌，從而取消了Scrum的開發模式回歸傳統填鴨式的倒排項目管理了。

對此，我們團隊做了一些調整：

• 首先從工作項的分解交給開發的Team Leader負責，他的經驗比較足偏離性小，并在planning game時和大家說明拆解的理由，如果還是不夠細則可以繼續拆解。
• 不再真對某一項任務進行評估，而是對所有任務做整體評估，只要整體團隊認為可以實現這個需求范圍就可。同時產品需要掌控每個任務的優先級，便于后期砍需求。
• 還有就是對于技術難點，提前要求開發的Team Leader或者架構師做好PoC (Proof of Concept)，提前踩踩坑。
• 對于實現上的重點問題做些設計，并對團隊成員宣講，讓開發和測試都理解。這個不用局限是開發的Team Leader或者架構師，只要做好review就可。具體如何做設計我下面講。

敏捷中如何做設計

這是個很容易遇到的問題，有些團隊做敏捷(無論是否是Scrum)的一個目的就是為了避免去寫繁重的設計文檔。而有些傳統開發的團隊，則仍然在做概要設計，然后詳細設計，有時有又有UI設計等等。我們的做法呢?Case by case!!!

首先我在前面blog講過，在Backlog的review的時候，需要多方一起確定是否需要做需求/系統分析(涵蓋什么內容，我后面講)以及架構設計和實現設計(或許和概要設計/詳細設計只是換一個名字)

需求分析 / 系統設計

這個主要是針對新feature的情況，目的是分析用戶故事場景，分析系統對外接口的變化等，主要包含一下內容但是不局限：

• 原始需求列表，盡可能保留原始的需求描述，以便于讀者更好的去理解。但是如果是技術人給的需求，這個就要小心了，通常他們都是根據自己的理解加工過的需求，從而掩蓋了需求的本質，而是直接給了你方案性的需求。這些在技術人建的溝通一定要小心這個。
• 需求分析整理。這個是針對原始的需求做出的整理、歸類、抽像等。
• 用戶故事User Story的描述，或者是use case的描述，取決設計者的偏好。這里面需要定位出Actors，并畫出不同場景的序列圖
• 領域模型分析， 根據新feature的變化，對領域模型進行修正和描述。如何畫好一個清洗的領域模型，這個是個大課題，容以后再表
• 系統的Layer 2的接口分析。Layer 2的意思是系統間的接口，這個是我的老東家Rick同學教的，一直用到現在。
• 系統的Layer 3的模塊分析。Layer 3通常指這個系統內的模塊組成關系。這個可以由技術產品給，也可以交給架構師做，取決于團隊的情況

架構設計/實現設計

這個通常由架構師負責，描述整體系統的架構。這塊我就不細講了。交由江南白衣去講吧，他整理一個架構設計的要點指南，就看他什么時候出這篇文章了。后面有他的微信公眾號。

實現設計

這個針對實現過程的每個要點的詳細描述，一般我們是在實現中發現開發中有疑惑的地方，或者實現起來比較別扭的時候，就交由開發Leader來出這個設計，并落到WIKI上。這個可能涵蓋的內容有：

• 具體算法
• 具體的參數配置
• 實現的類、接口等關系

總結

不要為了設計而設計，也不要一切都不設計。這個需要產品和開發leader一起把握。切實根據需要來做設計。

【本文是51CTO專欄作者“VIPDOCKER-了哥 ”的原創文章，如需轉載請通過51CTO與作者聯系】

戳這里，看該作者更多好文