為什么80%的碼農都做不了架構師？>>> ??

禪道項目管理軟件設計的需求有兩個字段來跟蹤它的變化，一個是需求的狀態字段，一個是需求的研發階段字段，下面來看下這兩個字段。

一、需求的狀態
需求狀態(status)字段，總共有四種狀態，分別是草稿(draft)、激活(active)、已變更(changed)和已關閉(closed)。對應為需求的流程操作共有：創建、變更、審核、關閉、激活，其狀態流轉圖如下：


二、需求的研發階段
需求還有一個階段(stage)字段，用來描述激活的需求在研發過程中所處的階段。目前總共有等待、已計劃、已立項、開發中、開發完畢、測試中、測試完畢、已驗收、已發布。
那么需求的研發階段是如何變化的呢？一種方案是通過編輯操作，來修改研發階段。但我們更提倡另外一種方案，就是在創建任務的時候，仔細設置任務的類型，比如開發，測試。禪道的程序會自動根據不同類型任務的變化來自動計算需求的研發階段，其規則如下：
如果需求沒有關聯到項目，也沒有關聯到計劃，則需求的研發階段是"等待"。
如果需求關聯到了計劃，還沒有關聯到項目中，則需求的研發階段是"已計劃"。
如果需求關聯到了項目中，但還沒有分解任務，則需求的研發階段是"已立項"。
如果需求關聯到了項目中，且進行了任務分解:
如果有一個開發任務進行中，并且所有的測試任務還沒有開始，需求的研發階段為“研發中”。
如果所有的開發任務已經完成，并且所有的測試任務還沒有開始，則為“研發完畢”。
如果有一個測試任務進行中，則視為“測試中”。
如果所有的測試任務已經結束，但還有一些開發任務沒有結束，則視為"測試中"。
如果所有的測試任務已經結束，并且所有的開發任務已經結束，則視為"測試完畢"。
"驗收"階段是需要產品經理手工來進行確認的。
如果需求關閉，且關閉原因是“已發布”， 則需求的研發階段是“已發布”。

三、需求的注意事項
1、禪道中需求的寫法
在禪道中，我們默認給大家提供了一個需求的模板：作為一名<某種類型的用戶>，我希望<達成某些目的>，這樣可以<開發的價值>。這個模板是借鑒自scrum開發里面的用戶故事(user story)的寫法。只不過我們使用了相對比較中性的概念。
在這個模板中，總共有三個元素：角色，要做的事情，價值或者原因。我們平時在寫需求的時候，往往會忽略角色和價值原因這兩個元素，只關注了要做的事情。其實這有很多的問題。不進行用戶角色的劃分，會影響對產品功能的設計和定位，從而導致產品往往是給一個用戶角色開發的，就是產品經理自己。:)而忽略開發的原因或者價值，會讓開發人員感到困惑。他們可能并不理解你這樣做的原因或者目的，不理解的需求實現起來自然會有問題。?

2、需求的INVEST原則
除了上面基本的模板之外，在撰寫用戶故事的時候，可以參考INVEST原則：(摘自http://duweizhong.blogbus.com/logs/112151436.html)
I dependent(獨立的):一個用戶故事對于另一個用戶故事應該是獨立的（盡可能的）。故事之間的依賴性使得增加了計劃編制，確立有限級，故事估計這些工作非常困難。通常，可以通過組合用戶故事或者分割用戶故事來減少依賴性。
N egotiable(便于溝通的):一個用戶故事是便于溝通的。一個故事的卡片是包含故事詳情的簡短描述。這些詳情是通過討論階段來完成的。一張還有很多詳情的卡片實際上減少了和客戶的會談。
V aluable(有價值的):每個故事必須對客戶具有價值（無論是用戶還是購買方）。一個讓用戶故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到一個用戶故事并不是一個契約而且可以進行協商的時候，他們將非常樂意寫下故事。
E stimable(可估計的):開發者需要去估計一個用戶故事以便確定有限級并對故事進行規劃。但是讓開發者難以估計故事的問題來自：對于領域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。
S mall(短小):一個好的故事應該在工作量上短小，描述具有代表性，而且不超過2-3人周的工作量。超過這個范圍的用戶故事，將會在劃分范圍和估計時出現很多錯誤。
T estable(可測試的) :一個用戶故事是可測試的來用于確認完成，記住，我們不開發不能測試的故事。如果你不能測試那么你永遠不知道你什么時候是完成了。一個不可測試的用戶故事例子：軟件應該是易于使用的。
一個編寫良好的用戶故事是敏捷開發的基礎。它們應該相互獨立，詳情應該便于開發者和用戶進行溝通，應該對用戶有價值，應該對于開發者來說盡可能的清晰以便進行估計，應該短小，通過預定義測試用例的使用確保它是可以測試的。

3、禪道里面的需求和原型圖、需求設計文檔的區別
傳統管理模式中，很多產品經理都在用原型圖軟件設計原型圖或者非常完整的需求設計文檔。設計完之后，交給設計人員進行頁面設計，然后由開發人員合并代碼。那么原型圖和用戶故事之間的關系和區別是什么呢？
和user story相比，原型圖或者需求設計文檔是一個整體，可以給人宏觀的把握。這是原型圖的優點。比較直觀。
它是一個整體，所以就沒有辦法進行分解。你不可能分解成，做頁面導航條，做頁面的中間部分等。
沒有分解，所以原型圖也就沒有辦法進行優先級的排序。比如頁面部分，有的很重要，有的不重要。但在原型圖里面是體現不出來優先級的。
沒有分解，自然也就無法進行跟蹤。你沒有辦法得知原型圖完成了多少。
過于死板，給設計人員和開發人員留下的發揮的空間太少，最后演變成被動執行。
需求設計文檔規定的比較細致，會讓產品經理陷入太多的細節，對整體的把握會減弱。
雖然相比較于用戶故事而言，傳統的原型圖或者需求設計文檔有一些不足，但在實際的開發過程中，二者可以相輔相成。禪道從1.2版本中，已經增加了文檔庫管理。可以將原型圖作為設計文檔，上傳到某一個產品相關的文檔庫中，和用戶故事相互配合，是一個最好的方案了。

轉載于:https://my.oschina.net/candou/blog/180138

總結

以上是生活随笔為你收集整理的NO.106 需求的状态、研发阶段及注意事项。的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。