Update(2016/3): 投影片新增第四階段：營運成長
感謝 David Ko 的邀請，在 Agile Tour Hsinchu 給一場分享講軟體開發流程，內容就東拼西湊這幾年在 startup 公司學到和用到的東西，沒想到迴響還不錯，得到的評價是很實用，摘要如下：
Update: Real Software Engineering by Glenn Vanderburg 這場演講也值得一看
前一陣子念「笑談軟體工程：敏捷開發法的逆襲」這本書，其中有幾篇文章的說法和比喻常被引用，所以我按圖索驥，也把原文章拿出來念一念，包括：
「原始碼就是設計」「 Source code is the design」，避免花費太多時間在分析設計上，原始碼本身就是是軟體設計的產生，而 compile, link 等才是軟體的生產活動。因此，寫程式是「設計」的活動，而不是「生產」的活動，因此傳統設計文件的重要性就大大降低了。
程式設計不是 “building software”，而是 “designing software”。
軟體系統的設計是演進來的，不能一步到位，而是要藉由憑繁與使用者互動得到的回饋來修改系統設計。
與其把程式設計比喻成蓋房子，實際上更像是園藝。
所有程式設計活動其實都是維護，因為絕大部分的時間都在改code，寫一點改一點。即使是新專案，也很快需要回頭作修改。
後兩篇是 A Conversation with Andy Hunt and Dave Thomas 訪談。Andy Hunt 和 Dave Thomas 是 The Pragmatic Programmer 這本經典的作者，他們後來共同創辦了 Pragmatic Bookshelf 這家出版社。其他五篇訪談也值得一看，都是關於軟體開發的真知灼見：
第一次在 Agile in a Flash 小卡上看到「守、破、離」還一頭霧水不知道在講什麼。最近因緣際會才終於了解意思，據說是出自於學習劍道的不同階段：
學習軟體開發又何嘗不是如此，無論是 Scrum、TDD 或是 Design Patterns，總是得先經歷一段照章行事「盡信書」的階段，循序漸進，才能融會貫通。而不是直接進到「黑貓白貓，會抓老鼠的就是好貓」「無招勝有招」「盡信書不如無書」的階段，直接把所有規範拋開。
例如，前一陣子 Kent Beck 大師 (TDD作者和XP發明人)在 stackoverflow 回答了一題測試要測多少深，答案竟然是 “I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence.” 可說是跌破眾人眼鏡 XD 但其實這種答案根本是第三階段的大師答案嘛，也就是「隨心所欲寫測試」的大師境界。如果從來沒學過寫測試，看到這句搞不好會說測試根本不重要，不需要學哩。所以搞清楚自己在哪個階段也是很重要的，當你聽到有人說「「X方法不重要，只要做的出來就好」時，要注意到大師已經練到可以隨心所欲，我們普通人還是先乖乖遵守「所有 production code 都應該要有對應的 test」培養寫測試的感覺跟經驗吧。
首先感謝 AgileCommunity.tw 辦了這場活動，大家討論的非常熱烈，分享了各自的團隊經驗，真是愉快的活動。
我投的題目是「從 Scrum 到 Kanban: 為什麼 Scrum 不適合 Lean Startup」，這個問題最早是我剛看 Lean Startup 時的小感想，加上被喲哪桑挖坑和自己的團隊施行 Scrum 所到碰到的問題和經驗。到底 Scrum 這麼多人推薦和著書的敏捷方法，會不會有什麼不一定適用的地方。所幸接著看到 Kanban and Scrum 這本書，作者將 Kanban 和 Scrum 做了比較，例如同一個 Limited WIP 的概念，不同工具只不過是用不同手法表現出來：Scrum 用 Sprint 固定開發週期，Kanban 用每一個流程狀態來限制。當我讀到這裡時，就體會到了工具只是工具，勿以器馭心。這又才解答了不少我對開發方法論的疑問。
所以我們團隊開始從 Scrum 改用 Kanban 了嗎? 目前算是某種混合的狀態吧，不是說用 Kanban 就要把 Scrum 的東西通通丟掉，就不斷地持續調整中：用 Kanban 增加了施工前和施工後的產品開發流程，並開始加上 WIP 限制。另一方面，則減少了 Sprint 固定開發週期的要求。
p.s. 「勿以器馭心」是宮本武藏的名言，出自簡體版的 Kanban and Scrum 翻譯
Update(2012/7/16): 由於投影片部分內容引用自 ezScrum 課程教材，不適宜公開，非常抱歉。他們的課程非常棒，推薦大家報名 Scrum敏捷方法實作班。
這是今天在公司內部講的 “敏捷開發與 Scrum” 投影片(大概花了一個小時講，加上另一個小時實作練習)，不是什麼經驗分享演講，畢竟還沒有 Scrum 的實際導入經驗 XD 所以只是東抄西抄整理重點，見笑了。
認識敏捷開發的精神不是第一次，但 Scrum 流程倒是頭一回。上回參加 Teddy 的 Scrum 課程，其中感觸最深的就是 cross-functional team 概念，全部 team members 都要參與 Story 討論與估計，無論其技術或設計背景。而上週末惡補 Scrum 書體會最深的則是 self-organized team 的 empowerment 和 accountable (賦權與當責)概念，可惜我還講的不好就是了。總之，學了 Scrum 流程，再回頭看敏捷宣言又有不同的體悟。
期待之後有更多實務經驗可以跟大家分享囉。
User stories 是一種非常好用且容易上手的需求文件，它是一種極簡主義，只要求寫下最有價值不要忘記的東西，而且夠讓我們足以估計時程以及與客戶溝通。
嚴謹、漂亮、詳細的文件有兩大危險，一是製作厲害的文件本身變成了一個目標，而不是製作軟體。二是語言本身是模糊的，”詳細”的文件會造成”確定性的幻覺”，以為規格都確定了無需要溝通，最後做出根本不符合預期的軟體。敏捷開發鼓勵我們將時間多花在開發者、客戶、使用者之間頻繁的溝通，而不是製作文件。
User Story(使用者敘述)是一段簡單的功能敘述，以客戶或使用者的觀點撰寫下有價值的功能(functionality/feature)。與其說它是規格文件(documentation)，不如說它代表(represent)客戶的一個需求而已，因為實做細節將延後至開發時才會確定。
幾個 User Stories 的範例如下：
初學的範本可以是：作為一個 (某個角色) 使用者，我可以做 (某個功能) 事情，如此可以有 (某個商業價值) 的好處。
As a (role of user), I want (some feature) so that (some business value).