PTT推薦

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

看板Soft_Job標題[討論] Scrum敏捷開發是這麼操作嗎?作者
LeoPan
(晴天)
時間推噓27 推:35 噓:8 →:150

最近在工作上遇到主管採用敏捷開發的管理模式,剛好在論壇上在報導高雄某間醫院的資訊室在程式專案開發所採用的管理模式。

報導標題提到”擁抱敏捷開發全臺第一家的醫院IT”,於是好奇看了報導內容。

看完之後,覺得是不是真的懂什麼是Scrum、迭代循環(黑人問號狂冒出)。

內容當中提到兩點:

1. 系統開發過程,不再跟使用者爭辯,為什麼這次提出的需求,又跟上次不一樣,「溝通衝突無益於系統本身,」她強調:「不一樣沒關係,我們改就對了!確定完成的功能是使用者要的,更重要。

2. 盡可能地不要撰寫詳細的開發需求書,使用者只需提出申請,簡單說明想要完成的事。但是,資訊室不會要求使用者一開始就能提出明確的需求。

所以不用詳細規格書? 不用跟使用者討論內容? 只要使用者提出需求意見,說什麼就做什麼!

Scrum是這麼操作運作?!


報導來源:https://www.ithome.com.tw/people/119258?

--

※ PTT 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 27.242.70.169 (臺灣)
PTT 網址

nh60211as06/11 09:54全盤接受使用者需求也不是不行ㄅ,反正改需求就把

nh60211as06/11 09:54時程拉長就對ㄌ

BlueBird556606/11 09:57要討論內容阿 討論完就開發 開發完就測試上線

BlueBird556606/11 09:57然後看使用者使用上有啥問題再逐一修改

BlueBird556606/11 10:01喔 原來是想酸人 那個是醫院

BlueBird556606/11 10:01醫院it本來就沒地位 使用者是醫護也沒空跟你談需求

BlueBird556606/11 10:02不同產業都會產生出自己的一套方法 很正常

gary86122606/11 10:06敏捷開發(X)隕石開發(O)

foreverk06/11 10:14這套你拿去套在金融業也完全沒問題,就算需求認真訪談

foreverk06/11 10:14認真寫,最後驗收也是另一回事,最後就乾脆走這套,大

foreverk06/11 10:14家開始通靈

foreverk06/11 10:15隕石開發你還知道隕石長怎樣,這種通靈開發要直到驗收

foreverk06/11 10:15階段,user跟工程師才會知道需求是什麼

michellehot06/11 10:171. 因為爭辯不是SM的職責 SM是要確認情境和優先度

michellehot06/11 10:17爭辯是PO的任務

michellehot06/11 10:182. 因為Agile就是假定使用者也搞不清處自己要什麼

michellehot06/11 10:18而是先做一個雛形再來改需求

michellehot06/11 10:23就我經驗而言 Scrum利於週期短的開發工程 例如客戶

michellehot06/11 10:23已經想到預期的產品效果 只是需要快速落地驗證

michellehot06/11 10:24但也相對的容易製造垃圾:用完發現沒用就丟

yamakazi06/11 10:24Product owner的工作啊,有時候使用者或客戶自己也不知

yamakazi06/11 10:24道自己要什麼

foreverk06/11 10:25我覺得全文重點反而是MVC跟call center,減少重工跟干

foreverk06/11 10:25擾提升效率,才有辦法真的跑敏捷,關鍵還是整合資源

yamakazi06/11 10:25牛頓迭代法有沒有聽過,就是先初始值,然後每一次迭代計

yamakazi06/11 10:25算後更接近實際值

michellehot06/11 10:26一些需要技術堆疊或是研發類的 還是需要一條清楚的

michellehot06/11 10:26路線 以保留中間開發的產物 所以有時候公司會有並行

yamakazi06/11 10:27實際值根本一開始不曉得

yamakazi06/11 10:28通常是有UI的裁會敏捷開發,沒UI沒使用者的哪需要跟使用

yamakazi06/11 10:28者溝通,組內自己橋一下就可以做了

new12285106/11 10:55工研院要不要也Scrum一下,哪天飛彈應user的需求可以掛

new12285106/11 10:55載排骨便當都不意外

NDark06/11 11:05問就是 你們沒有跑真的敏捷 都不是敏捷的錯

pttano06/11 11:17嗯你說的都對

sunsamy06/11 11:21新創搞敏捷的不是倒了就是在倒的途中,懂的就懂!

DrTech06/11 11:26原文:"不會要求使用者一開始就能提出明確的需求。" 你解

