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

atst203/12 15:19更根本的問題是,不論號稱是scrum還是waterfall,最基本的

atst203/12 15:19分析, 設計，開發，測試，維護有沒有缺漏?

atst203/12 15:20目前觀察下來，不論scrum/waterfall,很多團隊是連分析都沒

gino071703/12 15:21我覺得測試部門應該要有更大的話語權 應該要有個

atst203/12 15:21有，市場調查也不做，直接"我覺得是這樣"就往後跑了...

gino071703/12 15:21CT(test)O 東西沒穩不准出去

gino071703/12 15:22不然就像二哥守荊州 你不知道哪天會出包整天抖

abccbaandy03/12 15:58問題是大部分敏捷也是要做100%...問就是都要做

abccbaandy03/12 15:59根本不是啥MVP，超完整的

stepnight03/12 16:09有沒有scrum，套啥框架，不生文件都一樣XDD

ChungLi556603/12 16:16想走敏捷就看空X 同時建好幾個火箭 試飛成功就把其他

ChungLi556603/12 16:16建到一半的捨棄掉

kuosos52003/12 16:16躺平打工仔主點防禦，照顧好自己，敏捷是游擊隊的

kuosos52003/12 16:16事

hidog03/12 16:28敏捷但又要100%就沒敏捷的意義了吧orz

OyodoKai03/12 16:41大部分都 kanban 跑起來而已

ktasl03/12 17:09敏捷有文件 不可能沒有文件 難道需求拆分不算文件？

abccbaandy03/12 17:13有文件又怎樣，jira只寫個標題也算開ticket阿

hidog03/12 17:24要有能支援開發的文件...

ssccg03/12 19:30他們可是原本JIRA跑好好的，老闆說要改用便利貼和實體板

shadow032603/12 20:11什麼是100%? 從來沒看過任何產品是100%的

labbat03/12 22:12開發部門有權直接關閉議題，管你穩不穩東西就是要推出去的

dream112403/12 23:43敏捷的重點不是什麼做個20%概念吧。重點是定期頻繁發佈

dream112403/12 23:44然後衝次過程不要隨便亂改計劃，好讓大家能按一定節奏

dream112403/12 23:45共同前進。你一個大願景只做20%是能試出什麼水溫？

dream112403/12 23:47更何況就算瀑布式也能先做基礎版上市後續再修改。

dream112403/12 23:47敏捷在我看就是把原本一個大瀑布拆成好幾個小瀑布罷了

neo527703/12 23:51幾個小衝刺沒錯啊，但是現在想起來硬體迭代的確考慮要比

neo527703/12 23:51較多耶，也不是不能跑但是就是麻煩，一開始要弄得很活

DrTech03/12 23:54幾%？ 會用這個詞代表你還在waterfall思考模式啊。 minimu

DrTech03/12 23:54m "viable" product。 最簡化的"可行性"產品。 是否可行，

DrTech03/12 23:54根本不是%來訂的，沒人知道使用者的20%，100%到底是什麼。

DrTech03/12 23:54而且100%的定義隨時變動，才是Scrum與MVP開發的精髓啊。你

DrTech03/12 23:54能訂出20%, 100%是什麼，你幹嘛浪費時間用Scrum一直變需求

DrTech03/12 23:54與優先權。

DrTech03/12 23:56就是因為沒人知道100%的產品是什麼，才演化出了Scrum啊。

DrTech03/13 00:00頻繁發佈更不是精髓，頻繁發佈只是達成目的的方法手段。Sc

DrTech03/13 00:00rum精髓：可用最小開發成本，應對當前最有價值的需求，使

DrTech03/13 00:00產品價值最大化才是精髓。

DrTech03/13 00:04"敏捷在我看就是把原本一個大瀑布拆成好幾個小瀑布罷了"，

DrTech03/13 00:04錯誤的觀念。正確觀念：用"最小成本"，選擇當前"最有價值"

DrTech03/13 00:04的小瀑布開發才是重點。

