這是由公司同事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的經驗分享的文章
感覺滿有趣的，因此也在此附上
