敏捷軟體開發簡介 Agile Software Development 張平寬 Slide 1
軟體的特質 Ø Ø Ø Ø Ø Slide 2 軟體是一種奇妙有趣的產 業 軟體具有無限的創意和可能 軟體有個奇特的特質： 永遠可以改變，也很容易改 變 軟體的 真實需要要等使用者用過才會瞭解 軟體的功能永遠不能滿足使用者的需要和期望 軟體會 因需要而變更，也因而容易導致品質惡化 軟體是經由 長期的維護 來改善品質和提昇功能 軟體的 壽命由使用價值和維護成本的接受程度來 決定 軟體沒有庫存和流通成本，如果對了使用者的需 要和喜愛，利潤是非常可觀的。 …
做事的邏輯 Do right things, and then do things right. 先訂出想要達到的 目標、策略和途徑 ； Ø 檢討具備多少必要的 知識、資源和技術 ，並分 析在通往目標的途徑需要 做對哪些事和避免哪 些事 ； Ø 然後運用 有效和有效率的方法 和 避險與應變措 施 將這些事情 盡量做正確或降低損失 ； Ø 在 預訂的期限 以 接受的成本 做到 夠好夠用 ； Ø 並盡量產出最大的 成效或價值 。 Ø 軟體開發專案的目標是生產 體 Slide 3 優質軟
優質軟體 如期交付具有成本競爭力的優質軟體，是軟體開發者的夢 想。 Ø A Quality Software is： reasonably bug-free, ü meets requirements for customer’s needs, ü and delivered on time and within budget, ü and is maintainable. ü Ø 以下述情況產出具有一定品質的軟體，被稱為優質軟 體： 錯蟲少到合理的程度（當然最好是完全沒有錯蟲） ü 符合客戶需要的需求 ü 在成本預算內及時交付（或上線上市） ü 並且軟體是可維護的 ü Ø Slide 4 思考：學校培育出何種品質的學生，可被稱為優質學生 ？
優質軟體的要求 Ø 軟體開發專案是一種需求經常變更、用戶使用後才可 能瞭解真實需要、並且是永遠覺得不夠好的 不穩定型 專案。 優質軟體的專案品質要求： 錯蟲少到合理的程度（ 最低的產品品質要求 ） ü 符合客戶需要的需求（ 需求功能範圍 和相關的 產品品質要 求） ü 在成本預算內（開發成本和維護成本的專案管控品質 ） ü 及時交付（進度和期限的專案管控品質 ） ü 並且軟體是可維護的（以後 維護品質 的準備） ü 上列標紅色的內容 （範圍、成本、時間、和品質） 是 軟體開發專案 的四個控制變數。其中 時間 為主控項 目。 Ø 敏捷軟體開發 是一套有效且很有效率的軟體專案 管理和開發實務的方法論。主要的貢獻者是 XP和 Scrum。 Ø Slide 5
敏捷軟體開發 (Agile Software Development)是許多專家學者歷經十餘 年的努力貢獻，在 2001年具體成型的革新的軟體開發及程式設計測 試方法。 Ø 敏捷開發的做法 決定做對的事 Determine right things to do • 瞭解真實的需要，價值高的需要優先完成。 • 分析符合需要的軟體需求中風險高的優先解決。 ü 用聰明的方法 作，不是用很快的速度 作。 Work smart, not fast • 減少無效 作、不因錯誤或誤解需要重做更能節省時間。 • 一次設計符合很多需求的程式比一次增加一點需求，如有錯 誤時要花更多的更正時間。 • 盡量使用高效率的應用開發測試輔助軟體 具。 • 影響開發時間的，不只是程式設計、整合和驗證、還有團隊 與用戶代表的溝通。 ü 軟體產品生命週期的品質可維護的需求，必須設計在軟體裡面。 ü Design-in for maintainability Slide 6
如何設計發展程式 Ø 如何撰寫程式 先訂出簡單的功能需求和 個案測試 ü 先寫符合目前需求功能的個案測試程式，再撰寫功能處理程式 ü Ø 怎麼發展程式 一次發展一個功能需求 ü 每個需求從簡單的細部要求開始，逐步增加複雜性到符合需要就 好 ü 等前一個需求完成測試後，再增加下一個需求 ü Ø 撰寫易讀易懂的程式 要遵循程式設計標準規範 ü 資料和變數的命名要能表達真實物件和資料身分，能望文生義。 ü 加註必要的設計說明（不是程式說明） ü Slide 7
如何測試程式 Ø 沒有經過測試證實正確的程式是不能使 用的 如何測試程式 先訂出正確的測試條件和正確的結果（ 個案測試）； ü 如果程式不符合 測試條件和結果，顯示處理過程以判斷錯誤原 因； ü 如果偵錯太久還是找不出錯誤原因或所在，要找別人幫忙偵錯。 Ø 以測試來帶動程式的發展 （ Test-driven Development, TDD) ü 依需求設計測試個案（測試條件和結果）； ü 依測試個案 先寫測試程式 ，再寫一個功能處理程式（測試程式和 功能程式是寫在一起的）； ü 這項功能經測試正確後，再增加下一個功能的測試和功能程式； ü 反覆修改符合需求的測試個案、逐一增添功能直到全部需要的功 能都通過全部的測試個案為止，正確的程式模組與個案測試集也 一起完成。 ü 註：單元測試報告可以做為程式說明 ü Slide 8
符合客戶需要的軟體需求 Ø 軟體要經用戶使用過才可能瞭解真實的 需要 軟體需求在專案過程中是不穩定的 在軟體開發之前所訂的需求可能不夠明確 ü 軟體開發專案結束時的需求，可能和開發前的需求有很大的差 異 ü 在開發軟體過程中，客戶的需要 是會改變的，因而軟體需求也會 改變。 ü Ø 儘早發掘客戶真實的需要 必須和用戶一起討論現在和未來的需要，分析價值，確定滿足現 在需要的軟體需求的優先次序。 ü 在開發過程中經常交付可用的成果 (incremental delivery)給用戶使 用並回饋意見，以儘早發掘真正的需求。 ü Ø 開發方法要能因應需求的複雜度和頻繁的變更 ü Slide 9 需要與需求不可能不會變更，必須採取迭代式開發模式 development)以因應需求的複雜度和頻繁的變更。 (iterative
軟體開發的風險管理 事情的演變是無法可完全預測的，事前必須有足夠的避險和應變 計畫。 Ø 軟體開發專案的主要風險 需求的複雜度和未知的困難 ü 過度的專案變更、團隊異動 ü 開發方法不佳、開發環境不良、團隊訓練不夠 ü 專案預算或人力不足 ü Ø 避險和應變計畫 分析預測主要風險 ü 擬訂可避免風險的策略（做法或途徑）和預警指標 ü 擬訂風險發生時的應變措施（如替代途徑或降低損失的措施） ü Slide 10
軟體維護是對已佈署的軟體做更正、強化和最適化的處理過 程。 Ø 確保維護的完整性 如果是變更設計，則從設計架構上定岀維護範圍 ü 要能鑑定局部的變更可能影響到哪些地方 ü 確定需要隨著更新和測試的必要範圍 ü Ø 確保維護的正確性 個案測試與程式要一起納入維護管理 ü 依據測試的必要範圍重新做測試 ü Ø 維護範圍要提升到系統整合層次 共用的軟體也要納入維護範圍 ﹝ 如 Web service, Framework等 ﹞ 。 ü 整合的應用如有變更也要再重做整合測試。 ü Slide 11
什麼是可維護的軟體 軟體的生命週期很長，其一生可說都處於維護狀態，可維 護的軟體才有使用價值。 Ø 軟體的使用價值 ü Ø 可維護性 ü Ø 軟體的價值在於 使用 。使用後會有更多的需求，因而有用的軟 體需要 持續維持正確、加強改善、達到最好的狀態 。 可維護不只表示能夠維護正確而已，還要 容易維護、低成本、 時間少 。通常用比較資淺的人力維護已部署使用的軟體；在成 本效益和人力資源的有效運用和風險管控原則下，也不能依 賴原開發者才能 改善 軟體。 軟體的壽命 當軟體失去使用價值時其壽命也盡。 ü 軟體功能不能維護符合需要當然會失去使用價值，但過多的維護 成本或困難也會致使沒有維護的必要。 ü Slide 12
如何確保軟體的可維護性在設計系統架構、開發應用程式時就要納入 考慮；然後以能快速回應變更、低成本的維護管理接手。 Ø 設計可靠性高、容易維護的應用 程式 使用 TDD及自動測試發展程式單元 ü 程式撰寫方式要簡單易懂及 加註必要的設計說明 ü 程式間不要使用有記憶效應或 side effect設計；並降低內部交連 (internal coupling) ü Ø 設計可被管理的應用程式 可量測程式效能（例如 cycle time、執行頻次） ü 可支援 線上診斷（例如追蹤執行記錄） ü Ø 設計有管理維護能力的應用管理系統 設計獨立的應用管理系統 ü 監督應用程式的執行品質（ Quality dashboard） ü 執行線上診斷、回溯追蹤 ü 管控不符合應用程式管理介面的程式整合進應用系統。 ü Slide 13
如何管控開發進度和成本 Ø 如果預算是不容易調整的，就調整功能範圍和進 度。 依需要的價值分出需求的優先次序 協商縮小歷次發行的需要範圍 ü 依據達成需要的途徑擬訂開發進度表 ü Ø (Milestone) 以分次交付、簡化複雜度以縮短交期 將需求簡化到可管控範圍才能正確地預估 時和成本 ü 根據過去開發團隊的生產速率估計可完成的需求項目 ü Ø 嚴謹管控短期進度，必要時調整功能範圍或品質要求 每天管控進度，若有延遲或變更必須立即因應調整。 ü 以進度和交期為目標，若因故無法依進度完成，則需與客戶或市 場行銷協商調整本次開發的完成範圍。 ü Slide 14
敏捷軟體開發 Agile Software Development http: //www. agilealliance. org/ http: //37 signals. com/ Slide 15
敏捷開發價值宣言 2001 革新軟體 程價值觀和開發的敏捷價值宣 言： 個人和互動 重於 過程和 具 可以運作的軟體 重於 巨細靡遺的文件 與客戶協同合作 重於 合約談判 隨機應變 重於 循規蹈矩 雖然 右邊項目 是 有它的價值的 ， 不過我們 更重視 左邊項目 。 Ø右邊項目 代表傳統正確的思維和習慣 Ø左邊項目 是敏捷聯盟提出革新的思維和 做法 Slide 16
Agile Manifesto 2001 Individuals and interactions over process and tools 個人專業和團隊互動 勝於 嚴謹的管理流程和 具 Working software over comprehensive documentation 儘速產出可用的成果 勝於 撰寫詳盡精緻的文件 Customer collaboration over contract negotiation 與客戶開誠佈公的協同合作 勝於 盡心費力地談判合約 Responding to change over following a plan 適時回應變化 勝於 墨守計畫 That is, while there is value in the items on the right, we value the items on the left more. http: //www. agilemanifesto. org/ Slide 17
敏捷原則 Ø 1. part 1 軟體系統開發 程是一種變更頻繁高度複雜的專案， 敏捷式的開發方式和過程的管理可以大幅降低專案風 險、讓雙方快速獲得利益和價值 。敏捷宣言以 12項原則 指導軟體專案團隊，簡短描述如下： 最優先的是經由有價值軟體的儘早及持續交付以滿 足顧客。 強調焦點是把價值交付給顧客。在這些日子結束時，正是 這個客戶滿意度的哲學驅使敏捷團隊的努力。 Slide 18
敏捷原則 2. part 2 即使在開發的後期，也要歡迎需求的改變。敏捷的處 理過程能為顧客的競爭優勢駕馭各種需求的變更。 在以計畫為碁的專案裡，希望範疇內容停留不變，表示 範疇的變更經常是不被鼓勵的。藉由允許變更的考慮， 我們確信正在建造可以幫助把價值帶給顧客的產品。 透過儘早和連續的交付，同時也容許變更，我們能保 持靈活和因應變更狀況的能力因而更 "敏捷 "。 Slide 19
敏捷原則 3. part 3 以預設較短的作業週期，經常地交付可 作的軟 體 (Working software)，從幾個星期到幾個月。 以「 Time box」 作為連續交付成果給顧客的步調。更短 的 timescale表示團隊不會因建造產品時間太長而 沒有得到回饋。這是一種避險方法，避免在發展循 環過程中因長時間的建造而造成顧客在最後時刻 表現驚訝的危險。在敏捷環境裡，經由經常的交付， 很少有驚奇。 Slide 20
敏捷原則 4. part 4 在整個軟體專案中，業務人員必須和開發者一起協 同 作。 (這裡的業務人員是指使用該軟體的業務人員們或行 銷該軟體的業務人員 ) 業務人員或專案利害關係人代表某種產品的商業需求。 正如使用者一樣，關於系統應該怎樣 作他們有明 確的想法和信仰。此外，正如使用者一樣，直到他們 看見系統他們才知道需要什麼。因此，當業務人員與 開發者協同 作時，能確保他們的業務興趣將因內 容、想法、和回答的分享而得到更佳的滿足。 Slide 21
敏捷原則 5. part 5 環繞著受激勵的團隊成員來建置專案。給他們 作環境、支援他們的需要，並且相信他們會把 作 完成。 在敏捷的專案裡，團隊是在 timebox內自我管理；那 是在建造產品的迭替期間，他們應該能有近在手邊 的全部必要資源、和把 作完成的管理上的信任。 Slide 22
敏捷原則 6. part 6 對開發團隊和在團隊內部傳送訊息的最有效率和 有效的方法就是「面對面談話」。 雖然看起來像是常識，這個敘述說明以話語替換一些 文件編製。例如，不是寫詳細的設計說明，而是組 員一同 作討論並且探索關於軟體應該怎樣被建 造的想法。這不是說敏捷團隊不做文件 ─相反地，他 們有做，應該是說文件不是主要的溝通 具。我們 意識到很多團隊是被分隔數千里遠，有時候看起來 豐富的文件資料是唯一的溝通方法；不過，很多團 隊已經成功地使用即時通訊、視訊會議、 wikis、 和 最新的 程環境或使用其他技術來支援有效的協 同合作。 Slide 23
敏捷原則 7. part 7 可 作的軟體是專案發展的主要衡量對象。 要瞭解專案現況，沒有比檢查目前的系統狀態有更 好的方法。什麼被交付了？它如何作業？我們怎 樣能確信它按照我們需要的方式作業？當產品被 建造時看一看，營業人員和使用者能問這些問題 藉由查看這個剛完成的產品並且得到回答 ﹗ Slide 24 ─
敏捷原則 8. part 8 敏捷的處理流程促進可持續的發展。那些專案 發起人、開發者和使用者在發展期間應該能維持 一致的步調。 以可持續的步調方式 作對每個參與專案者的生 活品質來說是相當的重要。不僅是生活品質，而 且，如果勞累過度的 程師正為焦點和完成在奮 鬥時，產品的品質也能承受可能的損害。 Slide 25
敏捷原則 9. part 9 持續闗注卓越技術和良好設計以提升敏捷性。 在任何人的技藝裡，專業是最重要的。基於好且簡 單設計的軟體寫作的專業人士能對變更作出迅速 而有效的回應。這種靈活性考慮到敏捷的組織。 Slide 26
敏捷原則 10. part 10 簡潔是必要的 ─最大化不需要做的 作量的藝 術。 簡潔是敏捷的反鍍金機制。敏捷的團隊只建造使用 者想要的，不會更多。這個非常簡單的原則確保團 隊不會建造使用者不想或者將來不使用的功能。一 旦一個軟體特性被造岀，它必須在系統生命期內被 維護著，或者必須為支持它做出投資。不論是哪一 種情形，都是應該被避免的浪費。 Slide 27
敏捷原則 11. part 11 最好的架構、需求、和設計來自自我組織的團 隊。 團隊的集體智慧壯麗地超過個人的智慧。當組員們 集中心思時，他們協作建造可能最好的系統。這個 敏捷原則回應彼得. 杜拉克的關於知識 人的教導。 Slide 28
敏捷原則 12. part 12 團隊反應怎樣變得更有效，定期地依據情況調 適和調整它的行為。 雖然在每迭替結束時產品可能被檢查和調適過，這 個原則討論對處理調適的需要。敏捷團隊的回顧 是為了確定哪個過程是作業良好和哪個不是良好。 組員們一同 作集體地使用他們的流程解決任何 挑戰，並且隨時專注於改進。 Slide 29
Agile Approach 的思維 Ø 思維的調整 以符合客戶 ﹝ 用戶 ﹞ 的商業優先價值為軟體開發目標。 ü 認為需求變更是自然的、不可避免的事；要能隨時接受需求變 更，並運用有效措施以降低風險和變更成本。 ü 認為品質管控必須融入開發過程才能引導程式設計正確與迅速， 不做無濟於事的事後稽核。 ü 強調與用戶密切溝通回饋協同作業才能充分瞭解真實的需要， 並能及時管控品質惡化的風險和調適需求的變化。 ü 認為簡化作業、簡單設計，並運用自動化設計與測試 具，一次 就做正確，才能提昇生產力及軟體正確性。 ü 認為以 Just-in-Time, Just-enough滿足用戶或市場目前的需要 ﹝ 包 含維護更新 ﹞ 。 ü 認為團隊的凝聚力、創新能力、和愉快地 作是重要的成功因素。 ü Slide 30
Agile Approach 的做法 Ø 聰明有效的做法 採取 Iterative Incremental Development降低複雜度和需求變更的風 險 • 由於軟體的複雜度和變動風險太高，認為傳統的 Waterfall approach不適合軟體開發 程；應該採取由簡至繁、漸增產 出方式、邊開發邊用邊改善的開發模式。 ü 儘量簡化及縮短 作流程，以加速開發 • 運用短週期的迭代循環發展程式，容易預估人力需求和掌 握進度。 • 儘量使用開發 具、簡潔設計 , 大幅增進開發速度。 ü 及時溝通和回饋，並調和人性和生產力的衝突 • 要求用戶和發展團隊 協同作業 ﹝ 用戶決定需求優先次序、說 明需求、釋疑、驗證功能、允收測試等 ﹞ ，強調及時溝通和 回饋 ， 儘早瞭解確實的需求及發現問題，以降低風險和應變 成本。 • 發展團隊也要經常分享經驗與教訓，以增加凝聚力。 ü Slide 31
Agile Approach的設計與開發技巧 Ø 簡潔的設計與敏捷的開發技巧 強調簡潔設計是品質和快速開發的重要手法 ü 使用 TDD及自動測試平台以加速開發和符合軟體品質要求。 ü 主張軟體品質要設計在產品裡和在開發過程中管控，不能在事 後檢查： • 遵守 Coding standards， 以程式為應用設計的主要說明。 • 採取雙人撰寫與測試重要程式，及由用戶驗證功能，減少 事後的程式審查。 • 以重構（Refactoring）作業來改善軟體架構、功能和品質，以 因應需求變更。 ü Slide 32
常用的敏捷方法和軟體開發 具 Ø 比較受歡迎的的敏捷方法 ü ü ü ü Ø 市面上比較常見的敏捷軟體開發 具 ü ü ü Slide 33 Extreme Programming (XP) Scrum Development Agile Modeling (AM) Adaptive Software Development (ASD) Crystal Dynamic Systems Development Method (DSDM) Agile Unified Process (AUP)等 Microsoft Team System and Visual Studio Ruby on Rails (http: //rubyonrails. org) Eclipse IDE
What is Scrum An approach for New Product Development (以資訊應用軟體為例） www. controlchaos. com Slide 34
What is Scrum 1 Scrum is an iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration. Slide 35
Scrum Model Slide 36
What is Scrum 2 Scrum is based on what is called a Sprint – a focused effort for a 30 -day period (time-boxed) toward fixed goals. Defined Process Initiation Sprint 1 Empirical Process Ø 假設 Sprint 2 Sprint n Closure Scrum : 橄欖球賽 Sprint：短程衝刺 需求是無法在專案之初完全被確定和瞭解的 ü 在專案發展過程中需求也會不停的改變 ü 最終產品的需求是無法在專案開始前預測的 ü 在短週期內安排可負荷的需求才能規劃週期內有效的專案計畫 ü 簡化複雜度、縮短發展週期是管控風險最簡單的方法 ü Slide 37
Scrum的證言 Ø 理論證言 ü ü ü Ø 經驗證言 ü ü Slide 38 認為複雜度 (源自需求的不確定性與非預期的變更或產出， 和不穩定可靠的技術 ) 是軟體發展專案主要的風險來源。 軟體發展程序是一個隨著風險程度的升高，成功機率就會急 速下降的處理系統。專案管理是它的 風險管控機制 ，有必要 具有最大的 應變彈性 和 適度的管控機能 ，才能提昇成功機率。 經由複雜度理論證明 Scrum Method的頭尾部份是 defined process, 中間的 Sprint是 nonlinear但是 controlled的 empirical process，其成功機率高於以往的 Waterfall, Spiral, Iterative Methods. 推行 10年以上，數千個導入個案，程序和實務已經相當成熟。 如充分應用最新的發展 具， Scrum軟體開發與管理方法可 以突破性地提升團隊生產力達 600%。
Sprint process Ø Sprint planning → Develop → End of Sprint Timescale: 1~4 weeks/1~3 months Ø Sprint planning 轉換本次衝刺成果目標為細部計畫和 作清單，並允諾達成。 Ø Daily or weekly Review during Develop stage 瞭解執行狀況、迅速排除障礙、掌控進度和意外。 Ø End of Sprint 經由回顧與檢討，團隊內部和其他團隊分享階段成果、經驗和教 訓 與客戶和上層管理評估成果、需求和風險，並做適當的調整。 對需求和成果目標的變更採取因應措施 檢驗改善成效、承諾在下一衝刺需要改善的項目 Slide 39
極限程式設計 Extreme Programming (XP) www. extremeprogramming. org Slide 40
What is XP XP是一個輕量級、高效率、低風險、靈活的、可預估的、 科學的、和以有趣的方式來開發軟體的實務方法。 Kent Beck Ø XP是 由 Kent Beck等人所倡導 ， 主要目的是要： ü 降低開發軟體的 風險 ü 提高發展軟體的 品質和績效 ü 調和人性與生產力的衝突 Slide 41
XP想解決軟體開發的基本問題 ü ü ü ü Slide 42 進度失誤 Schedule slips 專案被取消 Project canceled 軟體系統變差 System goes sour 高的錯誤率 Defect rate is high 業務被誤解 Business misunderstood 業務的變更 Business changes 太多不正確的需求特性 False feature rich 開發人力的更換 Staff turnover
為何命名 『 極限 』 XP主張將常識般的原則和實務做到極限 程度 ü ü ü ü Slide 43 如果 程式審查 是好的做法，那麼就 隨時審查程式 。 如果 程式測試 是好的做法，那麼就 每個人隨時測試程式 。 如果 設計 是好的事，那麼就 讓設計成為每個人日常 作的一部 份。 如果 簡潔 是好的事，那麼就 總是讓系統擁有簡潔的設計 足夠支 援目前需要的功能就好。 如果 架構 是重要的東西，那麼 每個人在 作時將隨時定義和改 進架構 。 如果 整合測試 是重要的事，那麼就 一天整合及測試幾次 。 如果 短週期的迭代開發循環 是好的做法，那麼就 讓迭代開發循 環的週期真的很短 。
XP的解決策略 Ø 擁抱及駕馭變更 ü 任何事情的進展都可視作某種形式的 變更 ü Incremental changes, 要好好地駕馭變更最簡單的方 法是每次只做 一點點 變更。 ü 然後採用最有效的方法處理變更，讓變更成為機會； ü 並使變更成本穩定在最低的狀況 Ø Slide 44 1 化繁為簡、先重後輕、循環漸進發展軟體 ü 採取循環漸進式的發展模式，視需求複雜度，彈性規 劃多次短期的發展循環。 ü 從系統行為特徵、資料結構性質，擬訂系統架構、分 解功能結構，討論出發行計畫。 ü 採取小規模發行策略，開始時先降低功能需求和複 雜度，再逐漸增加回去。
XP的解決策略 2 Ø應用 80/20原則 ü 80%的需求可以用 20%的 時完成 ü選出優先完成的部分（高價值，高通用性）先做 Ø Slide 45 設法在可預測可計畫的情況下處理事情 ü 簡潔是關鍵 Simplicity is the Key ü 簡化做事的方法、 簡化流程、簡化設計 ü 降低複雜度、困難度與負荷
XP的實務對策 1 Ø 減輕每次交付品的複雜度和負荷 ü 採取漸增式產出，減輕每次發行的新增內容規模， 但要增加發行頻次 ü 協調每次發行的範圍和功能，使需求複雜度和 負荷在開發期內可以掌握品質與成本 ü 不更改發行期限，如期發行以儘速取得回饋 Ø 縮短迭代開發循環的週期 ü 1~4週的迭代週期 (2週是常態 ) ü 減少每一週期內的功能範圍，以降低開發複雜 度與負荷 ü 確實掌控每一週期的進度和品質 Slide 46
XP的 實務 對策 2 Ø 採用高度自動化的程式發展環境 ü 採取 Test-Driven Development (TDD)發展程式 ü 採取 Automated Testing保障高效率、程式的正確性和品 質 Ø 簡潔設計，不要做冗餘的設計 ü XP深信 Simplicity is the Key ü 複雜的 作容易隱藏錯誤，簡單才容易把事情做對 做好 ü 維持簡潔設計、一致性的編碼標準，效率高容易維 護 ü 先求程式能 作 ， 再求做得對，最後才求更好的效 能 Slide 47
XP的 實務 對策 3 Ø 經常 Refactoring使程式更簡潔 ü 當程式修改多次或有重大變更時，要做重整。 ü 重整 作一方面可以使程式更簡潔乾淨，一方面也 可因而把程式修改得更有效益更好。 Ø 釐清權責 ü 業務人員決定 • Scope, Priority, Composition and dates of releases ü 技術人員決定 • Estimates, Consequences, Process, Detailed scheduling ü 大家一起協同規劃，把每次的發行計畫擬訂得很適當。 Slide 48
XP的 實務 對策 4 Ø 改善團隊 作文化 ü 提倡集體擁有程式碼權益 Collective code ownership ü 提高團隊自主管理能力，迅速應變和負成敗責任。 ü 團隊成員 ﹝ 含使用者 ﹞ 有效地 溝通 協調與迅速 回饋 ü 團隊成員間要分享知識成果、互助合作解決困難、不 能有明星或英雄文化。 Ø 管理 作 ü 直接溝通，經理、客戶也與團隊一起 作 ü 每一個程式單元的 時在 8~16小時 ü 今日事今日畢，每天檢視 作成果與阻礙 ü 不以加班方式趕進度或解決困難 Slide 49
XP的價值觀 XP的 價值觀 ：Communication, Simplicity, Feedback, Courage, Respect Ø Slide 50 XP以價值觀來改善軟體專案的品質 ü 與團隊成員 ﹝ 含使用者 ﹞ 有效地 溝通 協調與迅速 回 饋； ü 要求 簡化 做事的方法，維持設計簡單和乾淨，並快速 回應變更需求； ü 鼓勵成員要有 勇氣 接受不斷的需求和技術變更的挑 戰； ü 尊重 人性，激勵成員對團隊有忠誠度和歸屬感。
XP的基本判斷原則 主要原則 ü Rapid feedback ü Assume simplicity ü Incremental change ü Embracing change ü Quality work Slide 51 次要原則 üTeach learning üSmall initial investment üPlay to win üConcrete experiments üOpen, honest communication üWork with people’s instincts, not against them üAccepted responsibility üLocal adaptation üTravel light üHonest measurement
Practices and Rules of XP l l l The planning game Small releases Metaphor Simple design Testing Refactoring n n n Pair programming Collective ownership Continuous integration 40 -hour a week On-site customer Coding standards 詳細說明請參閱 XP推廣網站 www. extremeprogramming. org Slide 52
TDD的單元測試 ü ü ü ü Slide 53 by Jeff Canna 聚焦於測試下的 特定 Class的 methods 從 發展者的觀點 定義單元規格，撰寫單元測試需求。 先 為欲測試的程式 單元 撰寫 測試個案 在 單元測試中 獲取程式註解 測試執行某一 關注功能 的所有 public methods 與有關聯的 版本管制系統 一起使用 將每一個 test case放進 相同的 package， class的測 讓 試能存取這個 package和受保護的 members。 在 單元測試中 避免使用 domain-specific objects
TDD的功能測試 ü ü ü Slide 54 by Jeff Canna 聚焦於使 用者所關注的 系統行為 從 使用者的觀點 定義系統行為規格，撰寫功能測試需 求。 只要寫一些可讓使用者可以與之互動的程式碼，就 立 即撰寫測試 。 選用良好的 功能測試架構 ，或者自行發展；並用這些 功能測試來確認使用者真正想要的需求。 用這種方法可讓功能測試者獲得一個 自動化 具 ，且 有開始使用這項 具的起點。 讓 單元測試和功能測試 成為軟體發展設計的 主要 作
XP的整合測試 Ø 依序整合或單緒整合 Sequential Integration ü 同時整合多項應用容易產生： • 沒有偵測到的潛在問題 • 最新版本沒有清楚的切割 • 物件類別內在相依問題 ü 嚴格採取由開發者一次整合一個應用，並配合集體擁有程式碼 權益是解決這些問題的簡單方案。 Ø經常整合 Integration Often ü當開發者沒有和其他開發者溝通什麼是可再使用或共用時，經 常持續性的整合可避免發生分歧或不完整的開發。 ü持續性的整合幾乎可以避免或儘早偵測到相容問題。 ü整合是一種「要現在付費，或是以後再付但要更多」類似的作業 XP Practices and Rules From extremeprogramming. org Slide 55
XP的三個假設 Ø 假設可以漸增地進行架構和設計 系統隱喻描述所有參與會者了解和認同的總體結構和詞彙。 隱喻是在整個專案過程中被反覆重新定義的。 ü 採取先測試後逐步編撰程式單元，通過必須遵守的測試。 ü 採取反覆地重構設計以適應不斷變化的知識，環境或要求。 ü Ø 假設 可以漸增地分析需求 簡短的需求，稱為 user story，在開發團隊與故事作者之間以迭 代方式闡述 。 ü 需求正式地被轉成可執行的驗收測試，它是軟體需求規格和軟 體是否符合需求的驗證。 ü 需求經由 The Planning Game被配置成發行計畫，在這裡開發團 隊和客戶盡量對開發成本產出最適化的價值。 ü Ø 假設可以為客戶產生最大利益的順序，漸增地交付軟體。 ü Slide 56 由於客戶可以選擇交付順序，他們可優先收到最重要和最有價 值的軟體功能。
XP的利益 Ø 如果前面 XP的假設成立，雙方可以從漸增式的作 業模式獲得下列利益： 早一點達交有用的軟體，早一點上線使用，早一點產生價 值 ü 依據用戶要求的價值所需的功能交付 ﹝ 業務驅動式取代 架構或風險驅動式軟體發展 ﹞ ü 在專案進程方面，有清楚且確實的回饋，每期的需求功 能都盡力達成，並且可以使用。 ü 在品質方面，有清楚且經常性的回饋，從用戶到發展團隊 軟體都合身。 ü 在專案計畫方面，有能力調適環境的變更。 ü 有清晰的進度和可預計的交期。 ü 發展滿足需求最簡單可能的系統，不需要任何不必要的 裝飾和複雜度。 ü Slide 57
XP帶來的一些啟發 Ø (1) 什麼情況適用 Work incrementally ？ ﹝ 降低複雜度和風險 ﹞ 小額投資雖只能獲得小利潤，但風險也比較低。 ü 如果需求是紛散的、不確定、不完整，如果環境改變或期望 能預料未來的事件。 ü 如果不熟悉該項領域、沒有造過類式的架構。反覆使用回 饋來設計系統，以及減免不需要的複雜度。 ü Ø 什麼情況適合 Work upfront/predictive？ ﹝ 想減少 reworks﹞ 大額投資可能一次獲得高利潤，但相對風險也比較高。 ü 如果需求和環境都是穩定的，與功能需求能定義清楚 ü 如果熟悉該項領域、造過很多類式的系統，很有把握時。 ü Slide 58
XP帶來的一些啟發 (2) Ø什麼情況適用 Deliver incrementally? ü如果是不能漸增式分次交貨，就不要用漸增式分次交貨。 ü但縱使不能以漸增式分次交貨給最終用戶，但也可以漸增 式分次交貨給內部用戶，例如 QA, 產品經理；或給團隊的成員。 這樣做，仍然可以獲得早一點回饋的好處。 Ø當需求如果會越來越困難和複雜呢？ ü如果知道需求會越來越困難和複雜，且以後還是要面對， 現在就做。例如有一些軟體系統的全域性特性像 localization, scalability, security等。 ü如果將這些少數例外列入考慮，仍然可以獲得以業務價值 帶動進度的利益。 Ø Slide 59 Iterative design 有什麼好處？ ü Refactoring和強調簡單可以幫助維持軟體 可接受改變。 “Soft”, 更有可展性、更
XP的一些風險 Ø 可能的風險 由於每次只注意到一個軟體小增量，必須做比較多的 reworks； 如果能正確地分析或設計整個系統，這種情形 或許可以避免或減少。 ü 或許會有 “在角落裡畫自己 ”，可能會獲得一個無法支援 某些新需求的系統。 ü 可能無法增加一些全域性的需求，例如 globalization, security等。對當初沒有想到這些需求的應用程式會有 全面翻新的可能。 ü 由於每一次增加功能時需要反覆分析設計可能會使發展 進度慢一些。 ü Ø所以，什麼是規劃專案的最佳方法？ ü與你的專案、團隊、環境有關。 ü想定義應該如何組織專案不是一件容易的事。 Slide 60
什麼情況不要嘗試 Ø 企業文化 ü ü Ø Ø 大團隊 ( >> 10人 ) 技術上無法支援美好的變更 ü ü Ø Slide 61 單緒整合作業 指數型的成本曲線 計算環境 ü Ø 不願檢討和改變做事的習慣 喜歡龐大的規格 非常依賴紙上作業 要求承諾重於實質的實踐 取得回饋的時間太久 不信任的客戶 XP
學習重點 1. 2. 3. Slide 62 Agile是十多年前許多軟體開發改革先驅們歷經長期實驗的 心血結晶，整理過去經過歷煉的常識和方法，調整思維並與 人性結合，提出具體有效因應變動頻繁的軟體開發且高效率 的實務和方法。 Agile聯盟的努力有下列幾點貢獻和影響： 1. 全面推廣 Agile software development 2. 終實的擁戴者 open source族積極開發 Agile所需的平台與 具 3. 證實有最低且穩定的變更成本的事實是項了不起的成就 4. 非常適合 Web_based Apps的開發與維護 5. 促使 RUP接受並在 2003改版 6. 促使 2005的 APM宣言，並在 2007促使 PMI接納 APM並全 球推廣。 7. 促成 Agile Enterprise概念和有企業積極地去實踐 有幾點可供資訊技術團隊先學習： 1. 價值觀和思維 2. Metaphor and The Planning game 3. Iterative and Test_driven development
參考網站 l l l Agile Process http: //www. agileadvice. com/ http: //epf. eclipse. org/wikis/openup/ Scrum http: //www. controlchaos. com http: //epf. eclipse. org/wikis/scrum/ XP http: //www. extremeprogramming. org/ TDD http: //www. testdriven. com/ Web-based applications development http: //rubyonrails. org. tw/ http: //www. rubyonrails. org/ l l l Slide 63 Tools http: //www. agitar. com/ http: //www. eclipse. org/ http: //www. junit. org/index. htm Ruby and Rails http: //www. ruby-lang. org/zh_TW/about/ http: //www. ruby-lang. org/en/documentation/ www. 37 signals. com 其他網站 http: //dir. yahoo. com/Computers_and_Internet/Programming_and_Development/Methodo logies/Extreme_Programming/ http: //www. javaworld. com/javaworld/jw-08 -2003/jw-0815 -xp. html
Скачать презентацию 敏捷軟體開發簡介 Agile Software Development 張平寬 Slide 1
7e9a6c7a560fa82f7e8df3c52ffb9042.ppt