PTT職涯區 / Soft_Job (軟體人)

Re: [討論] 故 CTO 對於 Scrum 的看法

看板Soft_Job (軟體人)作者 (.....)時間1月前 (2025/03/12 15:14), 1月前編輯推噓27(30推 3噓 135→)
留言168則, 34人參與, 3周前最新討論串3/3 (看更多)
※ 引述《JasperChang (PeterChou)》之銘言： : Scrum 造不出車、造不出火箭、做不出 IC，可能甚至連台電視都做不出來。 : 但我也同意在某些情境下 Scrum 是很好的工具， : 特斯拉車上有三套電腦， : 車控和自駕電腦完全符合 ISO16949 和 ISO26262 的嚴格規範， : 每一行程式碼都經過嚴格的靜態分析和解析、測試才能 deploy； : 負責 UI 的 MCU 電腦 : 就真的是沒事一直更新一直打 patch 一直有新 feature 一直有 bug 一直給人驚喜。 : 但我認為我們的攝影機凡是牽涉到串流的軟體， : 都是核心功能，不應該走得太激進。 : 但你在處理 PIP 和 SS 功能時並不這麼認為。 : ------ : 小弟剛接觸軟工只聽說 Scrum 強無敵只是你不會用用不好 : 上面資深技術長的看法是不是有修正餘地? 先聊一下為什麼會有敏捷式開發 軟體市場環境變動快,規格容易說改就改 今天開發功能A,用waterfull方式開發 開發完後發現功能A沒多少人用,市場主要競品重點放在功能B 要改做B也來不及了,產品直接GG 敏捷式開發的方式大概是做功能A,但不會做到100%, 可能做個20%有概念性產品時就先丟出來給合作廠商試用 做個40%有個雛形後丟試用版出來蒐集使用者回饋 如果這時候發現功能A回饋不如預期,提早修正或是放棄功能A 對新創(尤其是軟體)來講,最重要的是活下來 新創缺少資源,會需要盡快做出東西方便老闆募資等等等 但敏捷式+新創這個組合常常發生問題 例如很多人說敏捷式開發容易缺少文件 因為敏捷式開發是盡快生出能動的東西,功能又常常說變就變 對工程人員來講,我寫了功能A的開發文件,結果一個月後功能A被放棄 那我寫文件寫心酸的嗎? 同時因為功能常常說改就改,時程又壓得很緊 工程師大量靠work around做出能動的東西 久了以後軟體到處都是地雷,怎麼改都是修不完的bug 這時候很容易進入一個狀況... 公司缺少資金,出不起高薪或是擴編增加員工數量 軟體bug多時程緊,導致常常需要加班,工作環境變差 工程師受不了離職,因為缺少文件,導致新進工程師找不到參考資料 下git blame結果看到一堆已離職員工的名字,想問都找不到人問 新進工程師陣亡率高,公司產品每次更新都一堆bug,進入死亡惡性循環 以上應該是很多人都遇過的真實情況. 雲云CTO個人感覺是這樣.... CTO寫了一個計畫,掰了一個計畫名字(因為老闆喜歡看起來很潮的名字?) 內容推測是分析哪些程式模組容易產生bug,分析後進行重構 針對常用功能寫文件,消化TODO list等等 結果這個計畫被老闆否決,外加拔權限潑髒水等,導致CTO受了一肚子委屈... 至於到底是scrum還是waterfall,說實話不重要 混用的開發模式也不是沒有,這兩個東西並不是二分法的關係 scrum也不是什麼萬靈丹,台灣一堆老闆都把隕石開發包裝成敏捷式開發 然後一天到晚丟隕石下來...||| 敏捷點滿也躲不過連續隕石攻擊阿 XD -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.241.177.240 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1741763659.A.775.html
→
03/12 15:19, 1月前 , 1F
更根本的問題是,不論號稱是scrum還是waterfall,最基本的
03/12 15:19, 1F
→
03/12 15:19, 1月前 , 2F
分析, 設計，開發，測試，維護有沒有缺漏?
03/12 15:19, 2F
→
03/12 15:20, 1月前 , 3F
目前觀察下來，不論scrum/waterfall,很多團隊是連分析都沒
03/12 15:20, 3F
推
03/12 15:21, 1月前 , 4F
我覺得測試部門應該要有更大的話語權 應該要有個
03/12 15:21, 4F
→
03/12 15:21, 1月前 , 5F
有，市場調查也不做，直接"我覺得是這樣"就往後跑了...
03/12 15:21, 5F
→
03/12 15:21, 1月前 , 6F
CT(test)O 東西沒穩不准出去
03/12 15:21, 6F
→
03/12 15:22, 1月前 , 7F
不然就像二哥守荊州 你不知道哪天會出包整天抖
03/12 15:22, 7F
推
03/12 15:58, 1月前 , 8F
問題是大部分敏捷也是要做100%...問就是都要做
03/12 15:58, 8F
→
03/12 15:59, 1月前 , 9F
根本不是啥MVP，超完整的
03/12 15:59, 9F
→
03/12 16:09, 1月前 , 10F
有沒有scrum，套啥框架，不生文件都一樣XDD
03/12 16:09, 10F
→
03/12 16:16, 1月前 , 11F
想走敏捷就看空X 同時建好幾個火箭 試飛成功就把其他
03/12 16:16, 11F
→
03/12 16:16, 1月前 , 12F
建到一半的捨棄掉
03/12 16:16, 12F
推
03/12 16:16, 1月前 , 13F
躺平打工仔主點防禦，照顧好自己，敏捷是游擊隊的
03/12 16:16, 13F
→
03/12 16:16, 1月前 , 14F
事
03/12 16:16, 14F
→
03/12 16:28, 1月前 , 15F
敏捷但又要100%就沒敏捷的意義了吧orz
03/12 16:28, 15F
推
03/12 16:41, 1月前 , 16F
大部分都 kanban 跑起來而已
03/12 16:41, 16F
推
03/12 17:09, 1月前 , 17F
敏捷有文件 不可能沒有文件 難道需求拆分不算文件？
03/12 17:09, 17F
推
03/12 17:13, 1月前 , 18F
有文件又怎樣，jira只寫個標題也算開ticket阿
03/12 17:13, 18F
→
03/12 17:24, 1月前 , 19F
要有能支援開發的文件...
03/12 17:24, 19F
→
03/12 19:30, 1月前 , 20F
他們可是原本JIRA跑好好的，老闆說要改用便利貼和實體板
03/12 19:30, 20F
推
03/12 20:11, 1月前 , 21F
什麼是100%? 從來沒看過任何產品是100%的
03/12 20:11, 21F
→
03/12 22:12, 1月前 , 22F
開發部門有權直接關閉議題，管你穩不穩東西就是要推出去的
03/12 22:12, 22F
噓
03/12 23:43, 1月前 , 23F
敏捷的重點不是什麼做個20%概念吧。重點是定期頻繁發佈
03/12 23:43, 23F
→
03/12 23:44, 1月前 , 24F
然後衝次過程不要隨便亂改計劃，好讓大家能按一定節奏
03/12 23:44, 24F
→
03/12 23:45, 1月前 , 25F
共同前進。你一個大願景只做20%是能試出什麼水溫？
03/12 23:45, 25F
→
03/12 23:47, 1月前 , 26F
更何況就算瀑布式也能先做基礎版上市後續再修改。
03/12 23:47, 26F
→
03/12 23:47, 1月前 , 27F
敏捷在我看就是把原本一個大瀑布拆成好幾個小瀑布罷了
03/12 23:47, 27F
推
03/12 23:51, 1月前 , 28F
幾個小衝刺沒錯啊，但是現在想起來硬體迭代的確考慮要比
03/12 23:51, 28F
→
03/12 23:51, 1月前 , 29F
較多耶，也不是不能跑但是就是麻煩，一開始要弄得很活
03/12 23:51, 29F
→
03/12 23:54, 1月前 , 30F
幾%？ 會用這個詞代表你還在waterfall思考模式啊。 minimu
03/12 23:54, 30F
→
03/12 23:54, 1月前 , 31F
m "viable" product。 最簡化的"可行性"產品。 是否可行，
03/12 23:54, 31F
→
03/12 23:54, 1月前 , 32F
根本不是%來訂的，沒人知道使用者的20%，100%到底是什麼。
03/12 23:54, 32F
→
03/12 23:54, 1月前 , 33F
而且100%的定義隨時變動，才是Scrum與MVP開發的精髓啊。你
03/12 23:54, 33F
→
03/12 23:54, 1月前 , 34F
能訂出20%, 100%是什麼，你幹嘛浪費時間用Scrum一直變需求
03/12 23:54, 34F
→
03/12 23:54, 1月前 , 35F
與優先權。
03/12 23:54, 35F
→
03/12 23:56, 1月前 , 36F
就是因為沒人知道100%的產品是什麼，才演化出了Scrum啊。
03/12 23:56, 36F
→
03/13 00:00, 1月前 , 37F
頻繁發佈更不是精髓，頻繁發佈只是達成目的的方法手段。Sc
03/13 00:00, 37F
→
03/13 00:00, 1月前 , 38F
rum精髓：可用最小開發成本，應對當前最有價值的需求，使
03/13 00:00, 38F
→
03/13 00:00, 1月前 , 39F
產品價值最大化才是精髓。
03/13 00:00, 39F
還有 89 則推文
還有 2 段內文
推
03/13 19:14, 1月前 , 129F
Toyota 的 Kanban被應用在執行敏捷開發。不等於Toyot
03/13 19:14, 129F
→
03/13 19:14, 1月前 , 130F
a是敏捷開發吧
03/13 19:14, 130F
→
03/13 19:42, 1月前 , 131F
Toyota方法比較接近的是Lean吧? 而且要走Toyota方法，前提
03/13 19:42, 131F
→
03/13 19:43, 1月前 , 132F
相當嚴格, 生產要有完整自動化機制，遇到問題要能隨時叫停
03/13 19:43, 132F
→
03/13 19:45, 1月前 , 133F
所有問題都要排除後才能往下走. 對於很多企業來說，連前提
03/13 19:45, 133F
→
03/13 19:45, 1月前 , 134F
要達到都很難...
03/13 19:45, 134F
→
03/13 20:08, 1月前 , 135F
要原型肥宅會直接用現成硬體直接盡量用現成套件來拼
03/13 20:08, 135F
推
03/13 20:08, 1月前 , 136F
高效工作術不只硬體層面的規劃，還有計劃如何推進
03/13 20:08, 136F
→
03/13 20:10, 1月前 , 137F
例如下午要跟多個客戶討論能怎麼減少時間浪費
03/13 20:10, 137F
→
03/13 20:11, 1月前 , 138F
怎麼防止問題再犯，都跟敏捷有關，只是它不用敏捷稱呼
03/13 20:11, 138F
→
03/13 20:12, 1月前 , 139F
實際上要運用要看你夠不夠格啦，職位不夠想搞什麼都難
03/13 20:12, 139F
推
03/14 00:03, 1月前 , 140F
聽起來滿猛的
03/14 00:03, 140F
→
03/14 00:59, 1月前 , 141F
樓上有人講的高效工作術我看了大綱 那看起來就是超級
03/14 00:59, 141F
→
03/14 01:00, 1月前 , 142F
螺絲釘的概念 什麼思考how前先思考why... 這本身就是
03/14 01:00, 142F
→
03/14 01:02, 1月前 , 143F
上層思考的 什麼管好自己的不丟給別人 社會很複雜的
03/14 01:02, 143F
→
03/14 01:04, 1月前 , 144F
洗腦人當超級牛馬 高層當棋手下都下不好都沒責任
03/14 01:04, 144F
→
03/14 01:12, 1月前 , 145F
況且我不信可以當面問why 最後不是心裡os就是走人
03/14 01:12, 145F
→
03/14 07:52, 1月前 , 146F
一直問why到最後就是會被搞..螺絲釘就好好扮演螺絲釘好嗎
03/14 07:52, 146F
→
03/14 07:52, 1月前 , 147F
..整天問why只會拖慢速度..等到你真的上位有時間跟資源壓
03/14 07:52, 147F
→
03/14 07:52, 1月前 , 148F
力的時候看底下的人一直問why你就會有體會了
03/14 07:52, 148F
推
03/14 08:48, 1月前 , 149F
中肯
03/14 08:48, 149F
推
03/14 08:57, 1月前 , 150F
也有些公司會鼓勵工程師了解一下商業脈絡
03/14 08:57, 150F
→
03/14 08:57, 1月前 , 151F
但不是所有工程師都會對這個有興趣
03/14 08:57, 151F
推
03/14 14:23, 1月前 , 152F
鼓勵工程師問聰明的問題，不鼓勵問智障問題
03/14 14:23, 152F
→
03/14 14:23, 1月前 , 153F
至於哪種問題聰明哪種問題智障，我他媽怎麼會知道
03/14 14:23, 153F
→
03/14 15:56, 1月前 , 154F
鼓勵工程師通靈，不鼓勵工程師自己亂想
03/14 15:56, 154F
→
03/14 17:12, 1月前 , 155F
問不問也不是重點 重點是企業有沒有公開透明大家吵架的文
03/14 17:12, 155F
→
03/14 17:12, 1月前 , 156F
化 什麼事都拿出來吵 拿出來公開討論 包括需求
03/14 17:12, 156F
→
03/14 17:13, 1月前 , 157F
通常都是表面上講open mind 但是你開口就被記仇 再講你就
03/14 17:13, 157F
→
03/14 17:13, 1月前 , 158F
被捅 嘻嘻嘻
03/14 17:13, 158F
→
03/14 17:14, 1月前 , 159F
連真話都不能講 還跑什麼敏捷 敏你個洨 工程師不要刻意塞
03/14 17:14, 159F
→
03/14 17:14, 1月前 , 160F
bug就祖宗保佑惹 甚至也不需要故意塞 就故意粗心一點做事
03/14 17:14, 160F
→
03/14 17:19, 1月前 , 161F
桑原老師說過 架是要兩個人才能吵的
03/14 17:19, 161F
推
03/15 21:19, 1月前 , 162F
有的時候有問題的不是方法，而是執行的時候忽略人性
03/15 21:19, 162F
推
03/16 13:22, 1月前 , 163F
開發測試比至少要1比3，團隊10個開發者，就要搭配30個
03/16 13:22, 163F
→
03/16 13:22, 1月前 , 164F
測試人員
03/16 13:22, 164F
噓
03/16 15:09, 1月前 , 165F
通常測試開發比例是1：3 測試是1
03/16 15:09, 165F
→
03/16 15:50, 1月前 , 166F
抱歉測試人員去幫忙開發了，所以是0
03/16 15:50, 166F
推
03/17 21:05, 4周前 , 167F
測試？我快十年沒看過公司有測試了…
03/17 21:05, 167F
推
03/19 09:55, 3周前 , 168F
怎麼還再吵這個？產品品質下降就是事實，使用者哪管你媽媽
03/19 09:55, 168F
‣ 更多 hidog 的文章
文章代碼(AID): #1dqJHBTr (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 3 之 3 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共3篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 hidog 的文章
文章代碼(AID): #1dqJHBTr (Soft_Job)