l

2012年1月29日 星期日

Scrum 是什麼(10):時程估算

January 28 23:03~January 29 00:20

螢幕截圖 2015-06-11 23.48.17

前情題要:

 

Scrum的大小活動大致上算是都交代過一遍了,今天談一 下幾天前學妹在Facebook上問Teddy的一個問題:時程估算。

***

學妹:最近我們常常被問到關於時程估計的問題,尤其是之前沒有run過Scrum的團隊,他們會想知道假設客戶一個案子來了,要怎麼去估算時間跟報價呢。我們用自己的經驗回答了,但總覺得回答得不夠有說服力。很想請教學長在這方面有沒有相關經驗可以跟大家分享呢? 謝謝!!

Teddy:很簡單啊,請問你問題的人跟Teddy聯絡...不是啦,這個問題不容易回答,基本上agile是建議不要採用「固定費用的合約」,但是實務上目前很難能夠被客戶接受。再加上如果團隊沒有run過Scrum不知道自己的「速度(生產力)」那就更難估了。你都怎麼回答別人?

學妹:這問題其實是上次學長講座結束後,後續留資料跟我們接觸的廠商訪談時候提出來的XD。首先,我們是講說通常一個有經驗的scrum團隊開發速度會趨穩定,這時候可以根據這樣的速度做估計。如果沒有經驗的話,會請他們用Commitment Based的方式,變成邊做邊調整,並且預留buffer,可是留buffer又牽扯到報價的問題。而且對方是表示對他們接案為主的小公司來說,這樣真的滿難的。所以討論到最後,對方說可能先從自己有興趣沒時程壓力的案子先run看看。我自己覺得我們回答的不好,所以最近才在想這個問題有沒有好的做法 ~"~

Teddy:要回答這樣的問題其實也很簡單,最保險的作法就是看他們原本怎麼估,就怎麼估。然後用SCRUM想辦法在估算的時程內把案子做出來。以這種方式多做幾次就會越估越準,不用說去找什麼「沒有時程壓力的案子來試SCRUM」。

學妹:哈哈哈 這樣一說突然覺得很有道理耶XD 突然想起學長寫的「Scrum 不會幫你解決問題」這篇。我想我自己也陷入那種想用Scrum幫大家解決所有問題的迷思了XDDD 謝謝學長,我會再多想想的!!

***

Teddy覺得學妹原本的回答已經很得體了。時程估算在軟體開發中本來就是一件困難的事情,問什麼 ?很簡單,因為變數太多了啊。有什麼變數?

  • 需求會變
  • 開發團隊成員會變
  • 技術會變

但也不能說因為變數太多所以就什麼也不估。估算的結果通常有兩種:「不準」以及「非常不準」。對於一個剛開始想要採用Scrum的團隊,如果客戶還是只願意用傳統的固定價格合約的方式來進行專案,那麼案子還是可以做。也沒甚麼好害怕或是擔心的,採用Scrum並不是進京趕考「一試定終身」,也不是做數學四則運算考題,第一次就要算出所謂的「正確答案」才算是成功。Scrum(所有的敏捷方法)都是一種逐步改善的過程,先把箭射出去了,再看看箭離標靶有多遠,然後修正後再射箭...縱然標靶本身並非是固定不動的(活動標靶),但依此精神長久下去所射出的箭總是慢慢地往標靶靶心靠近。

沒錯,「Scrum 不會幫你解決問題」,江湖上沒有什麼大還丹或是天山雪蓮之類的補品,吃一口就可以平白增長數十年功力。只有「傻的願意相信」,勇敢誇出第一步,然後邊走邊修正(果真如Kent Beck大叔所說的,軟體開發就跟開車是一樣的道理)。

Robert L. Glass在Facts and Fallacies of Software Engineering第31頁寫了一段大家都知道的事實:

Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time.

Scrum能帶來的好處,是把「計畫」這兩個字從名詞變成動詞。Scrum團隊隨時都在計畫,隨時都在調整,眼睛隨時都盯著標靶前進。Teddy前面提到的三個影響需求估算的變數,第一點「需求會變」這幾乎是無法改變的事實,所以Kent Beck大叔又告訴我們要「擁抱改變」。在Scrum的設計中,專屬的Product Owner與Scrum Master,舉辦Sprint Planning Meeting、Daily Scrum、Sprint Demo等活動,以及自動化測試、refactoring等作法,都算是用來「擁抱改變」的方法。

