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

Shun-Yun Hu
May 30, 2019 · 6 min read
Image for post
Image for post
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 線上課程,或到我們官網約時間進一步了解!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store