Teddy Scrum 敏捷開發法的逆襲

搞笑談軟工 (http://teddy-chen-tw.blogspot.tw/) 一直是工作上的最佳良伴，具有調劑身心與增進智能的功效，呷(ㄒㄧㄚˊ )好到相報！

最近作者終於推出「敏捷開發法的逆襲」這本書了，所有開發軟體、吃「軟飯」的人都該買來讀啊！由於 Teddy 是北科大的校友，在此強力推薦一下 Teddy 的敏捷開發法的逆襲，建議北科大應該要將此書列入軟體學程的必修課與教科書。引用 Teddy 的話：「不買終身遺憾，買了不看遺憾終身。p. 284」

讀完「敏捷開發法的逆襲」的最大收穫在於了解什麼是 Scrum (整本書的主題是在講述Scrum 和搞笑)，作者基於傳福音的精神推廣 Scrum 給大家，這本書可說是 Scrum 的中文聖經本，信Scrum得永生(台灣目前應該還找不到專門介紹 Scrum 的中文書)。

而最近自己工作的環境也開始導入 Scrum，初淺地認識 Scrum 之後，我認為要「導入 Scrum，先換腦袋」(換誰的腦袋？老闆的還是 RD, PM 的...全部都該換掉)，因為 Scrum 有些觀念與現在台灣的軟體開發觀念不同，做法也不同，習慣於這個制度之下很難開始改變 (不是不能改變，要改變就可能要革命囉...)。

陳建村 (Teddy Chen)，笑談軟體工程：敏捷開發法的逆襲，台北：悅知文化，2012。

笑談軟體工程可以依序閱讀，也可以挑選有興趣的 PART 閱讀，或是擇一篇文章閱讀，這幾種方式都不會造成閱讀上的困擾或困難(意思是說書沒架構嗎？不是啦，因為Teddy用軟體工程的方式降低耦合)，不過還是建議依序閱讀吸收會較快，我大概花了3天的瑣碎時間依序看完，真的很好看，也吸收到搞笑能力...

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. 需求分析書中最重要的資訊是什麼？

這裡用 Teddy 的夢想總結：「希望改變人們在台灣開發軟體的方法，讓軟體開發真正成為一件愉快、有趣的工作與創作。」是的，以 Teddy 的燭火點燭，光亮與我們同在，我們卻不因此身處黑暗。

###