Category Archives: Agile

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

Agile, Software Development

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 的設計，還在努力學習中。

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

Agile, Programming, Software Development

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

第一次在 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

Agile

首先感謝 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 分享投影片

Agile

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?

Agile

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? →