Comments on: 採用敏捷方法的軟體開發合約該怎麼簽？ http://ihower.tw/blog/archives/2449 Ruby, Ruby on Rails, Mac and Agile development Sun, 14 Mar 2010 04:21:31 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: 網站製作學習誌 » [Web] 連結分享 http://ihower.tw/blog/archives/2449/comment-page-1#comment-58826 網站製作學習誌 » [Web] 連結分享 Thu, 12 Feb 2009 06:36:18 +0000 http://ihower.idv.tw/blog/?p=2449#comment-58826 [...] {|ihower.idv.tw| blog } | 採用敏捷方法的軟體開發合約該怎麼簽？ [...] [...] {|ihower.idv.tw| blog } | 採用敏捷方法的軟體開發合約該怎麼簽？ [...]

]]> By: ihower http://ihower.tw/blog/archives/2449/comment-page-1#comment-58796 ihower Thu, 22 Jan 2009 08:03:47 +0000 http://ihower.idv.tw/blog/?p=2449#comment-58796 路人甲: 專案開始前規格"確定不了"就是敏捷開發要解決的問題（或是說，你以為你確定了，但是其實沒有），因為一實作下去計畫(需求)就會改變，所以 Agile 會鼓勵不斷跟客戶溝通合作，而不是人間蒸發軟體開發法：一開始努力確定全部規格，接著你就不見了，深居簡出，埋頭苦幹，直到最後將軟體交付出來... XD 這裡也沒有限定說是 XP 方式，關於敏捷的概念可以參考 http://ihower.idv.tw/blog/archives/1750 一文。 同意 tcc 長輩所說，真正的商業行為很可能是根據客戶情況而定的，但不論採用什麼合約，實行 Agile 的目的都是為了在控制成本的情況下創造出最有實用效益的軟體。 路人甲: 專案開始前規格”確定不了”就是敏捷開發要解決的問題（或是說，你以為你確定了，但是其實沒有），因為一實作下去計畫(需求)就會改變，所以 Agile 會鼓勵不斷跟客戶溝通合作，而不是人間蒸發軟體開發法：一開始努力確定全部規格，接著你就不見了，深居簡出，埋頭苦幹，直到最後將軟體交付出來… XD

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

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

]]> By: 路人甲 http://ihower.tw/blog/archives/2449/comment-page-1#comment-58795 路人甲 Thu, 22 Jan 2009 06:10:11 +0000 http://ihower.idv.tw/blog/?p=2449#comment-58795 我倒覺得刻意要用某種開發方式反倒把專案團隊綁死,並不是個好主意,軟體系統開發的專案經理,應該依照專案的需求與特性選擇合適的開發方法,假如用XP開發方法有難以報價的困難,那又何必刻意用XP而增加報價失誤的風險呢? 而且我個人覺得把『規格不確定也無妨』說是XP的優點,還不如說是XP開發的彈性,也就是說在規格不確定時也能使用XP開發;但規格若能夠確定絕對是更好,因為這樣勢必可以減少與客戶重複討論的時間成本. 我倒覺得刻意要用某種開發方式反倒把專案團隊綁死,並不是個好主意,軟體系統開發的專案經理,應該依照專案的需求與特性選擇合適的開發方法,假如用XP開發方法有難以報價的困難,那又何必刻意用XP而增加報價失誤的風險呢?
而且我個人覺得把『規格不確定也無妨』說是XP的優點,還不如說是XP開發的彈性,也就是說在規格不確定時也能使用XP開發;但規格若能夠確定絕對是更好,因為這樣勢必可以減少與客戶重複討論的時間成本.

]]> By: tcc http://ihower.tw/blog/archives/2449/comment-page-1#comment-58794 tcc Thu, 22 Jan 2009 03:00:19 +0000 http://ihower.idv.tw/blog/?p=2449#comment-58794 關於 2F 提到 "信任"，在經歷過一些血與淚，真是深深感到認同。但 "信任" 之外，體認到的是無常 ... 沒放諸四海皆準的做法。 以個人瞭解優秀業務做法 ... 大部份作業準則都是瞭解客戶的預算後，謀靜而後動 ... 以合理報酬，創造最大利益 ... 也有其道理。 若以敏捷方法來看 ... Henrik Kniberg 先生的善書 Scrum and XP from the Trenches (http://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 部門價值(跟得上時代)、大幅縮短變更成本、... 之類的。 關於 2F 提到 “信任”，在經歷過一些血與淚，真是深深感到認同。但 “信任” 之外，體認到的是無常 … 沒放諸四海皆準的做法。

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

