古時候的簡報備份

1. 2009/11/03
eXtreme Programming
Introduction
eXtreme Programming
極道程式設計
Introduction
東海資工4A 952847
鄭新霖 <lancetw@gmail.com>

2. 2009/11/03
eXtreme Programming
Introduction
Agenda
eXtreme Programming (XP) 簡介
敏捷軟體開發流程
敏捷開發宣言
XP 的哲學思想
XP 的隱喻
XP 的精神
XP 的特色
XP 的概觀
XP 專案變數
XP 的 5 個基本價值觀
XP 開發流程的步驟與實務

3. 2009/11/03
eXtreme Programming
Introduction
eXtreme Programming (XP) 簡
介
這套方法主要來自 Kent Beck 身為物件導向軟體開發人
員的多年經驗
Kent Beck、Ward Cunningham、Ron Jeffries 於 1996 年 3
月在為克萊斯勒綜合報酬系統專案中，提出的軟體開發方
法
Kent Beck 於 1999 年 10 月 出版 《Extreme Programming
Explained》一書
Extreme Programming Explained:
embrace change (2nd Edition)
November 26, 2004
ISBN-13: 978-0321278654

4. 2009/11/03
eXtreme Programming
Introduction
敏捷軟體開發流程
XP 是敏捷軟體開發流程 (Agile Process) 的其中一種：
“Agile development uses feedback to make constant
adjustments in a highly collaborative environment.”
(敏捷開發是一個在高度合作的環境中不斷根據回應來
做修正的開發方式) – 《實戰敏捷開發》
「敏捷是一門社會科學。它關注的是如何讓大家像一個
團隊般工作、如何激勵成員、如何相互合作等等。」 -
Ivar Jacobson
實戰敏捷開發 Practices of an Agile Developer (1) 專業態度篇
http://ihower.idv.tw/blog/archives/1750

5. 2009/11/03
eXtreme Programming
Introduction
敏捷軟體開發流程
透過經常性地建構出可以實際使用的軟體，
我們持續得到回饋 (feedback)
程式碼會因為需求擴充而不斷地被修改重
構演進
工作的流程被拆成一至四周的短的反覆
(iterations)，每次透過 demo 得到回饋
(feedback)，確保方向正確。

6. 2009/11/03
eXtreme Programming
Introduction
敏捷開發宣言
2001 年 2 月，在美國猶他州的一個滑雪場，17位軟體開
發方法論的專家，共同發布了「敏捷開發宣言（The
Manifesto for Agile Software Development）」：
個人及互動勝於流程與工具（Individuals and interactions
over processes and tools）
可用的軟體勝於詳盡的文件（Working software over
comprehensive documentation）
與客戶合作勝於合約談判（Customer collaboration over
contract negotiation）
回應變化勝於墨守計畫（Responding to change over following
a plan）

7. 2009/11/03
eXtreme Programming
Introduction
XP 的哲學思想
《Extreme Programming Explained》書中所闡
述的哲學思想：
一種社會性的變化機制
一種開發模式
一種改進的方法
一種協調生產率和人性的嘗試
一種軟體開發方法

8. 2009/11/03
eXtreme Programming
Introduction
XP 的隱喻
Kent Beck 在書中提到，他的媽媽教他開車時不
是把方向盤固定不變在同一個位置，而是是持續
的注意，朝這邊作一些小小的修正，朝那邊作一些
小小的修正
既使事情似乎是進行的很完美，你也不能把你的
目光從道路移開
改變是唯一不變的原則，隨時準備朝這邊移動一
點點，朝那邊移動一點點
有時你可能必須朝向一個完全不同的方向，這是
程式設計師的生活

9. 2009/11/03
eXtreme Programming
Introduction
XP 的精神
欣然接受軟體需求是不斷變化的
(Embracing change)
引入基本價值、原則、方法等概念來達到
降低變更成本的目的
文件比不上面對面的溝通來的有效率
不去預想未來可能用到的功能
透過回饋瞭解目前的發展是否滿足委託人的需
求
勇於面對改變

10. 2009/11/03
eXtreme Programming
Introduction
XP 的特色
專案委託人必須是開發團隊的一部份
強調測試的重要性
簡單是最好的
(KISS Rule: Keep It Simple, Stupid - P.J.Plauger)
持續的建構和整合
建議以2週左右，由下而上快速循環
迅速作一次設計、測試、開發、交付的動作，而後檢討修
正，再開始下一個循環
在委託人與開發人員的共同參與下，一次次地修正，逐漸
達成目標

