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

看板Soft_Job作者 (晴天)時間11月前 (2023/06/11 09:52), 編輯推噓27(35推 8噓 150→)
留言193則, 63人參與, 11月前最新討論串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, 11月前 , 1F
全盤接受使用者需求也不是不行ㄅ，反正改需求就把
06/11 09:54, 1F
→
06/11 09:54, 11月前 , 2F
時程拉長就對ㄌ
06/11 09:54, 2F
→
06/11 09:57, 11月前 , 3F
要討論內容阿 討論完就開發 開發完就測試上線
06/11 09:57, 3F
→
06/11 09:57, 11月前 , 4F
然後看使用者使用上有啥問題再逐一修改
06/11 09:57, 4F
→
06/11 10:01, 11月前 , 5F
喔 原來是想酸人 那個是醫院
06/11 10:01, 5F
→
06/11 10:01, 11月前 , 6F
醫院it本來就沒地位 使用者是醫護也沒空跟你談需求
06/11 10:01, 6F
→
06/11 10:02, 11月前 , 7F
不同產業都會產生出自己的一套方法 很正常
06/11 10:02, 7F
推
06/11 10:06, 11月前 , 8F
敏捷開發（X）隕石開發（O）
06/11 10:06, 8F
→
06/11 10:14, 11月前 , 9F
這套你拿去套在金融業也完全沒問題，就算需求認真訪談
06/11 10:14, 9F
→
06/11 10:14, 11月前 , 10F
認真寫，最後驗收也是另一回事，最後就乾脆走這套，大
06/11 10:14, 10F
→
06/11 10:14, 11月前 , 11F
家開始通靈
06/11 10:14, 11F
→
06/11 10:15, 11月前 , 12F
隕石開發你還知道隕石長怎樣，這種通靈開發要直到驗收
06/11 10:15, 12F
→
06/11 10:15, 11月前 , 13F
階段，user跟工程師才會知道需求是什麼
06/11 10:15, 13F
推
06/11 10:17, 11月前 , 14F
1. 因為爭辯不是SM的職責 SM是要確認情境和優先度
06/11 10:17, 14F
→
06/11 10:17, 11月前 , 15F
爭辯是PO的任務
06/11 10:17, 15F
→
06/11 10:18, 11月前 , 16F
2. 因為Agile就是假定使用者也搞不清處自己要什麼
06/11 10:18, 16F
→
06/11 10:18, 11月前 , 17F
而是先做一個雛形再來改需求
06/11 10:18, 17F
推
06/11 10:23, 11月前 , 18F
就我經驗而言 Scrum利於週期短的開發工程 例如客戶
06/11 10:23, 18F
→
06/11 10:23, 11月前 , 19F
已經想到預期的產品效果 只是需要快速落地驗證
06/11 10:23, 19F
→
06/11 10:24, 11月前 , 20F
但也相對的容易製造垃圾：用完發現沒用就丟
06/11 10:24, 20F
推
06/11 10:24, 11月前 , 21F
Product owner的工作啊，有時候使用者或客戶自己也不知
06/11 10:24, 21F
→
06/11 10:24, 11月前 , 22F
道自己要什麼
06/11 10:24, 22F
→
06/11 10:25, 11月前 , 23F
我覺得全文重點反而是MVC跟call center，減少重工跟干
06/11 10:25, 23F
→
06/11 10:25, 11月前 , 24F
擾提升效率，才有辦法真的跑敏捷，關鍵還是整合資源
06/11 10:25, 24F
→
06/11 10:25, 11月前 , 25F
牛頓迭代法有沒有聽過，就是先初始值，然後每一次迭代計
06/11 10:25, 25F
→
06/11 10:25, 11月前 , 26F
算後更接近實際值
06/11 10:25, 26F
→
06/11 10:26, 11月前 , 27F
一些需要技術堆疊或是研發類的 還是需要一條清楚的
06/11 10:26, 27F
→
06/11 10:26, 11月前 , 28F
路線 以保留中間開發的產物 所以有時候公司會有並行
06/11 10:26, 28F
→
06/11 10:27, 11月前 , 29F
實際值根本一開始不曉得
06/11 10:27, 29F
→
06/11 10:28, 11月前 , 30F
通常是有UI的裁會敏捷開發，沒UI沒使用者的哪需要跟使用
06/11 10:28, 30F
→
06/11 10:28, 11月前 , 31F
者溝通，組內自己橋一下就可以做了
06/11 10:28, 31F
推
06/11 10:55, 11月前 , 32F
工研院要不要也Scrum一下，哪天飛彈應user的需求可以掛
06/11 10:55, 32F
→
06/11 10:55, 11月前 , 33F
載排骨便當都不意外
06/11 10:55, 33F
推
06/11 11:05, 11月前 , 34F
問就是 你們沒有跑真的敏捷 都不是敏捷的錯
06/11 11:05, 34F
噓
06/11 11:17, 11月前 , 35F
嗯你說的都對
06/11 11:17, 35F
推
06/11 11:21, 11月前 , 36F
新創搞敏捷的不是倒了就是在倒的途中,懂的就懂！
06/11 11:21, 36F
→
06/11 11:26, 11月前 , 37F
原文："不會要求使用者一開始就能提出明確的需求。" 你解
06/11 11:26, 37F
→
06/11 11:26, 11月前 , 38F
讀成：不用跟使用者討論需求，使用者說什麼就做什麼。你自
06/11 11:26, 38F
→
06/11 11:26, 11月前 , 39F
己過度解讀也很奇怪吧。
06/11 11:26, 39F
還有 114 則推文
→
06/12 15:56, 11月前 , 154F
錢給夠 要怎麼改就怎麼改囉
06/12 15:56, 154F
→
06/12 16:24, 11月前 , 155F
真的有符合敏捷精神在跑的是少數 多得是喊喊口號
06/12 16:24, 155F
→
06/12 16:24, 11月前 , 156F
的
06/12 16:24, 156F
→
06/12 16:52, 11月前 , 157F
我數學很快.jpg
06/12 16:52, 157F
→
06/12 17:25, 11月前 , 158F
table schema 進負責開啊?
06/12 17:25, 158F
→
06/12 17:27, 11月前 , 159F
接queue 的呢? 要共用嗎? 還是各自寫會比較Scrum ?
06/12 17:27, 159F
推
06/12 19:21, 11月前 , 160F
可以參考敏捷軟體開發宣言
06/12 19:21, 160F
→
06/12 19:21, 11月前 , 161F
06/12 19:21, 161F
→
06/12 19:22, 11月前 , 162F
可用的軟體重於詳盡的文件 與客戶合作重於合約協商
06/12 19:22, 162F
推
06/12 20:19, 11月前 , 163F
沒必要爭成這樣, 也許她就是拿個不重要的小系統演給長官看
06/12 20:19, 163F
推
06/12 23:22, 11月前 , 164F
主管:我說了算，就是敏捷
06/12 23:22, 164F
→
06/13 08:08, 11月前 , 165F
IT不就這樣的工作…就算討論半天，最後還是跟你說這不是我
06/13 08:08, 165F
→
06/13 08:08, 11月前 , 166F
想要的,可是你前面說…：我現在就想要改
06/13 08:08, 166F
→
06/13 09:59, 11月前 , 167F
敏捷是用來燃燒蠟燭人用的啦 燃盡圖 燃燒你的生命
06/13 09:59, 167F
推
06/13 10:01, 11月前 , 168F
你要了解什麼是行銷，本質是不是根本不重要
06/13 10:01, 168F
→
06/13 10:07, 11月前 , 169F
對開發人員最有善的還是走瀑布式吧
06/13 10:07, 169F
→
06/13 10:07, 11月前 , 170F
友善
06/13 10:07, 170F
→
06/13 10:08, 11月前 , 171F
講好的規格照著開發 使用者才不會一天到晚講鬼故事改
06/13 10:08, 171F
→
06/13 10:08, 11月前 , 172F
規格
06/13 10:08, 172F
→
06/13 11:03, 11月前 , 173F
使用者和鬼一樣，確定這是敏捷開發?
06/13 11:03, 173F
推
06/13 12:25, 11月前 , 174F
Scrum還要搭配一堆配套 不是有在跑sprint就是敏捷式開
06/13 12:25, 174F
→
06/13 12:25, 11月前 , 175F
發欸 很多台灣公司對外報告都講的很厲害 結果問個關鍵
06/13 12:25, 175F
→
06/13 12:25, 11月前 , 176F
點都沒做到
06/13 12:25, 176F
→
06/13 23:02, 11月前 , 177F
敏捷開發對高層來說 就是可以天天盯你進度
06/13 23:02, 177F
→
06/13 23:03, 11月前 , 178F
還有整天改你規格用的
06/13 23:03, 178F
→
06/13 23:06, 11月前 , 179F
而且就算你真照著敏捷開發走 最後還是發現大多狀況不適用
06/13 23:06, 179F
→
06/13 23:06, 11月前 , 180F
大概就前端能用吧
06/13 23:06, 180F
→
06/13 23:07, 11月前 , 181F
其他只要你系統複雜起來 你code寫再好沒詳細規劃就不行
06/13 23:07, 181F
→
06/13 23:51, 11月前 , 182F
敏捷有規劃啊 TDD 就是規劃了 只是不想太繁重文件
06/13 23:51, 182F
→
06/13 23:59, 11月前 , 183F
我的規劃不是指這個 是指整個系統架構設計
06/13 23:59, 183F
推
06/14 00:12, 11月前 , 184F
系統架構還是會改的啊 也是會一直重構的
06/14 00:12, 184F
→
06/14 00:13, 11月前 , 185F
這也是TDD過程中會遇到
06/14 00:13, 185F
→
06/14 00:44, 11月前 , 186F
上面幾位講的是不同的東西吧....B兄說的是大型應用系統
06/14 00:44, 186F
→
06/14 00:45, 11月前 , 187F
整個業務流程要有說明文件, 不然前後段各寫各的最後組不起來
06/14 00:45, 187F
推
06/14 01:32, 11月前 , 188F
敏捷是從PM角度推行的方法論 本來就不是要幫PG解決
06/14 01:32, 188F
→
06/14 01:32, 11月前 , 189F
開發問題的 所以導敏捷跟好不好開發or開發的好不好
06/14 01:32, 189F
→
06/14 01:32, 11月前 , 190F
一點關係都沒有 本質上只是讓PM比較容易有產出去跟
06/14 01:32, 190F
→
06/14 01:32, 11月前 , 191F
stakeholders交代而已
06/14 01:32, 191F
→
06/14 11:32, 11月前 , 192F
樓上正解 就是PM拿來燃燒各位用的
06/14 11:32, 192F
→
06/14 18:37, 11月前 , 193F
團隊一半都確診了還在每日站立會議
06/14 18:37, 193F
‣ 更多 LeoPan 的文章
文章代碼(AID): #1aXIZ5N6 (Soft_Job)