※ 引述《oopFoo (3d)》之銘言： : --------------------- : 敏捷軟體開發宣言 : https://agilemanifesto.org/iso/zhcht/manifesto : 個人與互動 重於 流程與工具 : 可用的軟體 重於 詳盡的文件 : 與客戶合作 重於 合約協商 : 回應變化 重於 遵循計劃 : 也就是說，雖然右側項目有其價值， : 但我們更重視左側項目。 : 敏捷軟體的 12 個原則 : https://agilemanifesto.org/iso/zhcht/principles 敏捷是做出客戶真正想用的東西 在需求變動與不確定 (連客戶自己都不確定，想用什麼軟體) 以快速小迭代，每個 Sprint 交付最小增量給客戶 客戶親自使用並回饋之後，再次修正 Sprint Goal 開發團隊再次衝刺 Sprint Goal 微調之後 不斷 Loop 把客戶"真正"想用的東西做出來 敏捷的目的，理論上是這樣對吧? 敏捷有可能需求不變動嗎? 反了吧，每個 Sprint 需求都在變，但是更接近客戶真正想要的 規格很穩定才是 Waterfall 吧，但最後做出垃圾被打翻重做 敏捷有可能不壓時程嗎? Sprint 衝刺本身就內含要交付給客戶 其實就是要做完阿，不保證做完，那客戶驗證什麼? 台灣用起來很奇怪的真正原因，是沒有(或無法)小迭代吧! 把一大包，幾個月才能開發完的東西 客戶說要規格A，老闆說要規格A+B，PM加碼規格A+B+C 包起來寫成超大的開發目標 切成 10 個 Sprint 開始追團隊 每個 Sprint 做完成多少，是否準時 切 10 個 Sprint 這件事本身就已是規劃甘特圖 敏不敏捷，吵需求不應該變動，不應該壓時程 根本劃錯重點 -- ※ 發信站: 批踢踢實業坊(ptt.org.tw), 來自: 180.218.93.74 (臺灣) ※ 文章網址: https://ptt.org.tw/Soft_Job/M.1722130959.A.3E2

→ lazarus1121: 第一句就有問題了，有明確客戶請做好需求訪談再開發 07/28 10:33

→ lazarus1121: 敏捷強的是有時連TA都不知道在哪就準備要開始了 07/28 10:35

→ testPtt: 我常遇到需求變動是要改資料庫邏輯的這比較麻煩 07/28 10:42

推 kuosos520: 越聽越覺得可能只有創業比較符合敏捷資格，真的對 07/28 10:48

→ kuosos520: 客戶對產品，有辦法這樣跑嗎？ 07/28 10:48

→ pot1234: 需求改幾次可以翻臉，還是只能像奴隸一樣一直做一直做 07/28 11:15

推 abccbaandy: 這聽起來就很理想，就算小需求也要討論吧？ 那這段時 07/28 13:27

→ abccbaandy: 間怎麼算？ 07/28 13:28

推 Wishmaster: 如果不訂清楚哪在台灣可能別想驗收惹 07/28 16:14

推 viper9709: 覺得創業比較符合+1 07/29 00:28

→ myhome6206: 客戶哪有空陪你一直參與測試 07/29 20:46

推 justben: 沒有初始規格就沒有敏捷 07/31 20:11

推 jobintan: 咋看都是為了追新而追新，本來waterfall 搞得好好的，P 08/01 08:18

→ jobintan: M本身對於agile認識不足或一知半解，又愛沒事找事跟客 08/01 08:18

→ jobintan: 戶說agile多新多潮多牛逼的然後客戶也啥都不知道，被這 08/01 08:18

→ jobintan: 種PM牽著鼻子走。 08/01 08:18