笑談軟體工程：敏捷開發法的逆襲

Chapter 02.

老闆，軟體不是這樣開發的



N年前，台北捷運藍線（板南線）通車之後，有一天Teddy 和第一份工作的老闆朱先生一起搭捷運（忘了去做什麼好事）。上車之後，Teddy 和朱先生聊到捷運的方便性：



Teddy：捷運通車之後節省了很多通勤時間。



朱先生：我認為節省時間還不是最重要的，而是捷運使得通勤時間變得可預測，會因此改變人們的行為模式。



當時捷運木柵線還沒有遇到強烈月光而變身為「柵湖線」，否則朱先生就不會這麼說了。



重點來了，速度快當然很重要，但捷運的可預測性卻是改變人們生活習慣的主要因素。Teddy第一份工作的公司剛好在台北捷運忠孝敦化站附近，在沒有捷運之前，Teddy搭公車至少要40~50 分鐘才能到公司（還不包括等公車時間）。有時候趕時間搭計程車也不一定比較快，雖然平常覺得台北的計程車多的跟螞蟻一樣，但是上班時間經常等了很久也攔不到一輛空的計程車。所以，為了不想上班或是約會遲到，就必須要提早出門以容忍這些不可預測性。有了捷運之後，從甲地到乙地（假設都在捷運沿線）的通勤時間就變得比較可預測。因此，無論是人們買房子、找工作、開店、約會見面，就經常會挑選捷運沿線。這就是所謂的「改變人們生活習慣」。



可預測性相當大的程度是立基於可靠性（reliability）之上。以路上交通而言，高鐵速度夠快了吧，時速300公里，台北到高雄90分鐘，好方便啊（也好貴）！如果今天有人發明時速9000公里的超級高鐵，從台北到高雄縮短到只要3分鐘，但是有0.01%的出事率（就是平均搭一萬次會有一次翻車的機率）。除非是想要賺保險費，不然應該沒人敢搭。



所以，有一陣子「柵湖線」被罵到臭頭也是相同的原因。通車之後的確變得很方便，但是它的不可靠性卻總是讓乘客們「心裡毛毛的」。搭完「柵湖線」沒出事的話，內心的感受有點像是不小心中了200塊發票般湧起一絲小小的安慰。大眾運輸能蓋成這樣子，也算是「台北奇蹟」了。













但是，做軟體就不一樣喔，反正軟體出包又不會「死人」。因此，這種「先研究不傷身體，再講求療效」的理論就不適用。做軟體有自己的一套公式：



( 交貨速度 = 收錢速度) >>>>> 軟體品質



所以，你的老闆便可以理歪氣壯的大聲說出以下名言：

• 做專案的不需要自動化測試，做產品才要。

• 解600多個bug要靠「專業領域知識（domain know-how）」很強的人來幫忙。（Teddy內心獨白：老闆，啊你嘛幫幫忙）

• 沒有測試人員沒關係，工程師自己測這樣就很好了。

• 這個軟體可以準備上市了，先找幾個客戶試用。（小工程師內心獨白：報告老闆，軟體連內部測試都還沒開始ㄟ）

• 軟體現在不能上市?! 我已經等了N 年了，我不想再等另一個N年。

• 我最多給你三天，在三天之內把這個bug

Chapter 02.
老闆，軟體不是這樣開發的

N年前，台北捷運藍線（板南線）通車之後，有一天Teddy 和第一份工作的老闆朱先生一起搭捷運（忘了去做什麼好事）。上車之後，Teddy 和朱先生聊到捷運的方便性：

Teddy：捷運通車之後節省了很多通勤時間。

朱先生：我認為節省時間還不是最重要的，而是捷運使得通勤時間變得可預測，會因此改變人們的行為模式。

當時捷運木柵線還沒有遇到強烈月光而變身為「柵湖線」，否則朱先生就不會這麼說了。

重點來了，速度快當然很重要，但捷運的可預測性卻是改變人們生活習慣的主要因素。Teddy第一份工作...

PART 1 軟體工程的現況
1 想看這本書的怨念有多深
2 老闆，軟體不是這樣開發的
3 600多個BUG要怎麼修？
4 軟體工程不等於髒話
5 這不是網路小說——軟體專案Scenario
Column A. 小朋友不可以說謊喔