至於另外兩點變動因素「團隊成員會變」與「技術會變」,還是要靠「Sustainable Pace」以及「Shared Code」與「Pair Programming」等實務作法,讓提升團隊合作的能力,並且讓團隊成員有餘力可以讀書與自我成長(Sustainable Pace是很重要的)。

***

講了一堆,其實講再多鄉民們不願意去嘗試也沒用。軟體是動手做出來的,開發軟體是一種逐步改善的活動,所以,不要怕第一次估算沒做好就裹足不前。因為這就跟追女朋友一樣,不開口機會永遠是零。考慮東,考慮西的,最後又回到原本每天加班的老方法上面。團隊是否一開始就可以馬上實施「正統的Scrum」並不是重點,重點是這一狗票的敏捷方法(例如XP與Scrum)與敏捷實務作法(例如自動化測試、持續整合、Pair Programming等等)有那一些是可以拿來改善軟體開發流程,能用多少就算多少。而且要記得「開發軟體是一種逐步改善的活動」,不是說那一天心血來潮隨便挑一個敏捷實務作法來試一下乎弄過去就沒事了,而是要依據團隊與專案現況,挑選合適的實務作,對症下藥方能見效。但這藥也不能亂吃,吃錯了藥輕則花錢消災,重則可能要終生洗腎,不可不慎。

***

下一集:〈Scrum 是什麼(11):不信邪之流程改善精神

***

友藏內心獨白:這整篇哪裡有提到時程要如何估算啊?

2 則留言:

  1. 我覺得Scrum就是一個把人性管理實踐的方法
    很多時候,它都強調:人的本性,以及作到位就好

    很多老闆,像是XX康的,自詡Zoo Keeper那樣
    我個人覺得那樣一定會有問題,畢竟人不是機器
    所以Scrum是很 "人本" 的Process :P
    而且它是很具體的,比起指導原則來得更實際

    而談到逐步改進,我想說:
    其實本來就沒有事情是完美的
    但是我們可以Do our best!

    Scrum的確短時間不能解決一切問題
    然而它解決的是 "非功能性問題",也就是內部結構及人際互動信任的問題
    所以它能夠提高效率

    別的不說,1.準時下班的要求是為什麼?
    2.共同Share code,共同編輯是為什麼?
    3.每一個Sprint都修正並且強調團隊而非個人,是為了什麼?

    準時下班,為了再次上班的成效 如果每天都強迫留下來,其實留下來也在混:
    台灣的老闆們把員工想簡單了,還真的當動物在管
    如果真的沒事作還強迫留,我只能說:是在坐牢嗎?還是在當兵?(無誤)
    老闆們把人想得像機器人,硬壓就有東西
    但是成本是無法想像的:其實失去得更多,像是創意,認同感及士氣,以及重要人才流動(強者太累,跳槽了)
    我只能說:難怪台灣沒有幾個大品牌

    2.共同編輯,pair programming,則是為了建立團隊的大家對於共同的榮譽,並且在互相交流中,教導彼此不熟的東西-->也就是交互記憶的現象(Wagner的交互記憶理論) 這點是非常非常重要的:因為如果能夠作到,那麼各人之間的防衛心會日漸卸下,而且還能夠建立對於團隊的認同感(因為成果是共有的,不分你我),而且知識的傳遞可以讓新進成員能很快進入狀況(如果基礎理論知識夠的話,有些演算法還是要特地去學才會)

    3.修正是必然,因為這樣才能跟上變化。
    有句話叫作:計劃趕不上變化,因為人又不是全知全能,想得作的不一定對,更何況客戶需求還會變來變去...
    所以強調在特定時間去檢視並與客戶交流,去改動,我覺得也是Scrum很強調的核心重點

    回覆刪除
  2. To SuperMan,
    感謝SuperMan熱心的補充說明,您的留言都快比Teddy寫的本文還要來的多了,真是慚愧,慚愧...XD。

    回覆刪除