JIRA允許為每個項目設置優(yōu)先級，比如Blocker、Critical、Major、Minor、Trivial，標識每個任務的重要程度，如圖4所示。

    圖4 JIRA支持優(yōu)先級排序

    如圖5所示，如果任務定義了優(yōu)先級，那么在每個人的桌面上，任務會自動排列。這點對于多任務的項目尤其重要。

    圖5 JIRA中的任務會自動排序

    預見到需求迭代的被動性后，Diapers項目團隊在Diapers項目上全面啟動了JIRA進行項目管理，將需求分解細化后進入JIRA，排定任務的優(yōu)先級并指定到人，確定每次小版本發(fā)布的需求編號，不定期的發(fā)布小版本。結合SVN等版本控制工具，Diapers項目團隊能夠將功能需求迭代的粒度控制到最小，項目逐步推進，客戶對項目的進度有充分的了解，項目經理也能夠準確把握項目的進度，團隊中充滿了樂觀的情緒。

    安撫團隊成員的情緒

    工程師對于冗長的需求說明書有天生的恐懼感，開發(fā)周期拉得太長，似乎需求迭代無窮無盡。如果需求的迭代周期不在可控范圍之內，項目的發(fā)布邊界模糊不清，項目發(fā)布的日期自然也遙遙無期。由此帶來的結果是團隊每天緊趕慢趕的跟蹤需求迭代，消化處理新的需求，工作氣氛也是高度緊張。每一次需求迭代，都會進一步增加這種緊張情緒。

    項目經理應該把握項目的進展情況以及客戶的真實需求，也要知悉客戶的需求底線，更要在必要的時候安撫團隊成員的情緒。

    當原始需求第一次被抽象出來的時候，團隊的第一要務是快速構建原型系統(tǒng)作為和客戶溝通的主要媒介和依據(jù)，項目經理應該引導團隊把握這一點。

    之后的每一次需求迭代，項目經理要將需求分解細化，控制需求的粒度，并且確定優(yōu)先級，消除團隊成員的焦急情緒，按照先后順序逐步的處理每一個粒度的需求，以發(fā)布每階段的小版本為階段性的目標。

    在這個過程中，需求細化到最小粒度，還需要注意到每個需求之間的關聯(lián)關系，關聯(lián)的需求要優(yōu)先集中處理，是降低每個小版本之間的耦合度。

    Diapers項目自從將需求細化成一個個任務并進入JIRA控制之后，軟件工程師每天的只需要按照順序處理JIRA上面的任務，并及時將代碼以最小粒度的形式通過SVN工具提交；測試人員根據(jù)發(fā)布邊界所指定的版本號從SVN下載最新代碼測試，確認并關閉相應的任務；項目經理引導團隊成員遵循規(guī)范的需求迭代程序，有條不紊的處理需求，輕松應對需求迭代。