PART 2 什麼是Scrum
6 SCRUM到底是？
Column B. 其實，Scrum是一種制度
7 SCRUM是很有內涵的
8 就是這個光──SCRUM＋LEAN＋XP
9 導入SCRUM？謝謝再聯絡。
10 我不能採用SCRUM，因為我家人不同意
11 導入Scrum前該有的領悟──都市游擊隊
12 100%符合Scrum精神──這是0與1的距離
13 不完美的Scrum──逆練九陰真經
14 Story要如何下筆？──啊！你練的不是九陰真經
15 end-to-end的story──這好比切蛋糕
16 如何估算Story Point？
17 Story Point為何沒有單位──這是一種相對論
18 Story寫的好才容易估算Story Point
19 Product Backlog長得什麼模樣？
20 The Definition Of Done──功課寫完沒
21 Bug”s”──放下心中舉起的中指
22 Redundancy──容錯的基本方法
23 Shared Code──讓我們變成博格人吧
24 Pair Programming──藥效強不強？
25 Retrospective Meeting──有許願池的功效
26 Scrum Master是個什麼咖？
27 有牌的Certified Scrum Master
Column C. 聞過則喜...誰說的？
28 導入Scrum──要有傳福音的精神
Column D. TEDDY的初衷

PART 3 精實生產，減少不必要的浪費
29 軟體也會有庫存問題
30 減少不必要的浪費——半成品
31 減少不必要的浪費——多餘功能
32 減少不必要的浪費——重複學習
33 減少不必要的浪費——交接
34 減少不必要的浪費——工作切換
35 減少不必要的浪費——延遲
36 減少不必要的浪費——缺陷
37 有缺陷，就停掉生產線

PART 4 開發軟體一定要加班，有沒有聽錯？
38 工程師與加班之間的愛恨情仇
39 非加班不可——台灣經濟奇蹟的幕後無名英雄
40 過勞死——軟體工程無用論
41 我可能不會18:30下班
Column E. 秀才遇到兵

PART 5 換顆腦袋——軟體工程的全新思維
42 學習犯錯
43 有問題才能解決真問題
44 傳承的風範
45 傻的願意相信
46 造船的目的
47 追求卓越——發語詞，無義
48 培育軟體還是組裝軟體？
49 對症下藥
Column F. ISO大戰乖乖
50 剽竊
51 重複程式碼的力量
52 TIME LOG的紀錄方式——這不是整人遊戲

PART 6 軟體架構
53 Problem Domain vs. Solution Domain
Column G. 一萬個小時的練習
54 用實際案例看Problem Domain vs. Solution Domain
55 要抄就要抄最好的——人人皆可成為架構師
56 你的軟體架構有多軟
57 設計最難的部份是什麼？
58 針對介面來寫程式
59 設計模式分成三大類
60 時間到

PART 7 人機介面
61 窮人的「人機介面」設計入門
62 GOMS——幫「人機介面」做體檢
63 DESIGNING FOR ERROR (1)：使用者犯錯
64 DESIGNING FOR ERROR (2)：外在世界與腦袋中的知識
65 DESIGNING FOR ERROR (3)：限制、強制功能、自然對應
66 DESIGNING FOR ERROR (4)：執行與評估
67 「人機介面」之博士熱愛的算式

PART 8 測試與整合
68 有測試案例改遍天下，無測試案例寸步難行
69 有些事不是能力的問題，而是整合
70 土炮跨平台自動化功能測試環境
71 10分鐘建構
72 落實測試與整合的能力有多少？
73 用ROBOT寫自動化功能測試到底有沒有用？
Column H. 需求分析書中最重要的資訊是什麼？

PART 1 軟體工程的現況
1 想看這本書的怨念有多深
2 老闆，軟體不是這樣開發的
3 600多個BUG要怎麼修？
4 軟體工程不等於髒話
5 這不是網路小說——軟體專案Scenario
Column A. 小朋友不可以說謊喔

PART 2 什麼是Scrum
6 SCRUM到底是？
Column B. 其實，Scrum是一種制度
7 SCRUM是很有內涵的
8 就是這個光──SCRUM＋LEAN＋XP
9 導入SCRUM？謝謝再聯絡。
10 我不能採用SCRUM，因為我家人不同意
11 導入Scrum前該有的領悟──都市游擊隊
12 100%符合Scrum精神──這是0與1的距離
13 不完美的Scrum──逆練九陰真經
14...