敏捷開發知識體系整體框架

敏捷開發工程實踐

專案管理

• 迭代開發
• 風險價值生命週期
• 多級專案規劃
• 完整團隊
• 每日站立會議
• 任務板
• 燃盡圖

需求管理

• 需求訂單
• 業務流程草圖
• 用例驅動開發
• 使用者故事

架構

• 演進的架構
• 演進的設計
• 基於元件的架構設計

開發

• 結對程式設計
• 測試驅動開發
• 重構
• 程式碼規範

測試

• 單元測試
• 並行測試
• 測試管理

變更管理

• 持續整合
• 自動構建
• 團隊變更管理

敏捷開發管理實踐描述

• 定義和特徵說明
• 主要角色
• 主要活動和最佳實踐
• 主要輸入輸出
• 工作流程

敏捷開發工程實踐描述

• 定義和特徵說明
• 應用說明
• 案例說明

敏捷開發核心價值觀和原則

敏捷軟體開發宣言

個體和互動 高於 流程和文件
工作的軟體 高於 詳盡的文件
客戶合作 高於 合同談判
響應變化 高於 遵循計劃
也就是說, 儘管右項有其價值, 我們更重視左項的價值.
 

• 1
• 2
• 3
• 4
• 5

• 1
• 2
• 3
• 4
• 5

敏捷軟體開發的核心價值觀

敏捷開發的核心理念就是以最簡單有效的方式快速打成目標, 並在這個過程中及時地響應外界的變化, 做出迅速的調整.

核心價值觀

• 以人為本
• 目標導向
• 客戶為先
• 擁抱變化

敏捷開發的原則

• 我們最重要的目標，是通過持續不斷地及早交付有價值的軟體使客戶滿意。
• 欣然面對需求變化，即使在開發後期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。
• 經常地交付可工作的軟體，相隔幾星期或一兩個月，傾向於採取較短的週期。
• 業務人員和開發人員必須相互合作，專案中的每一天都不例外。
• 激發個體的鬥志，以他們為核心搭建專案。提供所需的環境和支援，輔以信任，從而達成目標。
• 不論團隊內外，傳遞資訊效果最好效率也最高的方式是面對面的交談。
• 可工作的軟體是進度的首要度量標準。
• 敏捷過程倡導可持續開發。責任人、開發人員和使用者要能夠共同維持其步調穩定延續。
• 堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。
• 以簡潔為本，它是極力減少不必要工作量的藝術。
• 最好的架構、需求和設計出自自組織團隊。
• 團隊定期地反思如何能提高成效，並依此調整自身的舉止表現。

敏捷開發管理實踐

Scrum

Scrum是一種迭代式增量軟體開發過程，通常用於敏捷軟體開發。Scrum包括了一系列實踐和預定義角色的過程骨架。Scrum中的主要角色包括同項目經理類似的Scrum主管角色負責維護過程和任務，產品負責人代表利益所有者，開發團隊包括了所有開發人員。

Scrum中的角色

“豬”角色

• 產品負責人（Product Owner） 
  
  • 通常由市場部門的人擔任
• 敏捷教練 (Scrum Master) 
  
  • 通常由開發組組長擔任
• 開發團隊 (Scrum Team) 
  
  • 包括開發,需求,測試

“雞”角色

• 使用者 
  
  • 軟體是為了某些人而建立！就像“假如森林裡有一棵樹倒下了，但沒有人聽到，那麼它算髮出了聲音嗎”，“假如軟體沒有被使用，那麼它算是被開發出來了麼？”
• 利益所有者 (客戶，提供商) 
  
  • 影響專案成功的人, 但只直接參與衝刺評審過程。
• 管理者 
  
  • 為產品開發團體架起環境的那個人

主要活動和最佳實踐

• 迭代式軟體開發
• 兩層專案規劃 (Two-Level Project Planning)
• 整體團隊協作 (Whole Team)
• 持續整合
• 衝刺規劃會議 (Sprint Plan Meeting)
• 每日站立會議 (Sprint Daily Meeting)
• 衝刺複審會議 (Sprint Review Meeting)
• 衝刺回顧會議 (Retrospective Meeting)

主要輸入輸出

• 產品訂單(Product Backlog)
• 衝刺訂單(Spring Backlog)
• 燃盡圖(Burndown Chart)
• 新的功能增量

工作流程

專案管理過程

