l

2011年4月18日 星期一

答客問

April 18 21:20~22:35

趁著 Teddy 還記得的時候整理一下上禮拜六 Scrum 經驗分享活動中來賓所問的問題。

人客甲:我有一個新專案是 fixed price 的專案,如果按照 Scrum 的講法,客戶可以一直改需求但是 fixed price 的專案又不能增加費用,這樣可以採用 Scrum 嗎?

Teddy:請問您以前是否有接過類似性質的專案?

人客甲:有。

Teddy:請問以前的案子都有準時結案嗎?客戶都不會更改需求嗎?

人客甲:沒有準時結案過,客戶會修改需求。

Teddy:那你還怕甚麼....XD

***

上面這個算是有點不負責任的回答,不過既然以前的方法已經多次被證明了不 work,那換個新的 Scrum 方法有什麼好怕的?當場 Teddy 沒有給這位人客太多 狡辯 回應的機會,他心裡可能在想,『雖然以前的方法不 work,但是可能只會 delay 個兩個月,萬一改用 Scrum 變成 delay 三個月甚至更久那怎麼辦?

的確,這種情況可能發生。好幾年前 XP 很流行的時候,Teddy 聽過一個故事,台灣某家本土做 ERP 的大公司的某個小團隊,決定採用 XP 來開發某個軟體。因為他們認為 『XP 不需要做 big up-front design,只需要透過 refactoring 來改善 design』,於是他們就真的沒有做什麼 design,導致有一陣子連續花了超過 6 個月的時間在 refactor 他們的軟體。最後這個案子已失敗告終。該公司得到一個結論,就是 XP 不 work。

人客啊,俗話說『不會駛船嫌溪彎』,自己不學好要怪東怪西這樣 Teddy 也沒辦法。Teddy 在『同誰,九陰真經不是這樣子練滴』曾經說過:

就算你是『逆練九陰真經』,好歹練功的內容還是和『九陰真經』相關連,總不能說當年郭靖給歐陽峰一本『瑜伽大全』或是『第一次學有氧舞蹈就上手』然後騙他說這是『九陰真經』,這樣就『騙太大了』。

那有採用 XP 的團隊會連續 6 個月以上都在做 refactoring 的,這樣就是在練『瑜伽』而不是在練『九陰真經』了,別搞錯方向了。

回到原本的問題上面,如果怕自己 Scrum 不熟,那麼至少有兩個方法可以解決:
  • 花錢:找顧問來協助導入,這樣最快而且比較保險。但是,千萬,千萬記住,不要找錯顧問啊,否則是會...祝恐怖..滴...。花錢又不能消災,到時候又要怪 Scrum 不好。如果不知道要找誰,請看『工商服務 』,服務範圍應該有包含海峽兩岸
  • 自己慢慢試:這個方法風險就比較高了,首先,在公司內部找到一個類似 Teddy 這樣的人來擔任 Scrum Master 幫忙導入。可以先送這個人去上課(2 天搞定),然後從『殺傷力最小』的地方開始導入 Scrum。例如,可以先改善工作環境,把辦公室隔間先拆掉,幫 developers 換大桌子,大螢幕,好電腦,並且多準備一些測試環境。接著,試著將需求改用 story 的方式來表達,如果客戶無法接受,那麼這個 story 就變成開發者自己看的資料就好,不需要告訴客戶。再下來就可以開始 sprint planning meeting, daily scrum, sprint demo meeting, and retrospective meeting。如果一開始無法立即上手,可以試著採用 iteration 0。.... 等等...再寫下去可以寫一本書了,下面就自由發揮。
總之,Teddy 的經驗是,只要找對 Scrum Master,事情應該就成功一半了。至於採用 Scrum 的效果,就要看公司文化,長官的支持程度,每個團隊成員的能力與配合度,這是需要時間來證明的。

***

人客乙是一位年輕小伙子,問了 Teddy 好幾個問題,試圖將 350 元報名費發揮到極致,不過 Teddy 只記得其中兩個問題。

人客乙:請問如果到專案快結束的時候,客戶改了一個需求影響到整個軟體架構,需要大改,那該怎麼辦?

Teddy:請問每個 sprint demo 的時候客戶都在做什麼?如果 sprint demo 客戶都有參加,『理論上』你講的這個問題發生的機率應該是很低的。這樣的問題在採用 waterfall 的專案倒是很常見。不管如何,萬一真的發生,你也只好認了啊。不過,至少你可以說『每個 sprint demo 的過程你都有參與,現在你要做這麼大的改變,是不是應該要重新談專案合約』。雖然客戶並不一定會買單,但是只要有點人性的客戶應該多多少少有點商量的餘地。

***

當人客乙問了下一個問題之後 Teddy 就知道他一定沒有看過(或是沒有專心看)搞笑談軟工,問題如下。

人客乙:Use case 裡面有所謂的 main success path 以及 extension 或是 exceptional path。通常我們會把 main success path 寫成 story,那麼 extension 與 exceptional path 要怎麼辦?

Teddy:嘿,嘿,嘿,你沒看過搞笑談軟工對不對? 嗯嗯...總之這個問題說來話長,請參考 Teddy 部落格的『exception handling』分類文章,至少要把『敏捷式例外處理設計的第一步:決定例外處理等級』與『用 Robustness stories 評估 SyncFree 有多強壯』看完。

