在傳統的專案開發中，都有一個角色負責分配工作，常常是由PM（專案經理）或是Team Lead（組長）來擔任。分配工作這回事非常吃力不討好，既要了解每件工作的急迫性和複雜度，還要考量每個人的能力，平衡每個人的工作量。
這角色常常會成為團隊的瓶頸，因為每件事情都要經過他來分析、排程、驗收、忙著開會，常發生團隊成員空等他來分派工作。更別提如果工作項目比既定時程提早做完、或延遲完成所需要的協調工作。這也是最容易被上下壓力夾殺，很快Burnout陣亡的苦主。
敏捷開發或Scrum如何解決這個角色的問題呢？ 閱讀全文〈工作沒人想做怎麼辦？ – Scrum中的工作分派與分工〉
今天在玩Taco桑的Scrum Lego Game中，需要預估所有需求（Story）的大小，利用T-Shirt Size方法歸類到XL，L，M，S。而有一個Story是要蓋市長紀念碑，團隊先放到到S，但最後花了一整個Sprint，比其他XL花的時間還多。（都怪某一組拉高了市長的期待，還放跑馬燈，讓我們壓力很大 T_T）
其他Story預估大小也和真正實作的時間差很多。
所以在Retrospective（自省）中有夥伴說：『因為我們沒有玩積木的經驗，所以估計不準。』
我很好奇的問：「大家在現實工作中，都估計的很準嗎？」
有夥伴回：『如果估不準，怎麼報價給客戶？』
閱讀全文〈閉嘴也不錯 – 如何用靜音排序(Mute Mapping)快速估算需求〉
6/30/2015 參加了Agile Brewery，活動是由 TomTom 和 Rally 全額贊助，不但免費食物豐富還有啤酒供應，真是佛心來的。
今天主講是TomTom荷蘭來的資深技術副總，Han Schaminee，有超過40年專案管理經驗。
之前有討論過如何衡量團隊的產出和價值，接下來讓我們看看如何衡量個別開發人員（包含Programmer，Tester 和 Designer）的產能。
情境一，假設你是督導建金字塔的其中一個拖拉隊的工頭，團隊裡面有三個如上圖，兩個很賣力在工作，另一個很反骨，整天都在吵為什麼輪子不用圓的之類的，吵歸吵，大夥每個月還是可以運20趟。你是工頭，每個月底加菜金的時候要怎麼分呢？
江湖上軟體開發有兩個大門派，第一個門派歷史跟軟體一樣久，心法是以流程為主軸，正式名稱瀑布式開發（Waterfall），最具代表的武功就是CMMI，幾年前台灣政府大力推動支持。另一個門派在1990年代異軍突起，心法是以人為主軸，正式名稱為敏捷式開發（Agile），最知名的武功是Scrum。
江湖上軟體開發（或專案管理）有兩個大門派，第一個門派歷史跟軟體一樣久，心法是以流程為主軸，正式名稱瀑布式開發（Waterfall），最具代表的武功就是 CMMI，幾年前台灣政府大力推動支持。另一個門派在1990年代異軍突起，心法是以人為主軸，正式名稱為敏捷式開發（Agile），最知名的武功是 Scrum，但在台灣則是這一兩年才開始熱門起來，近年因爲許多公司的敏捷轉型成功，業界也把敏捷式開發的概念延申到敏捷式管理中。（註：Scrum 的原始意思是橄欖球的爭球動作，在軟體界沒有翻譯成中文，都是直接叫 Scrum）
關於軟體開發最經典的問題就是，要如何評量開發團隊？這不但是管理人員最頭痛的問題，連開發人員也很想知道自己怎麼被評量的。我們來看看能不能由產品（程式）或生產線（開發人員）上，找些東西幫助管理人員對開發團隊打分數。
另一種常見的Scrum導入方式是由部門主管自己跳下來當Scrum Master，在關於Scrum Master的一些怪味道中提到，主管當Scrum Master，的風險就是沒辦法產生一個自組織的團隊。而讓團隊有自我組織的能力是跑Scrum最大的理由之一，所以強烈不建議主管拿Scrum Master的角色，反而主管拿Product Owner的角色會是比較容易養成自組織的團隊。
但如自組織不是近程目標，也充分了解風險，主管擔任Scrum Master也不是不行。假設主管要當Scrum Master，會建議要如何實作呢？
接受預估不可能準後，下一步是了解客戶的需求。
客戶要的軟體跟夢中情人是一樣的，不管列出再多條件：大學畢業，身高一米七，腿長一百公分，溫柔，體貼，勤奮，顧家。都是僅供參考。
具體的標準如身高還好搞定，溫柔體貼勤奮顧家到底要怎麼衡量啊？而且往往看對眼的時候什麼標準都不重要了，變成自己溫柔體貼勤奮顧家每天當工具人。所以知道如何找夢中情人，就知道如何了解客戶需求。
今天（2015/06/07）上了Teddy的Design Pattern 這樣學就會了- 入門實作班（第一天課程投影片）。本課程主要客群是軟體工程師，讓工程師能在做開發時用更有效的方法來做出易讀，易了解，易維護，易擴充的程式，畢竟程式是給人看的。第一天的課程著重在設計模式（Design Pattern）的觀念導入，程式實作的部分在第二天跟第三天。
感覺很多軟體設計的Pattern好像可可以用在做事情和組織設計上。這個課程也有一日卷，適合工程師以外，對設計和問題定義有興趣的朋友參加。 閱讀全文〈來一個解決問題的公式 – Design Patterns 這樣學就會了心得〉
記錄一些關於Yves讀過的，關於Scrum和敏捷的書籍，和上過的教育訓練
Scrum簡介中文版，英文版
Scrum指南中文版，英文版
以上兩本是對Scrum的人事物的定義，一小時就可以談Scrum。
精實創業：用小實驗玩出大事業
如何用漸進迭代的方式交付價值 閱讀全文〈Scrum與Agile敏捷開發書單和學習資源〉