• 在Scrum專案管理過程中產品負責人獲取專案投資, 並對整個產品的成功負責.
• 產品負責人協調個中利益干係人, 確定產品訂單中初始的需求清單及其優先順序, 完成專案商業價值分析和專案整體規劃, 並任命合適的敏捷教練開展專案工作.

專案開發過程

在Scrum軟體開發過程中, 每個衝刺就是較短的迭代, 通常為2~4周.

• 在每個衝刺開始時, 產品負責人和敏捷教練通過召開衝刺規劃會議和”兩層專案規劃”的最佳實踐, 制定衝刺訂單(類似迭代計劃)
• 產品負責人明確在本次衝刺中實現的需求清單, 響應的工作任務和負責人.
• 在每個衝刺迭代中, 團隊強調應用”整體團隊協作”的最佳實踐, 通過保持可持續發展的工作節奏和每日站立會議, 實現團隊的自組織, 自適應和自管理, 高效完成衝刺工作.
• 在每個衝刺結束時, 團隊都會召開衝刺複審會議, 團隊成員會在會上分別展示他們開發出的軟體(或其他有價值的產品), 並從產品負責人和其他利益關係人那裡, 得到反饋資訊.
• 在衝刺複審會議之後, 團隊會自覺招開衝刺回顧會議, 回顧整個專案過程, 討論哪些方法做的好, 哪些方面可以改進, 實現軟體交付過程的持續, 自發的改進.

XP

OpenUp

Lean

敏捷開發工程實踐

迭代式開發

敏捷迭代開發是指每次按照相同的開發方式短期的開發軟體的部分, 或前期開發並不詳盡的軟體, 每次開發結束獲得可以執行的軟體, 以供各方干係人觀測, 獲得反饋, 根據反饋適應性的進行後續開發, 經過發福多次開發, 逐步增加軟體部分, 逐步補充完善軟體, 最終開發得到最後的軟體. 每次反覆開開發叫一次迭代, 在Scrum中成為Sprint, 中文常譯為”衝刺”.

持續整合

持續整合(Continuous integration)是指當代碼提交後, 馬上啟動自動編譯, 自動部署金額自動化測試來快速驗證軟體, 從而儘快的發現整合錯誤.

多級專案規劃

多級專案/產品規劃, 在軟體開發領域, 是指以迭代開發為基礎, 形成多層次的, 逐步細化的專案或產品計劃. 這些層層相關的專案/產品規劃包括:

• 專案/產品願景
• 專案/產品路線圖
• 版本釋出計劃
• 迭代計劃
• 每日實現

專案/產品願景

在計劃階段, 首先, 專案stakeholder, 專案/產品負責人將參與並組成工作組, 他們負責闡述專案的重要性, 給出專案成功失敗的關鍵標準以及專案整體層面”完成”的定義; 在過程中, 可以利用形成專案願景的一些個工具, 包括願景盒子(Vison Box), 業務收益矩陣(Business Benefits Matrix), 專案範圍矩陣(Scope Matrix), 滑動器(Slider), 成本收益矩陣(Cost/Benefit Matrix)等; 最後, 專案願景需要使用盡量簡要的文件固定下來, 並保證專案團隊成員都能瞭解.該文件需要包括:

• 當前的問題
• 機會描述和理由(描述專案的重要性)
• 專案的價值
• 專案如何和組織的戰略目標達成一致
• 解決方案綜述
• 專案包含的關鍵功能
• 專案必須服從的技術和約束條件
• 專案範圍
• 專案的關鍵時間線
• 專案收益分析
• 專案和其他專案的依賴性
• 專案的相關風險以及如何消除

專案/產品路線圖

主要描述為了達到產品願景而需要交付的關鍵功能和特性, 這些特性基本處於Epic和特性層面, 不包裹使用者故事(User Story). 它從時間的維度來表述對願景的支援和實現. 它從時間維度來表達對願景的支援和實現. 當專案/產品需要釋出多個版本時, 專案線路圖就非常重要, 否則, 它和釋出計劃相同, 專案/產品線路圖由專案負責人和專案經理維護, 並保持更新. 通常, 會形成路線圖問題或幻燈片, 使用大圖示顯示重要的里程碑, 包含的功能和釋出日期等, 讓所有專案/產品相關人員都清楚產品各個元件的可能釋出日程.

版本釋出計劃

