Agile LEGO City workshop

這是由公司同事Jed所發起的公司內部課程。
Agile LEGO City workshop是用樂高積木來模擬敏捷開發的實際情形的一個小遊戲,藉著遊戲可以從中體認到軟體開發時,可能會遇到的許多狀況,並藉由會後的討論與檢討來讓參與者更能夠理解敏捷開發的意義。

敏捷開發宣言

在一開始時,我們先讀了下面的敏捷開發宣言

藉著親自並協助他人進行軟體開發,
我們正致力於發掘更優良的軟體開發方法。
透過這樣的努力,我們已建立以下價值觀:

個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商 
 回應變化 重於 遵循計劃 

也就是說,雖然右側項目有其價值,
但我們更重視左側項目。

讓參與者能夠從中理解敏捷的核心精神,也就是重視團隊間的溝通互動,接受需求的變化
並且讓我們知道敏捷開發最核心的就是這個宣言裡所描述的,所有敏捷實作方法如SCRUM等都需要建構於這個核心精神上。

遊戲規則

接著就是介紹LEGO遊戲的規則:
1. 依照下圖建造客戶所需的樂高城市,項目越前面代表客戶越重視的

2. 這個建城市的PO就是主講人Jed,在開始之前可以先和Jed提問,在每一個sprint的結束也會由PO來做驗收
3. 總共會有8個sprint,每個sprint開始之前要先計劃好這個sprint要做的,並移到TO DO去
PS:在這邊使用如下圖的看板方法去追每一個TASK的進度

4. 有一個計分表去計算每個sprint計劃要做的和實際驗收成功的任務比較表

遊戲進行

在開始遊戲後,本組所交付的任務頻頻被打槍,首先是我們在第一個sprint交付了平房,結果被打槍~原因是,請依照客戶需求優先順序做交付,我們前面都還沒有交付,不接受。
接著河濱公園安全設施因為圍牆沒蓋滿被拒絕,然後開始沒有做門,門沒有面對道路,沒有畫道路,圓環要在市中心,托兒園應臨近住宅….
等等原因一直被拒絕交付退回重改(火大)。

這是我們小組最後所交付的成果圖

會後檢討

我覺得這部份是這整個遊戲中最精華的部份,很感謝Jed還特別為我和Jack再做一次報告,讓我得以有機會聽到這個最精華的部份。

首先他讓我們提出我們覺得在遊戲中的感想,最多人提出的就是我們在一開始沒有搞清楚客戶需求,導致頻頻被退件
以及在一開始沒有先對整個城市做完整的規劃,例如圓環要在市中心等等…
造成我們所做的產品一直無法即時被release

然後Jed分享了敏捷開發的原則

The Agile Principles (敏捷原則)

1. 最為優先的事情是透過早期與持續交付有價值的軟體來使客戶滿意。
有價值的軟體指的是要重視客戶的優先順序,交付對客戶最有價值的東西
2. 歡迎需求的變動,即使是在開發的晚期。敏捷式流程駕馭變動來作為客戶的競爭優勢。
重點在於掌握變更,歡迎改動
3. 頻繁的交付工作產生的軟體,自數週至數月,週期越短越好。(2~4周)
4. 領域專家與開發成員必須一同作業,並貫穿整個專案開發時期。團隊的概念
5. 使用積極的工作成員來建構專案,給予他們環境以及支援所需的一切,然後信任他們能夠完成工作。
支援積極的個人(指願意主動多做更多事的人)帶動團隊氣氛,也就是信任團隊成員
6. 在開發團隊中最快也最有效的傳遞資訊方法就是面對面的溝通。
7. 工作產生的軟體是衡量進度最主要的依據。
這是最主要度量進度的方法,對使用者來說一定要完成的部份,因此找到使用者需求的核心價值十分重要
8. 敏捷式流程倡導水平一致的軟體開發
持續的開發,維持穩定步調,讓團隊狀況保持穩定
9. 專案發起者,開發人員以及使用者都必須持續的維持專案進度。
精簡,避免over design,不做太多額外的設計
10.持續重視技術的優勢以及設計品質
追求優良設計與技術
11.最好的架構、需求以及設計會出現在能夠自我管理的團隊裡
可以不需要PM就可以完成架構需求與規劃
12.在規律的反覆之間,團隊會反省與思考如何更有效率,然後相對的來調整與修正團隊的開發方式。
以天為單位定時自省,適當調整與修正自己的行為

在上述的精神底下的意義主要就是承諾,責任與互相信任。
敏捷是一個價值觀,也就是敏捷宣言與原則所述說的這樣的價值觀,Scrum是敏捷開發的一個框架,在Scurm裡所說的站立會議是一個scrum的儀式
優文分享:我對Daily Scrum的理解與看法
一般來說敏捷開發只估算這一回合要做的事情,過去我們在估算專案講的是人/天,這是以成本的角度去切入
而敏捷開發主要講的是故事點,也就是客戶需求的核心價值,重心在於價值。

對敏捷開發而言,估算是為了針對團隊生產力訂出並製定策略,重視的是產品的核心價值
因此可以看成是這樣

因此對於敏捷開發來說,每一個sprint只規劃該sprint要做的事,將客戶所需的功能切分到最小,每2-4週交付一次,每一次的sprint會將所有任務填上相對的一個數字,由多個成員來估算所需工時,並取一個平均值(若有差異較大的則需確認原因)
並在該sprint去計算本來我們預估這個sprint可以完成幾個工時,但實際完成了幾個?
再使用這個實際完成的數字去調整下一次sprint要release的總工時。
在這樣個估算方式下,隨著團隊穩定成長與默契的增加,估算的準確度會慢慢提升,如下圖

也因此在敏捷開發會特別重視團隊的穩定,惟有穩定的團隊才能帶來穩定的產品開發。

參考資料

雖然本文實際上沒有參考到這些文章,不過我去網路上爬了一些別人做LEGO workshop的經驗分享的文章
感覺滿有趣的,因此也在此附上

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *