給 Sprint 一個更有意義的名稱

Sprint 絕對需要重新命名的,但也不是說 Sprint 1/ Sprint 2/ … 這種命名方式就不好!? 採用預設的方式能有良好的順序性,這是命名時不可缺少的資訊,也足夠區分不同的 Sprint了,算是還OK的。

但這種命名的缺點是它提供給Scrum團隊或相關人士的資訊太少了,很容易讓人感覺麻木…。

 

註: 感覺麻木是Sprint 團隊效能最大的隱憂之一。

 給Sprint 一個好名字

Sprint 需要朝氣,要有能一眼就被看出團隊在這個衝刺區間所想達成的願景。同時,這也能讓所有參與者時時記得目標及任務所在。不論這個Sprint執行的好壞都能讓人印象更為深刻。所以值得團隊在Planning meeting 時花一點時間來決定Sprint 的名稱。而且討論得越激烈越好,要知道情緒的提升對開發工作是無價的。這便是所謂的『膽大心細模式』。

註: “膽大心細模式": 這是參考《學徒模式》一書對模式的運用方式而產出的一種容易讓人一看便有所體會的模式命名。這種模式命名方式對敏捷開發的衍生式設計有著極重要的影響(賣個關子,有機會會在課堂上說明的)。在這裡我是假借一個為即將展開的Sprint的命名進行會議討論,藉此來激發開發人員的士氣,進而提升團隊效能,讓人能夠更勇於嘗試創新,並透過團隊參與人員較多的情形下,使得考慮變得較細心些。

 給Sprint 一個有意義的名字

例如:

<年份> CW<日曆上的開始星期數>-<結束星期數><目標>(<版本>)

2014 CW 20-22: Define project spec (v1.0.1)

2014 CW 23-24: Create the first spec (v1.0.2)

...

(CW: Calendar with Week numbers)

這個常被使用的命名法,提供了:
即將完成工作的內容及工作的簡單描述,所附帶的版本別則明白的表現出順序及規律,相當不錯。
提供大家做參考。

(相關資料請參考: How do you name sprints in your projects? )

再談scrum專案的時程預估

明明知道軟體開發工時是絕對估不準的,那為何還要辛苦的計劃估算呢?

《  話說朋友有難,我們當然應該義不容辭的挺身而出才是。但習慣作救火動作的我,這次卻是去放火的。怎麼說呢?事情是這樣的;軟體公司在議價前夕,對專案唯一有經驗的scrum master卻離職了,這個標案被指定要採用這家軟體公司不是很熟悉的silverlight技術來開發。老闆(就是我那個老朋友了)在不知如何是好時找我來幫忙。你說,該幫他預估時程嗎?所以我始終覺得是來放火的。我搭高鐵南下,大概只有5/6小時的時間可以從了解專案內容,分析規劃到交卷。好刺激,人生嘛~ 就是這麼有趣! 》

