---
# System prepended metadata

title: 2022 年 07 月 - 敏捷開發是否太過理想？

---

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 寫程式的技巧，先寫測試再開發

上面的人想推下面的人想做