shooter55503/13 00:23敏捷的精神應該是同步共享 資訊透明 吧 把瀑布的每一

shooter55503/13 00:23階段同步跑

shooter55503/13 00:24算了 我也不瞭 大家就敏捷自助餐 各取所需

OyodoKai03/13 00:25一堆DT在討論PO跟SM煩惱的東西 甚至是沒有SM的Scrum

Lhmstu03/13 00:43軟體新創真的一堆那種，難怪台灣軟體很難起來

viper970903/13 01:07推敏捷式+新創這個組合常常發生問題+1

strlen03/13 01:34敏捷這兩個字當初翻譯就有問題了才導致華文圈管理模式亂用

strlen03/13 01:35敏捷不是快快快 什麼都講求快 敏捷是短週期頻繁檢視現實需

strlen03/13 01:36求 然後修正開發方向 這跟快不快一點關係也沒有 也跟什麼

strlen03/13 01:36最小可行性產品一點關係都沒有 敏捷開發真正的精神可以用

strlen03/13 01:37在任何一種產品上 就是 短週期檢視小成果 頻繁討論修正方

strlen03/13 01:37向 一步一步讓軟體慢慢演化 你整個工期要快要慢跟敏捷一點

strlen03/13 01:38關係都沒有 敏捷真正的意思 是讓整個系統的架構更快更容易

strlen03/13 01:39做修改 做調整 做擴展 也就是能快速做出改變 快是指這個

strlen03/13 01:40要達到這種效果 你的軟體模組化要做好 SOLID原則要用好 設

strlen03/13 01:40計模式也要仔細檢討 而且重點不是一股腦全把這些東西尻進

strlen03/13 01:41去 你還要判斷哪邊該加入SOLID和設計模式 哪邊不要 以免過

strlen03/13 01:42度設計 結果適得其反 所以敏捷非常非常注重架構設計 大區

strlen03/13 01:42塊中區塊小區塊的各種設計 也非常非常重視單元測試整合測

strlen03/13 01:43試 因為你沒有這些東西怎麼能保證你改了啥 東西不會壞？

strlen03/13 01:44架構設計最麻煩的就是沒有標準答案 你怎麼知道這個部份要

OyodoKai03/13 01:44樓上講的敏捷也太高大上了

strlen03/13 01:45用哪個設計模式？工廠？還是策略？所以跑敏捷大家要常常吵

strlen03/13 01:46架 常常討論 所以要pair programming 要老的帶小的 學徒制

strlen03/13 01:46團隊要公開透明 甚至對需求方窗口也要公開透明

strlen03/13 01:47對工程師的要求也相當高 光是每個人都一定要寫測試就飽了

strlen03/13 01:47敏捷要認真跑 工期絕對比什麼隕石瀑布長啦

strlen03/13 01:48這就是真正的敏捷開發 那要魔改亂七八糟的 隨便啦 爽就好

strlen03/13 01:49敏捷也不是沒有文件 而是文件輔助用 重點團隊溝通 和與需

strlen03/13 01:49求方溝通 緊密合作 公開透明 無所保留 也不要搞什麼政治

strlen03/13 01:51反正敏捷最終要達到的最高目標 就是讓系統能更快速的修改

strlen03/13 01:51和擴展 而且還不能弄壞 要穩定 那些管理模式都是為了這事

strlen03/13 01:52一般瀑布和隕石開發根本做不到快速修改擴展 做到一半要改

strlen03/13 01:53因為設計寫死了要改又要花大半時間 而且沒測試 一邊改bug

strlen03/13 01:53就一邊出 挖東牆補西牆 最後整鍋都砸了

strlen03/13 01:54當然你們很屌用瀑布隕石開發 然後還可以讓系統做到能快速

strlen03/13 01:55修改擴展而且也非常穩定測試也都有寫 那你天生神力

strlen03/13 01:58要讓產品能夠快速做出改變適應需求還要穩定不能壞掉 這是

