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

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

  • 與客戶一起作需求探索

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. 清楚掌握進度

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

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

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

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

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

 

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

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *