如何透過 TEAM 解決軟體開發專案的不確定性?

Shun-Yun Hu
May 30 · 6 min read
Christina Morillo (pixabay)

我們公司「意門科技」是家敏捷式開發的系統開發商。我們希望透過「遠距」的工作模式,能替成員及客戶都「創造自由」。過去做過線上遊戲、雲端監控,近兩年則著重 IT 系統及區塊鏈的開發。

除了遠距,我們從 Day 1 開始就用 Scrum 做敏捷開發,週期是兩週一次的 review/planning。但經歷過幾次內部及外部開發案後,發現以「規格為主」(spec-based) 的開發模式下要「如時上線」,挑戰實在很大,主要是通常會遇到三種困難:

1. 規格不清 (unclear spec)

通常提需求者,對自己要甚麼只有一個方向性的概念,而落實到執行,需把想法轉成企劃或規格文件。但如何把想法及需求轉成文件就是一門大學問! 即使經驗豐富的企劃者,也常無法預料所有可能發生的風險,或所有待做的重要規格。而有時一些關鍵規格,甚至是在實作過程中才能被發現。

2. 溝通障礙 (communication gap)

需求轉成規格或企劃書、到透過專案經理規劃進度、開發者實作,這「需求 → 企劃 → 管理 → 實作」四階層,每一層都可能有誤解。甚麼時候才會發現呢?通常是和客戶展示進度,做回顧時才會得知,而這可能是以周、雙周、甚至月為單位。落差因此會累積,也要到進度會議時才會發現並修正。

3. 規格變更 (changing spec)

事事無常,軟體開發案特別如此。長專案、創新的專案更是如此。但這是自然的:開發後才發現某個技術難點,或人員有狀況,也可能外部環境有所改變,或組織的優先順序有調整。總之,軟體上線前 (乃至上線後) 的規格變更 ,都是很正常的,越是適應動態的外在環境越是如此。

但目前普遍的「規格為主」開發模式,遇到這類問題,通常就是開發者和需求者都很挫折。開發者覺得:「你說的不就是這樣嗎?」或「原本說的怎麼又改了?」而需求者則害怕「到底是否能順利如期完成?」「目前到底進行如何?」或「怎麼做成這個樣子?」

需求者害怕「做的」不是「要的」、專案延遲,開發者則害怕一直加功能、改規格。所以有經驗的雙方,開案前都會先進行耗時的「規格談判」,雙方都想透過把規格越明確化、越好,對自己「越有保障」。

但結果常是事與願違,因為上述的三個問題是軟體專案本質上會發生的。除非做的東西已經是過去做過很熟悉的東西。但軟體有趣的就在:做過的直接重用就好了,不用再做,通常要做的都是新的東西。

怎麼辦呢?如何能在有限的時間及預算中,完成專案並順利上線?其實是所有軟體開發的挑戰。

我們經過多年慘痛的摸索,及許多失敗經驗後,得出一個看法:要把「無常」視為「正常」,從根本改變開發的模式及想法。我們現在的模式可稱為 Time-limited Extreme Agile Method (TEAM),或「有時間限制的極端敏捷開發」。雖不能說完美,但在資源有限下完成可上線的專案,有一定成效。

TEAM 的根本精神及原理在:善用 80/20 法則。也就是所有事情的成效/結果,大部分只來自於少數的原因這個「自然現象」。

80/20 法則可說是個自然定律,不論生活工作、乃至各種行為活動,都可觀察到它。80%的聯繫來自20%的朋友、80% 的營收來自20%的客戶、80% 的成效來自 20% 的力氣、80% 的衝突來自20% 的問題。80/20 只是一般法則。某些情況下更為極端,可能是 85/15, 90/10, 甚至 95/1。

那如何應用呢? 我們現在的做法是:

1. 用「優先名單」(Prioritized List) 而非「待做名單」(To-Do List) 來開發

開案前,我們還是有「規格」。但基本上只是一個簡易的清單 (當然,規劃到多詳細要視專案、資源調整)。但好處是,不必鉅細靡遺的規畫所有細節,開案可以較快開始,避開耗時的「規格談判」。但此清單我們會請客戶先用優先順序排序,並先釐清專案整體的「主要流程」(main flow) 為何。

2. 每日交付、每日同步

這是我們「極端敏捷」(extreme agile) 的部分。一般敏捷開發都設 1–2 周為一個周期,其中包括「計畫、實作、單元測試、整合測試、交付回顧」等階段。但客戶通常是一個週期結束時才來看成果。我們盡量鼓勵、甚至要求客戶「每日」參加「同步會議」(daily sync) ,看到、操作、並回饋昨天的開發進度。

這有兩個目的:1) 每天都和客戶確認是否符合需求? 避免前面提及的「溝通障礙」。就算有誤解,最多只會錯一天,每天的「同步會議」 被反應及修正了。2) 重新確認目前「最關鍵項目」為何?也就是落實 80/20 的概念,將每天的力氣,都用在「目前」客戶認為最重要的項目。

3. 保留一天做「緩衝」

我們一周只有四天的標準工作日。第五天原則上休息,單純做「交付」(delivery sync),驗收本周成果。原因有二:1) 開發是腦力、知識密集工作,一直工作、超時工作,不健康也無效益,團隊需要休息,也需要充電。2) 任何不預期的意外或「最後一秒」問題,還有時間可以做調整,預先設計「緩衝時間」。

這個模式,自然需要客戶的理解和配合,因為和目前主流的開發模式相當不同。但我們多次執行下來已發現一些特殊好處,特別是在上述的三個問題上:

1. 規格不清

因為是每天重新確認規格的優先順序及「當日目標」,規格在做的過程中就會越來越明確。隱藏的潛性需求也會逐步發現,但立刻就可納入開發目標中。

2. 溝通障礙

理解或溝通的落差,最多偏離一天就會被發現、反應、修正。

3. 規格變更

完全沒問題! 因為每天開始時,我們都期待可能有新的目標要做,甚至新的方向! 抱著面對「無常」來進行專案。

其他還有一些意料外的好處,例如:客戶因每天都能看到進度,會較了解專案實際進度,避免雙方有不切實際的期待。而開發的能量基本上會用在刀口上,需求和實際開發通常是能緊密配合的。

我們實際的成效是:在製作透過區塊鏈投票的專案上,第一周就完成所有主要功能,而從 web 轉成手機版,也僅花兩周 (且是在沒有經驗的情況下)。另個我們做的「常仁基金」(一款加密幣指數型基金),也僅用 3 個月、兩位工程師,就完成第一個可測試的 alpha 版,也大致如期的在第 10 個月即上線。

若您對這套 TEAM 模式有進一步興趣了解,歡迎來參加我們的 Agile Bootcamp 線上課程,或到我們官網約時間進一步了解!

Shun-Yun Hu

Written by

Founder of Joint Commonwealth Inc. (JCF), Co-founder of Imonology Inc. Someone who enjoys to observe, to think, and to create…