11. 2009/11/03
eXtreme Programming
Introduction
XP 的概觀
一種敏捷軟體開發流程
注重溝通與測試
多個小循環、往覆式 (Iteration) 的開發方法
強調團隊作業，管理者、委託人、開發人員，
缺一不可
特別適合應用在需求經常更改的領域
輕量級、低儀式性、高規範性
適合 2 ~ 12 人的小團隊

12. 2009/11/03
eXtreme Programming
Introduction
XP 專案變數
XP 認為，軟體專案有四個重要變數：
成本
無論給你幾個媽，生個孩子還是要十個月
有更多的錢也不能讓軟體更快交貨
品質
應該很少人會想降低品質...
時間
時間是客戶決定的
規模
規模事實上變動幅度相當大，需求在一開始絕不可能明朗
化，客戶也絕不可能說得出他們真正想要的是什麼
XP 認為規模是其中最容易控制的

13. 2009/11/03
eXtreme Programming
Introduction
XP 的 5 個基本價值觀
溝通 (Communication)
簡單 (Simplicity)
回饋 (Feedback)
勇氣 (Courage)
尊重 (Respect)

14. 2009/11/03
eXtreme Programming
Introduction
XP 的 5 個基本價值觀
溝通 (Communication)
XP鼓勵開發者之間，委託人與開發者之間經常的口頭
交流
簡單 (Simplicity)
回饋 (Feedback)
勇氣 (Courage)
尊重 (Respect)

15. 2009/11/03
eXtreme Programming
Introduction
XP 的 5 個基本價值觀
溝通 (Communication)
簡單 (Simplicity)
只開發符合目前需求的程式，不對將來可能的需求上
投入精力
回饋 (Feedback)
勇氣 (Courage)
尊重 (Respect)

16. 2009/11/03
eXtreme Programming
Introduction
XP 的 5 個基本價值觀
溝通 (Communication)
簡單 (Simplicity)
回饋 (Feedback)
來自系統：透過單元測試回饋目前的程式狀態給程式
設計師
來自委託人：功能性測試由委託人與測試人員撰寫，委
託人可以以此瞭解、掌控開發的進度
來自團隊：於專案會議時評估新需求並回饋給委託人
勇氣 (Courage)
尊重 (Respect)

17. 2009/11/03
eXtreme Programming
Introduction
XP 的 5 個基本價值觀
溝通 (Communication)
簡單 (Simplicity)
回饋 (Feedback)
勇氣 (Courage)
程式設計師有勇於重構、甚至完全丟棄目前程式碼，避
免陷入設計的泥潭
勇於改變，時時修正缺失
委託人要有勇氣參與 XP 流程
尊重 (Respect)

18. 2009/11/03
eXtreme Programming
Introduction
XP 的 5 個基本價值觀
溝通 (Communication)
簡單 (Simplicity)
回饋 (Feedback)
勇氣 (Courage)
尊重 (Respect)
團隊成員間互相尊重，保證提交的程式碼是可以運作
的，並堅持追求高品質與重構手段，找到最好的解決方
案

19. 2009/11/03
eXtreme Programming
Introduction
XP 開發流程的步驟與實務
1. 開發人員隨時可以和委託人進行有效溝通，撰寫使用者故事 (User
Stories) 以確認需求
2. 簡易快速的系統設計，撰寫獨立的驗證程式以解決特殊困難的問
題，找出演算法即可丟棄驗證程式
3. 規劃多次小型階段的專案計劃，以最快速度完成每一階段的程式交
付委託人，委託人負責驗收測試 (Acceptance Tests)
4. Coding 前必須先完成單元測試 (Unit Test) 與驗收測試的程式，所
有模組整合前都須經過單元測試
5. 開發人員必須快速回應 Bug 與需求變更
6. 要求二人一組使用一台電腦設計程式，當一人 Coding 時，另一人
負責思考與設計
7. 程式必須符合程式規範，並常做程式的重構 (Refactoring)
Ref: http://www.microsoft.com/taiwan/msdn/columns/rd/200311softdev.
htm

20. 2009/11/03
eXtreme Programming
Introduction
團隊合作 (Whole Team)
委託人也是團隊的一份子，協助團隊開發，
隨時可以被問問題
專案團隊裡擔任不同職務的成員可以互相
協助或替代，每個人都是多技能工
團隊成員間可以互相學習、成長

