Agile software development introduction.

1. Agile development(敏捷開發)
2014/04/03
Sway Wang

2. Outline
• 傳統的軟體工程
• 敏捷開發(Agile development)
• Extreme Programming
• Scrum
• 實務上常使用的工具
• 結論

3. 傳統的軟體工程
• Capability Maturity Model Integration(CMMI)
• UML
• 瀑布式開發(Waterfall Development )
• 強調寫文件的重要性
•需求分析規格書
•系統分析規格書
•系統設計規格書
•系統測試設計規格書
•系統測試計畫書
•系統測試報告書

4. Use-case diagram

5. Class diagram

6. Sequence diagram

7. 敏捷開發(Agile development)
• 1995年後，陸續有人提出敏捷開發的觀念
• Lightweight agile software development methods
•主張軟體有容易改變的特性，改變是無法避免的
•擁抱改變以及即時回饋
• Small release (release週期短，2周~一個月)

8. The Agile Manifesto (敏捷宣言)
•Individuals and interactions over processes and tools
•Working software over comprehensive documentation
•Customer collaboration over contract negotiation
•Responding to change over following a plan
個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商
回應變化 重於 遵循計劃
雖然右側項目有其價值，但我們更重視左側項目。
http://agilemanifesto.org/

9. The Agile Principles (敏捷原則)
•最為優先的事情是透過早期與持續交付有價值的軟體來使客戶滿
意。
•歡迎需求的變動，即使是在開發的晚期。敏捷式流程駕馭變動來
作為客戶的競爭優勢。
•頻繁的交付工作產生的軟體，自數週至數月，週期越短越好。
•領域專家與開發成員必須一同作業，並貫穿整個專案開發時期。
•使用積極的工作成員來建構專案，給予他們環境以及支援所需的
一切，然後信任他們能夠完成工作。

10. The Agile Principles (敏捷原則)
•在開發團隊中最快也最有效的傳遞資訊方法就是面對面的溝通。
•工作產生的軟體是衡量進度最主要的依據。
•敏捷式流程倡導水平一致的軟體開發
•專案發起者，開發人員以及使用者都必須持續的維持專案進度。
•持續重視技術的優勢以及設計品質
•最好的架構、需求以及設計會出現在能夠自我管理的團隊裡
•在規律的反覆之間，團隊會反省與思考如何更有效率，然後相對
的來調整與修正團隊的開發方式。
http://agilemanifesto.org/principles.html

11. Reference Book
http://www.amazon.com/Software-Development-
Principles-Patterns-Practices/dp/0135974445

12. Extreme Programming(XP)
•Extreme Programming was created by Kent Beck(Facebook)
•強調自動測試和軟體品質
•Pair programming
•Unit test(單元測試)
•Code review
•Refactoring (重構)
•Test driven development(TDD)
•測試程式取代文件

13. Reference Book
http://www.amazon.com/Extreme-Programming-
Explained-Embrace-Edition/dp/0321278658

14. Pair Programming
• 兩人共用一台電腦一起開發程式
• 常見疑問：生產力減半
• 軟體品質 v.s.
軟體開發速度
• 優點
– 軟體品質佳
– 經驗傳承
– 同份code有兩個人懂

15. Unit Test(單元測試)
• 測試單一模組的正確性 (比如說函式或類別)
• 在修改程式碼後通常會重跑一次所有的單元測試，確認功能正常
• 如何讓程式容易被測試是一門學問
– Class之間低耦合
– 高模組化
– 所有邏輯都寫在main或一個if的程式難以被測試
• 自動測試framework
– C#: Nunit
– Java: JUnit

16. Code review
• (Google)使用者commit code時會先執行
coding style檢查，並由系統分配一位
reviewer進行code review。

17. Refactoring(重構)
• XP鼓勵經常做重構
• 要有完整的單元測試下才能進行重構

18. Test Driven Development(TDD)
• 開始實做程式碼前先寫測試程式
• 通過所有測試程式後程式就開發完成
• 優點：
– 開發程式時自然會容易測試
– 寫測試程式時可以順便釐清問題

19. Scrum
• 更精簡的一種敏捷開發方法
• 不需要複雜的基礎建設，使用便條紙管理
Item

20. Daily Meeting
昨天做了什麼事？(或 今天做了什麼事, 依開會時間而定)
今天要做什麼事？(或 明天要做什麼事, 依開會時間而定)
工作上是否遇到任何阻礙或問題？(主持者(Scrum Master)必須快速解決成員
所遇到的困難。)

21. 實務上常搭配的工具

22. Version Control System

23. Issue Tracking System
• 改善傳統Email + Excel 的方法
• Ex: Redmine, trac, mantis
• 團隊內部透明
• 處理事項目前的執行狀態
• 優先權的分配
• 執行人
• Wiki功能

24. Continuous integration(持續整合)
• CI Server
• 固定時間自動從SVN上check out code編
譯(Daily build)
• 自動執行單元測試以及靜態程式碼分析工
具
• 產生報表和email通知相關人員

28. OOP
• 要寫出好的測試程式，程式的架構很重要

29. 結論
• 敏捷開發對團隊內成員個人能力要求較高
• 目前主流開發方式是混用各種方法的適合
團隊的地方，調整成適合內部使用的方法

30. Q & A
• Thanks for your listening!!