敏捷軟件開發宣言
<big><big>
個體與交互 勝過 流程和工具
可用的軟件 勝過 完備的文檔
客戶合作 勝過 合同談判
響應變化 勝過 遵循計劃
</big></big>
敏捷宣言遵循的原則
- 我們的最高目標是通過盡早、持續地交付有價值的軟件來滿足客戶
- 即使到了開發后期也歡迎改變需求，敏捷過程利用變化來為客戶創造競爭優勢
- 不斷交付可用的軟件，周期越短越好
- 在整個項目開發期間，業務人員與開發人員必須天天都在一起工作
- 善于激勵項目成員，給他們提供所需的環境和支持，并相信他們能夠完成任務
- 無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談
- 可用的軟件是衡量進度的主要指標
- 責任人、開發者和用戶應保持恒久穩定的開發速度
- 對技術的精益求精以及對設計的不斷完善將提升敏捷性
- 簡潔是一門藝術，要盡最大可能減少不必要的工作
- 最佳的架構、需求和設計出自于自組織的團隊
- 團隊要定期反省并調整團隊行為以便更高效地工作
Scrum 最佳實踐
承諾 勇氣 專注 開放 尊重
- 具備清晰且好記的愿景
- 擁有維護良好的產品代辦列表
- 產品代辦列表依照業務價值進行排序
- 產品代辦列表中故事的大小由團隊決定
- 舉行每日站立會議
- 使用燃盡圖
- Sprint 不能受到管理層以及客戶的干擾
- 團隊交付的軟件必須符合“完成的定義”
- 舉辦協作式的評審會議
- 回顧會議的重點要放在改進團隊和組織的工作流程上
十大典型障礙
- 會議規則沒能被遵循
- 產品遠景和 Sprint 目標不清晰
- 沒有產品負責人負責回答提問
- 產品待辦列表未能按商業價值區分優先級
- 并不是所有負責交付產品的人員都是團隊里的成員
- Scrum Master 還要處理其他任務，不能集中精力
- 團隊人數過多（多于7人）
- 團隊沒有能坐在一起工作的空間
- 團隊的 Sprint 待辦列表混亂
極限編程最佳實踐
溝通 簡單 回饋 勇氣 尊重
-
結對編程
所有的產品軟件都是由兩個程序員、并排坐在一起在同一臺機器上構建的。 -
計劃游戲
計劃是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。 -
測試驅動開發
程序員以非常短的循環周期工作，他們先增加一個失敗的測試，然后使之通過。 -
完整團隊
開發人員、業務分析師、測試人員等一起工作在一個開放的場所中，他們是同一個團隊的成員。這個場所的墻壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進度的東西。 -
持續集成
團隊總是使系統完整地被集成。 -
改進設計
隨時改進糟糕的代碼。保持代碼盡可能的干凈、具有表達力。 -
客戶測試
作為選擇每個所期望的特性的一部分，客戶定義出自動驗收測試來表明該特性可以工作。 -
編碼標準
系統中所有的代碼看起來就好像是被單獨一個非常值得勝任的人編寫的。 -
集體代碼所有權
任何結對的程序員都可以在任何時候改進任何代碼。 -
簡單設計
團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試，不包含任何重復，表達出了編寫者想表達的所有東西，并且包含盡可能少的代碼。 -
系統隱喻
團隊提出一個程序工作原理的公共景像。 -
可持續的速度
團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作。他們保存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。
敏捷開發最佳實踐
面向對象設計原則
-
SRP 單一職責原則
就一個類而言，應該僅有一個引起它變化的原因。 -
OCP 開放－封閉原則
軟件實體（類、模塊、函數等）應該是可以擴展的，但是不可修改。 -
LSP 里斯科夫替換原則
子類型必須能夠替換掉它們的基類型。 -
DIP 依賴倒置原則
抽象不應該依賴于細節。細節應該依賴于抽象。 -
ISP 接口隔離原則
不應該強迫客戶依賴于它們不用的方法。接口屬于客戶，不屬于它所在的類層次結構。 -
REP 重用發布等價原則
重用的粒度就是發布的粒度。 -
CCP 共同封閉原則
包中的所有類對于同一類性質的變化應該是共同封閉的。一個變化若對一個包產生影響，則將對該包中的所有類產生影響，而對于其他的包不造成任何影響。 -
CRP 共同重用原則
一個包中的所有類應該是共同重用的。如果重用了包中的一個類，那么就要重用包中的所有類。 -
ADP 無環依賴原則
在包的依賴關系圖中不允許存在環。 -
SDP 穩定依賴原則
朝著穩定的方向進行依賴。 -
SAP 穩定抽象原則
包的抽象程度應該和其穩定程度一致。
通用會議規則
縮寫詞：
- PB = Product Backlog/產品待辦列表
- SB = Sprint Backlog/Sprint 待辦列表
- SM = Scrum Master
- PO = Product Owner/產品負責人
基本要求
- 每次會議都要準時開始、準時結束
- 每次會議都采取開放形式，所有人都可以參加
會前準備
- 提前邀請所有必須參會的人，讓他們有時間準備
- 發送帶有會議目標和意圖的會議綱要
- 預訂會議所需的全部資源：房間、投影儀、掛圖、主持設備，以及此次會議需要的其他東西
- 會前 24 小時發送提醒
- 準備帶有會議規則的掛圖
會議推進
- 展開討論時會議的推進人必須在場。他不能參與到具體討論中，但是他需要注意討論進程，如果討論參與者失去重點，他還要將討論帶回正軌
- 推進人展示會議的目標和意圖
- 必要時推進人可以商定由某個人撰寫會議記錄
- 推進人可以記錄團隊的意見或教授團隊如何自己記錄文檔；而且推進人可能會在掛圖上進行記錄，將對話可視化
- 推進人會使用類似“停車位”之類的工具來記錄與會議無關的議題供后續討論，從而保證會議圍繞重點進行
- 推進人會對會議進行收尾，并進行非常簡短的回顧以傳達會議上所達成的共識(不超過 5 分鐘)
估算會議
- 與會者 = 團隊 + SM + PO + 用戶
- 時間 < 90 分鐘
會議目的
- 估算 PB 中的故事便于后續計劃 Sprint
- 讓團隊成員知道項目接下來會有哪些事情要做
- 讓團隊通過估算更深入地理解 PB 中的故事
會議輸入
- PO 根據業務價值排列好優先級的 PB
會議過程
- PO 依次展示 PB 中的故事
- 每展示一個團隊就對該故事進行估算并記錄平均故事點數
- 如果其中兩個人的估算點數超過兩倍則分別說明原因，然后重新估算
- 如果某個故事過大應將其劃分為較小的故事然后進行估算
注意：
- 只有團隊能估算 PB 中的故事，PO 不參與估算
- 上一個 Sprint 遺留下來的故事需要重新估算
- 不要討論技術細節
會議輸出
- 經過估算和調整的 PB
計劃會議
- 與會者 = 團隊 + SM + PO + 用戶
- 時間 < 60 分鐘
會議目的
- 讓團隊詳細了解最終用戶的真實需要
- 團隊承諾他們本次 Sprint 能夠交付哪些內容
會議輸入
- 經過估算和排序的 PB
會議過程
- 團隊依次討論 PB 中的故事
- 找出驗收條件
- 找出非功能性需求（性能、安全……）
- 確定每個故事的驗收測試用例
- 確定每個故事完成的定義
- SM 向團隊正式提問“是否能在本 Sprint 周期內完成該故事”，如果是則放入本次 SB 中
- 確定本次 Sprint 要達成的目標
注意：
- 只有團隊能夠決定 SB 中可以包含哪些故事
會議輸出
- 選擇好的 SB
- 各個故事的驗收測試用例
任務分解會議
- 與會者 = 團隊 + SM
- 時間 < 60 分鐘
會議目的
- 確定 SB 中各個故事的設計方案
- 會議結束后團隊成員都知道如何完成每個故事
會議輸入
- 選擇好的 SB
會議過程
- 團隊依次討 SB 中的故事
- 針對每個故事討論需要創建什么樣的架構，需要編寫什么樣的接口、類、組件，需要新增或修改哪些數據表等
- 根據討論的結果創建任務
- 為每個任務估算時間（可選）
- 將故事和任務整理到任務板上并宣布本次 Sprint 正式開始
注意：
- 不要分配任務
會議輸出
- 一些方案設計圖表
- 整理好的任務板
每日例會
- 與會者 = 團隊 + SM
- 時間 < 15 分鐘
會議目的
- 為每天的工作做計劃和調整
- 解決團隊開發過程中遇到的障礙
- 通過任務板幫助團隊聚焦于每日活動之上
- 讓團隊成員彼此清楚各自的工作
會議輸入
- 任務板和燃盡圖
會議過程
- 團隊在任務板旁站成一個圈
- 從左邊第一個人開始，從任務板上取下其當前的任務并向其他成員說明目前的情況
- 如果沒有完成則放回進行列并做好標記
- 如果該任務已經完成則將其放入完成列，然后領取新的任務并承諾完成時間
- 如果在完成該任務過程中遇到障礙則報告給 SM，同時在任務卡上做好標記
- 和其他成員預約結對編程
- 其他成員對該任務有疑問可隨時提出
注意：
- SM 站在圈外，團隊不是向 SM 匯報工作
- SM 不要提問題、不要移動任務卡或更新燃盡圖
- 不要討論技術細節問題，可以會后單獨討論
- 不要在沒有準備的情況下參會
- 進行中的任務不要過多（一般不超過 4 個）
會議輸出
- 更新后的任務板和燃盡圖
評審會議
- 與會者 = 團隊 + SM + PO + 用戶
- 時間 < 90 分鐘
會議目的
- 團隊通過展示工作成果獲取反饋
- PO 驗收團隊的工作成果
會議輸入
- 已完成的故事列表
- 可演示的工作成果
會議過程
- PO 歡迎大家來參加本次評審會議
- PO 提醒大家本次 Sprint 要達成的目標
- 團隊根據已完成的故事列表依次展示新功能并讓大家嘗試新功能
- PO 或 SM 在卡片上記錄會議過程中的反饋
注意：
- 不要展示還不能發布的產品增量
- SM 不要負責展示結果
- 團隊不要針對 PO 展示
會議輸出
- 根據會上的反饋新增的待辦列表
回顧會議
- 與會者 = 團隊 + SM
- 時間 < 90 分鐘
會議目的
- 發現哪些方面需要改進
會議輸入
- 燃盡圖，PB，SB
會議過程
- 宣布本次 Sprint 結束
- 準備一張寫著“做得好”標題和一張寫著“可改進”標題的掛圖
- 在每張掛圖上繪制一條帶有開始和結束日期的時間線
- 從“做得好”開始，團隊成員依次（包括 SM）在時間線上寫上認為做得不錯的事件并說明
- 以同樣的方式完成“可改進”議題
- 討論如何改進并記錄在卡片上，如果是障礙則做好標記
會議輸出
- 為了改進而新增的待辦列表
用戶故事
用戶故事是從用戶的角度來描述用戶渴望得到的功能
故事三要素
- 角色：誰要使用這個功能
- 活動：需要完成什么樣的功能
- 商業價值：為什么需要這個功能，這個功能帶來什么樣的價值
用戶故事模板
- 英文：As a <Role>, I want to <Activity>, so that <Business Value>
- 中文：作為一個 <角色>, 我想要 <活動>, 以便于 <商業價值>
注意:
- 用戶故事不能夠使用技術語言來描述，要使用用戶可以理解的業務語言來描述
Ron Jeffries 的 3 個 C
- 卡片（Card）：用戶故事一般寫在小的記事卡片上?？ㄆ峡赡軙懮瞎适碌暮喍堂枋觯ぷ髁抗浪愕?。
- 交談（Conversation）：用戶故事背后的細節來源于和客戶或者產品負責人的交流溝通。
- 確認（Confirmation）：通過驗收測試確認用戶故事被正確完成。
用戶故事的六個特性（INVEST原則）
- 獨立性（Independent）：要盡可能的讓一個用戶故事獨立于其他的用戶故事。用戶故事之間的依賴使得制定計劃，確定優先級，工作量估算都變得很困難。通常我們可以通過組合用戶故事和分解用戶故事來減少依賴性。
- 可協商性（Negotiable）：一個用戶故事的內容要是可以協商的，用戶故事不是合同。一個用戶故事卡片上只是對用戶故事的一個簡短的描述，不包括太多的細節。具體的細節在溝通階段產出。一個用戶故事卡帶有了太多的細節，實際上限制了和用戶的溝通。
- 有價值（Valuable）：每個故事必須對客戶具有價值（無論是用戶還是購買方）。一個讓用戶故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到這是一個用戶故事并不是一個契約而且可以進行協商的時候，他們將非常樂意寫下故事。
- 可以估算性（Estimable）：開發團隊需要去估計一個用戶故事以便確定優先級，工作量，安排計劃。但是讓開發者難以估計故事的問題來自：對于領域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。
- 短小（Small）：一個好的故事在工作量上要盡量短小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代或Sprint中能夠完成。用戶故事越大，在安排計劃，工作量估算等方面的風險就會越大。
- 可測試性（Testable）：一個用戶故事要是可以測試的，以便于確認它是可以完成的。如果一個用戶故事不能夠測試，那么你就無法知道它什么時候可以完成。一個不可測試的用戶故事例子：軟件應該是易于使用的。
任務板
任務板以可視化的方式展示團隊的工作
- 任務板只能由團隊維護
- 盡量使用實體大白板
任務板有 3 列
-
準備做
- 要完成一個故事，你得完成一些任務。在計劃會議上創建的任務以及后續添加的任務都應該放在該列
-
進行中
- 當團隊成員領取某個任務時將任務挪到該列
- 每日站會上會對該列中沒有完成的任務做一個標記（如一個圓點）
- 如果該列中的任務是因為過大而不能在一天內完成則可以考慮將其分解為多個任務重新安排
- 如果一個任務因為障礙無法完成應該做一個標記（如一個紅點）
-
已完成
- 當一個任務完成后，著手該任務的團隊成員就可以將其放入該列并領取下一個任務
燃盡圖
記住：跟蹤進度要由團隊來完成。
- 你必須要有一個 Sprint 燃盡圖！
- 燃盡圖展示“燃盡”（即開發完成）的故事點數，而不是工作小時數
- 縱軸展示故事點數，橫軸展示當前 Sprint 的天數
- 團隊每天更新燃盡圖
- 燃盡圖要便于團隊更新，沒必要讓它看起來很炫，也不要過于復雜、難以維護
角色
隱喻：我們是在拍電影！
Scrum Master = 電影導演
- Scrum Master 保護團隊不受外界干擾
- 他不是團隊的一部分，但是是團隊的領導和推進者
- 他提升 Scrum 團隊的工作效率，控制 Scrum 中的“檢視和適應”周期過程
- 他保護團隊，并與 Product Owner 一起將投資產出最大化
- 他確保所有的利益相關者都可以理解敏捷和尊重敏捷的理念
- 然而，他不負責交付產品
團隊 = 演員
- 團隊交付產品并對其質量負責
- 團隊與所有提出產品請求的人一起工作，包括客戶和最終用戶，并共同創建 Product Backlog
- 團隊分析 Product Backlog 的條目，藉此獲得足夠的信息以構建產品
- 團隊按照大家的共識來創建功能，開發、測試 Backlog 條目并交付產品
- 團隊自愿做出承諾，它對其工作產出負責，并且需要考慮其所屬組織和項目本身的實際情況
- 團隊還會一直和 Product Owner 一起工作，以制定產品的戰略方向
管理層 = 制片廠老板
- Scrum 組織中的管理層非常重要，管理層要為 Scrum 團隊搭建良好的環境，以確保團隊能夠出色工作
- 管理層創建結構和穩定性，必要的時候，他們也會與 Scrum Master 一起重組組織結構和指導原則
客戶 = 制片人
- 客戶是為 Scrum 團隊提出產品需求的人，她會與組織簽訂合同，以開發產品
- 一般來說，這些人是組織中的高級管理人員，負責從外部軟件開發公司購買軟件開發能力
- 在為內部開發產品的公司中，負責批準項目預算的人就是客戶
Product Owner = 故事作者
- Product Owner 從業務角度驅動項目，她傳播產品的明確愿景，并定義其主要特性，她也會在 Sprint 結束時接收產品
- Product Owner 的主要職責是確保團隊只開發對于組織最重要的 Backlog 條目
- 她與團隊的目標相同，并在 Sprint 中幫助團隊完成工作，不干擾團隊成員，并迅速提供團隊需要的所有信息
- Product Owner 對投資回報負責
最終用戶 = 觀眾
- 很多人都可能成為最終用戶，比如市場部人員、領域專家，也可能是因其專業知識而被雇傭的咨詢顧問
- 最終用戶會根據自己的業務知識定義產品，并告知團隊自己的期望，提出請求
產品負責人工作檢查清單
- 產品待辦列表是根據產品負責人最新的想法按優先級排序的嗎？
- 來自所有利益相關人對產品的需求和愿望都被放到產品待辦列表了嗎？
- 產品待辦列表是涌現的嗎？
- 產品待辦列表的規?？晒芾韱?？
- 產品待辦列表中的故事（特別是優先級靠前的）符合 INVEST 原則嗎？
- 產品待辦列表中有技術債務相關的內容嗎？
- 產品待辦列表作為信息輻射體，對所有利益相關人立即可見嗎？
- 如果是電子版待辦列表，每個人都知道如何方便地使用它嗎？
- 評審會議后發布計劃是跟著調整的嗎？
團隊工作檢查清單
- 團隊成員大多數時間處在流暢狀態嗎？（目標明確、全神貫注、及時反饋、工作輕松、不斷學習……）
- 團隊成員經常在一起慶祝各自的成功嗎？
- 團隊成員相互以高標準監督、相互挑戰以促進成長嗎？
- 有沒有一些話題因為大家感覺難受，所以在團隊里沒有進行討論？
- 嘗試過用不同的形式和地點開回顧會議嗎？
- 團隊在開發過程中一直關注驗收標準嗎？
- 任務板和燃盡圖方便可見嗎？易于使用嗎？
- 任務板和燃盡圖能反映團隊的真實情況嗎？
- 任務板和燃盡圖被團隊外部用于微觀管理了嗎？
- 團隊成員是自己選擇并領取任務嗎？
- 團隊有和產品負責人溝通將技術債務的內容包含在待辦列表中了嗎？
- 團隊成員能否拋開各自的崗位定義，對約定工作的所有方面（開發、測試、文檔等）集體負責？
- 管理層是否以集體的成功來衡量團隊？
工程實踐檢查清單
- 正在開發的系統有沒有一個類似“按下測試”的按鈕，從而每個人（同一團隊或不同團隊的）都能方便地檢測到系統是否被破壞了？
- 自動化的端到端系統測試（或功能測試）與自動化的單元測試之間有適當的平衡嗎？
- 系統功能測試和單元測試代碼是團隊自己維護的嗎？（還是說由其他團隊單獨編寫和維護）
- 團隊已經發現在系統測試和單元測試之間存在有用的灰色區域了嗎？
- 當有人引起回歸失敗時，是否有個持續集成服務器會在一小時甚至幾分鐘內自動發出警報？
- 所有的測試都會在持續集成服務器上運行嗎？
- 團隊成員已經發現重構的樂趣和成功了嗎？
- 重構是隨時在進行嗎？有自動化測試的保障嗎？
- 故事的“完成”定義或驗收標準中包含自動化化測試和重構了嗎？
- 團隊成員大多數時間都結對編程嗎？
