如何透過 TEAM 解決軟體開發專案的不確定性？
我們公司「意門科技」是家敏捷式開發的系統開發商。我們希望透過「遠距」的工作模式，能替成員及客戶都「創造自由」。過去做過線上遊戲、雲端監控，近兩年則著重 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 線上課程，或到我們官網約時間進一步了解!
