[討論] 關於敏捷越來越深入台灣職場
小弟就業大概十來年
雖然剛入職場時
敏捷開發就已經是很紅的議題
但至少我前幾份專案都還是很傳統的瀑布
個人感覺是近年越來越明顯
所有的專案管理方式都越來越朝敏捷的概念走
我自己體感
比以前痛苦指數提高了很多
例如說
以前談好一整個版本的spec
要談時程就是基於一整個版本再談
中間有什麼改動很正常
基於是整個版本談時程
大多數還有arrange的空間
時程變動就是整體移,不會在一條一條對
通常不太會很細節的追進度
頂多每週或每天需要跟自己直屬報一下
最近幾年很明顯
所有的專案管理方式都往敏捷的精神走
工作訂出來就是丟給工程師問時程
沒有一個很固定的版本空間
就是請你一直做,做到一個程度再確定版本
但是需求一直改本來就很正常
所以明面上是工程師自己壓
但其實需求根本不固定
所以細項時程根本沒參考性
每天為了其實很不重要的東西被時間追著跑
早期都是談1-2個月的版本開發時間
需要的話平日加班週末加班趕進度
進度狀態比較好也可以適度休息一下
只要在講好的時間拿出來,大家都好說話
現在偏向每一天都被進度追著跑
一個禮拜要報好幾次進度
時程沒對到就說工程師自己定的
以前傳統瀑布式自己可以抓放工作
有些小東西先放一下以後再處理
或是卡關太久需要交代進度
就抓個小東西出來作
交代完進度再來專心面對魔王關
現在敏捷其實
不會給你自己安排的空間
東西丟出來就要定時程
每次都跟你逐條討論
你根本無法自己安排每天要做什麼
甚至上下午可能都被定死
先不討論哪一個開發模式對專案品質比較好
我也沒有那個視野可以討論這種事情
單就痛苦指數來說
從工程師角色看,絕對是指數級上升
我就很不解
為啥很多工程師很熱衷於討論敏捷開發
甚至是去學習敏捷開發課程
從我的邏輯看
相當於工程師用管理者的視角
去思考如何壓榨自己
然後還去實踐
-----
Sent from MeowPtt on my SM-S9110
--
因為推的人都是傳道者
這只是披著敏捷開發實際上是waterfall的變體
敏捷(X) 隕石(O)
敏捷不是要有個有經驗的PM來帶比較好嗎
這就要看思考角度了,單純只想領薪水的話敏捷很痛苦
因為推的人,只負責開會
還要浪費時間開會 白吃東西
管
理職,不管你換什麼玩法這個本質不07/25 10:58
會改變
工程師精於解決需求,管理職精於靠嘴壓榨出價值,不論哪
種開發方法都不能扭轉這樣的利益關係
最簡單的,你敢不敢拿著需求去跟你帶的新人說,這個本來
一個月要完成的東西麻煩你們趕工一下兩個禮拜完成
然後再轉頭跟上面報告說這個沒有一個半月做不出來
現在路邊的貓貓狗狗都可以直接跑去找工程師押時程了
當然是方便插單跟臨時改scope呀
因為老闆聽到敏捷就高潮阿...你痛不痛苦關他屁事
PM也爽,需求講不清楚可以說我們是敏捷
每天一堆會搞得好像很忙 有在做事
一堆打著敏捷開發,實際上整天浪費時間開會
就是一種新的壓榨手法阿 老闆聽到當然開心
習慣就好
整天在那邊裝忙
你這不是敏捷 是隕石石開發法 真正的敏捷是目標小又明確
全力在短時內作出來 而不是亂改
而且成員是全職在寫 本來就不給你自己安排想作別的
需求不明確不叫敏捷,這叫隕石
那些熱衷的通常是想轉PM的開發XD
就是產出最大化啊 不把人當人看 當工具用
插單+hotfix+milestone都要同時間做好喔,做不完的時候
還可以說給工程師自由規劃工作時間的空間了。
比較痛苦的瀑布式開發
根本沒有敏捷,只是換個名詞繼續催你而已
其實對於QA也是折磨,例如regression testing只給了更
短的時間跑整個流程
會強調敏捷的80%都是隕石
有時候不一定強調敏捷這個名稱,只是業界大多往這
個方向走了
你們是不是都沒用jira之類的管理工具然後一直用開會對進度
的方式做事?
我們公司說穿也是常常什麼週會連站會都在細究進度
用jira,走敏捷精神,還是一樣,
問題不是實踐方法
是被被短時程追著跑的痛苦
我感覺用什麼工具都差不多,就這種精神很反人性
看到你說一直報進度 感覺是不是浪費很多時間開會
我總有燃燒自己的時間跟融化的時間
不能一直讓我燃燒
我倒不覺得反人性 敏捷應該是及早發現及早治療 我前公司我
們做了一個軟體做超久 丟上市場才發現沒半個用
要是能小步快跑 早點驗證早點發現不對 我們就不用浪費時間
了
那是公司的角度看,不是工程師的角度看
工程師的時間有換到薪水,就不是浪費時間,除非你
說你創業
那感覺你應該多抓一點自己的buffer吧 順風就提早做完 不順
就on time 這樣對管理方也比較好暗算
也可以請假吧 需要休息就好好休息
另外我沒記錯的話敏捷精神不是要大家專注在一個sprint上嗎
?你怎麼有很多進度要追
不討論細節跟實踐方式,是指目前大多往這個方向做
管理
敏捷到底應該怎樣,窩不知道,窩只知道比瀑布痛苦
很多
因為大部分公司是假敏捷啊 只會站立咪聽+隕石
我覺得很多都是假敏捷 搞錯重點弄成他不舒服我也很痛苦的樣
子
道理簡單 跨過學習門檻後公司競爭力會提升很多
Scrum Master就是小PM的變形
不過我現在都不講敏捷 都化整為零直接精算時間
你要一天就上版也行 那少掉的測試時間自己要負責任
沒有測試人員的組織 基本上是輕視測試這項專業
甚麼叫做 "開發人員應該..." 那都是一種不負責任的話術
年紀越大我越覺得有個專門的品管人員會很安心
很多開發人員認為測試人員不會測 那只是打資訊落差而已
如果在開發過程中測試人員提早進場做測試計畫
那麼測試人員的準備不一定會比開發人員少
假scrum 真daily review, push進度 會議又超時
差異就在於成本 (不好意思離題了講一堆)
最近也遇到 跟原po深有同感
你知道十家公司一般會有十一種敏捷跑法嗎
這不是敏捷的問題 是你公司制度的問題 看起來不是敏捷
時間是在grooming跟planing時就決定的 也是左移提早發現問題
做到一半改需求改AC 這看起來根本沒有敏捷
"那是因為沒有執行真正的敏捷"
真正的敏捷只存在於幻想中吧
人不是機器 每天叫你全力 最好能做到
又不是國外可以按時休長假
本來就是來壓榨出工程師生產力的機制...
最後可能發現真正的敏捷速度比瀑布還慢XDDD
敏捷的總時程本來就會比瀑布慢啊...
想要用一條鞭的方式管理,結局就是悲劇
敏捷不會比較快 只是一種管理方式 不會讓工作變少
主要是提早發現隨時調整 暴露隱藏成本
瀑布最糟方向錯了最後60分也沒有 敏捷邊做邊調能80分
不知道原 po 只是想上來抱怨一下還是想改變現狀
瀑布方向錯了也能一顆隕石砸成80分阿
抱怨的話大家可以陪嘴一下,想改變就跳槽吧
上面說的對 其實敏捷並不保證快 敏捷是保證"逐步"趨近需求
不太可能吧XD 砸成80分可能是花200分工的後果
問題在於, 團隊中最應該瞭解需求,最能反應改變的,會是工
程師嗎?
如果不是,那團隊中誰該負責去明確需求?
不管瀑布還是敏捷, 需求還不明確就要求訂時程,都不合理吧?
Product Owner可是有明確定義的喔 這點沒錯
能決定事情的這個人必須進入團隊 老闆在外圍點菜就失格
因為這是瀑布群
敏捷可以快速反應變化 瀑布不行 想請問原PO假設
你們現在回到瀑布是可行的嗎? 週期多長呢?
那麼做到一半有需求改變了 工程師可以拒絕嗎?
這樣不能比應該要設定 兩個禮拜的瀑布vs兩個禮拜的敏捷
或是半年的瀑布vs半年一個sprint的敏捷 這樣才能比出差異
你的描述看起來不像敏捷
你和你的公司都不熟敏捷和瀑布,倒是都很懂隕石XD
敏捷不是在追進度,是你們公司認為的敏捷是那樣而已
推這篇&二樓
這篇重點到真的不是敏捷式開發
有效率的工作模式當然包含壓榨勞工的心力阿
你可以為了錢拚老命 也可以自己設定工作步調
反正我們只是打工仔 要自己決定平衡點阿
假敏捷
這不是敏捷,只是錯誤理解沒被糾正而已
我覺得有些荒謬的是 很多人反應的是,這不是敏捷 那我想反問,敏捷是什麼? 就我而言 追求快速跌代,就是敏捷開發 至於怎麼實現,每個地方都不一樣 就算瀑布開發 每個公司,每個部門,甚至每個專案 流程一定都不一樣 難道有一些固定形式必須滿足才能稱為XXX模式 這怎麼感覺變成哲學問題 我認知 垂直運作是瀑布 快速跌代是敏捷 而且單就工程師角度看 追求快速跌代這個精神,本身就比較折磨人
※ 編輯: kuosos520 (1.200.249.3 臺灣), 07/25/2024 18:40:39以前三天做完的喊一禮拜,改成三小時做完喊一天而已
唯一的差別就是每天站會很浪費時間,耽誤拉屎跟看盤
在台灣的敏捷 大概都會變成壓榨工具 壓迫開發時程
敏捷是給pm或po失敗的藉口之一
最好有工程師會喜歡敏捷XD
台灣只有隕石式開發
隕石:找我?
你認為的敏捷開發跟別人認為敏捷的開發,雙方起始點就
不一定相同。某個pm認為的敏捷開發是在一個sprint不斷
需
求,但工程師要能夠快速反應,這也能稱為快速跌07/25 19:21
代。上線後有問題,就在下一個sprint再來調整。
這樣的敏捷開發,是原po認定的敏捷開發嗎?
敏捷開發會因為不同環境而有所異動,但大部分公司說的
敏捷開發就只是單純的壓榨跟抱怨工程師速度不夠快,不
夠敏捷。但有定義好每個sprint的目標是什麼?
我覺得在相同的buffer比例之下 不會比較折磨人
回覆樓上,只要是開發中快速跌代我都認知是偏敏捷
的管理模式
敏捷開發有一個條件是 "擁抱改變"
也就是說敏捷開發的成員 心態上 就不要太把規格改變放心上
也就是說心態反倒是要訓練改變為 "你改我就下一周期開時程"
那使用waterfall開發,就無法快速跌代嗎?一定要用敏捷
才能快速跌代?
改越多越好 等於是PO自己不在意時程問題
敏捷開發比較適合那種老闆不知道怎麼準確描述需求的案子
所以只好一步步改
對於大型系統的模仿案就不應該用敏捷 因為參考對象已經有了
模仿案反而在意時程問題 因為要搶時間趕快上線
今天真的使用waterfall,難道就真的先等SA,SD把文件寫
好,pg才進來開發嗎?其實也沒有,難道今天需求有變動
pg能說文件先改好,我才能動程式,其實也沒有阿
確實有PG說你規格不完全接露我無法開發 通常是資料庫人員
@NDark,因為DBA通常就是你給我什麼我就做甚麼
敏捷的規格可以模糊(少)一點 只滿足現在想得到的規格
若不在意變化那就很有敏捷精神了.那就是他改歸他改.任我行.
無意爭辯 這樣偏瀑布
https://tinyurl.com/y93q5nr6這樣偏敏捷
https://tinyurl.com/ybbqoexd這只是我的認知,以大家自己認知為主
※ 編輯: kuosos520 (1.200.249.3 臺灣), 07/25/2024 19:37:12就我的經驗 規格差一點 資料庫關聯開起來會差很多
然後就會有人出來說專案品質很差,程式品質很差
原po若開發快速跌代就是敏捷開發,那你應該也只有取你
效能很差就繼續改.這也是PO要自己承受.
覺得有意義的地方,而忽略整各精神
敏捷我怎麼聽都覺得是現在遊戲的EA模式
硬要套在開發上只能說推的人根本沒開發過
最好瀑布式開發spec開完團隊下次見面就是成品交付了
不是 大家不用這麼激動 把變動造成的影響通通丟給RD負責
除了時程週期長短之外 兩者差在哪裡? 我認為是完整規格揭露
是錯的 這應該所有人認知都一致吧
敏捷允許一次只接露一點(瞎子摸象)
原po貼的連結是理論,但跟現實實作相距甚遠
瀑布式因為時程長揭露的比較多這個週期開始就往產品奔跑了
所以我認為差異最大是在PO能否把目標描述清楚
差異只是在不用等所有需求都釐清才開始做而已
如果一開始就能描述100%(抄襲作) 那時程長短就不是問題
如果PO很難把事情講清楚或這項產品沒有參考作品那適合敏捷
允許蝦子摸象只是模糊po的責任罷了
我還遇過要我一起參加產品發想的XD
長週期能投注在設計上的時間多 所以能揭露/思考多一點再幹
樓樓上 有一條是 "每個成員都是專家" ,老闆不專業只好花錢
所以我就說敏捷是分散po責任的開發方式啊
所以這樣的模式對開發來說沒啥幫助
敏捷的奧義是不管規格怎樣改 開發周期都已經訂好了嗎?
真的有人敢跟上面說 因為你改了規格所以之前承諾的時間
不算嗎?
新規格就下一個週期再作啊 這跟瀑布與敏捷無關
瀑布也不可能作出沒講好的規格
@MOONY135,這時候就會把這各異動放到下一個sprint
只是短周期比較好轉向改規格彈性比較大(心態)
之前遇過某PM 弄出來的東西不能開發
開發周一邊順需求一邊先改寫 然後讓他去改文件的
最後pm還是說就算改了做法也是這個開發周要完成
回到原 po 的論點好了,假設敏捷就是這個樣子
新的規格順好都周三下班了 剩兩天開發
敏捷的問題就是道理都很多
但開發真的實作起來就跟小瀑布沒啥兩樣
那原 po 可能性格上就是不喜歡這樣,也沒什麼不對
那問題是,然後呢?原 po 想改變什麼嗎
如果想改變,原 po 也說了不想管工程以外的東西
那必然無法在組織內部造成影響,所以就只有換環境了
原PO的圖沒錯, 但每個sprint都要重訂時程
你有沒有想過是你的問題 時間就這麼多 速度就這樣 做
不來就是做不來 有沒有嘗試說不行
這根本不是敢不敢的問題吧 一個sprint就1-4週 改到生不
出來當然是要資源 要人要時間啊
敏捷不是剩兩天但我大改需求你照樣要生給我吧
沒有 Scrum Master 就不要說自己敏捷了好嗎
有 Scrum Master 還把需求跟會議搞成這樣就叫 SM 出來面對
我剛剛想了一下,樓上的說法有點類似如果沒有用nod
e.js就不要說你會Javascript這樣
如果需求變動不改時程 此例一開不管是否敏捷以後都很難過吧
因為好交差啊
啊?你一次要做很多事怎麼敏捷?單位都是用周算的吧
你這就真的不是敏捷,所謂快速迭代指的是需求拆小快速實
現並上線,不是把時間塞滿就叫敏捷好嗎。不同需求之間也
會有幾天修整期,另外,開發時間給工程端喊,啊你自己要
喊這麼緊有意外就自己吞很正常,如果是需求變動那就是時
間重拉這你們團隊要有共識
要不改時程,可以啊
壓“最後需求變動時間”
過了,就進入閉關狀態了
其他,等出來再說
唯一推薦「敏捷總舵主-Hermes」
這是假敏捷 我們團隊也是這樣 超痛苦
之前遇到的都是時程不能變 需求 規格一直變..
敏捷(x) 流星雨(o)
說原 po 這不是敏捷 阿敏捷就 10 間公司有 11 種方案
實際上敏捷只有殼沒有料 根本給喇叭嘴唬爛進度推卸
責任用的 我現在都只要改規格就把時間往後估 陪這
些喇叭嘴慢慢耗
台灣公司做的才不是敏捷,是需求亂改時間不能再多
啊你們現在流程就離敏捷太遠了啊 跟你自己的定義沒什麼關係
快速迭代是目的 你們達到目的的手段就是隕石小瀑布
手段差這麼多 哪裡算敏捷???
有一種敏捷 = 老闆叫你做甚麼你就做甚麼
這種敏捷不叫做敏捷
能達成快速迭代且工程師沒靠北才叫敏捷
"老闆叫你做甚麼你就做甚麼" 這就是工作(雇傭)
只是追求快速迭代不論方法,那就是流星雨也可以啊
"用我的方法滿足雇主需求" 這叫委託(承攬)
你說的瀑布其實也不對,瀑布就是每階段要切得乾淨,需求一
直改並不正常,只能整個做完,或開發全推翻回去設計重來
基本上你就是從時程長的隕石,轉到時程短的流星雨而已
瀑布裡面不是水 是隕石群~~
就一堆無能高層覺得新東西很潮
實際上都是隕石開發
你是對的 台灣搞敏捷的一堆都效率更差 笑死
真的 打著敏捷旗幟 PM把他要做的工作帶到每次會一請大
家「討論」 PM根本就會議提醒機器人
隕石不要裝敏捷
瀑布裡不是水而是隕石群XDDD
潮阿,可以拿來嘴砲,業界常態拉
假敏捷
敏捷開發就是別人要敏捷一點的意思
AGI點高,寫程式會比較快嗎
幹真的 每天都被進度追==
敏捷的本質不是這樣 但是敏捷的"做法" 到是學的8成像 只能
說最終就是求最高壓榨是真 但這也是軍備競賽產生的..只能說
合作的本質是競爭+合作 而當重點放在前者時 就會壓力爆增..
同意三樓,多得是用敏捷在跑瀑布開發。還看過PO在sprint
快結束還插單整個story硬說是bug的
傳產 比較不會管這些歐
你的敏捷怎麼怪怪的
5
敏捷只是工具 聽到花篇幅宣揚特色是敏捷的公司建議逃 就好比英文是工具 連高中生都知道這沒啥好吹的 敏捷認真要研究雖然要翻理論3
這就是莫明其妙的點,兩位沒啥實績的人,出了一本書,胡鄒一個方法。 然後一群人拿來當聖經在拜。 這就是外國的和尚會唸經的概念,要是像人月神話的作者這種有實績就算了。 偏偏沒有還當神,就是一堆不沒開發過軟體的人,拿來唬人用,然後病毒式傳開。 說實在的,還真的跟紅衛兵沒兩樣。25
痛苦就不是敏捷 : 例如說 : 以前談好一整個版本的spec : 要談時程就是基於一整個版本再談 : 中間有什麼改動很正常X
以我自己覺得敏捷的特色 在於如何有效的生產及完成一個又一個的 sprint,SA,PM最好有技術經驗,團隊間成員 水準能力要差不多,會議就是拉有關係的開發進來就好。 我覺得跟客戶團隊的溝通有沒有及時的管道1
→ Lordaeron: AGILE的專家們,請問AGILE 在最開始前,要先寫一些底 07/27 19:10 → Lordaeron: 層的東西嗎? 要架環境嗎? 要的話,要算進sprint? 07/27 19:11 → Lordaeron: 會人人都有工作? 還是只有某幾位負責? 07/27 19:12 → Lordaeron: 再來,何時on production? 按國外大神的說法,沒提到呢 07/27 19:13 → Lordaeron: 若成員的程度差異,導致他的工作無法如期完成,會不會 07/27 19:134
敏捷是做出客戶真正想用的東西 在需求變動與不確定 (連客戶自己都不確定,想用什麼軟體) 以快速小迭代,每個 Sprint 交付最小增量給客戶 客戶親自使用並回饋之後,再次修正 Sprint Goal 開發團隊再次衝刺 Sprint Goal 微調之後
爆
[請益] 專案經理們都用什麼工具來管理專案?小弟奉命成立一個資訊團隊,工程師都己招募完成了。 專案經理的部分因為專業的關系用了一些對流程 很熟,但對專案管理很不熟的人 結果就是明明工程師都很認真,也能在時程內完成工作 但上線時程總是因為一些溝通不良的原因延期.......46
Re: [新聞] PChome高層又跳船!技術長陳俊仰宣布走人PC家真的越來越扯了 低薪就算了 現在連請正職的錢都沒了嗎? 誠徵敏捷團隊 前端技術好手 專案約聘5個月35
[請益] 主管跟工程師工作性質我朋友在一個工程師部門當主管 底下的人約8個 他主管的工作主要是 管理專案進度 跟團隊合作 因為最近案子很多34
[討論] 就算提早做完是不是不要回報比較好目前在接案公司擔任前端工程師 以前的我總是覺得分給我的任務能盡早完成越好 因為專案時程都開得很趕,東西又多 不做快一點絕對趕不上 當然也絕對不是亂寫然後交個勉強能動的22
[討論] RD還需要身兼專案管理嗎小弟在一家烘焙坊擔任RD 公司主力產品是 摩斯漢堡 與 七龍珠人的蛋糕 最近因為專案開了近百個 而且我司編制上Project manager 只有 一隻手數得出來的數量 為了不讓這些Project manager 倒掉23
[分享] Scrum 的適合場景:「外包團隊」今天早上看到社群的分享文章 轉貼過來 --12
Re: [面試] 帆擎/和盛/叡揚/達暉/凱發還好655那個你沒被騙進去,糟糕的部門!! 完全就是上面壓榨中下層的代表, 也沒什麼技術能力,只會想找便宜耐操的人力, 實習生多多,菜鳥多多,這兩個是開發主力!!厲害了吧! 這職位除了寫文件到死(規格書、測試報告書等等等),10
Re: [請益] PM懂程式有優勢嗎懂程式給一點建議其實還不錯,有時候客戶的需求不合理在第一時間就被丟回去了 但是這其實是兩面刃,最近就有配合到那種懂程式但是似懂非懂裝逼的PM 專案開始前 "我會幫忙擋需求,不是什麼東西來了就要做,先看提出的需求合不合理" 開會時2
[揪團] 徵求2-3名朋友一起報名長宏敏捷課程徵求新竹朋友一同報名長宏敏捷課程! 開課日期:109年4月18日開課 上課日期:4月18日~5月16日,每周六9:00-17:00,共五周 上課地點:清華大學創新育成大樓2樓 (寶山路清大南大門旁) 需求人數:2~3位3
Re: [討論] 用AI寫code產生的疑問幾個未來可能的 cases: 當工程師工作開始都提早完成了,會有以下幾種發展 1-0: 裝忙不要被老闆發現 or 更早下班 1-1: 老闆接更多工作 1-2: 砍人,更少工程師做更多工作