首先要弄清楚的是,花這麼多工不是只為了搞清楚開發的時程或是何時可以完工而已。 其實專案成敗的「風險」以及多弄清楚有那些「不確定的因素」才是重點。對我們這些專門推廣scrum的人而言,有時教導才是最最重要的。(說到這裡,難免要報怨一下,Scrum對軟體開發的規範太少了,是個非常輕量化的開發架構。所以經驗與過程的教導便成為十分重要的事,尤其在開發專案中,將會面臨到的各式問題,不但問題本身會相當有挑戰性,也經常扮演著專案成敗的重要因素。但這正是它有趣的地方。

話說回來,依據Mike Cohn 所述,時程估算的三種方法:

1. 依據團隊在相關專案上的歷史開發速度。

2. 針對目前的專案,就實際上執行一個sprint來做做看,然後依據這個sprint團隊所表現得到的速度來作預估。

3. 給自己一個好理由,用猜猜看的方式來估算。

這是Mike Cohn 給的建議。但很不幸的是,我們經常都在指導新的開發團隊,他們又總是在接沒作過的工程技術,因此前二種方法好像都派不上用場。最後只好來玩猜猜看的遊戲了。這個時候我還是習慣、也比較喜歡拿IBM古老的HIPO專案估算法來作breakdown, 原因正是它對專案在程式模塊上有相當的幫助,可以幫助工程人員進行思考並減少盲點(可以降低風險),雖然它的break down正確性有待考驗,但仍不失為委外開發或是專案進展下去的良好參考分析。對降低風險及不確定性有著一定的幫助。

與業者溝通,看清需求的本源

不過這次我沒有這麼做(沒考慮用HIPO來解題),一個理由是,自己對這個專案沒有感覺,或許是倉促之下,一心急著閱讀相關文件,看得快了,也就沒能意識到主軸所在,當然就沒感覺了。 另外一個重要因素則是缺乏溝通,沒跟真正的使用者接觸,進行語言上的交流,總覺得文件的描述少了些甚麼? 所以就在時間不足的情境下,選擇了與業者的需求單位見面,由需求的本源來進行分析的工作。

由發佈專案日期,倒推迭代的次數

台灣最多的就這種價格固定,時程又畫押的專案。對軟體公司而言,我們唯一可斟酌的就是功能的多寡了,做多了就做不完,還要賠錢。當然是想盡辦法來說服使用者少做一些功能了。以降低風險與減少不確定性為主旨來進行分析(然後希望老朋友能據此增加作決策時的準確性)。所以我以模擬"專案發佈會議"的方式來作計畫。這不是Scrum的制式會議,但過去在執行敏捷開發法時常常做。老實說;這是一種宣示性質大於實質意義的會議。能夠讓所有參與專案的人員有著一種共同的目標與期望,對接下來專案的進行工作絕對是一種好事。倒推迭代的方式,可以事前預估那些使用者要求的功能故事將不會被時間內做到。這一點,對雙方都有著極大的意義及幫助,它讓大家看到一個一致性的願景。放心好了,使用者的一致反應便是開始調整功能需求的優先順序。這種即時反應的回饋正是敏捷開發據以成功的依歸,也能讓人安心不少(希望這回火不要放得太大…)。

Break down Product backlog之後,我也順勢多訂了幾回迭代的規劃,感覺上有一些在做傳統專案的規劃動作,但多計畫一二個迭代的規劃,確實讓人更放心了些。這也是好事一樁。

在回程的高鐵車上,抒發一下情緒 …。

在竹科上SCRUM的課程: reading SCRUM

與第二組可愛的隊員合照

在竹科上SCRUM的課程

第一次試著運用讀書會的方式,把原本應該是程式開發的一次Sprint的迭代過程改成運用閱讀來進行(好棒! 我稱他為 Reading SCRUM),在為期三天的敏捷開發法 SCRUM課程中實際的run了一次 Sprint, 真是有趣,效果也比我預期的好太多了,看到很多人性的可取面,第一次上SCRUM課程感覺得這麼累,但卻這麼過癮~~~真是教學相長!

讀書會的專案設計

下面是讀書會的專案設計文案,有興趣的人請參考,過程挺精彩的,或許是這群學員的求知慾望旺盛吧! 我總覺得自己好像一下子年輕了好多好多~~

Listing 出來的書都真的買來了,其中(2) Succeeding with Agile ,by Mike Cohn依照組數買了許多本,花了不少精力把這些書扛過去,但看著學員們閱讀時的專注表情,真是太值得了! (雖然成本增加了許多,但我一定會繼續做下去的,因為太值得了,SCRUM的講師們有興趣的話,不妨試試看,這也證實了 SCRUM 的多方面運用性)。

為了這個課程把清明掃墓祭祖的家庭活動延了下來,夜深了…讓人倍感思念已經過世多年的老爸老媽,好想念您們!

專案文檔
專案文檔

有一點要特別提醒講師的,那就是不要輕估了學員們閱讀的能力,千萬別把範圍訂得太小了~

總是會有一二個團隊把閱讀的範圍定在只挑選單獨的一本書及裡面的一個章節上頭,說得好聽是集中精髓–精讀,但基本上是見樹不見林。一般的老闆最討厭這種情形發生了,他總希望專案能做到的功能越多越好,這一點講師們可以把專案鐵三角拿來作機會教育,「範圍 – 資源 – 時間」的調整練習,但千萬別犧牲了中間的品質。這是最值得強調的了。