strlen03/13 01:58要付出代價的

OyodoKai03/13 02:00待過成功上市的新創 雖然不是跑真的Scrum 應該也不可能

strlen03/13 02:01agile這個字其實是靈活上的敏捷 而不是快速上的敏捷

OyodoKai03/13 02:01期待隕石開發天生神力保佑

strlen03/13 02:03一堆老闆大概看到敏捷 就覺得原文是fast......

strlen03/13 02:04你啥設計都沒有把功能直接從頭寫到尾 這叫fast 最快

strlen03/13 02:04但你如果要考慮設計 還要跟同事吵架 東想西想才弄出一個架

strlen03/13 02:05構 然後再加上測試 可能花你兩倍以上時間 但要改就很快

strlen03/13 02:05你從頭寫到尾的 前面很快 等到後面要改 就是還債囉

strlen03/13 02:06我講白一點 這雲三洨的果然雲 老董跟CTO兩個老人真的啥都

strlen03/13 02:07不懂在胡說八道 雞同鴨講 其實agile也夠老了也能亂扯一通

strlen03/13 02:09什麼scrum造不三洨督三洨的 這跟那有何關係？混業界混幾十

strlen03/13 02:09年了 上網搞懂這些管理模式花幾小時而已很難嗎 可悲喔

strlen03/13 02:10難怪公司爛成這樣 哈

OyodoKai03/13 02:11scrum如果真的能滿足老闆(PO) 大家就老老實實跑了

OyodoKai03/13 02:13新創基本上都魔改成kanban來接隕石

strlen03/13 02:15其實重點還是在達成目標 把產品做成可快速修改的穩定系統

strlen03/13 02:16你要自己發明什麼鬼模式都可以 能尻出這種效果就行

OyodoKai03/13 02:17老闆要的是賺錢的系統 XD

strlen03/13 02:17可快速修改的穩定系統 這可並不容易 應該說 非常困難

strlen03/13 02:17你東西不能快速修改 跟不上需求 就賺不了錢 可以改 但不穩

strlen03/13 02:18定 客戶體驗爛 一樣不賺錢 所以囉

OyodoKai03/13 02:18大部分公司聘不起能做出可快速修改的穩定系統的工程師

dio020403/13 02:45結論：跟共產主義一樣 只有小屁孩相信

strlen03/13 02:49也不是什麼共產主義 這就經驗累積的結果 就是這樣

strlen03/13 02:49你的目標是開發出能快速修改擴充又穩定的產品

strlen03/13 02:50前人累積了許多心酸血淚 最後才試出一套敏捷開發模式 是最

strlen03/13 02:50有機會能達成這個目標的 別的模式不是不行喔 就說你屌炸天

strlen03/13 02:51自己發明什麼碗糕模式也能達到一樣效果 那算你厲害囉

OyodoKai03/13 02:52我覺得該來個scrum九宮格了 形式自由

strlen03/13 02:53這葛雲三洨的產品 很明顯就是 能快速修改 但極不穩定 哈哈

strlen03/13 02:53敏捷玩一半就會變成這樣 可憐哪

B098869808803/13 08:47感覺文就別發了 你講的大家早就知道了

luke7203/13 12:1820%這種事跑mini waterfall也行，沒規定waterfall要100%

luke7203/13 12:20再來CTO跟這串文講的都是硬體跟核心，就不適合agile啊

jack020403/13 16:42硬體可以參考Toyota高效工作術，也是敏捷精神

jack020403/13 16:43特斯拉造車也是想方法各種加速

NDark03/13 17:00特斯拉造車法就是解決不能接受改變的人

NDark03/13 17:01因為馬斯克每個站點都自己盯敢說不的就被ＦＩＲＥ了

lonelytea03/13 17:55第一段確實

superpandal03/13 18:30不會有無敵的系統出來的 真有也不會甘心獻給一個不是

superpandal03/13 18:31自己所有的公司或單位 雖然我自己隨手做的靈活性就不

