Scrum手法在waterfall軟體開發專案的應用

敏捷手法近年來不僅在軟體產品開發被大量的採用，也被非軟體開發的產業/工作所使用。但在採用waterfall手法的軟體開發專案是否有機會運用敏捷的手法進行軟體開發?所得到的答案大概都是否定的。但筆者試著提出不同的作法讓讀者試試，看能否改善 waterfall的致命傷：「越早產生的問題，越晚發現」。

• 與客戶一起作需求探索

Waterfall 的需求探索方式，大多由SA進行需求訪談後，進一步撰寫「需求規格書」、「系統分析報告」，認真想理解的客戶可能會反應：「太難懂」。因此在此階段SA會有加入雛型畫面的作法，由SA畫出未來的操作畫面，在需求訪談/確認時讓彼此的認知距離可以縮小。此作法雖有改善溝通的差異，但依然會遇到「系統交給客戶時，仍被改很大」的問題。原因在於：當SA 在說明畫面及操作動線時，客戶會被SA的思緒帶著走，若客戶沒有立即反思差異處、確認是否缺漏，就容易出現上述問題。

為避免後續系統製作所衍生的差異，如能請客戶繪製雛型畫面，將會迫使客戶思考未來的系統動線、操作畫面、資料內容處理等問題。對於需求認知的差異將會有效的縮小。

配合客戶對於工具的熟悉度，繪製方式可以是Word、PPT、Mockup繪圖工具、甚至手繪，只要快速省工，清楚表達即可。此舉主要是傳達客戶業務的資料處理、操作及流程需求，不在於畫面的美觀，一切以快速製作、減少浪費無謂工時投入為原則。

經客戶產出的雛型畫面，SA可與客戶討論內容、檢查一致性、是否有矛盾之處等。再以工具製作畫面雛型，與客戶確認後放入需求文件內。

• 程式開發階段採用Scrum手法

在Waterfall的程式開發階段，就專案外而言是最看不清楚且時間最長的階段，以至於此時專案經理對外(客戶與主管)的報告常遭批評像是作帳遊戲、作文比賽。

若要改善此階段的缺失，可採用Sprint的手法，規劃每2~4週為一期，PM/SA在每一期選出最重要的程式優先開發，並於週期結束時向外界展示此週期的實際開發結果，如此作法可以讓各階段的進度變得透明，且外界對進度掌握也更實際。詳細好處及作法說明如下：

1. 經由短期目標的達成，提高團隊士氣

使用Sprint的手法將程式開發細切成一個個的週期，每一個週期都有開發團隊追求的短期具體目標，經由一次次的達成及檢討改進工作方法，讓團隊清楚知道努力的進度及感受短期目標「達標」的成就，因而提高團隊士氣。

2. 團隊的問題可以即時顯現與解決

筆者曾聽聞專案成員為躲避專案會議進度的追蹤，常回報預計完成日期皆在專案會議日的隔日，或乾脆在專案會議日請假。

對此，團隊可採用Daily stand-up meeting解決上述問題，且在會議中反應的問題，專案經理採用僕人式領導的方式，協助問題的處理，讓專案開發的潛在問題可以提早發現與解決，取代原waterfall每週開一次的內部專案會議，避免問題總有幾日的時間差才顯現。

3. 即時掌握估算與實際進度的差異

敏捷的開發方式的估算與Waterfall不同，如果團隊不熟悉敏捷中集體估算的方式，也可使用在現有由PM/SA進行估算的形式。在每一次Sprint結束進行的反省與檢討會議中，可以比較預計與實際進度的差異，因而得知估算的偏差，進行推估進度的差異分析。就算有會造成專案延遲的過大差異也可提早因應。

4. 清楚掌握進度

在每一個Sprint結束需要進行展示。這個展示可以在與客戶的專案會議中進行，也可以在對主管Report時進行。為了這個展示，團隊都需讓程式達到可驗收/使用的狀態，因此程式的複測會提前，程式的品質會提升。

對於客戶而言，不需要了解所謂的「功能點」、「複雜度」、「程式開發天數」等估算方式，從團隊中所展示的功能中，將已完成展示功能除以全部應開發功能，簡單計算即可大約得知程式開發的進度。

就專案經理而言，在這個階段進行專案報告，如能佐以功能展示，讓進度報告更具說服力，達到「可用的程式為進度量測的唯一標準」原則。

5. 提前得知產出與需求的差異

程式開發每一週期對客戶的展示中，客戶極有可能會回饋「需求變更」、「需求誤解」、「設計錯誤」… 等不同類型的問題，以正面思考的角度而言，這些問題沒有在展示時提出，也會在客戶驗收測試時提出，相較於後者，若能在程式階段提出，團隊有較多的時間處理問題，對於團隊的壓力也較小。

 
在waterfall的開發方式中，大都要求依客戶需求開發出「如期」、「如質」、「如預算」的產品供客戶使用。在合約仍是「固定期間」、「固定規格」、「固定價格」的情況下，專案難以捷敏原則「擁抱需求變更」來執行，但在專案過程中局部採用敏捷的手法，或許可改善waterfall開發方式的先天問題。