若以敏捷方法來看 … Henrik Kniberg 先生的善書 Scrum and XP from the Trenches (http://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 部門價值(跟得上時代)、大幅縮短變更成本、… 之類的。

]]> By: 同人 http://ihower.tw/blog/archives/2449/comment-page-1#comment-58793 同人 Thu, 22 Jan 2009 01:22:04 +0000 http://ihower.idv.tw/blog/?p=2449#comment-58793 用總價契約很難不固定範圍，因為訂這個契約的前提就是把風險轉嫁到開發者身上，因此開發者要想盡辦法降低專案範疇風險，很難讓開發範圍不確定。 如同我在〈合約與需求變更〉提到的，要用漸進反覆的開發模式，還是用 T&IM 合約比較適合，軟體專案多半複雜性較高，用總價合約不大適合，即使訂定附加的獎勵或懲罰條款來爭取開發者的利益，但規格不確定，還是風險很高的，而且是客戶要開發者承擔的風險。 用總價契約很難不固定範圍，因為訂這個契約的前提就是把風險轉嫁到開發者身上，因此開發者要想盡辦法降低專案範疇風險，很難讓開發範圍不確定。

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

]]> By: Polley Wong http://ihower.tw/blog/archives/2449/comment-page-1#comment-58792 Polley Wong Wed, 21 Jan 2009 16:24:26 +0000 http://ihower.idv.tw/blog/?p=2449#comment-58792 其實不論用哪種方式, 最重要的互動是"互信" 客戶對於開發者/公司專業上的肯定與信任 開發者或公司提供不讓客戶失望的專業態度與技術 "信任"雖然無法在白紙黑字上寫的清楚 但卻可以由白紙黑字裡頭輔助完成, 不衝突的 我的建議是切割專案, 把整個專案的時間由小至大切割開來 並按每個階段完成度來付款 譬如, 階段一是由今天算起一週後驗收 當然, 在這個階段要完成哪些討論, 要讓多大比例的需求定案 這些都要在這個super短期的合約中寫的清楚 比方說寫User Story會包含很多跟客戶談論商討的合作方式 這是個建立信任的好機會, 這個星期若合作愉快則繼續合作 若合作不愉快則可終止合作, 當然一星期的user story成果文件應交到客戶手裡 而客戶的錢也花在刀口上, 因為就算對此公司不滿意 這份user story也可以用在下一個合作對象上 最大風險是user story根本完成度低到不能延續使用 但在可忍受的負擔下 賺得了"哪種公司不適合合作"的經驗 也不無所得 若要降低這種最初就用錯人的風險 最好也建立類似"標案"的機制 多家公司一起競爭一個案子可以讓客戶更清楚自己要什麼 也讓競爭的公司知道其他公司比自己好在哪裡, 自己需要加強在哪裡 這種將專案分割成巨量的細小專案可以確保品質 承案公司因隨時都有被換掉的危機感而維持品質 但在案子進行順利的時候也會因為不斷完成目標而建立自信 (因為目標變近了, 目標的數量也變多了) 從XP的角度來說這也符合"邊走邊做, 邊做邊確定該往哪個方向走"的原則 也符合Kent Beck說的, 在每天的一開始專案團隊有個小小的10分鐘開會的做事方法 因大量的小型會議不斷的溝通, 訓練了在短時間內完成目標 (注意:這個目標不需要大, 重點是要合理並要能確定完成) 大部分的客戶不會在一開始就知道自己全盤要什麼 所以也是戰戰兢兢地邊學習邊合作 所以 "按照客戶舒適的速度" 和 "完美的達陣率" 就是建立信任的關鍵 以上是我的短見 還請多多指教 其實不論用哪種方式, 最重要的互動是”互信”
客戶對於開發者/公司專業上的肯定與信任
開發者或公司提供不讓客戶失望的專業態度與技術
“信任”雖然無法在白紙黑字上寫的清楚
但卻可以由白紙黑字裡頭輔助完成, 不衝突的
我的建議是切割專案, 把整個專案的時間由小至大切割開來
並按每個階段完成度來付款

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

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

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

]]> By: BobChao http://ihower.tw/blog/archives/2449/comment-page-1#comment-58791 BobChao Wed, 21 Jan 2009 16:09:54 +0000 http://ihower.idv.tw/blog/?p=2449#comment-58791 很有趣的問題耶，而且我剛好正遇到… 我是發包者。即便開發團隊不以 XP 模式開發，需求不定的狀況應該也是經常發生吧？目前的作法如你所說，時程、細節、預算都設法固定下來，我唯一做到的是讓開發團隊自訂時程，因為只有他們最清楚… anyways，或許「包與被包」也是一個很好的聚會主題 :P 很有趣的問題耶，而且我剛好正遇到… 我是發包者。即便開發團隊不以 XP 模式開發，需求不定的狀況應該也是經常發生吧？目前的作法如你所說，時程、細節、預算都設法固定下來，我唯一做到的是讓開發團隊自訂時程，因為只有他們最清楚… anyways，或許「包與被包」也是一個很好的聚會主題 :P

]]>