: 雖然剛入職場時
: 敏捷開發就已經是很紅的議題
: 但至少我前幾份專案都還是很傳統的瀑布
: 個人感覺是近年越來越明顯
: 所有的專案管理方式都越來越朝敏捷的概念走
: 我自己體感
: 比以前痛苦指數提高了很多
痛苦就不是敏捷
: 例如說: 以前談好一整個版本的spec
: 要談時程就是基於一整個版本再談
: 中間有什麼改動很正常
: 基於是整個版本談時程
: 大多數還有arrange的空間
: 時程變動就是整體移，不會在一條一條對
: 通常不太會很細節的追進度
: 頂多每週或每天需要跟自己直屬報一下
這還比較敏捷
: 最近幾年很明顯: 所有的專案管理方式都往敏捷的精神走
: 工作訂出來就是丟給工程師問時程
: 沒有一個很固定的版本空間
: 就是請你一直做，做到一個程度再確定版本
敏捷跟不確定不相關，這是誤解。這種情況其實就是隕石
: 但是需求一直改本來就很正常: 所以明面上是工程師自己壓
: 但其實需求根本不固定
: 所以細項時程根本沒參考性
: 每天為了其實很不重要的東西被時間追著跑
壓時間就不是敏捷了。
: 早期都是談1-2個月的版本開發時間: 需要的話平日加班週末加班趕進度
: 進度狀態比較好也可以適度休息一下
: 只要在講好的時間拿出來，大家都好說話
: 現在偏向每一天都被進度追著跑
: 一個禮拜要報好幾次進度
: 時程沒對到就說工程師自己定的
再重申一次，定時間是完全違反敏捷的精神。敏捷是預估(forecast)不是設定(promise)
: 以前傳統瀑布式自己可以抓放工作: 有些小東西先放一下以後再處理
: 或是卡關太久需要交代進度
: 就抓個小東西出來作
: 交代完進度再來專心面對魔王關
: 現在敏捷其實
: 不會給你自己安排的空間
: 東西丟出來就要定時程
: 每次都跟你逐條討論
: 你根本無法自己安排每天要做什麼
: 甚至上下午可能都被定死
流星雨，不是敏捷
: 先不討論哪一個開發模式對專案品質比較好: 我也沒有那個視野可以討論這種事情
: 單就痛苦指數來說
: 從工程師角色看，絕對是指數級上升
: 我就很不解
: 為啥很多工程師很熱衷於討論敏捷開發
: 甚至是去學習敏捷開發課程
: 從我的邏輯看
: 相當於工程師用管理者的視角
: 去思考如何壓榨自己
: 然後還去實踐
因為你被假敏捷壓榨。Scrum常常會變成這樣，Scrum是壓榨員工的好工具，如果濫用的話。
---------------------
敏捷軟體開發宣言
https://agilemanifesto.org/iso/zhcht/manifesto.html---------------------
敏捷軟體開發宣言
個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商
回應變化 重於 遵循計劃
也就是說，雖然右側項目有其價值，
但我們更重視左側項目。
敏捷軟體的 12 個原則
Ron Jefferies有寫Scrum的問題，但問題就是使用的人
特別有講sprint壓時間是完全違反敏捷的精神。
敏捷的起源是跟"toyota way"很有關係的。實做的人（工程師）要主導開發，換句話說是由下往上。瀑布是由上往下。隕石跟流星雨也都是由上往下。
像我就很不欣賞Jira跟Slack，不是工具不好，但使用起來都是追進度，抓戰犯，完全違反敏捷的精神。
敏捷的意義是以人為本，支持工程師，跟客戶良好互動，但台灣很多公司都是用敏捷之名行壓榨員工之實。
--