回看板
Disp BBS
作者 hidog (.....)
標題 Re: [討論] 故 CTO 對於 Scrum 的看法
時間 Wed Mar 12 15:14:17 2025

※ 引述《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 (臺灣)
※ 作者: hidog 2025-03-12 15:14:17
※ 文章代碼(AID): #1dqJHBTr (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1741763659.A.775.html
※ 同主題文章:
[討論] 故 CTO 對於 Scrum 的看法
03-08 16:12 JasperChang
Re: [討論] 故 CTO 對於 Scrum 的看法
03-08 20:18 langrisser19
Re: [討論] 故 CTO 對於 Scrum 的看法
03-12 15:14 hidog
→ atst2: 更根本的問題是,不論號稱是scrum還是waterfall,最基本的
分析, 設計，開發，測試，維護有沒有缺漏?
目前觀察下來，不論scrum/waterfall,很多團隊是連分析都沒1F 03/12 15:19
推 gino0717: 我覺得測試部門應該要有更大的話語權  應該要有個4F 03/12 15:21
→ atst2: 有，市場調查也不做，直接"我覺得是這樣"就往後跑了...5F 03/12 15:21
→ gino0717: CT(test)O 東西沒穩不准出去
不然就像二哥守荊州 你不知道哪天會出包整天抖6F 03/12 15:21
推 abccbaandy: 問題是大部分敏捷也是要做100%...問就是都要做
根本不是啥MVP，超完整的8F 03/12 15:58
→ stepnight: 有沒有scrum，套啥框架，不生文件都一樣XDD10F 03/12 16:09
→ ChungLi5566: 想走敏捷就看空X 同時建好幾個火箭 試飛成功就把其他建到一半的捨棄掉11F 03/12 16:16
推 kuosos520: 躺平打工仔主點防禦，照顧好自己，敏捷是游擊隊的
事13F 03/12 16:16
→ hidog: 敏捷但又要100%就沒敏捷的意義了吧orz15F 03/12 16:28
推 OyodoKai: 大部分都 kanban 跑起來而已16F 03/12 16:41
推 ktasl: 敏捷有文件  不可能沒有文件 難道需求拆分不算文件？17F 03/12 17:09
推 abccbaandy: 有文件又怎樣，jira只寫個標題也算開ticket阿18F 03/12 17:13
→ hidog: 要有能支援開發的文件...19F 03/12 17:24
→ ssccg: 他們可是原本JIRA跑好好的，老闆說要改用便利貼和實體板20F 03/12 19:30
推 shadow0326: 什麼是100%? 從來沒看過任何產品是100%的21F 03/12 20:11
→ labbat: 開發部門有權直接關閉議題，管你穩不穩東西就是要推出去的22F 03/12 22:12
噓 dream1124: 敏捷的重點不是什麼做個20%概念吧。重點是定期頻繁發佈然後衝次過程不要隨便亂改計劃，好讓大家能按一定節奏共同前進。你一個大願景只做20%是能試出什麼水溫？
更何況就算瀑布式也能先做基礎版上市後續再修改。
敏捷在我看就是把原本一個大瀑布拆成好幾個小瀑布罷了23F 03/12 23:43
推 neo5277: 幾個小衝刺沒錯啊，但是現在想起來硬體迭代的確考慮要比較多耶，也不是不能跑但是就是麻煩，一開始要弄得很活28F 03/12 23:51
→ DrTech: 幾%？ 會用這個詞代表你還在waterfall思考模式啊。 minimum "viable" product。 最簡化的"可行性"產品。 是否可行，根本不是%來訂的，沒人知道使用者的20%，100%到底是什麼。而且100%的定義隨時變動，才是Scrum與MVP開發的精髓啊。你能訂出20%, 100%是什麼，你幹嘛浪費時間用Scrum一直變需求與優先權。
就是因為沒人知道100%的產品是什麼，才演化出了Scrum啊。頻繁發佈更不是精髓，頻繁發佈只是達成目的的方法手段。Scrum精髓：可用最小開發成本，應對當前最有價值的需求，使產品價值最大化才是精髓。30F 03/12 23:54
實務上我不會用%數來評估,但如果老闆比較喜歡%數,我就會想辦法掰%數給他.
只要能適應快速變動的市場,要用%數還是用其他方式決定release時間並不重要吧.
→ DrTech: "敏捷在我看就是把原本一個大瀑布拆成好幾個小瀑布罷了"，錯誤的觀念。正確觀念：用"最小成本"，選擇當前"最有價值"的小瀑布開發才是重點。40F 03/13 00:04
→ shooter555: 敏捷的精神應該是同步共享 資訊透明 吧 把瀑布的每一階段同步跑
算了 我也不瞭 大家就敏捷自助餐 各取所需43F 03/13 00:23
推 OyodoKai: 一堆DT在討論PO跟SM煩惱的東西 甚至是沒有SM的Scrum46F 03/13 00:25
推 Lhmstu: 軟體新創真的一堆那種，難怪台灣軟體很難起來47F 03/13 00:43
推 viper9709: 推敏捷式+新創這個組合常常發生問題+148F 03/13 01:07
推 strlen: 敏捷這兩個字當初翻譯就有問題了才導致華文圈管理模式亂用敏捷不是快快快 什麼都講求快 敏捷是短週期頻繁檢視現實需求 然後修正開發方向 這跟快不快一點關係也沒有 也跟什麼最小可行性產品一點關係都沒有 敏捷開發真正的精神可以用在任何一種產品上 就是 短週期檢視小成果 頻繁討論修正方向 一步一步讓軟體慢慢演化 你整個工期要快要慢跟敏捷一點關係都沒有 敏捷真正的意思 是讓整個系統的架構更快更容易做修改 做調整 做擴展 也就是能快速做出改變 快是指這個要達到這種效果 你的軟體模組化要做好 SOLID原則要用好 設計模式也要仔細檢討 而且重點不是一股腦全把這些東西尻進去 你還要判斷哪邊該加入SOLID和設計模式 哪邊不要 以免過度設計 結果適得其反 所以敏捷非常非常注重架構設計 大區塊中區塊小區塊的各種設計 也非常非常重視單元測試整合測試 因為你沒有這些東西怎麼能保證你改了啥 東西不會壞？架構設計最麻煩的就是沒有標準答案 你怎麼知道這個部份要49F 03/13 01:34
推 OyodoKai: 樓上講的敏捷也太高大上了64F 03/13 01:44
→ strlen: 用哪個設計模式？工廠？還是策略？所以跑敏捷大家要常常吵架 常常討論 所以要pair programming 要老的帶小的 學徒制團隊要公開透明 甚至對需求方窗口也要公開透明
對工程師的要求也相當高 光是每個人都一定要寫測試就飽了敏捷要認真跑 工期絕對比什麼隕石瀑布長啦
這就是真正的敏捷開發 那要魔改亂七八糟的 隨便啦 爽就好敏捷也不是沒有文件 而是文件輔助用 重點團隊溝通 和與需求方溝通 緊密合作 公開透明 無所保留 也不要搞什麼政治反正敏捷最終要達到的最高目標 就是讓系統能更快速的修改和擴展 而且還不能弄壞 要穩定 那些管理模式都是為了這事一般瀑布和隕石開發根本做不到快速修改擴展 做到一半要改因為設計寫死了要改又要花大半時間 而且沒測試 一邊改bug就一邊出 挖東牆補西牆 最後整鍋都砸了
當然你們很屌用瀑布隕石開發 然後還可以讓系統做到能快速修改擴展而且也非常穩定測試也都有寫 那你天生神力
要讓產品能夠快速做出改變適應需求還要穩定不能壞掉 這是要付出代價的65F 03/13 01:45
推 OyodoKai: 待過成功上市的新創 雖然不是跑真的Scrum 應該也不可能82F 03/13 02:00
→ strlen: agile這個字其實是靈活上的敏捷 而不是快速上的敏捷83F 03/13 02:01
→ OyodoKai: 期待隕石開發天生神力保佑84F 03/13 02:01
→ strlen: 一堆老闆大概看到敏捷 就覺得原文是fast......
你啥設計都沒有把功能直接從頭寫到尾 這叫fast 最快
但你如果要考慮設計 還要跟同事吵架 東想西想才弄出一個架構 然後再加上測試 可能花你兩倍以上時間 但要改就很快
你從頭寫到尾的 前面很快 等到後面要改 就是還債囉
我講白一點 這雲三洨的果然雲 老董跟CTO兩個老人真的啥都不懂在胡說八道 雞同鴨講 其實agile也夠老了也能亂扯一通什麼scrum造不三洨督三洨的 這跟那有何關係？混業界混幾十年了 上網搞懂這些管理模式花幾小時而已很難嗎 可悲喔
難怪公司爛成這樣 哈85F 03/13 02:03
→ OyodoKai: scrum如果真的能滿足老闆(PO) 大家就老老實實跑了
新創基本上都魔改成kanban來接隕石95F 03/13 02:11
→ strlen: 其實重點還是在達成目標 把產品做成可快速修改的穩定系統你要自己發明什麼鬼模式都可以 能尻出這種效果就行97F 03/13 02:15
推 OyodoKai: 老闆要的是賺錢的系統 XD99F 03/13 02:17
→ strlen: 可快速修改的穩定系統 這可並不容易 應該說 非常困難
你東西不能快速修改 跟不上需求 就賺不了錢 可以改 但不穩定 客戶體驗爛 一樣不賺錢 所以囉100F 03/13 02:17
→ OyodoKai: 大部分公司聘不起能做出可快速修改的穩定系統的工程師103F 03/13 02:18
推 dio0204: 結論：跟共產主義一樣 只有小屁孩相信104F 03/13 02:45
→ strlen: 也不是什麼共產主義 這就經驗累積的結果 就是這樣
你的目標是開發出能快速修改擴充又穩定的產品
前人累積了許多心酸血淚 最後才試出一套敏捷開發模式 是最有機會能達成這個目標的 別的模式不是不行喔 就說你屌炸天自己發明什麼碗糕模式也能達到一樣效果 那算你厲害囉105F 03/13 02:49
推 OyodoKai: 我覺得該來個scrum九宮格了 形式自由110F 03/13 02:52
→ strlen: 這葛雲三洨的產品 很明顯就是 能快速修改 但極不穩定 哈哈敏捷玩一半就會變成這樣 可憐哪111F 03/13 02:53
噓 B0988698088: 感覺文就別發了 你講的大家早就知道了113F 03/13 08:47
※ 編輯: hidog (111.241.148.153 臺灣), 03/13/2025 09:24:45
推 luke72: 20%這種事跑mini waterfall也行，沒規定waterfall要100%再來CTO跟這串文講的都是硬體跟核心，就不適合agile啊114F 03/13 12:18
推 jack0204: 硬體可以參考Toyota高效工作術，也是敏捷精神
特斯拉造車也是想方法各種加速116F 03/13 16:42
推 NDark: 特斯拉造車法就是解決不能接受改變的人
因為馬斯克每個站點都自己盯敢說不的就被ＦＩＲＥ了118F 03/13 17:00
→ lonelytea: 第一段確實120F 03/13 17:55

--
作者 hidog 的最新發文:
點此顯示更多發文記錄