DrTech06/11 11:26讀成:不用跟使用者討論需求,使用者說什麼就做什麼。你自

DrTech06/11 11:26己過度解讀也很奇怪吧。

DrTech06/11 11:27該文看起來就是一堆沒經驗的人,嘗試做scrum。但原文帶風

DrTech06/11 11:27向加油添醋解讀,也很沒必要。

k79897686906/11 11:28就是一種管理方法但是最後還是以老闆的需求為主

DrTech06/11 11:30原文到底哪裡說了:"不用跟使用者討論需求,使用者說什麼

DrTech06/11 11:30就做什麼"亂解讀帶風險耶

moom5030206/11 11:32錯了吧…增進溝通、快速調整才是敏捷開發的重點

DrTech06/11 11:36scrum本來就不需要像UML,PMP,CMMI哪種詳細規格書,這篇

DrTech06/11 11:36文章說的沒錯。然後這篇文章也沒說使用者來的需求全部不溝

DrTech06/11 11:36通都做。HR系統哪段也有說會跟使用者溝通後才做。 是你自

DrTech06/11 11:36己誤解文章內容,還來帶風向耶。

jack020406/11 11:36確認目標,從目標來討論需求是否有效

jack020406/11 11:37PM/老闆大多知道做這個需求的目的,但不知道怎麼達成

safe06/11 11:39所以你跑的敏捷開發都有詳細規格書喔?:)

jack020406/11 11:39不過也是有老闆只是想花錢找人做事,有沒有用沒差

lazarus112106/11 11:41敏捷開發本來就先求有再求好吧

lazarus112106/11 11:41免去無意義的討論,直接弄個demo最快

lazarus112106/11 11:45只要方向正確,細部後續再調整就好

BaconBao06/11 11:50哈哈要注意不要/不再一詞主要強調的對象。第一點不要的

BaconBao06/11 11:50對象偏向”爭辯與衝突”;第二點不要的對象偏向”詳細的

BaconBao06/11 11:50”需求書,此外由申請與說明兩詞可知需求仍以較簡單的文

BaconBao06/11 11:50件或交流方式傳遞。

TAKADO06/11 12:11需求加了時程就延啊,幹嘛吵架,反正我PG一樣每天寫code,

TAKADO06/11 12:11時間到了不能上線怪我囉?大概是這樣

foreverk06/11 12:24比較靠背的是真的怪開發者沒有sense,沒有講也應該要想

foreverk06/11 12:24到(???)

MonkeyCL06/11 12:33隕石開發

InfinitySA06/11 12:39敏捷就是不斷地循環修正

InfinitySA06/11 12:39至於循環的大小範圍頻率 自己拿捏

InfinitySA06/11 12:40然後 其實一般不太會有"純"敏捷 多少會混合其他模式

za75518806/11 12:50因為實務上不可能在一開始就搞清楚全部的需求

za75518806/11 12:51所以敏捷提倡先做出可以demo的東西再來改善

abccbaandy06/11 13:10重點其實是人跟公司文化,大家好溝通,公司也接受這種

abccbaandy06/11 13:11半成品當然沒問題,但如果不是的話就...

abccbaandy06/11 13:12現實多的是開始不講清楚,後面再那邊吵架,不小心影響

abccbaandy06/11 13:12現有系統更慘,工程師87%績效--

loadingN06/11 13:15你中文裡解有問題 你知道什麼是迭代嘛?

ctrlbreak06/11 13:43薪水給夠 我就不委屈了

askaleroux06/11 13:53Spec不用寫得太清楚 意思是實作者看得懂

askaleroux06/11 13:54保留Flexibility 去快速迭代修改

askaleroux06/11 13:54避免你自以為是的寫了一堆到後面做的時候要打掉

askaleroux06/11 13:54但並不是說不用寫Spec

askaleroux06/11 13:54Agile 這邊的精神跟 Lean methodology類似

askaleroux06/11 13:55去快速的驗證 而不是想一步到位

askaleroux06/11 13:55Fail fast, learn faster.

EricTao06/11 14:03你的用詞怪怪的 應該只是不強求一開始就設計完善 而不是

EricTao06/11 14:03反過來強求模糊需求

labbat06/11 14:17設計不完善就不完善,搞什麼這不是BUG這是feature

labbat06/11 14:18錯就是錯,沒有那種萬能許願機能讀心知道開發者到底想要的

tank070106/11 14:39台灣搞scrum只會生出四不像

t6414106/11 15:45我的理解是這兩點的前提建立在先做最小功能版本再一次一