21. 2009/11/03
eXtreme Programming
Introduction
策劃遊戲 (Planning Game)
由委託人與開發團隊共同參與，確定一組需
在本時程內完成之功能的過程，這場遊戲
包括兩回合：
發行週期計畫（Release Plan）
制訂未來二到四個月內，需要完成的功能
反覆週期計畫（Iteration Plan）
制訂未來兩週內，需要完成的功能
「敏捷軟體開發」心得（三）：就算計畫趕不上變化，還是得規劃
http://bcl.robertchi.tw/2007/07/blog-post_30.html

22. 2009/11/03
eXtreme Programming
Introduction
系統隱喻 (System Metaphor)
利用說故事和打比方的方式，取代冗長而
難以理解的文件
盡量以易於了解的方式，表達需要的功能
避免專業術語干擾溝通，確保所有人的溝通
沒有誤解

23. 2009/11/03
eXtreme Programming
Introduction
使用者故事 (User Story)
從委託人的觀點出發，描述系統行為的簡短敘述
委託人和程式設計師溝通的媒介
希望由委託人撰寫，而不只是簽名，委託人需要思考他到
底要甚麼
當實作一個使用者故事時，開發者將拜訪委託人面對面討
論詳細的需求描述
委託人定義, 程式設計師建構
可讓焦點放在委託人的需求與利益，而不是技術上的細節
在1~2週內完成
Use cases - User Stories: so precious but not the same ! :
http://www.agile-ux.com/2009/01/23/use-cases-user-stories-so-precious-
but-not-the-same/

24. 2009/11/03
eXtreme Programming
Introduction
簡單設計 (Simple Design)
只設計目前需要功能，不去預想未來可能用到的功能，因
為需求在未來是會不斷改變的
簡單的設計更容易用於溝通與除錯
以更簡單的方法重構程式碼
盡可能地使用最簡單的工具
手寫的 CRC 卡
以便利貼與白板塑模 (Modeling)
在紙上描述資料表或設計使用者介面雛型
是「使用最簡單的工具」而不是「使用簡單的工具」
http://tzuchieh.miroko.tw/sdp/simpleTools.htm

25. 2009/11/03
eXtreme Programming
Introduction
CRC Cards
XP 方法論推薦使用 CRC 卡片來設計系統，讓團隊成員都
能完全趨向物件技術，進行 CRC 會議使整個團隊都能貢
獻於設計
CRC 代表類別 (Class)、責任 (Responsibilities) 和合作
(Collaborators)

26. 2009/11/03
eXtreme Programming
Introduction
搭檔程式設計 (Pair Programming)
兩個人共同開發一支程式
一個人寫程式，另一個人看程式，檢視是否有錯誤
或可改進的地方
兩人經常互換角色
目的是藉由充分的溝通與交流提升團隊整體的能
力
Why Pair Programming Works:
http://cafe.elharo.com/programming/why-pair-programming-works/
敏捷方法實務研討會會後筆記1 - 溝通與 Pair programming
http://blog.roodo.com/rocksaying/archives/3479401.html

27. 2009/11/03
eXtreme Programming
Introduction
測試驅動開發 (Test-Driven
Development, TDD)
測試驅動開發是 XP 的基石
測試先行 (Test First)
在寫程式之前，先寫可以自動及重複執行的單元測試
(Unit Tests) 程式
循環漸進
每次寫程式的「週期 (Cycle)」 變得更短，甚至一次還寫
不到一整個 Class 的量，而是一次幾行、或一個
Method。
一點測試、寫一點程式、一點測試、寫一點程式

28. 2009/11/03
eXtreme Programming
Introduction
XP 寫程式碼的 5 分鐘週期
寫一個測試程式
編譯該測試程式。應該不會過，因為你還沒寫測試程式要測的那個程
式
寫剛好夠測的程式，然後編譯（如果必要的話，先進行程式重構）
執行測試程式，看著它不過
寫「剛好讓測試程式能通過」的程式量
執行測試程式，看著它過
重構程式，讓架構變得更清晰，並去除掉程式碼重複的部分
重複整個流程 （一次流程 1~5分鐘）
《極端軟體製程-探索篇》
碁峰，ISBN: 986-421-149-8

29. 2009/11/03
eXtreme Programming
Introduction
測試先行的好處
使得程式是可以被自動、重複測試
可透過測試確認程式功能是否完成
測試程式形同程式文件
因測試程式使得程式設計簡單化 (寫出的程
式是為了剛好足夠通過測試)

30. 2009/11/03
eXtreme Programming
Introduction
重構 (Refactoring)
時常重構，不斷重構
勇於以更簡單的方法改善原先的設計
保持程式碼是乾淨，更容易被理解的
使用版本控制系統與其他工具協助重構工
作

