PTT職涯區 / Soft_Job (軟體人)

[討論] Scrum敏捷開發是這麼操作嗎？

看板Soft_Job (軟體人)作者 (晴天)時間3年前 (2023/06/11 09:52), 編輯推噓29(39推 10噓 161→)
留言210則, 70人參與, 最新討論串1/1
最近在工作上遇到主管採用敏捷開發的管理模式，剛好在論壇上在報導高雄某間醫院的資 訊室在程式專案開發所採用的管理模式。 報導標題提到”擁抱敏捷開發全臺第一家的醫院IT”，於是好奇看了報導內容。 看完之後，覺得是不是真的懂什麼是Scrum、迭代循環(黑人問號狂冒出)。 內容當中提到兩點： 1. 系統開發過程，不再跟使用者爭辯，為什麼這次提出的需求，又跟上次不一樣，「溝 通衝突無益於系統本身，」她強調：「不一樣沒關係，我們改就對了！確定完成的功能是 使用者要的，更重要。 2. 盡可能地不要撰寫詳細的開發需求書，使用者只需提出申請，簡單說明想要完成的事 。但是，資訊室不會要求使用者一開始就能提出明確的需求。 所以不用詳細規格書？ 不用跟使用者討論內容？ 只要使用者提出需求意見，說什麼就做 什麼！ Scrum是這麼操作運作？！ 報導來源：https://www.ithome.com.tw/people/119258? -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 27.242.70.169 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1686448325.A.5C6.html
→
06/11 09:54, 3年前 , 1F
全盤接受使用者需求也不是不行ㄅ，反正改需求就把
06/11 09:54, 1F
→
06/11 09:54, 3年前 , 2F
時程拉長就對ㄌ
06/11 09:54, 2F
→
06/11 09:57, 3年前 , 3F
要討論內容阿 討論完就開發 開發完就測試上線
06/11 09:57, 3F
→
06/11 09:57, 3年前 , 4F
然後看使用者使用上有啥問題再逐一修改
06/11 09:57, 4F
→
06/11 10:01, 3年前 , 5F
喔 原來是想酸人 那個是醫院
06/11 10:01, 5F
→
06/11 10:01, 3年前 , 6F
醫院it本來就沒地位 使用者是醫護也沒空跟你談需求
06/11 10:01, 6F
→
06/11 10:02, 3年前 , 7F
不同產業都會產生出自己的一套方法 很正常
06/11 10:02, 7F
推
06/11 10:06, 3年前 , 8F
敏捷開發（X）隕石開發（O）
06/11 10:06, 8F
→
06/11 10:14, 3年前 , 9F
這套你拿去套在金融業也完全沒問題，就算需求認真訪談
06/11 10:14, 9F
→
06/11 10:14, 3年前 , 10F
認真寫，最後驗收也是另一回事，最後就乾脆走這套，大
06/11 10:14, 10F
→
06/11 10:14, 3年前 , 11F
家開始通靈
06/11 10:14, 11F
→
06/11 10:15, 3年前 , 12F
隕石開發你還知道隕石長怎樣，這種通靈開發要直到驗收
06/11 10:15, 12F
→
06/11 10:15, 3年前 , 13F
階段，user跟工程師才會知道需求是什麼
06/11 10:15, 13F
推
06/11 10:17, 3年前 , 14F
1. 因為爭辯不是SM的職責 SM是要確認情境和優先度
06/11 10:17, 14F
→
06/11 10:17, 3年前 , 15F
爭辯是PO的任務
06/11 10:17, 15F
→
06/11 10:18, 3年前 , 16F
2. 因為Agile就是假定使用者也搞不清處自己要什麼
06/11 10:18, 16F
→
06/11 10:18, 3年前 , 17F
而是先做一個雛形再來改需求
06/11 10:18, 17F
推
06/11 10:23, 3年前 , 18F
就我經驗而言 Scrum利於週期短的開發工程 例如客戶
06/11 10:23, 18F
→
06/11 10:23, 3年前 , 19F
已經想到預期的產品效果 只是需要快速落地驗證
06/11 10:23, 19F
→
06/11 10:24, 3年前 , 20F
但也相對的容易製造垃圾：用完發現沒用就丟
06/11 10:24, 20F
推
06/11 10:24, 3年前 , 21F
Product owner的工作啊，有時候使用者或客戶自己也不知
06/11 10:24, 21F
→
06/11 10:24, 3年前 , 22F
道自己要什麼
06/11 10:24, 22F
→
06/11 10:25, 3年前 , 23F
我覺得全文重點反而是MVC跟call center，減少重工跟干
06/11 10:25, 23F
→
06/11 10:25, 3年前 , 24F
擾提升效率，才有辦法真的跑敏捷，關鍵還是整合資源
06/11 10:25, 24F
→
06/11 10:25, 3年前 , 25F
牛頓迭代法有沒有聽過，就是先初始值，然後每一次迭代計
06/11 10:25, 25F
→
06/11 10:25, 3年前 , 26F
算後更接近實際值
06/11 10:25, 26F
→
06/11 10:26, 3年前 , 27F
一些需要技術堆疊或是研發類的 還是需要一條清楚的
06/11 10:26, 27F
→
06/11 10:26, 3年前 , 28F
路線 以保留中間開發的產物 所以有時候公司會有並行
06/11 10:26, 28F
→
06/11 10:27, 3年前 , 29F
實際值根本一開始不曉得
06/11 10:27, 29F
→
06/11 10:28, 3年前 , 30F
通常是有UI的裁會敏捷開發，沒UI沒使用者的哪需要跟使用
06/11 10:28, 30F
→
06/11 10:28, 3年前 , 31F
者溝通，組內自己橋一下就可以做了
06/11 10:28, 31F
推
06/11 10:55, 3年前 , 32F
工研院要不要也Scrum一下，哪天飛彈應user的需求可以掛
06/11 10:55, 32F
→
06/11 10:55, 3年前 , 33F
載排骨便當都不意外
06/11 10:55, 33F
推
06/11 11:05, 3年前 , 34F
問就是 你們沒有跑真的敏捷 都不是敏捷的錯
06/11 11:05, 34F
噓
06/11 11:17, 3年前 , 35F
嗯你說的都對
06/11 11:17, 35F
推
06/11 11:21, 3年前 , 36F
新創搞敏捷的不是倒了就是在倒的途中,懂的就懂！
06/11 11:21, 36F
→
06/11 11:26, 3年前 , 37F
原文："不會要求使用者一開始就能提出明確的需求。" 你解
06/11 11:26, 37F
→
06/11 11:26, 3年前 , 38F
讀成：不用跟使用者討論需求，使用者說什麼就做什麼。你自
06/11 11:26, 38F
→
06/11 11:26, 3年前 , 39F
己過度解讀也很奇怪吧。
06/11 11:26, 39F
還有 131 則推文
→
06/13 10:08, 3年前 , 171F
講好的規格照著開發 使用者才不會一天到晚講鬼故事改
06/13 10:08, 171F
→
06/13 10:08, 3年前 , 172F
規格
06/13 10:08, 172F
→
06/13 11:03, 3年前 , 173F
使用者和鬼一樣，確定這是敏捷開發?
06/13 11:03, 173F
推
06/13 12:25, 3年前 , 174F
Scrum還要搭配一堆配套 不是有在跑sprint就是敏捷式開
06/13 12:25, 174F
→
06/13 12:25, 3年前 , 175F
發欸 很多台灣公司對外報告都講的很厲害 結果問個關鍵
06/13 12:25, 175F
→
06/13 12:25, 3年前 , 176F
點都沒做到
06/13 12:25, 176F
→
06/13 23:02, 3年前 , 177F
敏捷開發對高層來說 就是可以天天盯你進度
06/13 23:02, 177F
→
06/13 23:03, 3年前 , 178F
還有整天改你規格用的
06/13 23:03, 178F
→
06/13 23:06, 3年前 , 179F
而且就算你真照著敏捷開發走 最後還是發現大多狀況不適用
06/13 23:06, 179F
→
06/13 23:06, 3年前 , 180F
大概就前端能用吧
06/13 23:06, 180F
→
06/13 23:07, 3年前 , 181F
其他只要你系統複雜起來 你code寫再好沒詳細規劃就不行
06/13 23:07, 181F
→
06/13 23:51, 3年前 , 182F
敏捷有規劃啊 TDD 就是規劃了 只是不想太繁重文件
06/13 23:51, 182F
→
06/13 23:59, 3年前 , 183F
我的規劃不是指這個 是指整個系統架構設計
06/13 23:59, 183F
推
06/14 00:12, 3年前 , 184F
系統架構還是會改的啊 也是會一直重構的
06/14 00:12, 184F
→
06/14 00:13, 3年前 , 185F
這也是TDD過程中會遇到
06/14 00:13, 185F
→
06/14 00:44, 3年前 , 186F
上面幾位講的是不同的東西吧....B兄說的是大型應用系統
06/14 00:44, 186F
→
06/14 00:45, 3年前 , 187F
整個業務流程要有說明文件, 不然前後段各寫各的最後組不起來
06/14 00:45, 187F
推
06/14 01:32, 3年前 , 188F
敏捷是從PM角度推行的方法論 本來就不是要幫PG解決
06/14 01:32, 188F
→
06/14 01:32, 3年前 , 189F
開發問題的 所以導敏捷跟好不好開發or開發的好不好
06/14 01:32, 189F
→
06/14 01:32, 3年前 , 190F
一點關係都沒有 本質上只是讓PM比較容易有產出去跟
06/14 01:32, 190F
→
06/14 01:32, 3年前 , 191F
stakeholders交代而已
06/14 01:32, 191F
→
06/14 11:32, 3年前 , 192F
樓上正解 就是PM拿來燃燒各位用的
06/14 11:32, 192F
→
06/14 18:37, 3年前 , 193F
團隊一半都確診了還在每日站立會議
06/14 18:37, 193F
→
06/17 22:42, , 194F
敏捷參考用而已
06/17 22:42, 194F
噓
06/19 22:22, , 195F
亂扯什麼PM角度 敏捷也包括程式設計好嗎 而且還是重中之重
06/19 22:22, 195F
→
06/19 22:23, , 196F
應該說 程式面沒到位 你敏捷只是狗屁
06/19 22:23, 196F
噓
06/24 10:11, , 197F
敏捷開發是工程師起草的實踐方式，少在那邊鬼扯
06/24 10:11, 197F
→
06/24 10:12, , 198F
不要把失敗的敏捷轉型都推到PM身上
06/24 10:12, 198F
推
06/24 10:54, , 199F
正解 老人最愛寫一堆智障文件sa sd 的 智障廢物老派做法
06/24 10:54, 199F
推
07/06 23:28, , 200F
我參加過的Scrum，早上站會是批鬥會議
07/06 23:28, 200F
→
07/06 23:30, , 201F
不是表達昨天做了什麼，遇到了什麼問題，也不只是說明今
07/06 23:30, 201F
→
07/06 23:30, , 202F
天要做什麼
07/06 23:30, 202F
→
07/06 23:41, , 203F
每日站會在批誰沒有把事做完，說誰已經把工作的好幾天的
07/06 23:41, 203F
→
07/06 23:41, , 204F
份都做好了，就是你工作太慢。這就是個人與互動重於流程
07/06 23:41, 204F
→
07/06 23:41, , 205F
與工具。再好的制度在臺灣就會變質
07/06 23:41, 205F
推
07/08 09:17, , 206F
87%自稱agile但實際上根本隕石
07/08 09:17, 206F
推
07/15 16:04, , 207F
第一天在軟體業？
07/15 16:04, 207F
→
07/15 16:04, , 208F
敏捷開發的本質本來就是先搞出一個能動的產品，後
07/15 16:04, 208F
→
07/15 16:04, , 209F
面再改啊，可以
07/15 16:04, 209F
→
07/15 16:04, , 210F
先收錢才是他的目的
07/15 16:04, 210F
‣ 更多 LeoPan 的文章
文章代碼(AID): #1aXIZ5N6 (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 LeoPan 的文章
文章代碼(AID): #1aXIZ5N6 (Soft_Job)