Category Archives: Agile

淺談 Startup 公司的軟體開發流程 投影片

Update(2016/3): 投影片新增第四階段:營運成長

感謝 David Ko 的邀請,在 Agile Tour Hsinchu 給一場分享講軟體開發流程,內容就東拼西湊這幾年在 startup 公司學到和用到的東西,沒想到迴響還不錯,得到的評價是很實用,摘要如下:

  1. 需求收集
    • Lean Startup: MVP
    • 用 User Stories 描述
    • 善用線上協同工具 Quip 或 Hackpad
  2. 實作
    • 專案管理: Scrum 或 Kanban
    • 不重複發明輪子
    • 用 Wireframe 做設計
    • 寫自動化測試
    • 用版本控制系統 Git 搭配 Github flow 或 git flow
  3. 佈署上架
    • 自動化部署程序
    • 善用第三方 Monitor 和通訊工具 Slack
    • 使用 Metrics 量測
  4. 最後:在 Startup 就要關注全局,參與產品設計與營運

比較可惜的是 Measuring 資料分析這一塊還沒有做好做滿。投影片裡面只有放一張倒不是因為時間不夠,主要是因為我也還不太會實務(XD),知道非常重要,但是要怎麼做才能融入在 startup 的基因裡面、如何在產品的每個環節納入 Data-Driven 的設計,還在努力學習中。

程式設計不像建築工程,而是園藝維護

Update: Real Software Engineering by Glenn Vanderburg 這場演講也值得一看

前一陣子念「笑談軟體工程:敏捷開發法的逆襲」這本書,其中有幾篇文章的說法和比喻常被引用,所以我按圖索驥,也把原文章拿出來念一念,包括:

1. What Is Software Design? by Jack W. Reeves

「原始碼就是設計」「 Source code is the design」,避免花費太多時間在分析設計上,原始碼本身就是是軟體設計的產生,而 compile, link 等才是軟體的生產活動。因此,寫程式是「設計」的活動,而不是「生產」的活動,因此傳統設計文件的重要性就大大降低了。

程式設計不是 “building software”,而是 “designing software”。

2. Is Design Dead? by Martin Fowler

軟體系統的設計是演進來的,不能一步到位,而是要藉由憑繁與使用者互動得到的回饋來修改系統設計。

3. Programming is Gardening, not Engineering

與其把程式設計比喻成蓋房子,實際上更像是園藝。

4. Orthogonality and the DRY Principle

所有程式設計活動其實都是維護,因為絕大部分的時間都在改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」培養寫測試的感覺跟經驗吧。

從 Scrum 到 Kanban: 為什麼 Scrum 不適合 Lean Startup

首先感謝 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 翻譯

敏捷開發與 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 (1) 什麼是 User Story?

User stories 是一種非常好用且容易上手的需求文件,它是一種極簡主義,只要求寫下最有價值不要忘記的東西,而且夠讓我們足以估計時程以及與客戶溝通。

嚴謹、漂亮、詳細的文件有兩大危險,一是製作厲害的文件本身變成了一個目標,而不是製作軟體。二是語言本身是模糊的,”詳細”的文件會造成”確定性的幻覺”,以為規格都確定了無需要溝通,最後做出根本不符合預期的軟體。敏捷開發鼓勵我們將時間多花在開發者、客戶、使用者之間頻繁的溝通,而不是製作文件。

什麼是 User Story?

User Story(使用者敘述)是一段簡單的功能敘述,以客戶或使用者的觀點撰寫下有價值的功能(functionality/feature)。與其說它是規格文件(documentation),不如說它代表(represent)客戶的一個需求而已,因為實做細節將延後至開發時才會確定。

幾個 User Stories 的範例如下:

  • 使用者可以在網站上張貼履歷
  • 使用者可以搜尋有哪些工作
  • 公司可以張貼新工作
  • 使用者可以限制誰可以看到他的履歷

初學的範本可以是:作為一個 (某個角色) 使用者,我可以做 (某個功能) 事情,如此可以有 (某個商業價值) 的好處。

As a (role of user), I want (some feature) so that (some business value).

Continue reading User Stories (1) 什麼是 User Story?