31. 2009/11/03
eXtreme Programming
Introduction
程式碼共享 (Collective Code
Ownership)
團隊的每個成員都有機會轉換與不同的對
象搭檔，合作開發系統的各個部分
所有人也就都有能力修改與維護系統的每
個部分
程式碼共享就是方法之一
使用版本控制系統協助程式碼共享

32. 2009/11/03
eXtreme Programming
Introduction
持續整合 (Continuous Integration)
當一組搭檔共同完成一個使用者故事，並通
過單元測試過後，便可以將程式簽入集中管
理的版本控制系統，重新建構一次系統
可以讓開發團隊與委託人了解系統現階段
確實可執行的功能是否符合需求

33. 2009/11/03
eXtreme Programming
Introduction
小規模發行 (Small Releases)
通常開發團隊是依據 Story Card 切割工作
每完成一個 Story Card，就發行最新、可執
行的版本，交由委託人驗收
委託人可以以此確認專案是否符合期望，進
而回饋意見給開發團隊作為持續改進的參
考

34. 2009/11/03
eXtreme Programming
Introduction
XP 12 項實務
小規模回饋 (Fine scale feedback)
搭檔程式設計 (Pair programming)
策劃遊戲 (Planning game)
測試驅動開發 (Test-driven development)
團隊合作 (Whole team)
持續性流程 (Continuous process)
持續整合 (Continuous integration)
重構或改善設計 (Refactoring or design improvement)
小規模發行 (Small releases)
共識 (Shared understanding)
程式設計標準 (Coding standards)
程式碼共享 (Collective code ownership)
簡單設計 (Simple design)
系統隱喻 (System metaphor)

35. 2009/11/03
eXtreme Programming
Introduction
XP 12 項實務
程式設計師的福祉 (Programmer welfare)
可持續的步調 (Sustainable pace)
寫程式 (Coding)
委託人要隨時可以聯絡到 (The customer is always available)
先寫單元測試 (Code the Unit test first)
一次只有一組搭檔整合程式碼 (Only one pair integrates code at a time)
直到最後才作最佳化 (Leave Optimization till last)
決不加班 (No Overtime)
測試 (Testing)
所有程式碼必須要有單元測試 (All code must have Unit tests)
所有程式碼必須在發行之前通過單元測試 (All code must pass all Unit tests
before it can be released)
一找到瑕疵就建立測試 (When a Bug is found tests are created before the bug is
addressed (a bug is not an error in logic, it is a test you forgot to write))
經常執行驗收測試並公布結果 (Acceptance tests are run often and the results are
published)

36. 2009/11/03
eXtreme Programming
Introduction

37. 2009/11/03
eXtreme Programming
Introduction
參考資料
敏捷的軟體開發流程
http://www.microsoft.com/taiwan/msdn/columns/rd/200311softdev.htm
Extreme Programming: A Gentle Introduction
http://www.extremeprogramming.org/
Xprogramming.com
http://xprogramming.com
Extreme Programming FAQ
http://www.jera.com/techinfo/xpfaq.html
開放流程的開發方法論—Extreme Programming
http://www.openfoundry.org/index.php?option=com_content&id=491&lang=en&task=view
極致軟體製程 – Chapter 4 軟體製程的四個變數
http://tzuchieh.miroko.tw/Jyemii/xpcolumn/xpexplained/Chapter4.htm
XP方法論英語先修班
http://www.ithome.com.tw/itadm/article.php?c=45045
XP訴求以最佳智慧做出客戶最想要的東西
http://www.ithome.com.tw/itadm/article.php?c=39401&s=6
http://tzuchieh.miroko.tw/xp/XP.htm

38. 2009/11/03
eXtreme Programming
Introduction
參考資料
{iThome 書評—11} Test Driven Development By Examples
http://kenming.blog.ithome.com.tw/post/296/16975
極端軟體製程－探索篇
http://jyhshin2.blogspot.com/2009/02/blog-post_23.html
極限編程
http://zh.wikipedia.org/zh-tw/%E6%9E%81%E9%99%90%E7%BC%96%E7%
A8%8B
{iThome 書評—4} 極致軟體製程中譯本
http://kenming.blog.ithome.com.tw/post/296/10956
XP的價值標準
http://xieliming.blogspot.com/2009/04/xp_29.html
User Stories 二三事
http://www.wretch.cc/blog/kojenchieh/13364440
關於 XP(eXtreme programming)
http://tzuchieh.miroko.tw/xp/XP.htm
書評－敏捷開發－以人為本，擁抱改變
http://www.ithome.com.tw/itadm/article.php?c=39265

39. 2009/11/03
eXtreme Programming
Introduction
Thank you !