這個圖是你的合約關係嗎？
在上Agile Project Management的課程時，一直想跟實際工作情形連起來，連到採購的時候，心中有的大問號：現在一般常見的系統開發合約(開發一個系統，分3或4期付款：簽約、系統設計完成、開發完成、結案) ，跟以 Iteration 為進行方式的Agile Project，要怎麼對應的起來？ 用Agile 開發的話，不把全部的SA/SD文件都寫完啊，那要怎麼付款跟請款 ?
上完課後，為了一解心中的疑惑，開始蒐集 Agile Contract 的類型，這一系列分3篇，算是對整理後的筆記，先整理目前常見的合約類型共4種，最後再加上一個比較表，說明適用的時機與缺點。
這一篇先講兩種常見的固定價格合約(Fixed Price and Fixed Scope)與工時與材料(Time and Material)類型的合約：
- 固定價格合約(Fixed price)：是目前最常見的軟體專案發包方式，這種合約通常有固定的總金額與專案範圍，通常付款是分為：
- (1)合約簽約付一筆
- (2)中間階段0~N次付款：通常可以分 "系統分析文件交付"、"系統設計文件交付"、"系統開發完成交付"、"系統通過使用者驗收測試(UAT)" 等等不同階段
- (3)專案結案付一筆
- 譬如一個中型專案，乙方為了公司營運金流的順暢，希望分 4 次付款，所以請款的時候會是 "合約簽約"、"系統分析、系統設計文件交付與確認"、"通過UAT"、"專案結案"，這樣的合約配合瀑布式開發方式是很合適的，各階段都能搭配上。
- 在Agile Project Management時，並不會一開始完整的分析整個系統，用 固定價格的合約 就會覺得有點卡卡，譬如甲方要求 "SA, SD文件確認" 付款時，乙方不知道要怎麼產出 超大本的SA/SD文件 去給甲方確認，所以出現其他比較符合Agile的合約類型。但是，如果甲方說，只能發包這樣的合約(組織要求或...)，乙方是可以應用一些觀念，讓合約比較能符合Agile開發方式，譬如偷偷引入漸進式交付合約的想法(Incremental Delivery)，把Release當作階段 而不把SA/SD文件完成當作階段 (完成子系統#1,2當作第一階段、完成子系統#3,4,5 當作第二階段)。
- Scrum 大師Jeff Sutherland 提出的 2個重要的合約的觀念 (1) ，如果必須要承接/發包固定價格的合約，可以加入到合約中，對甲乙雙方都會有幫助的 (小弟不喜歡用"雙贏", 講出雙贏的人通常都不會說自己贏比較多...)
- Money for nothing 金錢無用 ：甲方可以在任一個 Iteration 後結束專案。評量的標準是, 如果甲方認為後續要做的價值不如已經完成的價值(i.e 已經完成的功能已經能達到所需要，因為Agile 是從高優先順序開始開發) 甲方將會付給乙方剩下合約的20%的金額。( 金錢無用 -> 不想付錢買不會用到的功能..)
- Change for free 改變免費：雖然講免費，但實際是，當有改變的時候，Product Owner 在 Iteration Planning 前或中提出新需求，Agile Team 評估 Story Point，確定要做的話，Product Owner把不重要的功能或相等Story Point的功能的移出 Product Backlog，做一些 TradeOff，甲方的高優先需求得以滿足，乙方一樣做那麼多Story Point 的工作，以這個方式來歡迎改變！
- 時間與材料合約/有上限的時間與材料合約( T&M / T&M with cap)：跟台灣俗稱的的"買人力"的想法很接近，可以想成"買整組人"在甲方駐點(通常還是要駐一下, out of sight out of mind, XD )開發所需要的系統，這種方式就是做多久就付多少金額。因為時間都是乙方估計，所以風險都在甲方，也因此有變種的，是加上上限的T&M(Capped T&M)合約，這個上限是雙方同意後的金額，通常甲方應該要加上鼓勵條款，鼓勵乙方早日完成。(不知為何，在台灣的甲方，能夠準時驗收與準時付款，對乙方就是一種激勵...) (2)
下一篇將整理的是漸進式的與目標成本的合約。
參考
沒有留言:
張貼留言