最後再奉送一篇免費的 paper『敏捷式例外處理』,如果這樣還不了,那就要付費請 Teddy 一對一教學了... XD

 ***

還有一位人客問到:如果團隊有 50 - 60 人那怎麼辦?Teddy 回答那要用 Scrum of Scrum... 不過很可惜,Teddy 的團隊人數遠遠遠小於這個數目(Teddy 內心獨白:我也很想有 50-60 個人可以帶啊),所以沒辦法分享任何具體的經驗。
 
ㄟ,年紀大了,只記得這四個問題,下次還有機會的話,Teddy 要記得把人客的問題記下來。

 ***

友藏內心獨白:其實 Teddy 的博速論文就是研究 exception handling 滴...



8 則留言:

  1. 對於那位人客甲的問題, 我倒是有另一種想法, 通常這種專案時間通常1年以上, 如果可以使用Scrum精神將1年的驗收分成3-4次, 其實這對發包與接案的公司都是可以降低風險的作法, 對於接案公司, 客戶修改需求讓結案日期延後其實就是賠錢, 去年就遇到類似的案子, 於是使用上述的方式將那個案子的需求刪到為3個月為驗收的時間點, 雖然還是遇到同樣的狀況->客戶要修改需求, 但是至少第一階段就可知道對方的態度, 如果公司真的有底子, 何苦再接第二個階段的需求

    回覆刪除
  2. 最後的問題是我問的,因為我不確定大型計畫是否能使用 agile.

    回覆刪除
  3. 記得在網路上爬文的時候,有看到過一些 agile + 合約 的文章,或多或少,會討論到 Agile vs. Fixed-Price, Fixed-Scope, Fixed-Schedule contracts…等等的東西。
    您可以用 agile + 合約 或 agile + contract;google e一下,看看別人怎麼說…

    回覆刪除
  4. To A Linux Blogger:

    看您的樣子就是那種手下帶著幾10個人的主管...Teddy 挺羨慕的...

    To 匿名:

    謝謝你的建議。

    回覆刪除
  5. 哈, 請不必羨慕,敝人的工作就是與白痴老闆+白痴PM+殘弱手下打架

    回覆刪除
  6. To A Linux Blogger:

    哈哈,萬一被您的老闆看到,豈不是要開啟 104...XD

    回覆刪除
  7. 先謝謝Teddy兄熱心的回答,以及各位前輩的意見!

    其實Agile與我心中許多想法一致,第一次看到Agile Manifesto 時真是熱淚盈眶,後來看到Scrum時,也覺得這個方法有搞頭!
    我很想要導入Scrum,好讓大家(有機會可以每天準時下班)把案子做好。不過考慮環境的限制,確實有一些困難之處。
    Teddy說對了,我擔心的問題之一確實是如果搞Scrum結果delay更兇,讓Agile成了代罪羔羊,那以後就很不妙了。前一陣子也在網路上爬了一些文章,沒太大的收穫。所以,能抓到人就一定要來問一下!

    我目前的想法是:
    若要用Scrum來作為實際的開發方法,那就在合適的合約型態之下進行。
    (此乃世界大同之境界也!)

    當然,現實的環境之下可沒那麼完美。目前公司的SOP就是很傳統的SDLC模式,大部份的PM腦袋裏面都是Water Fall,而Agile只是工程師的想法;客戶只願意使用現在的合約模式,不然晚上會睡不著覺。如Teddy所說的,要導入需要一點技巧,而且要有長官的支持,也需要時間讓環境慢慢成熟。我想,最後還是需要讓客戶相信這是一種雙贏的方式
    就目前的狀況,我有一個想法是:由於案子的規模都超過1年,合約都會分成好幾個階段來簽,甚至不斷擴充延續數年。
    第1階段包含硬體設備和一些基礎的功能,就用 Fixed priced contract。在第1階段的執行過程中先取得客戶的信任,也讓客戶能夠對這個案子後續的每個feature需要的成本有一個概念(有個共識,也不用怕我會坑他)。後續階段的合約再把它談程適合敏捷開發的模式。
    不過客戶端實際負責合約的人未必有權可以改變以往的合約模式。這時就需要我方的高層長官願意支持,然後透過雙方高層之間的溝通來促成。
    從另外一個方向想起來就更覺得真不容易呀!因為公司中有能力和對方談改變合約方式的高層願意支持時,這時Scrum的時機已經成熟了,要到這一天需要不少努力。
    還不知大家的看法如何?

    我想,Scrum是種好方法,但如果真的沒辦法完全採用,還是可以參考。我很怕抓錯藥方,用錯劑量,結果藥到命除勒!我開104沒什麼大不了,害支持我的主管下台就真的很歹勢啦!

    如果合約變不了、沒辦法Scrum...,在技術上還是可以使用TDD, Continuous Integration... 也能照著Agile精神與原則來執行專案中的各項工作。...我的觀念還不是很清晰,趁著目前還沒辦法試行時先研究,也會試著做點小實驗,當作是進入大同世界前的風景囉。

    雖然在肥沃的土地上才好種花,沙漠裡還是可以種仙人掌,聽說也是會開花勒。

    回覆刪除
  8. 那家"本土ERP大廠"(台灣大概也只剩那一家吧)是篤信"加班加到爆,產品就會好"的那種,根本沒在改善什麼開發流程還假裝有在改善

    回覆刪除