深入淺出軟體開發----（四）計劃反覆式開發法

標籤：

（多年前的筆記，從ITEYE遷移過來的） 

　　在擷取到使用者的需求並編寫成User Stories，並且通過Playing Poker Game 估算出每一個User Story開發所需的時間後。我們得到了要開發所有的User Stories需要的時間，大多數情況都是客戶對新軟體的要求都相當的迫切。很少有項目是不受時間的制約的。而成功的軟體開發就是在規定的時間，規定的預算開發出來使用者需要的軟體。所以我們需要根據我們的可用時間來進行軟體開發。

 

   計算實際可用的開發時間（以人天為單位）：

 

       每一個項目都會有一個明確的截至時間，客戶需要在那個時候得到他們需要的東西。所以我們的理論上可用時間一般是固定的，就是從項目開始到客戶規定的截至時間。但是我們的開發時間並沒有這麼多，其中包括了周末、節假日、員工度假等等，在計算是都要考慮進入，這樣每一個月的工作天數就是20。另外我們還要考慮開發人員的工作效率，還有就是員工請假、生病等情況，我們可以用開發速率來代表（其值應該小於一）0.7或0.8是一個不錯的起點。等我們進行了一次反覆式開發法後我們根據實際的工作情況再調整該值。

 

       我們用下邊的公式來計算實際可用的開發時間：

 

       實際可用的開發時間 =    可用自然月數 × 20 × 開發人數 × 開發速率

 

 

   讓客戶挑選要開發的User Sotries並安排優先順序：

 

      在計算出實際可用的開發時間後，我們就可安排我們在可用時間內開發的User Stories了。等等，不是我們而是客戶決定要開發哪些User Stories。只有客戶才真正知道他們需要什麼，不需要什麼。通常情況下客戶都會要求的比實際需要的多，這時候我們就要協助使用者跳選他們真正需要的，同時我們也能在可用時間內開發的User Stories。

 

      根據優先順序和實際可用時間使用者挑選出了必須要實現的User Stories並排序，這些User Stories將做為Milestone 1.0中要開發的特性。在這個過程中我們需要告訴客戶那些沒有被挑出來的User Stories 並不是被捨棄掉，而是延遲到Milestone2.0或Milestone3.0。

 

       Milestone1.0中應該只包含Baseline Functionality,如果少了這些功能軟體就無法提供它的功能，這些功能是軟體的最小功能集。

 

 

   將選出的User Stories 分到各個反覆式開發法中（同樣根據優先順序）：

 

        在得到Milestone1.0的所有User Stories後，我們需要它們分到幾個迭代迴圈中。迭代迴圈不宜過長，宜採用較短的迭代。較短的迭代周期有助於發現和應對變化和沒有預期的時間，可以及時的調整。同時較短的迭代周期也容易更早的從客戶那裡得到反饋，更容易調整計劃。

 

        但是太短話，又因為頻繁的計劃、發布反而不利於開發。同時，迭代周期的選擇也和開發人員的經驗，項目的特點有關。一般情況下，一個自然月即20個工作日作為一個迭代周期是比較合適的。

 

        根據每次迭代可以完成的工作量將Milestone1.0 中的User Stories分到各個迭代周期中。優先順序高的User Stories應該最先開發。這樣我們就得到了幾個反覆式開發法周期。

 

 

 

   使用Big Board監控開發的過程：

 

         在得到第一個反覆式開發法後，我們就可以進行第一次的反覆式開發法了。別急，我們還需要一個工具來監控我們的工作效率和實際工作量。這就是Big Board。沒有找到的Big Board的圖片(會在以後的文章中介紹)。       

 

 

   需要注意的問題：

 

         1.在處理要開發什麼，不開發什麼，以什麼順序開發，都是由客戶決定的。作為開發人員只能輔助客戶。

 

         2.Team Dev的人員不是越多越好，根據團隊成員的情況和項目特點，當人員達到一定數目時再新增人員不但不會提升開發速度反而會降低團隊的生產力。這是由於人員越多交流溝通和管理的開銷越大。

 

        3.不要加班，加班只會使開發人員感到疲憊並降低生產力，而且影響開發人員的生活（一些極特殊的情況除外，如：產品發布前）。

 

       4.與客戶保持良好的溝通，注意溝通方式。最重要的要“Be honest with customer”.

深入淺出軟體開發----（四）計劃反覆式開發法