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

笑談軟體工程:敏捷開發法的逆襲這一本書是ㄚ琪這一週借來翻閱的書,看了前面幾章之後感覺是以部落格文章寫作的方式來出書,很像是嵌入式系統開發之道:菜鳥成長日誌與專案經理的私房菜寫作方式,不過這樣也好,應該比較多人可以接受吧。想要知道這書究竟可以看博客來簡介↓↓↓↓↓↓↓

[adsense][/adsense]

導入Scrum,讓你的軟體開發人生從黑白變彩色!


  ●最務實的敏捷方法。從需求分析、程式開發、軟體架構、UI設計、軟體測試、持續整合 ─ 軟體工程的全新思維

●最幽默、簡單、輕鬆的Scrum導論。沒有艱深的學術論述、索然無趣的古典教條─ 一讀就懂的敏捷方法

最重要的是,從此每天準時下班享受幸福人生!

用笑聲取代淚水,用準時下班取代爆錶的肝指數!

本書將扭轉你對軟體開發專案錯誤,但卻一直以來根深蒂固的想法。作者多年的軟體專案執行經驗,透過詼諧且幽默的文筆,讓你在笑聲中搞懂Scrum的精神及相關實務做法。

● 什麼是Scrum——Role、Activity、Artifact的精闢解析。
● 如何做到精實?徹底終結不必要的浪費吧。
● 軟體架構要從Solution Domain,還是從Problem Domain著手?
● 人機介面的設計原則有哪些?
● 你知道測試與整合有多重要嗎?

目錄:

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

這本書有個副標題導入Scrum,讓你的軟體開發人生從黑白變彩色!

看來要推薦Scrum,那就讓我們看看維基說明吧↓↓↓↓↓↓↓

Scrum是一種迭代式增量軟體開發過程,通常用於敏捷軟體開發。Scrum在英語的意思是橄欖球里的爭球。
雖然Scrum是為管理軟體開發項目而開發的,它同樣可以用於運行軟體維護團隊,或者作為計劃管理方法。Scrum之間的合作稱為「Scrum of Scrums」。

ㄚ琪看了前面三章之後,比較感興趣的倒是自動化測試,原因無它,我們寫出的程式真的需要測試,為了趕件賺錢,常常就是把客戶當測試人員,結果應該會被罵得很慘吧,呵呵~不過看來也沒那麼簡單吧,所以就讓ㄚ琪繼續看下去…
arrow
arrow
    全站熱搜

    ivacation 發表在 痞客邦 留言(0) 人氣()