[討論] Scrum敏捷開發是這麼操作嗎?
最近在工作上遇到主管採用敏捷開發的管理模式,剛好在論壇上在報導高雄某間醫院的資訊室在程式專案開發所採用的管理模式。
報導標題提到”擁抱敏捷開發全臺第一家的醫院IT”,於是好奇看了報導內容。
看完之後,覺得是不是真的懂什麼是Scrum、迭代循環(黑人問號狂冒出)。
內容當中提到兩點:
1. 系統開發過程,不再跟使用者爭辯,為什麼這次提出的需求,又跟上次不一樣,「溝通衝突無益於系統本身,」她強調:「不一樣沒關係,我們改就對了!確定完成的功能是使用者要的,更重要。
2. 盡可能地不要撰寫詳細的開發需求書,使用者只需提出申請,簡單說明想要完成的事。但是,資訊室不會要求使用者一開始就能提出明確的需求。
所以不用詳細規格書? 不用跟使用者討論內容? 只要使用者提出需求意見,說什麼就做什麼!
Scrum是這麼操作運作?!
報導來源:https://www.ithome.com.tw/people/119258?
--
全盤接受使用者需求也不是不行ㄅ,反正改需求就把
時程拉長就對ㄌ
要討論內容阿 討論完就開發 開發完就測試上線
然後看使用者使用上有啥問題再逐一修改
喔 原來是想酸人 那個是醫院
醫院it本來就沒地位 使用者是醫護也沒空跟你談需求
不同產業都會產生出自己的一套方法 很正常
敏捷開發(X)隕石開發(O)
這套你拿去套在金融業也完全沒問題,就算需求認真訪談
認真寫,最後驗收也是另一回事,最後就乾脆走這套,大
家開始通靈
隕石開發你還知道隕石長怎樣,這種通靈開發要直到驗收
階段,user跟工程師才會知道需求是什麼
1. 因為爭辯不是SM的職責 SM是要確認情境和優先度
爭辯是PO的任務
2. 因為Agile就是假定使用者也搞不清處自己要什麼
而是先做一個雛形再來改需求
就我經驗而言 Scrum利於週期短的開發工程 例如客戶
已經想到預期的產品效果 只是需要快速落地驗證
但也相對的容易製造垃圾:用完發現沒用就丟
Product owner的工作啊,有時候使用者或客戶自己也不知
道自己要什麼
我覺得全文重點反而是MVC跟call center,減少重工跟干
擾提升效率,才有辦法真的跑敏捷,關鍵還是整合資源
牛頓迭代法有沒有聽過,就是先初始值,然後每一次迭代計
算後更接近實際值
一些需要技術堆疊或是研發類的 還是需要一條清楚的
路線 以保留中間開發的產物 所以有時候公司會有並行
實際值根本一開始不曉得
通常是有UI的裁會敏捷開發,沒UI沒使用者的哪需要跟使用
者溝通,組內自己橋一下就可以做了
工研院要不要也Scrum一下,哪天飛彈應user的需求可以掛
載排骨便當都不意外
問就是 你們沒有跑真的敏捷 都不是敏捷的錯
嗯你說的都對
新創搞敏捷的不是倒了就是在倒的途中,懂的就懂!
原文:"不會要求使用者一開始就能提出明確的需求。" 你解
讀成:不用跟使用者討論需求,使用者說什麼就做什麼。你自
己過度解讀也很奇怪吧。
該文看起來就是一堆沒經驗的人,嘗試做scrum。但原文帶風
向加油添醋解讀,也很沒必要。
就是一種管理方法但是最後還是以老闆的需求為主
原文到底哪裡說了:"不用跟使用者討論需求,使用者說什麼
就做什麼"亂解讀帶風險耶
錯了吧…增進溝通、快速調整才是敏捷開發的重點
scrum本來就不需要像UML,PMP,CMMI哪種詳細規格書,這篇
文章說的沒錯。然後這篇文章也沒說使用者來的需求全部不溝
通都做。HR系統哪段也有說會跟使用者溝通後才做。 是你自
己誤解文章內容,還來帶風向耶。
確認目標,從目標來討論需求是否有效
PM/老闆大多知道做這個需求的目的,但不知道怎麼達成
所以你跑的敏捷開發都有詳細規格書喔?:)
不過也是有老闆只是想花錢找人做事,有沒有用沒差
敏捷開發本來就先求有再求好吧
免去無意義的討論,直接弄個demo最快
只要方向正確,細部後續再調整就好
哈哈要注意不要/不再一詞主要強調的對象。第一點不要的
對象偏向”爭辯與衝突”;第二點不要的對象偏向”詳細的
”需求書,此外由申請與說明兩詞可知需求仍以較簡單的文
件或交流方式傳遞。
需求加了時程就延啊,幹嘛吵架,反正我PG一樣每天寫code,
時間到了不能上線怪我囉?大概是這樣
比較靠背的是真的怪開發者沒有sense,沒有講也應該要想
到(???)
隕石開發
敏捷就是不斷地循環修正
至於循環的大小範圍頻率 自己拿捏
然後 其實一般不太會有"純"敏捷 多少會混合其他模式
因為實務上不可能在一開始就搞清楚全部的需求
所以敏捷提倡先做出可以demo的東西再來改善
重點其實是人跟公司文化,大家好溝通,公司也接受這種
半成品當然沒問題,但如果不是的話就...
現實多的是開始不講清楚,後面再那邊吵架,不小心影響
現有系統更慘,工程師87%績效--
你中文裡解有問題 你知道什麼是迭代嘛?
薪水給夠 我就不委屈了
Spec不用寫得太清楚 意思是實作者看得懂
保留Flexibility 去快速迭代修改
避免你自以為是的寫了一堆到後面做的時候要打掉
但並不是說不用寫Spec
Agile 這邊的精神跟 Lean methodology類似
去快速的驗證 而不是想一步到位
Fail fast, learn faster.
你的用詞怪怪的 應該只是不強求一開始就設計完善 而不是
反過來強求模糊需求
設計不完善就不完善,搞什麼這不是BUG這是feature
錯就是錯,沒有那種萬能許願機能讀心知道開發者到底想要的
台灣搞scrum只會生出四不像
我的理解是這兩點的前提建立在先做最小功能版本再一次一
次的改版更新
因為每個版本改動都小所以快,然後使用者會根據每個版本
的結果一直更新需求這樣
這不是敏捷 這只是這個案例想跑敏捷帶來的結果
原Po有沒有看過搞了半年然後給高層一看結果幾乎要打掉重
做的瀑布開發?
敏捷的核心就是各自解讀 懂?你管人家的敏捷長怎樣
是不懂敏捷嗎?
先改先試用,改不好馬上再改也是種敏捷
一樣是要通靈,敏捷至少被翻掉的損失的工時少
看起來他們的確不懂敏捷,換MVC才是真的,但是你不懂醫院IT
醫院就點就在醫生最大,醫生也沒有空跟你討論,你就是得通
靈,誰管你用什麼開發流程
我常遇到資料庫1對1用一段時間要改成1對多的
上面說的對,要通靈或是上面隨時隨意變更工作內容的
就不要想用敏捷開發了,自找麻煩
多的是不讓你做完一個sprint就要你改的
scrum本身就是一種方法論跟專案技術,一堆人看了幾本
中文書就以為自己懂了卻不知道寫書的人自己都不懂
會寫書跟會看書不代表有實務經驗
gradient descent?
大家能力跟認知都差不多才敏的起來
原來用了Scrum就不用管軟體架構了?
敏捷就是一個做事情的風格,使用什麼技術來達成才是重點
推prag222
我的工作經驗是,敏捷與類似的框架是給一群能力不強的人
用的,而且套上之後大部分時間還會花在討論改善流程與開
會,產出的軟體一點都沒變好。在一個同事都足夠強的成熟
環境,根本從來不會把時間花在開發流程的討論
一個sprint還沒做完就要插隊改的叫做隕石開發
是一個對老闆來說比敏捷開發更敏捷的方法 馬上改!
台式敏捷開發就是今天說的東西明天就要
敏捷不代表可以讓使用者任意改需求 PM和資深工程師要審核
難道使用者隨口說我們要做大數據 下禮拜要上線 你也OK?
但看到是醫院 那就當我沒說....
真正跑Scrum,遇到插隊很平常好嗎。頭腦不要那麼死,萬一
臨時出現一個使線上系統掛掉的Bug,使公司購物系統不能用(
公司損失持續發生),你不先去插隊修,你還在扯先跑完這個S
print,下個Sprint再排進tickets處理,這樣會比較好嗎。
接案被教訓幾次,就知道要收錢了
原文醫院資訊室,根本沒說:使用者說什麼,就無腦做什麼。
全是原PO加油添醋帶風像亂解讀吧。
ithom的原文到底哪裡說了:"只要使用者提出需求意見,說什
麼就做什麼!"??? 亂帶風向耶。
原PO你要不要出來解釋一下,我什麼要污衊原文,原文哪裡有
寫到:"不用跟使用者討論內容 只要使用者提出需求意見,說
什麼就做什麼!"
原文根本沒說好嗎。這種帶風向亂解讀的行為,簡直可恥。
第二點應該是對敏捷宣言的誤會,可用的軟體重於詳
盡的文件,有提到,“雖然右側項目有其價值,但我
們更側重左側項目”,這其實不代表完全不需要右側
項目,只是如果不得已走左側至少好過一點
推 DrTech 雖然我知道很多跑敏感是個笑話 但不應該帶風
向 抹煞想努力改變的人
樓上有人說 跑敏捷適合能力不強的人?我倒是想問 能力不
強的團隊能跑的起來嗎
台灣式敏捷開發=今天開會明天上線
其實scrum是概念而不是形式
很多公司只學兩週sprint每天立會就覺得是敏捷
搞錯了吧 瀑布式才適合能力不強的成員 菁英規劃 雜魚執行
敏捷才需要都是不會偷懶的精英 因為估計時程錯誤就整個完蛋
會有插隊流程啊,但不是想插就插
沒有story point跟5分鐘早會嗎?
這個敘述是奴隸開發法 不是敏捷
錢給夠 要怎麼改就怎麼改囉
真的有符合敏捷精神在跑的是少數 多得是喊喊口號
的
我數學很快.jpg
table schema 進負責開啊?
接queue 的呢? 要共用嗎? 還是各自寫會比較Scrum ?
可以參考敏捷軟體開發宣言
可用的軟體重於詳盡的文件 與客戶合作重於合約協商
沒必要爭成這樣, 也許她就是拿個不重要的小系統演給長官看
主管:我說了算,就是敏捷
IT不就這樣的工作…就算討論半天,最後還是跟你說這不是我
想要的,可是你前面說…:我現在就想要改
敏捷是用來燃燒蠟燭人用的啦 燃盡圖 燃燒你的生命
你要了解什麼是行銷,本質是不是根本不重要
對開發人員最有善的還是走瀑布式吧
友善
講好的規格照著開發 使用者才不會一天到晚講鬼故事改
規格
使用者和鬼一樣,確定這是敏捷開發?
Scrum還要搭配一堆配套 不是有在跑sprint就是敏捷式開
發欸 很多台灣公司對外報告都講的很厲害 結果問個關鍵
點都沒做到
敏捷開發對高層來說 就是可以天天盯你進度
還有整天改你規格用的
而且就算你真照著敏捷開發走 最後還是發現大多狀況不適用
大概就前端能用吧
其他只要你系統複雜起來 你code寫再好沒詳細規劃就不行
敏捷有規劃啊 TDD 就是規劃了 只是不想太繁重文件
我的規劃不是指這個 是指整個系統架構設計
系統架構還是會改的啊 也是會一直重構的
這也是TDD過程中會遇到
上面幾位講的是不同的東西吧....B兄說的是大型應用系統
整個業務流程要有說明文件, 不然前後段各寫各的最後組不起來
敏捷是從PM角度推行的方法論 本來就不是要幫PG解決
開發問題的 所以導敏捷跟好不好開發or開發的好不好
一點關係都沒有 本質上只是讓PM比較容易有產出去跟
stakeholders交代而已
樓上正解 就是PM拿來燃燒各位用的
團隊一半都確診了還在每日站立會議
75
[請益] 公司轉型 scrum 重談 offerconst N = 'U'.charCodeAt() + 'K'; // ------- 前情 ---- 我是前端工程師,大概從 VB6 開始做 windows 視窗應用程式介面 Web 是從沒 jQuery 且溝通主流也非 json 而是 XML 時代開始寫的,目前擅長 Vue 現職公司一開始進去是開發 jQuery 前端專案,打包工具是 gulp34
Re: [請益] 如何抓上櫃歷史股價?分享我做的台股爬蟲,我收集台股相關 data,包含上櫃股價, 並開發 api,直接發 request 就可以拿到 data, 而為了有些非工程師的使用者,我也做了網頁,可在網頁上搜尋、直接下載20
[請益] 有關六年經驗非本科系的軟工身價問題請教一下版上的各位大大,目前本人擔任系統開發組組長, 年領49K*14。因目前在內部發現技術能力已經停止增長, 想更換一個工作以接觸更多新的東西。 我是非本科系出身,實際接觸軟工的時間六年, 目前實力應該處在需求功能都能實作。19
Re: [討論] 大家公司產品的Release週期都多長阿先快速回答這題的答案, 我待過的不同團隊有兩週上線一次、每天上版的, 也有一天上很多次(每個人都可以 deploy)的團隊。 原文下面的推文也滿多人提到跟工作方法或產品型態有關, 我寫了一篇文章來分享自己過去在團隊做 Release Management 的經驗,10
Re: [請益] 目前工作的職涯發展以下個人主觀片面的看法,聽聽就好 我覺得「網路服務」這樣的方向仍舊太含糊。 你最好依據幾個你有興趣開發的軟體系統之需求來決定你學習科技的方向, 免得像我職涯一樣大摔一跤。 我在前面回文說的「持續設計、實作特定類型系統」是從功能和用途的角度來分類系統,9
[請益] 轉職需求技能各位軟體業資訊業前輩們好 小弟本身在紡織產業擔任業務開發人員 派駐國外 對未來感到迷惘 因為一些原因個性慢慢轉變 不喜歡為了達到目的不擇手段的說謊、罵人、吵架等等,心很累6
[周邊] App Gametogo Hub M1各位Mac版的大大們有使用game to go的使用者嗎? 最近Game to go 推出 M1版本能使用的版本 改做 App to go hub 搶先版! 請問有人購買後關於一般文書處理跟簡單的遊戲使用體驗與系統穩定度可以分享一下? 設備 2021 MacBook Pro 13 m1chip5
[心得] SCRUM:用一半的時間,做兩倍的事書名: SCRUM:用一半的時間,做兩倍的事 推薦指數:★★★★☆ 網誌: 購買連結:3
Re: [心得] 如果可以, 真的建議不要再去創業公司了結論:人的問題、際遇的問題 大公司的架構你沒權限摸不到 大公司的設計你沒經過一連串的開發過程 不懂為何這樣設計 多數的情形是X
[問卦] 有沒有敏捷開發的八卦?常看到敏捷開發大會 scrum什麼的 我公司也照著跑 我也體驗了一年 覺得就差不多是那樣 不過也要常檢視是不是真敏捷 然後走這套 PM就不是叫PM了 好奇有用的企業多嗎