Re: [討論] 故 CTO 對於 Scrum 的看法軟工
: 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→ atst21樓更根本的問題是,不論號稱是scrum還是waterfall,最基本的 03/12 15:19
→ atst22樓分析, 設計，開發，測試，維護有沒有缺漏? 03/12 15:19
→ atst23樓目前觀察下來，不論scrum/waterfall,很多團隊是連分析都沒 03/12 15:20
gino07174樓我覺得測試部門應該要有更大的話語權 應該要有個 03/12 15:21
→ atst25樓有，市場調查也不做，直接"我覺得是這樣"就往後跑了... 03/12 15:21
→ gino07176樓CT(test)O 東西沒穩不准出去 03/12 15:21
→ gino07177樓不然就像二哥守荊州 你不知道哪天會出包整天抖 03/12 15:22
abccbaandy8樓問題是大部分敏捷也是要做100%...問就是都要做 03/12 15:58
→ abccbaandy9樓根本不是啥MVP，超完整的 03/12 15:59
→ stepnight10樓有沒有scrum，套啥框架，不生文件都一樣XDD 03/12 16:09
→ ChungLi556611樓想走敏捷就看空X 同時建好幾個火箭 試飛成功就把其他 03/12 16:16
→ ChungLi556612樓建到一半的捨棄掉 03/12 16:16
kuosos52013樓躺平打工仔主點防禦，照顧好自己，敏捷是游擊隊的 03/12 16:16
→ kuosos52014樓事 03/12 16:16
→ 本人15樓敏捷但又要100%就沒敏捷的意義了吧orz 03/12 16:28
OyodoKai16樓大部分都 kanban 跑起來而已 03/12 16:41
ktasl17樓敏捷有文件 不可能沒有文件 難道需求拆分不算文件？ 03/12 17:09
abccbaandy18樓有文件又怎樣，jira只寫個標題也算開ticket阿 03/12 17:13
→ 本人19樓要有能支援開發的文件... 03/12 17:24
→ ssccg20樓他們可是原本JIRA跑好好的，老闆說要改用便利貼和實體板 03/12 19:30
shadow032621樓什麼是100%? 從來沒看過任何產品是100%的 03/12 20:11
→ labbat22樓開發部門有權直接關閉議題，管你穩不穩東西就是要推出去的 03/12 22:12
dream112423樓敏捷的重點不是什麼做個20%概念吧。重點是定期頻繁發佈 03/12 23:43
→ dream112424樓然後衝次過程不要隨便亂改計劃，好讓大家能按一定節奏 03/12 23:44
→ dream112425樓共同前進。你一個大願景只做20%是能試出什麼水溫？ 03/12 23:45
→ dream112426樓更何況就算瀑布式也能先做基礎版上市後續再修改。 03/12 23:47
→ dream112427樓敏捷在我看就是把原本一個大瀑布拆成好幾個小瀑布罷了 03/12 23:47
neo527728樓幾個小衝刺沒錯啊，但是現在想起來硬體迭代的確考慮要比 03/12 23:51
→ neo527729樓較多耶，也不是不能跑但是就是麻煩，一開始要弄得很活 03/12 23:51
→ DrTech30樓幾%？ 會用這個詞代表你還在waterfall思考模式啊。 minimu 03/12 23:54