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

補充(2016/1/16): Software Costs Estimation In Agile Project Management

一般在台灣簽軟體開發合約,最常見的就是固定價格、固定規模的合約(最晚何時要交出符合這些規格的軟體和文件),但是碰到的問題就是兩造雙方都覺得需求定不清楚,而陷入對立的情形。接案的希望少做、出錢的希望多要一點,所以往往都在討價還價中試圖在期限中完成。如果實作後發現一開始的估計太保守、開發中途客戶又不斷加規格、需求頻繁變更或是任何意外,往往就就會開始 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 的範例如下:

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

參考資料:

參與討論

9 則留言

  1. 很有趣的問題耶,而且我剛好正遇到… 我是發包者。即便開發團隊不以 XP 模式開發,需求不定的狀況應該也是經常發生吧?目前的作法如你所說,時程、細節、預算都設法固定下來,我唯一做到的是讓開發團隊自訂時程,因為只有他們最清楚… anyways,或許「包與被包」也是一個很好的聚會主題 :P

  2. 其實不論用哪種方式, 最重要的互動是”互信”
    客戶對於開發者/公司專業上的肯定與信任
    開發者或公司提供不讓客戶失望的專業態度與技術
    “信任”雖然無法在白紙黑字上寫的清楚
    但卻可以由白紙黑字裡頭輔助完成, 不衝突的
    我的建議是切割專案, 把整個專案的時間由小至大切割開來
    並按每個階段完成度來付款

    譬如, 階段一是由今天算起一週後驗收
    當然, 在這個階段要完成哪些討論, 要讓多大比例的需求定案
    這些都要在這個super短期的合約中寫的清楚
    比方說寫User Story會包含很多跟客戶談論商討的合作方式
    這是個建立信任的好機會, 這個星期若合作愉快則繼續合作
    若合作不愉快則可終止合作, 當然一星期的user story成果文件應交到客戶手裡
    而客戶的錢也花在刀口上, 因為就算對此公司不滿意
    這份user story也可以用在下一個合作對象上
    最大風險是user story根本完成度低到不能延續使用
    但在可忍受的負擔下 賺得了”哪種公司不適合合作”的經驗 也不無所得
    若要降低這種最初就用錯人的風險
    最好也建立類似”標案”的機制
    多家公司一起競爭一個案子可以讓客戶更清楚自己要什麼
    也讓競爭的公司知道其他公司比自己好在哪裡, 自己需要加強在哪裡

    這種將專案分割成巨量的細小專案可以確保品質
    承案公司因隨時都有被換掉的危機感而維持品質
    但在案子進行順利的時候也會因為不斷完成目標而建立自信
    (因為目標變近了, 目標的數量也變多了)
    從XP的角度來說這也符合”邊走邊做, 邊做邊確定該往哪個方向走”的原則
    也符合Kent Beck說的, 在每天的一開始專案團隊有個小小的10分鐘開會的做事方法
    因大量的小型會議不斷的溝通, 訓練了在短時間內完成目標
    (注意:這個目標不需要大, 重點是要合理並要能確定完成)
    大部分的客戶不會在一開始就知道自己全盤要什麼
    所以也是戰戰兢兢地邊學習邊合作
    所以 “按照客戶舒適的速度” 和 “完美的達陣率” 就是建立信任的關鍵

    以上是我的短見
    還請多多指教

  3. 用總價契約很難不固定範圍,因為訂這個契約的前提就是把風險轉嫁到開發者身上,因此開發者要想盡辦法降低專案範疇風險,很難讓開發範圍不確定。

    如同我在〈合約與需求變更〉提到的,要用漸進反覆的開發模式,還是用 T&IM 合約比較適合,軟體專案多半複雜性較高,用總價合約不大適合,即使訂定附加的獎勵或懲罰條款來爭取開發者的利益,但規格不確定,還是風險很高的,而且是客戶要開發者承擔的風險。

  4. 關於 2F 提到 “信任”,在經歷過一些血與淚,真是深深感到認同。但 “信任” 之外,體認到的是無常 … 沒放諸四海皆準的做法。

    以個人瞭解優秀業務做法 … 大部份作業準則都是瞭解客戶的預算後,謀靜而後動 … 以合理報酬,創造最大利益 … 也有其道理。

    若以敏捷方法來看 … Henrik Kniberg 先生的善書 Scrum and XP from the Trenches (www.infoq.com/minibooks/scrum-xp-from-the-trenches) 其中 12 章 How we do release planning and fixed price contracts 是蠻不錯的參考 … 畢竟商業行為不可因為軟體開發方式有太大的改變。

    然而雙方若都以底線(功能、人力)溝通,容易陷於角力競賽、一翻兩瞪眼的局面。較理想方式當是 Mike Cohn 先生在 Agile Estimating and Planning 一書中第三部份 Planning for value 以價值為準則 … 也就是好業務做法? 以手上案例,除金錢的價值,還有不少其他選項 … 例如: 提升 IT 部門價值(跟得上時代)、大幅縮短變更成本、… 之類的。

  5. 我倒覺得刻意要用某種開發方式反倒把專案團隊綁死,並不是個好主意,軟體系統開發的專案經理,應該依照專案的需求與特性選擇合適的開發方法,假如用XP開發方法有難以報價的困難,那又何必刻意用XP而增加報價失誤的風險呢?
    而且我個人覺得把『規格不確定也無妨』說是XP的優點,還不如說是XP開發的彈性,也就是說在規格不確定時也能使用XP開發;但規格若能夠確定絕對是更好,因為這樣勢必可以減少與客戶重複討論的時間成本.

  6. 路人甲: 專案開始前規格”確定不了”就是敏捷開發要解決的問題(或是說,你以為你確定了,但是其實沒有),因為一實作下去計畫(需求)就會改變,所以 Agile 會鼓勵不斷跟客戶溝通合作,而不是人間蒸發軟體開發法:一開始努力確定全部規格,接著你就不見了,深居簡出,埋頭苦幹,直到最後將軟體交付出來… XD

    這裡也沒有限定說是 XP 方式,關於敏捷的概念可以參考 ihower.tw/blog/archives/1750 一文。

    同意 tcc 長輩所說,真正的商業行為很可能是根據客戶情況而定的,但不論採用什麼合約,實行 Agile 的目的都是為了在控制成本的情況下創造出最有實用效益的軟體。

發佈留言

發表迴響