t6414106/11 15:45次的改版更新

t6414106/11 15:48因為每個版本改動都小所以快,然後使用者會根據每個版本

t6414106/11 15:48的結果一直更新需求這樣

SHANGOYANYI06/11 16:08這不是敏捷 這只是這個案例想跑敏捷帶來的結果

brucetu06/11 16:14原Po有沒有看過搞了半年然後給高層一看結果幾乎要打掉重

brucetu06/11 16:14做的瀑布開發?

BigCockman06/11 16:29敏捷的核心就是各自解讀 懂?你管人家的敏捷長怎樣

BigCockman06/11 16:29是不懂敏捷嗎?

ssccg06/11 17:29先改先試用,改不好馬上再改也是種敏捷

ssccg06/11 17:30一樣是要通靈,敏捷至少被翻掉的損失的工時少

ssccg06/11 17:37看起來他們的確不懂敏捷,換MVC才是真的,但是你不懂醫院IT

ssccg06/11 17:38醫院就點就在醫生最大,醫生也沒有空跟你討論,你就是得通

ssccg06/11 17:40靈,誰管你用什麼開發流程

testPtt06/11 19:17我常遇到資料庫1對1用一段時間要改成1對多的

joney64111906/11 19:36上面說的對,要通靈或是上面隨時隨意變更工作內容的

joney64111906/11 19:36就不要想用敏捷開發了,自找麻煩

joney64111906/11 19:38多的是不讓你做完一個sprint就要你改的

prag22206/11 20:54scrum本身就是一種方法論跟專案技術,一堆人看了幾本

prag22206/11 20:55中文書就以為自己懂了卻不知道寫書的人自己都不懂

prag22206/11 20:55會寫書跟會看書不代表有實務經驗

ckp413102506/11 22:15gradient descent?

neo527706/11 22:21大家能力跟認知都差不多才敏的起來

Lordaeron06/11 22:29原來用了Scrum就不用管軟體架構了?

neo527706/11 22:40敏捷就是一個做事情的風格,使用什麼技術來達成才是重點

viper970906/11 23:14推prag222

alihue06/11 23:17我的工作經驗是,敏捷與類似的框架是給一群能力不強的人

alihue06/11 23:17用的,而且套上之後大部分時間還會花在討論改善流程與開

alihue06/11 23:17會,產出的軟體一點都沒變好。在一個同事都足夠強的成熟

alihue06/11 23:17環境,根本從來不會把時間花在開發流程的討論

brucetu06/11 23:35一個sprint還沒做完就要插隊改的叫做隕石開發

brucetu06/11 23:35是一個對老闆來說比敏捷開發更敏捷的方法 馬上改!

stkoso06/11 23:50台式敏捷開發就是今天說的東西明天就要

umum2906/12 00:28敏捷不代表可以讓使用者任意改需求 PM和資深工程師要審核

umum2906/12 00:29難道使用者隨口說我們要做大數據 下禮拜要上線 你也OK?

umum2906/12 00:31但看到是醫院 那就當我沒說....

DrTech06/12 00:43真正跑Scrum,遇到插隊很平常好嗎。頭腦不要那麼死,萬一

DrTech06/12 00:43臨時出現一個使線上系統掛掉的Bug,使公司購物系統不能用(

DrTech06/12 00:43公司損失持續發生),你不先去插隊修,你還在扯先跑完這個S

DrTech06/12 00:43print,下個Sprint再排進tickets處理,這樣會比較好嗎。

IhateOGC06/12 00:44接案被教訓幾次,就知道要收錢了

DrTech06/12 00:46原文醫院資訊室,根本沒說:使用者說什麼,就無腦做什麼。

DrTech06/12 00:46全是原PO加油添醋帶風像亂解讀吧。

DrTech06/12 00:48ithom的原文到底哪裡說了:"只要使用者提出需求意見,說什

DrTech06/12 00:48麼就做什麼!"??? 亂帶風向耶。

DrTech06/12 00:50原PO你要不要出來解釋一下,我什麼要污衊原文,原文哪裡有

DrTech06/12 00:50寫到:"不用跟使用者討論內容 只要使用者提出需求意見,說

DrTech06/12 00:50什麼就做什麼!"

DrTech06/12 00:52原文根本沒說好嗎。這種帶風向亂解讀的行為,簡直可恥。

internetms5206/12 08:01第二點應該是對敏捷宣言的誤會,可用的軟體重於詳

internetms5206/12 08:01盡的文件,有提到,“雖然右側項目有其價值,但我

