Agile development

552 views
397 views

Published on

Agile software development introduction.

Published in: Software, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
552
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Agile development

  1. 1. Agile development(敏捷開發) 2014/04/03 Sway Wang
  2. 2. Outline • 傳統的軟體工程 • 敏捷開發(Agile development) • Extreme Programming • Scrum • 實務上常使用的工具 • 結論
  3. 3. 傳統的軟體工程 • Capability Maturity Model Integration(CMMI) • UML • 瀑布式開發(Waterfall Development ) • 強調寫文件的重要性 •需求分析規格書 •系統分析規格書 •系統設計規格書 •系統測試設計規格書 •系統測試計畫書 •系統測試報告書
  4. 4. Use-case diagram
  5. 5. Class diagram
  6. 6. Sequence diagram
  7. 7. 敏捷開發(Agile development) • 1995年後,陸續有人提出敏捷開發的觀念 • Lightweight agile software development methods •主張軟體有容易改變的特性,改變是無法避免的 •擁抱改變以及即時回饋 • Small release (release週期短,2周~一個月)
  8. 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. 9. The Agile Principles (敏捷原則) •最為優先的事情是透過早期與持續交付有價值的軟體來使客戶滿 意。 •歡迎需求的變動,即使是在開發的晚期。敏捷式流程駕馭變動來 作為客戶的競爭優勢。 •頻繁的交付工作產生的軟體,自數週至數月,週期越短越好。 •領域專家與開發成員必須一同作業,並貫穿整個專案開發時期。 •使用積極的工作成員來建構專案,給予他們環境以及支援所需的 一切,然後信任他們能夠完成工作。
  10. 10. The Agile Principles (敏捷原則) •在開發團隊中最快也最有效的傳遞資訊方法就是面對面的溝通。 •工作產生的軟體是衡量進度最主要的依據。 •敏捷式流程倡導水平一致的軟體開發 •專案發起者,開發人員以及使用者都必須持續的維持專案進度。 •持續重視技術的優勢以及設計品質 •最好的架構、需求以及設計會出現在能夠自我管理的團隊裡 •在規律的反覆之間,團隊會反省與思考如何更有效率,然後相對 的來調整與修正團隊的開發方式。 http://agilemanifesto.org/principles.html
  11. 11. Reference Book http://www.amazon.com/Software-Development- Principles-Patterns-Practices/dp/0135974445
  12. 12. Extreme Programming(XP) •Extreme Programming was created by Kent Beck(Facebook) •強調自動測試和軟體品質 •Pair programming •Unit test(單元測試) •Code review •Refactoring (重構) •Test driven development(TDD) •測試程式取代文件
  13. 13. Reference Book http://www.amazon.com/Extreme-Programming- Explained-Embrace-Edition/dp/0321278658
  14. 14. Pair Programming • 兩人共用一台電腦一起開發程式 • 常見疑問:生產力減半 • 軟體品質 v.s. 軟體開發速度 • 優點 – 軟體品質佳 – 經驗傳承 – 同份code有兩個人懂
  15. 15. Unit Test(單元測試) • 測試單一模組的正確性 (比如說函式或類別) • 在修改程式碼後通常會重跑一次所有的單元測試,確認功能正常 • 如何讓程式容易被測試是一門學問 – Class之間低耦合 – 高模組化 – 所有邏輯都寫在main或一個if的程式難以被測試 • 自動測試framework – C#: Nunit – Java: JUnit
  16. 16. Code review • (Google)使用者commit code時會先執行 coding style檢查,並由系統分配一位 reviewer進行code review。
  17. 17. Refactoring(重構) • XP鼓勵經常做重構 • 要有完整的單元測試下才能進行重構
  18. 18. Test Driven Development(TDD) • 開始實做程式碼前先寫測試程式 • 通過所有測試程式後程式就開發完成 • 優點: – 開發程式時自然會容易測試 – 寫測試程式時可以順便釐清問題
  19. 19. Scrum • 更精簡的一種敏捷開發方法 • 不需要複雜的基礎建設,使用便條紙管理 Item
  20. 20. Daily Meeting 昨天做了什麼事?(或 今天做了什麼事, 依開會時間而定) 今天要做什麼事?(或 明天要做什麼事, 依開會時間而定) 工作上是否遇到任何阻礙或問題?(主持者(Scrum Master)必須快速解決成員 所遇到的困難。)
  21. 21. 實務上常搭配的工具
  22. 22. Version Control System
  23. 23. Issue Tracking System • 改善傳統Email + Excel 的方法 • Ex: Redmine, trac, mantis • 團隊內部透明 • 處理事項目前的執行狀態 • 優先權的分配 • 執行人 • Wiki功能
  24. 24. Continuous integration(持續整合) • CI Server • 固定時間自動從SVN上check out code編 譯(Daily build) • 自動執行單元測試以及靜態程式碼分析工 具 • 產生報表和email通知相關人員
  25. 25. OOP • 要寫出好的測試程式,程式的架構很重要
  26. 26. 結論 • 敏捷開發對團隊內成員個人能力要求較高 • 目前主流開發方式是混用各種方法的適合 團隊的地方,調整成適合內部使用的方法
  27. 27. Q & A • Thanks for your listening!!

×