分類
Agile Software Development

Release It! 讀書摘要

Release It! 第一版出版於 2007,獲得了 2008 年的 Jolt Awards 獎。第二版是 2019 年出的,跟第一版差了11年,二版前半段講 Stability 的內容一樣,這也是我認為這本書最精彩的部分。而二版整個後半章節幾乎用全新的 DevOps 內容改寫了,十年間的變化還是很大的 :>

這裡摘要第一版 + 第二版上半的一些心得重點,第二版下半段講 DevOps 這幾年講很多了,很多知識點這幾年很熱門都知道了,就沒有細看了。

何謂 Stability

Resilient system 在當有突發流量或持續壓力時,用戶仍能完成任務不會全面崩潰。

分類
Agile

深入淺出探索式測試工作坊 筆記

2018/9/1 去參加了 David Ko 大大的課程,對於軟體測試有了新的認識,幾個重要收穫: 

  • 做測試最重要的就是找到 bugs、得到品質資訊。不管用什麼測試技術,如果找不到 bug 就沒用
  • 自動化測試只能找到已知問題,而不是新 bugs
  • 90% 的 bugs 是從手動測試中找出來的
  • 但是,其中又有多少是從先寫好的 test case (plan) 中找出來的呢?
  • 只從 test caes 中去找,也不會一直找出新 bugs
  • testing = 檢查(scripted test: ST) + 探索(ET)
  • 檢查只是照表操課
分類
Agile Software Development

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

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

淺談 Startup 公司的軟體開發流程 from Wen-Tien Chang

感謝 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 就要關注全局,參與產品設計與營運

分類
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」培養寫測試的感覺跟經驗吧。

分類
Agile

從 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: 為什麼 Scrum 不適合 Lean Startup from Wen-Tien Chang

所以我們團隊開始從 Scrum 改用 Kanban 了嗎? 目前算是某種混合的狀態吧,不是說用 Kanban 就要把 Scrum 的東西通通丟掉,就不斷地持續調整中:用 Kanban 增加了施工前和施工後的產品開發流程,並開始加上 WIP 限制。另一方面,則減少了 Sprint 固定開發週期的要求。

p.s. 「勿以器馭心」是宮本武藏的名言,出自簡體版的 Kanban and Scrum 翻譯