internetms5206/12 08:01們更側重左側項目”,這其實不代表完全不需要右側

internetms5206/12 08:01項目,只是如果不得已走左側至少好過一點

ura121006/12 08:26推 DrTech 雖然我知道很多跑敏感是個笑話 但不應該帶風

ura121006/12 08:26向 抹煞想努力改變的人

ura121006/12 08:27樓上有人說 跑敏捷適合能力不強的人?我倒是想問 能力不

ura121006/12 08:27強的團隊能跑的起來嗎

oyaji556606/12 09:00台灣式敏捷開發=今天開會明天上線

lazarus112106/12 10:04其實scrum是概念而不是形式

lazarus112106/12 10:04很多公司只學兩週sprint每天立會就覺得是敏捷

NDark06/12 10:46搞錯了吧 瀑布式才適合能力不強的成員 菁英規劃 雜魚執行

NDark06/12 10:46敏捷才需要都是不會偷懶的精英 因為估計時程錯誤就整個完蛋

ckp413102506/12 12:17會有插隊流程啊,但不是想插就插

yamagishi06/12 13:33沒有story point跟5分鐘早會嗎?

shooter55506/12 15:13這個敘述是奴隸開發法 不是敏捷

scott9021306/12 15:56錢給夠 要怎麼改就怎麼改囉

answermangtr06/12 16:24真的有符合敏捷精神在跑的是少數 多得是喊喊口號

answermangtr06/12 16:24

ybon306/12 16:52我數學很快.jpg

Lordaeron06/12 17:25table schema 進負責開啊?

Lordaeron06/12 17:27接queue 的呢? 要共用嗎? 還是各自寫會比較Scrum ?

StrangeJ06/12 19:21可以參考敏捷軟體開發宣言

StrangeJ06/12 19:22可用的軟體重於詳盡的文件 與客戶合作重於合約協商

atpx06/12 20:19沒必要爭成這樣, 也許她就是拿個不重要的小系統演給長官看

showshowman06/12 23:22主管:我說了算,就是敏捷

qss0506/13 08:08IT不就這樣的工作…就算討論半天,最後還是跟你說這不是我

qss0506/13 08:08想要的,可是你前面說…:我現在就想要改

shooter55506/13 09:59敏捷是用來燃燒蠟燭人用的啦 燃盡圖 燃燒你的生命

eplis06/13 10:01你要了解什麼是行銷,本質是不是根本不重要

shooter55506/13 10:07對開發人員最有善的還是走瀑布式吧

shooter55506/13 10:07 友善

shooter55506/13 10:08講好的規格照著開發 使用者才不會一天到晚講鬼故事改

shooter55506/13 10:08規格

realbout06/13 11:03使用者和鬼一樣,確定這是敏捷開發?

friends2906/13 12:25Scrum還要搭配一堆配套 不是有在跑sprint就是敏捷式開

friends2906/13 12:25發欸 很多台灣公司對外報告都講的很厲害 結果問個關鍵

friends2906/13 12:25點都沒做到

BoXeX06/13 23:02敏捷開發對高層來說 就是可以天天盯你進度

BoXeX06/13 23:03還有整天改你規格用的

BoXeX06/13 23:06而且就算你真照著敏捷開發走 最後還是發現大多狀況不適用

BoXeX06/13 23:06大概就前端能用吧

BoXeX06/13 23:07其他只要你系統複雜起來 你code寫再好沒詳細規劃就不行

shomingchang06/13 23:51敏捷有規劃啊 TDD 就是規劃了 只是不想太繁重文件

BoXeX06/13 23:59我的規劃不是指這個 是指整個系統架構設計

Sunal06/14 00:12系統架構還是會改的啊 也是會一直重構的

Sunal06/14 00:13這也是TDD過程中會遇到

atpx06/14 00:44上面幾位講的是不同的東西吧....B兄說的是大型應用系統

atpx06/14 00:45整個業務流程要有說明文件, 不然前後段各寫各的最後組不起來

SHANGOYANYI06/14 01:32敏捷是從PM角度推行的方法論 本來就不是要幫PG解決

SHANGOYANYI06/14 01:32開發問題的 所以導敏捷跟好不好開發or開發的好不好

SHANGOYANYI06/14 01:32一點關係都沒有 本質上只是讓PM比較容易有產出去跟

SHANGOYANYI06/14 01:32stakeholders交代而已

shooter55506/14 11:32樓上正解 就是PM拿來燃燒各位用的

ChungLi556606/14 18:37團隊一半都確診了還在每日站立會議