superpandal03/13 18:33錯了 但我絕對不會想做一個讓人可以在技術上躺贏

superpandal03/13 18:36並且危害到自己生存的東西 因為人不可盡信

superpandal03/13 18:39職場上經驗就是王八蛋人數遠遠超過好人

superpandal03/13 18:48故現實上這些東西是不可能完美進行的 不管你打算用幾

superpandal03/13 18:49% 災難如果可以意料就不是災難

superpandal03/13 18:53即便全部沒算漏 但薪水明顯就是不合理

AudiA4Avant03/13 19:14Toyota 的 Kanban被應用在執行敏捷開發。不等於Toyot

AudiA4Avant03/13 19:14a是敏捷開發吧

atst203/13 19:42Toyota方法比較接近的是Lean吧? 而且要走Toyota方法，前提

atst203/13 19:43相當嚴格, 生產要有完整自動化機制，遇到問題要能隨時叫停

atst203/13 19:45所有問題都要排除後才能往下走. 對於很多企業來說，連前提

atst203/13 19:45要達到都很難...

dildoe03/13 20:08要原型肥宅會直接用現成硬體直接盡量用現成套件來拼

jack020403/13 20:08高效工作術不只硬體層面的規劃，還有計劃如何推進

jack020403/13 20:10例如下午要跟多個客戶討論能怎麼減少時間浪費

jack020403/13 20:11怎麼防止問題再犯，都跟敏捷有關，只是它不用敏捷稱呼

jack020403/13 20:12實際上要運用要看你夠不夠格啦，職位不夠想搞什麼都難

viper970903/14 00:03聽起來滿猛的

superpandal03/14 00:59樓上有人講的高效工作術我看了大綱 那看起來就是超級

superpandal03/14 01:00螺絲釘的概念 什麼思考how前先思考why... 這本身就是

superpandal03/14 01:02上層思考的 什麼管好自己的不丟給別人 社會很複雜的

superpandal03/14 01:04洗腦人當超級牛馬 高層當棋手下都下不好都沒責任

superpandal03/14 01:12況且我不信可以當面問why 最後不是心裡os就是走人

hegemon03/14 07:52一直問why到最後就是會被搞..螺絲釘就好好扮演螺絲釘好嗎

hegemon03/14 07:52..整天問why只會拖慢速度..等到你真的上位有時間跟資源壓

hegemon03/14 07:52力的時候看底下的人一直問why你就會有體會了

moon251903/14 08:48中肯

CRPKT03/14 08:57也有些公司會鼓勵工程師了解一下商業脈絡

CRPKT03/14 08:57但不是所有工程師都會對這個有興趣

shadow032603/14 14:23鼓勵工程師問聰明的問題，不鼓勵問智障問題

shadow032603/14 14:23至於哪種問題聰明哪種問題智障，我他媽怎麼會知道

ssccg03/14 15:56鼓勵工程師通靈，不鼓勵工程師自己亂想

strlen03/14 17:12問不問也不是重點 重點是企業有沒有公開透明大家吵架的文

strlen03/14 17:12化 什麼事都拿出來吵 拿出來公開討論 包括需求

strlen03/14 17:13通常都是表面上講open mind 但是你開口就被記仇 再講你就

strlen03/14 17:13被捅 嘻嘻嘻

strlen03/14 17:14連真話都不能講 還跑什麼敏捷 敏你個洨 工程師不要刻意塞

strlen03/14 17:14bug就祖宗保佑惹 甚至也不需要故意塞 就故意粗心一點做事

gino071703/14 17:19桑原老師說過 架是要兩個人才能吵的

AudiA4Avant03/15 21:19有的時候有問題的不是方法，而是執行的時候忽略人性

new12285103/16 13:22開發測試比至少要1比3，團隊10個開發者，就要搭配30個

new12285103/16 13:22測試人員

s86013403/16 15:09通常測試開發比例是1：3 測試是1

labbat03/16 15:50抱歉測試人員去幫忙開發了，所以是0