2022 年 07 月 - 敏捷開發是否太過理想？ === 敏捷開發 scrum Less 不同角色 概念 一個 Sprint 1-2 週 除非東西做完不能加東西 (Feature 做不完放下個 Sprint) 放棄 Sprint 重新開始 所有團隊同步 上課實際練習的東西 ——— Product backlog 剛出現的需求被記錄下來 PBI: Product Backlog Item 討論的單位是一個功能(情況) 越緊急的寫得越詳細 PO 不管進度，只管有什麼事情要做 管理 product backlog 只有產品沒有專案 沒有結束 一個 Sprint 不等於一個功能的完成 Sprint 越短可以調整的頻率越高 唯一能改： 做不完 提早做完 立會 讓大家知道其他人狀況 故意讓所有人互卡！？->要幫忙解決其他人的問題 一個單位是一個團隊 團隊內會的東西差越多越好，ex: 後端, 前端, 設計, QA, 個性 規格 scope 關鍵範例 key example ATDD 驗收測試驅動程式開發 一直做有用的事情 每個人有需要的知識 互卡 pair programming 很重要全部的人一起處理 所有人教其他人其他東西 Finished 和 Done 的差別 Finished：絕對的完成 Done：可以用的完成 (敏捷) 人類做不到就不是 end to end test 設定 feature flag 保護未釋出功能（通常只有一個） 隨時可以部署 (commit 就上傳正式環境) 隨時可以退版 完成的定義 開發團隊的水準 * 完成的定義 - 設定完成條件 - 成員水準越高條件設定越高 敏捷開發 PO 不會分工作 有能力消化的人去消化 傳統 PM 推 planning 1 所有團隊 planning 2 團隊內部 回顧會議重新檢視 適應性開發 靈活開發 正常狀況敏捷開發會變慢，品質變好！！！ 每個東西都是跟真的有需要的人確定完才做 - ATDD 為了驗收寫的測試，用測試開發，符合產品需求 - TDD 寫程式的技巧，先寫測試再開發 上面的人想推下面的人想做