瀑布流
- 1970 年 Royce 在 IEEE WestCom 軟體工程會議提出，有趣的是，他提出瀑布流是想告訴別人【軟體開發不可以這麼做!】
- 1985 年 美國國防部採用瀑布流
- 21 世紀，政府開始隱約發現瀑布流有著缺陷，在 NASA 官方文件寫道 【一些大型系統的失敗或取消被認為與標準瀑布流有關，而它還非常昂貴】
- 該文還提到 【極限程式設計】看起來很有前景
[補圖]
瀑布流分成四個階段
- 需求收集
- 設計
- 程式
- 測試
BDUF (Big Design Up Front)
瀑布流的問題在於期望【完美化(perfecting)】設計，現實是，你可能創造出讓人驚嘆不已的理論，到實作時才發現一堆併發症。
1995 年 standish group chaos 的報告指出
- 16% 可以如期交付
- 31% 專案被取消
- 53% 預算超出 189%
而原因都是【使用者參與太少】、【需求不完整】
做的工作跟瀑布團隊一樣，但做事的方式不一樣
敏捷宣言
個人互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商
回應變化 重於 遵循計畫
個人互動 重於 流程與工具
- 邊做邊測試
- 頻繁交付給客戶【使用】
- 文件邊做邊寫
- 跨職能團隊 : 不要因為任何個人、部門、流程、資訊瓶頸。
個人互動 重於 流程與工具
- 團隊自我選擇 > 規範
- 當你學了 Scrum 你可能迫不及待的想要導入，但你不該這麼做，自主性團隊應自己選擇工具
- 嘗試 > 規範
- 你可以請求團隊【試著】在一兩個 sprint 使用看看
- 如果你禁止犯錯，阻止試驗，他們將無法得知還存在著更好的工具
可用的軟體 重於 詳盡的文件
- 別把文件當工作產品
- 敏捷仍然要寫文件，甚至會寫更多文件，但文件是為了檢視與調整。
與客戶合作 重於 合約協商
- 一份完善的合約應對【各方】的照顧都很齊全
- 各方關係更像【合夥人】齊心力在預算內完成任務，而不是轉嫁給任何一方。
回應變化 重於 遵循計畫
- 計畫趕不上變化
- 別想只拿堅定的計畫出海，準備好你的羅盤跟地圖修訂航線
- 檢視與調整
敏捷原則
- 你的最優先任務是滿足客戶需求
- 駕馭變化，為客戶創造競爭優勢
- 頻繁交付
- 與業務一起工作
- 給予所需的環境與工具，並信任他們能完成工作
- 團隊內部面對面交談
- 可用軟體是唯一開發進度的量測標準
- 穩定開發速度(DPS)
- 追求卓越
- 工作量最大化 (先做最重要的功能)
- 架構、需求、設計都來自自我組織的團隊
- 定期檢視、討論如何提高效率、修正自己行為
自省會議不能省
要是超級程式設計師離職，誰來維護系統
天才贏得比賽，合作與才智贏得冠軍 – 麥克喬丹
PO
- 引導團隊做最有價值的工作
- 唯一有權要求團隊做事，並改變待辦清單優先順序的人
- 唯一窗口 ，【聽起來蠻重要的，你應該去找 PO 談談】
- 掌握願景
- 代表業務
- 代表客戶
- 持有產品待辦清單
- 劃定故事優先順序
- 設定故事驗收標準
- 有空回答問題
SM
- 諫言者
- 不做任何決定，由團隊自行決策
- 為團隊移除障礙
- 將團隊的成功放在自己的成功之上
- Scrum專家
- 教練
- 障礙移除者
- 引導者
【這不是我該負責的?這是其他部門的事】
RD
- 團隊必須共同承擔，共同負責，並不是完成【你的】工作，而是完成【這份】工作。
- 團隊需要你做什麼，你就是什麼，為了讓某人工作【有效率】反而會拖慢了團隊
- 負責交付使用者故事
- 做開發工作
- 自我組織地交付使用者故事
- 估算流程權
- 可以自己決定如何做事
- 避免【與我無關】
Sprint 各種會議
[補圖]