版本釋出計劃由團隊成員和專案/產品負責人共同制定, 並通過版本釋出計劃會議討論通過. 它包括了當前版本需要交付的, 達成一致的關鍵功能, 並經過優先順序排序, 可以包含EPIC和User Story. 版本釋出計劃中常使用的概念包括:故事點, 迭代團隊速率和優先順序排序. 通常, 專案/產品負責人提出本次釋出的目標, 團隊成員根據目標和功能特性的重要性對故事進行排序, 並依據團隊速率覺得本次釋出需要包含的故事點. 前幾次版本釋出使用估算值, 其準確性隨著專案/產品的時間持續而逐步精確. 版本釋出計劃是劇本適應性可調整的計劃, 會隨著專案演進而改變.

迭代計劃

迭代計劃是對版本釋出計劃的再次細化, 同樣由團隊成員和專案/產品負責人共同制定, 並聽過迭代計劃會議討論通過. 迭代會議負責兩件事情:

• 根據當前狀態確定是否需要對版本計劃做出更新
• 為當前的迭代計劃制定迭代計劃

迭代計劃中常使用的概念包括: 拆分Epic和User Story, 任務, 任務估算. 在迭代會議上, 成員首先根據當前的專案變化對釋出計劃進行更新, 然後根據更新後的, 重新排序過的故事制定當前迭代需要完成的故事, 並對這些故事進行詳細的任務拆分. 成員在認領完任務後, 會對任務的實現時間做出估算, 估算值需要具體到這些估算資訊可以方便任何成員追蹤任務的進度.

每日實現

沒事實現是團隊成員完成任務的具體過程, 它依據任務估算值並根據任務最終實現情況更新該值. 在敏捷方法中, 使用每日站會議來報告進度. 通過15分鐘的站立形式, 團隊成員報告故事或者任務的完成,未完成狀態, 而解決層面的問題則在會議之後處理.

完整團隊

Scrum團隊必須具備的三個完整性:

團隊職責完整性

產品負責人（Product Owner）

• 確定產品的功能。
• 決定釋出的日期和釋出內容。
• 為產品的收益(profitability of the product)負責。
• 根據市場價值確定功能優先順序。
• 在30天內調整功能和調整功能優先順序。
• 接受或拒絕接受開發團隊的工作成果

敏捷教練 (Scrum Master)

• 負責監督整個Scrum專案程序, 調整開發計劃
• 保證團隊資源完全可被利用並且全部是高產出的。
• 保證各個角色及職責的良好協作。
• 解決團隊開發中的障礙。
• 做為團隊和外部的介面，遮蔽外界對團隊成員的干擾。
• 保證開發過程按計劃進行，組織 Daily Scrum, Sprint Review and Sprint Planning meetings。
• 需要知道什麼任務已經完成，哪些任務已經開始，哪些新的任務已發現，和哪些估計可能已經發生變化. 根據以上的情況更新反映每天完成的工作量以及還有多少沒有完成的燃盡圖
• 需要找出阻礙Scrum的障礙和依賴, 根據優先順序指定計劃解決這些障礙
• 個人問題或衝突在Scrum裡是需要解決的。這些都需要被澄清，或通過內部的溝通解決，或向管理層和HR尋求幫助解決
• Scrum Master需要知道什麼任務已經完成，哪些任務已經開始，哪些新的任務已發現，和哪些估計可能已經發生變化。Scrum Master需要根據以上的情況更新反映每天完成的工作量以及還有多少沒有完成的Burndown Chart。 Scrum Master還必須仔細考慮進展中的開放任務數，進展中的工作需要得到最小化，以實現精益生產率的收益。
• Scrum Master需要找出阻礙Scrum的障礙和依賴。他們需要的優先次序和跟蹤。根據優先順序指定計劃解決這些障礙。其中有些問題可以在團隊內部解決，有些則要團隊之間的協調，還有的要管理層的介入來解決.

開發團隊 (Scrum Team)

• 具有不同特長的團隊成員，人數控制在5-7個左右, 跨職能, 包括開發, 需求, 測試
• 弱化分工, 每個人都參與設計, 開發與測試
• 確定Sprint目標和具體說明的工作成果。
• 在專案嚮導範圍內有權利做任何事情已確保達到Sprint的目標。
• 向Product Owner演示產品功能。

團隊素質完整性

• 要具備很強的集體協作精神.
• 要具備良好的溝通能力
• 必須能積極主動的接受新的事物, 要具備創新能力
• 要具備極強的自我管理能力和積極主動的精神

溝通的完整性

• Sprint啟動會
• 每日站立會議
• Sprint回顧會

案例

驗收測試驅動開發ATDD

