敏捷開發使用者故事系列之九開發與跟進

這是使用者故事系列的第九篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）

產品負責人常常被描述成在計畫會前準備好使用者故事，在計畫會上講解並幫助開發團隊估算後就萬事大吉，只等月底接收「可工作軟體」的樣子，其實如果真的這樣，很容易出問題。

這是發生在迭代週期中間的常規活動，產品負責人會與團隊密切接觸（確切說如果能經常坐在一起更好），在每個故事開發的前夜或中間，將之前講解過的使用者故事更詳細地描述一番（有時候是在看到開發一半的半成品後做一些細化或更正）。

一般認為產品負責人在開發的中間來打擾開發組工作是不令人歡迎的行為，那這兩者之間到底區別何在呢？

在以後將會編寫的乙個《敏捷開發產品管理》系列中將會提到，產品負責人要做到「迭代期內無變更」，必須要做好長週期的研發管理，就是為每個版本每個迭代提前設定好目標。因此落實到具體迭代的時候，這個目標不是那麼容易發生變化的，但「如何更好地達到這個目標」，則可能經常在變化。

需求精化的過程，就是產品負責人幫助團隊更好地達到目標的過程。

「需求精化到底包含哪些活動？」確切說，只要把產品負責人和團隊放在一起，什麼事情都可能發生。

可能會對模糊的需求進行細化；可能會根據半成品做一些調整；可能給開發人員講解一下使用者背景……總之試一試，就知道了。

nec的迭代開發中甚至有乙個固定的時間（忘了是乙個月中的第10天還是第20天），產品負責人會幫助全組對下乙個迭代的故事進行一次提前通告，以幫助團隊**到以後發生的故事，從而略微地為未來做一些準備。這種準備既有提前了解業務的方面，也有潛在的在架構上為擴充套件做一些有限的準備。

若開發組的人數眾多，而產品負責人只有乙個，他的工作會相當繁忙，顧此失彼。

跟進人制度是在產品負責人團隊基礎上建立起來的。所謂產品負責人團隊，就是多個對產品了解的人組成乙個團隊，集體行使產品負責人的職責，典型的如軟體或嵌入式產品研發中的產品總監-產品經理-產品專員團隊，遊戲團隊中的主策劃-策劃組長-策劃團隊。

而跟進人，就是針對某個使用者故事，指定相應的產品負責人團隊的某個組員，來跟蹤故事的開發進展。

跟進人最大的好處，是可以在使用者故事一完成的時間點就進行評審、改進，防止了到最後卻發現故事實現的不好，一則返工浪費時間，二則影響了上線日期（只能下個迭代修改）。

跟進人制度和漸進式評審在網路遊戲的敏捷開發中非常普遍，原因是網遊的策劃人員比較多能完成跟進，而且對於「影響上線」比較敏感。

個人感覺跟進人制度和漸進式評審在普通研發中也應該推廣，無論如何如果使用者故事因為「只差一點，需要改進」而不能交付，要延期到下一迭代中，的確令人沮喪。

故事板的一般概念就不多說了，無外乎幾個欄目：待開發-開發中-待測試-測試中-待發布-發布之類的，大同小異。

乙個技巧則是「開發中」這一列一定要窄，含義是不要同時開發多個故事，最好結束幾個再開幾個。目的是不要所有故事開始了卻都沒有結束，導致最後無法交付。

這也使得跟進人不會太忙亂於多個故事，可以乙個乙個介紹，乙個乙個評審。

敏捷開發使用者故事系列之九 開發與跟進