採用敏捷方法的軟體開發合約該怎麼簽？

{|ihower.idv.tw| blog } | 採用敏捷方法的軟體開發合約該怎麼簽？

一 般在台灣簽軟體開發合約，最常見的就是固定價格、固定規模型的合約（最晚何時要交出符合這些規格的軟體和文件），但是碰到的問題就是兩造雙方都覺得需求定 不清楚，而陷入對立的情形。接案的希望少做、出錢的希望多要一點，所以往往都在討價還價中試圖在期限中完成。如果實作後發現一開始的估計太保守、開發中途 客戶又不斷加規格、需求頻繁變更或是任何意外，往往就就會開始 Delay，一旦專案延遲，第一個犧牲的就是開發品質了，例如省掉測試作業等。變成開發範圍太大 -> 無法如此交貨必須加班 -> 品質降低的惡性循環。

但是要採用敏捷開發，這種合約要怎麼寫啊？敏捷開發不就說專案一開始不需對規格詳細內容做決定嗎？

XP 方法論提出四個互相影響的專案變數：成本、時間、品質、開發範圍。也就是如果定死價格、時間和範圍，品質就會變成可犧牲的變數。XP 派別認為這四個變數，最常、最應該可以變動的就是開發範圍，也就是定好價格、時程和品質，但是要做什麼再談。回到合約上看，也就定期限、定總價但不定規 格，例如 Kent Beck 建議的：『供應商將提供八個程式設計師為顧客服務，並且兩個月的金額是 $1,000,000。規模每兩週協商一次，協商時根據 XP 方法進行』。

但是不定規模對顧客而言最大的擔心，就是他想要知道他花了 $1,000,000 到底可以得到什麼，因此在台灣還很難接受這種合約方式，照 Kent Beck 的說法，只能玩成價格固定、交期不變、規模求個大概。例如我們和多就使用 User Story (註)的方式來定規模，保留與客戶溝通及實作的彈性，又有可以拿來估價的基準。雖然都會將專案時程切到至多三個月（一季）來做最大的估價範圍，不過還是會 有一開始低估規模而造成專案 delay 風險（所以加強專案的估計技巧也是個努力的方向）。

另一種在台灣常見合約的作法，是分成兩次簽約跟報價，第一次簽約預備開發期，目的是要完整討論出需求跟規格，這部份就會先收取一次費用。第二次簽的約才根據詳細規格再報一次總價。不過這種方式基本上就把敏捷開發一開始『規格不確定也無妨』的優點給犧牲掉了。

還有一種簽法就是計時合約（顧問費），花了多少時間就請多少款，但是基本上這跟固定價格、固定規模型的合約還是有一樣的利益矛盾問題：供應商為了多賺點錢，會希望多加人、多加班多報一點時數。客戶則想要在人力、時間盡可能少的情況下，做出盡可能多的功能。

各位接案的前輩們，你們是怎麼做的呢？

註：

User Story(使用者情節)是一段簡單的功能敘述，以客戶或使用者的觀點撰寫下有價值的功能(functionality/feature)。與其說它是規 格文件(documentation)，不如說它代表(represent)客戶需求，因為實做細節將延後至開發時才會確定。

幾個 User Stories 的範例如下：

* 使用者可以在網站上張貼履歷
* 使用者可以搜尋有哪些工作
* 公司可以張貼新工作
* 使用者可以限制誰可以看到他的履歷

參考資料：

* 極致軟體製程 (Kent Beck)
* 規劃極致軟體製程 (Kent Beck)
* Extreme Programming 理論與實務 (Japen eXtreme Programming User’s Group)
* 同人的生活派對 » 合約與需求變更
* User Stories Applied (Cohn)