TDD 只是開發人員的職責，通過單元測試用例來驅動功能程式碼的實現。ATDD在準備實施一個功能或特性之前，首先團隊需要定義出期望的質量標準和驗收細則，以明確而且達成共識的驗收測試計劃（包含一系列測試場景）來驅動開發人員的TDD實踐和測試人員的測試指令碼開發。面向開發人員，強調如何實現系統以及如何檢驗。

• 挑選使用者故事
• 為故事寫測試
• 實現測試
• 實現故事

結對程式設計

結對程式設計可以看做是一種敏捷化的Code Review

新結對程式設計

兩位程式設計師新成結對小組, 每人一臺電腦, 坐在臨近的工位上, 兩人合作完成一組功能(可以是兩個或多個獨立的模組)的設計, 程式碼實現. 但對已某一個模組來說設計和程式碼是分開的, 一個人負責設計, 另一個人負責寫程式碼, 對於其他模組則反之.

確定衝刺計劃

定義和說明

• 目的: ST和PO共同決定在接下來的衝刺週期內的目標以及那些功能和任務需求要完成
• 主要角色: ST, PO, SM
• 主要輸入: Product backlog, 團隊的能力
• 主要輸出: Sprint Backlog

衝刺會議分兩個部分 
1. 解決本次衝刺要完成哪些需求 
2. 解決這些選擇的需求要如何被完成

案例

故事點估算

故事點是表述一個使用者故事, 一項功能或一件工作的整體大小的一種度量單位. 數值本身不重要, 重要的是這些故事之間對比體現相對大小.

計劃撲克

• 開始時, 美人得到一張撲克, 上面有任務點(?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, 無窮).?代表無法估算, 無窮代表故事太大
• 開始對故事進行估算, 先由PO介紹這個故事的描述. 接著澄清問題
• 每一個組員從撲克中挑選可以代表這個故事的卡片, 集體亮牌
• 最高分和最低分的組員像團隊做出解釋
• 全組成員自由討論幾分鐘
• 重新打分, 直到全組統一.

敏捷估算2.0(Agile Estmating 2.0)

• PO像團隊成員介紹每一個使用者故事, 確保所有需求相關的問題都在做估算前得到解決
• 整個團隊參與遊戲: 一次由一人將一個故事卡片放在合適的位置, 規模小的在左,規模大的在右, 一樣大的豎排. 輪流移動故事卡片, 直到整個團隊都認同白板上故事卡的排序為止.
• 團隊將故事點(Story Point)分配給每個故事.

需求訂單(Product Backlog)

記錄使用者需求的列表, 包括產品所有需要的特徵.

• 每一項包含了需求標題, 描述, 重要性, 故事點(或其他表示大小的數字)
• 需求訂單式開放的, 團隊每個成員都可以編寫和維護
• 在整個專案開放生命週期內, 需求訂單需要不斷維護, 管理與跟蹤需求變化

燃盡圖

在專案完成之前, 對需要完成的工作的一種視覺化表示. 燃燒故事點.每天更新一次

• 具備可視性
• 具備風險預估, 提醒團隊目前完成情況
• 具備可估量, 直接顯示當前還需要的時間.

燃盡圖常見問題

每日站立會議(Daily Scrum)

每日站立會議旨在讓團隊統一目標, 協調內部問題的解決, 絕非進度彙報.一般不超過15分鐘.

• 我們上次開會後你都幹了什麼
• 在我們下次開會之前你要做什麼
• 每個你負責的、正在做的任務還剩下多少時間
• 你的工作被阻礙了嗎

任務板(Task board)

• 為專案團隊提供一個便利的工具用於管理他們的工作
• 是團隊成員對本衝刺的工作一目瞭然

任務板通常設立與專案團隊日常工作的公共空間的一面牆上. 任務板上得資訊包括該沖洗計劃完成的使用者故事和相應的任務, 分別解除安裝卡片上, 按照一定的方式貼在任務板上(To Do, In Progress, Done). 團隊成員通過調整任務卡得位置和上面的資訊反映任務的執行情況.

使用者故事卡

每張卡片記錄一條使用者故事, 故事點.

任務卡

每個使用者故事卡片通對應的多個任務卡. 每張卡片記錄一條任務, 到目前為止完成該任務所需的工作量(小時).隨著進展試試更新.

任務板的使用

使用者故事

作為<某個角色>, 我希望<實現何種功能>, 以便<帶來何種價值>.

如: 作為一個使用者, 我希望在每次退出系統前得到是否儲存的提示, 以便所有內容都被成功儲存了.

測試驅動開發(TDD)

先開發測試用例, 然後再開發程式碼