最后則是評估需求的優(yōu)先級，綜合分析以上三個要素，來最后給需求評估優(yōu)先級。一般情況下核心需求的優(yōu)先級往往是最高的，不過有時候由于技術風險過大，或者開發(fā)耗時過長，有些核心需求的優(yōu)先級會被降低。在優(yōu)先級評估完畢后，開發(fā)團隊會確定第一輪的迭代要完成的需求。如果是使用 Scrum 敏捷開發(fā)有一段時間的話，開發(fā)團隊是知道自己在一個迭代周期能夠完成多少時間點的任務的，也就是團隊的速率。一些高優(yōu)先級的需求由于時間點太大而不能放入本次迭代，而使用其他優(yōu)先級相對較低但時間點小的需求代替的情況也會時常發(fā)生。
 
4.讓欲望在掌握之中
 
在完成需求評估后，開發(fā)團隊就會進入開發(fā)階段。在 Scrum 團隊中，需要對開發(fā)中的需求進行管理。常用的方法是在一塊木板或是一面墻上列出正在開發(fā)的，開發(fā)完成的，正在測試的和完成了的需求。這塊木板或強被稱為看板。每個人都可以在看板上清晰的看到團隊現在的開發(fā)狀況。我的團隊沒有使用實體的看板，而是使用 JIRA 這個軟件提供的電子看板。
 
在開發(fā)過程中，需求的變更是必然會發(fā)生的。正常情況下，如果一輪迭代已經開始了，Scrum 團隊是不會中途停止的。新的需求必須在下一輪迭代中才能加入，這樣可以保證開發(fā)的正常秩序。為此，我們在看板最前方新加了一項：待開發(fā)。我們會將變更的而且有限級高的需求放在這一列，以保證在下一輪迭代中實現這些需求。
 
大部分公司都會要求寫需求文檔，這樣對所有需求歸類，并且可以方便以后的查閱。但是這些需求文檔有時候書寫的并不是很規(guī)范，或是很全面。導致查閱的時候很難找到我們需要的內容而且在需求，有時候甚至是寫完后根本無人去理會。而且，在需求變更時需要進行維護，耗費人力，文檔在多次修改后導致內容很亂，或是前后需求矛盾的情況時有發(fā)生。
 
現在一個新的需求管理方法，需求的實例化，可以解決這些問題。需求的實例化是不再編寫和維護需求文檔，而是直接使用高質量的測試用例作為需求文檔。通過測試用例可以很清楚的看到產品的需求內容，而且，在需求變更時，必然會產生新的測試用例，而不必費力去維護。在清晰的表現需求的同時，減少了維護需求文檔的人力。
 
VIA：人人都是產品經理

 3/3   首頁 上一頁 1 2 3