作者:
LeoPan (晴天)
2023-06-11 09:52:03最近在工作上遇到主管採用敏捷開發的管理模式，剛好在論壇上在報導高雄某間醫院的資
訊室在程式專案開發所採用的管理模式。
報導標題提到”擁抱敏捷開發全臺第一家的醫院IT”，於是好奇看了報導內容。
看完之後，覺得是不是真的懂什麼是Scrum、迭代循環(黑人問號狂冒出)。
內容當中提到兩點：
1. 系統開發過程，不再跟使用者爭辯，為什麼這次提出的需求，又跟上次不一樣，「溝
通衝突無益於系統本身，」她強調：「不一樣沒關係，我們改就對了！確定完成的功能是
使用者要的，更重要。
2. 盡可能地不要撰寫詳細的開發需求書，使用者只需提出申請，簡單說明想要完成的事
。但是，資訊室不會要求使用者一開始就能提出明確的需求。
所以不用詳細規格書？ 不用跟使用者討論內容？ 只要使用者提出需求意見，說什麼就做
什麼！
Scrum是這麼操作運作？！
報導來源：https://www.ithome.com.tw/people/119258?
全盤接受使用者需求也不是不行ㄅ，反正改需求就把時程拉長就對ㄌ
要討論內容阿 討論完就開發 開發完就測試上線然後看使用者使用上有啥問題再逐一修改喔 原來是想酸人 那個是醫院醫院it本來就沒地位 使用者是醫護也沒空跟你談需求
這套你拿去套在金融業也完全沒問題，就算需求認真訪談認真寫，最後驗收也是另一回事，最後就乾脆走這套，大家開始通靈隕石開發你還知道隕石長怎樣，這種通靈開發要直到驗收階段，user跟工程師才會知道需求是什麼
1. 因為爭辯不是SM的職責 SM是要確認情境和優先度爭辯是PO的任務2. 因為Agile就是假定使用者也搞不清處自己要什麼而是先做一個雛形再來改需求就我經驗而言 Scrum利於週期短的開發工程 例如客戶已經想到預期的產品效果 只是需要快速落地驗證但也相對的容易製造垃圾：用完發現沒用就丟
作者:
yamakazi (大安吳彥祖)
2023-06-11 10:24:00Product owner的工作啊，有時候使用者或客戶自己也不知道自己要什麼
我覺得全文重點反而是MVC跟call center，減少重工跟干擾提升效率，才有辦法真的跑敏捷，關鍵還是整合資源
作者:
yamakazi (大安吳彥祖)
2023-06-11 10:25:00牛頓迭代法有沒有聽過，就是先初始值，然後每一次迭代計算後更接近實際值
一些需要技術堆疊或是研發類的 還是需要一條清楚的路線 以保留中間開發的產物 所以有時候公司會有並行
作者:
yamakazi (大安吳彥祖)
2023-06-11 10:27:00實際值根本一開始不曉得通常是有UI的裁會敏捷開發，沒UI沒使用者的哪需要跟使用者溝通，組內自己橋一下就可以做了
工研院要不要也Scrum一下，哪天飛彈應user的需求可以掛載排骨便當都不意外
作者:
NDark (溺於黑暗)
2023-06-11 11:05:00問就是 你們沒有跑真的敏捷 都不是敏捷的錯
作者:
pttano (pttano)
2023-06-11 11:17:00嗯你說的都對
作者:
DrTech (竹科管理處網軍研發人員)
2023-06-11 11:26:00原文："不會要求使用者一開始就能提出明確的需求。" 你解讀成：不用跟使用者討論需求，使用者說什麼就做什麼。你自己過度解讀也很奇怪吧。該文看起來就是一堆沒經驗的人，嘗試做scrum。但原文帶風向加油添醋解讀，也很沒必要。
作者: k798976869 (kk) 2023-06-11 11:28:00
就是一種管理方法但是最後還是以老闆的需求為主
作者:
DrTech (竹科管理處網軍研發人員)
2023-06-11 11:30:00原文到底哪裡說了："不用跟使用者討論需求，使用者說什麼就做什麼"亂解讀帶風險耶
作者: moom50302 (武林三羚鱷) 2023-06-11 11:32:00
錯了吧…增進溝通、快速調整才是敏捷開發的重點
作者:
DrTech (竹科管理處網軍研發人員)
2023-06-11 11:36:00scrum本來就不需要像UML，PMP，CMMI哪種詳細規格書，這篇文章說的沒錯。然後這篇文章也沒說使用者來的需求全部不溝通都做。HR系統哪段也有說會跟使用者溝通後才做。 是你自己誤解文章內容，還來帶風向耶。
作者:
jack0204 (Jarbar王朝)
2023-06-11 11:36:00確認目標，從目標來討論需求是否有效PM/老闆大多知道做這個需求的目的，但不知道怎麼達成
作者: safe (safe) 2023-06-11 11:39:00
所以你跑的敏捷開發都有詳細規格書喔？：）
作者:
jack0204 (Jarbar王朝)
2023-06-11 11:39:00不過也是有老闆只是想花錢找人做事，有沒有用沒差
敏捷開發本來就先求有再求好吧免去無意義的討論，直接弄個demo最快只要方向正確，細部後續再調整就好
作者:
BaconBao (BaconBao)
2023-06-11 11:50:00哈哈要注意不要/不再一詞主要強調的對象。第一點不要的對象偏向”爭辯與衝突”；第二點不要的對象偏向”詳細的”需求書，此外由申請與說明兩詞可知需求仍以較簡單的文件或交流方式傳遞。
作者:
TAKADO (朕沒給的你不能搶)
2023-06-11 12:11:00需求加了時程就延啊，幹嘛吵架，反正我PG一樣每天寫code，時間到了不能上線怪我囉？大概是這樣
比較靠背的是真的怪開發者沒有sense，沒有講也應該要想到（？？？）
敏捷就是不斷地循環修正至於循環的大小範圍頻率 自己拿捏然後 其實一般不太會有"純"敏捷 多少會混合其他模式
作者: za755188 2023-06-11 12:50:00
因為實務上不可能在一開始就搞清楚全部的需求所以敏捷提倡先做出可以demo的東西再來改善
重點其實是人跟公司文化，大家好溝通，公司也接受這種半成品當然沒問題，但如果不是的話就...現實多的是開始不講清楚，後面再那邊吵架，不小心影響現有系統更慘，工程師87%績效--
作者:
loadingN (sarsaparilla)
2023-06-11 13:15:00你中文裡解有問題 你知道什麼是迭代嘛?
作者: ctrlbreak 2023-06-11 13:43:00
薪水給夠 我就不委屈了
Spec不用寫得太清楚 意思是實作者看得懂保留Flexibility 去快速迭代修改避免你自以為是的寫了一堆到後面做的時候要打掉但並不是說不用寫SpecAgile 這邊的精神跟 Lean methodology類似去快速的驗證 而不是想一步到位Fail fast, learn faster.
你的用詞怪怪的 應該只是不強求一開始就設計完善 而不是反過來強求模糊需求
作者:
labbat (labbat)
2023-06-11 14:17:00設計不完善就不完善，搞什麼這不是BUG這是feature錯就是錯，沒有那種萬能許願機能讀心知道開發者到底想要的
作者: t64141 (榕樹) 2023-06-11 15:45:00
我的理解是這兩點的前提建立在先做最小功能版本再一次一次的改版更新因為每個版本改動都小所以快，然後使用者會根據每個版本的結果一直更新需求這樣
作者:
brucetu (sec)
2023-06-11 16:14:00原Po有沒有看過搞了半年然後給高層一看結果幾乎要打掉重做的瀑布開發？
敏捷的核心就是各自解讀 懂？你管人家的敏捷長怎樣是不懂敏捷嗎？
作者:
ssccg (23)
2023-06-11 17:29:00先改先試用，改不好馬上再改也是種敏捷一樣是要通靈，敏捷至少被翻掉的損失的工時少看起來他們的確不懂敏捷，換MVC才是真的，但是你不懂醫院IT醫院就點就在醫生最大，醫生也沒有空跟你討論，你就是得通靈，誰管你用什麼開發流程
作者:
testPtt (測試)
2023-06-11 19:17:00我常遇到資料庫1對1用一段時間要改成1對多的
作者: joney641119 (johnny) 2023-06-11 19:36:00
上面說的對,要通靈或是上面隨時隨意變更工作內容的就不要想用敏捷開發了,自找麻煩多的是不讓你做完一個sprint就要你改的
作者:
prag222 (prag)
2023-06-11 20:54:00scrum本身就是一種方法論跟專案技術,一堆人看了幾本中文書就以為自己懂了卻不知道寫書的人自己都不懂會寫書跟會看書不代表有實務經驗
作者:
neo5277 (I am an agent of chaos)
2023-06-11 22:21:00大家能力跟認知都差不多才敏的起來
作者:
neo5277 (I am an agent of chaos)
2023-06-11 22:40:00敏捷就是一個做事情的風格，使用什麼技術來達成才是重點
作者:
alihue (wanda wanda)
2023-06-11 23:17:00我的工作經驗是，敏捷與類似的框架是給一群能力不強的人用的，而且套上之後大部分時間還會花在討論改善流程與開會，產出的軟體一點都沒變好。在一個同事都足夠強的成熟環境，根本從來不會把時間花在開發流程的討論
作者:
brucetu (sec)
2023-06-11 23:35:00一個sprint還沒做完就要插隊改的叫做隕石開發是一個對老闆來說比敏捷開發更敏捷的方法 馬上改!
作者:
stkoso (Asperger)
2023-06-11 23:50:00台式敏捷開發就是今天說的東西明天就要
作者:
umum29 (....)
2023-06-12 00:28:00敏捷不代表可以讓使用者任意改需求 PM和資深工程師要審核難道使用者隨口說我們要做大數據 下禮拜要上線 你也ＯＫ？但看到是醫院 那就當我沒說....
作者:
DrTech (竹科管理處網軍研發人員)
2023-06-12 00:43:00真正跑Scrum，遇到插隊很平常好嗎。頭腦不要那麼死，萬一臨時出現一個使線上系統掛掉的Bug，使公司購物系統不能用(公司損失持續發生)，你不先去插隊修，你還在扯先跑完這個Sprint，下個Sprint再排進tickets處理，這樣會比較好嗎。
作者:
DrTech (竹科管理處網軍研發人員)
2023-06-12 00:46:00原文醫院資訊室，根本沒說：使用者說什麼，就無腦做什麼。全是原PO加油添醋帶風像亂解讀吧。ithom的原文到底哪裡說了："只要使用者提出需求意見，說什麼就做什麼！"？？？ 亂帶風向耶。原PO你要不要出來解釋一下，我什麼要污衊原文，原文哪裡有寫到："不用跟使用者討論內容 只要使用者提出需求意見，說什麼就做什麼！"原文根本沒說好嗎。這種帶風向亂解讀的行為，簡直可恥。
作者: internetms52 (Oaide) 2023-06-12 08:01:00
第二點應該是對敏捷宣言的誤會，可用的軟體重於詳盡的文件，有提到，“雖然右側項目有其價值，但我們更側重左側項目”，這其實不代表完全不需要右側項目，只是如果不得已走左側至少好過一點
作者: ura1210 (jack) 2023-06-12 08:26:00
推 DrTech 雖然我知道很多跑敏感是個笑話 但不應該帶風向 抹煞想努力改變的人樓上有人說 跑敏捷適合能力不強的人？我倒是想問 能力不強的團隊能跑的起來嗎
其實scrum是概念而不是形式很多公司只學兩週sprint每天立會就覺得是敏捷
作者:
NDark (溺於黑暗)
2023-06-12 10:46:00搞錯了吧 瀑布式才適合能力不強的成員 菁英規劃 雜魚執行敏捷才需要都是不會偷懶的精英 因為估計時程錯誤就整個完蛋
作者: yamagishi (山岸刑務官) 2023-06-12 13:33:00
沒有story point跟5分鐘早會嗎？
作者:
ybon3 (讓我想想)
2023-06-12 16:52:00我數學很快.jpg
table schema 進負責開啊?接queue 的呢? 要共用嗎? 還是各自寫會比較Scrum ?
作者:
StrangeJ (兩光男孩....)
2023-06-12 19:21:00作者:
atpx (秋雨的心情)
2023-06-12 20:19:00沒必要爭成這樣, 也許她就是拿個不重要的小系統演給長官看
作者:
qss05 (minami)
2023-06-13 08:08:00IT不就這樣的工作…就算討論半天，最後還是跟你說這不是我想要的,可是你前面說…：我現在就想要改
作者:
eplis (Eplis)
2023-06-13 10:01:00你要了解什麼是行銷，本質是不是根本不重要
對開發人員最有善的還是走瀑布式吧友善講好的規格照著開發 使用者才不會一天到晚講鬼故事改規格
Scrum還要搭配一堆配套 不是有在跑sprint就是敏捷式開發欸 很多台灣公司對外報告都講的很厲害 結果問個關鍵點都沒做到
作者:
BoXeX (心愛騎士團異端審判騎士)
2023-06-13 23:02:00敏捷開發對高層來說 就是可以天天盯你進度還有整天改你規格用的而且就算你真照著敏捷開發走 最後還是發現大多狀況不適用大概就前端能用吧其他只要你系統複雜起來 你code寫再好沒詳細規劃就不行
敏捷有規劃啊 TDD 就是規劃了 只是不想太繁重文件
作者:
BoXeX (心愛騎士團異端審判騎士)
2023-06-13 23:59:00我的規劃不是指這個 是指整個系統架構設計
作者:
Sunal (SSSSSSSSSSSSSSSSSSSSSSS)
2023-06-14 00:12:00系統架構還是會改的啊 也是會一直重構的這也是TDD過程中會遇到
作者:
atpx (秋雨的心情)
2023-06-14 00:44:00上面幾位講的是不同的東西吧....B兄說的是大型應用系統整個業務流程要有說明文件, 不然前後段各寫各的最後組不起來
敏捷是從PM角度推行的方法論 本來就不是要幫PG解決開發問題的 所以導敏捷跟好不好開發or開發的好不好一點關係都沒有 本質上只是讓PM比較容易有產出去跟stakeholders交代而已
作者:
strlen (strlen)
2023-06-19 22:22:00亂扯什麼PM角度 敏捷也包括程式設計好嗎 而且還是重中之重應該說 程式面沒到位 你敏捷只是狗屁
作者:
iceorz (喔喔~~~)
2023-06-24 10:11:00敏捷開發是工程師起草的實踐方式，少在那邊鬼扯不要把失敗的敏捷轉型都推到PM身上
作者:
zaiter (zaiter)
2023-06-24 10:54:00正解 老人最愛寫一堆智障文件sa sd 的 智障廢物老派做法
作者:
astt88 (水月幻夢)
2023-07-06 23:28:00我參加過的Scrum，早上站會是批鬥會議不是表達昨天做了什麼，遇到了什麼問題，也不只是說明今天要做什麼每日站會在批誰沒有把事做完，說誰已經把工作的好幾天的份都做好了，就是你工作太慢。這就是個人與互動重於流程與工具。再好的制度在臺灣就會變質
第一天在軟體業？敏捷開發的本質本來就是先搞出一個能動的產品，後面再改啊，可以先收錢才是他的目的