作者:
prag222 (prag)
2016-05-21 22:18:57※ 引述《chatmonkey (打屁猴)》之銘言：
: ※ 引述《purin88 (原來我是憤怒的鄉民)》之銘言：
: : 唉，但工時估太短，就造成我不停的加班追進度，沒有六日、沒有晚上
: : 請問我該怎麼辦？
: : 還有更好的solution嗎？
推文有提到scrum,我也來討論一下
小弟在新創公司,開發模式導scrum
廢話就不講了
一次sprint需求會議16人,開兩三天(整個團隊
估工時要花兩天
我看我同事都估的短(主管會壓時間
我自己估還花心力看需求文件認真地估出來
也是估的短
每天daily meeting約40分鐘
進公司後一個小時,才能真正動工
也就是8小時的事,7小時要做完
導scrum真的好嗎?
daily meeting本意不是每天盯進度造成員工時程壓力吧?我不懂
而且什麼sprint google翻譯出來就是跑百米
跑百米是能夠讓人跑幾次衝刺幾次...
作者:
NDark (溺於黑暗)
2016-05-21 22:21:00#1NCTBu6G (Soft_Job)sprint 是衝刺沒錯啊. 他的精神就是每個sprint週期衝刺一次daily meeting要盡量縮短. 我們最短紀錄是一人只有15秒4個人可以在一分鐘內結束. 這樣就不會造成時間浪費.
作者:
a1b2c3d4e5x (int *lpnArr, int nSize)
2016-05-21 22:33:00那產品品質使用這種模式會下架嗎？因為都是衝出來的下降
作者:
NDark (溺於黑暗)
2016-05-21 22:34:00敏捷並不保證品質喔.
作者:
prag222 (prag)
2016-05-21 22:35:00跟主管提過了,問說不怕之後會有看不到的bug爆出來嗎我自己工作上都覺得這樣開發都抖抖得,但也說不定主管有默默的fix bug(?)
作者: uiceg 2016-05-21 22:51:00
會議時間太久了
作者:
Masakiad (Masaki)
2016-05-21 22:52:00主管壓時間的結果就是不管用不用scrum都是產出糟糕的產品而已......
作者:
prag222 (prag)
2016-05-21 22:53:00專案衝刺+每天時程壓力.....讓人受不了
作者:
Masakiad (Masaki)
2016-05-21 22:54:00而且scrum就是要所有人保持中立估算時間，主管沒理由的干涉就失去估算的意義
作者: hidog (.....) 2016-05-21 23:13:00
是因為台灣會把scrum作為壓榨勞力的作法而非提高生產力
作者:
GoalBased (Artificail Intelligence)
2016-05-21 23:17:00不適合就別用 你用一個library發現很難用很花時間你還不趕快換別套15秒的meeting還不如不開 用個群組講一下就好
作者:
NDark (溺於黑暗)
2016-05-21 23:21:00standup meeting其實有其精神及好處. 不是時間長才叫開會.敏捷有優缺點,不能因為缺點,而全盤否認它想要解決的問題.對於即時通訊軟體,我也可以說e-mail就能解決問題.
作者:
prag222 (prag)
2016-05-21 23:23:00我只看到16X 2.5=一個人一個月的工作量
作者:
NDark (溺於黑暗)
2016-05-21 23:24:00事實上e-mail,即時通訊,面對面的會議各有擅場及適用的時機.
作者:
prag222 (prag)
2016-05-21 23:26:00我想台灣不適合談軟工吧,這裡是台灣....
作者:
final01 (牛頓運動定律)
2016-05-21 23:46:00感覺是你們自己的問題吧??我覺得沒能力就不要學人家啊??學半套有啥用?
作者: manaup 2016-05-21 23:50:00
看起來八成像有daily meeting的waterfall。樓下你覺得呢?
作者:
oneheat (等待)
2016-05-21 23:50:00找些有經驗的人比較實在新創最愛看幾本書幾篇文章，然後搞一堆很無意義的東西
你們一組16個人太多了！可google「scrum people number」，建議是5～7人，不過我個人覺得兩三人的時候也挺不錯「sprint開兩三天，daily meeting 40分鐘」這很明顯就是沒有符合scrum的精神，你們有人在看書或看網站嗎？
作者:
Argos (Big doge is watching u)
2016-05-22 00:02:00敏捷開發神話不是早被戳破？
scrum是提升團隊透明度、向心力、降低溝通成本吧，和軟體品質是無關的東西，為什麼會覺得用scrum會產生品質不好的東西？理論上你要排測試的task進去，還有你開發要多少時間你就照實估那個task要多久，這樣下來怎麼會造成很趕或是軟體品質下降呢～sprint衝刺的意思是指，在為期兩到三週的sprint內，一起弄出一個workable feature，「整個團隊專心做好某件事」的那種衝刺感，可是未必要很趕。
作者:
prag222 (prag)
2016-05-22 00:14:00我想這種東西跟KPI有異曲同工之妙....
作者:
atst2 (atst2)
2016-05-22 00:19:00每個sprint結束應該要有檢討會議，原Po有在會議上反映這些事讓團隊知道嗎?團隊有每次做一些調整來改進scrum的執行嗎?
作者:
prag222 (prag)
2016-05-22 00:23:00團隊對問題的回應跟調整都太慢了....可能也是工作忙吧
retro應該是sprint結束後大家一起開會檢討、提出問題、想解法～是當下一起想解法啊～我覺得你們scrum應該是很多地方都跑歪了吧……看你有沒有影響力或說服力，讓整個團隊取消這樣的制度囉，這樣跑歪還不如不跑～另外在國外還有什麼scrum coach，公司都會請有證照的scrum coach(顧問)來導入scrum，從這點也許可以看出，跑scrum是有點難度吧……好像有很多眉角要注意。
作者:
siriusu (かがみは俺の嫁。)
2016-05-22 00:45:00推各位的討論與分享
作者:
prag222 (prag)
2016-05-22 00:55:00我想scrum還是有其專業性在吧...有興趣可參考Pro Agile .NET Development with Scrum要落實scrum還是要先kk書吧我在我公司完全沒聽過retro是啥...
作者:
dlikeayu (太陽拳vs野球拳)
2016-05-22 01:12:00sprint跟驗收標準是兩回事吧，不要混為一談基礎規範不說，有些公司PR要兩個人同意過，有些要四個人這些PR驗收後續動作有多少公司有做到？倒是反過來說公司人數不夠做短跑衝刺又要互相review這才比較是問題…
作者:
prag222 (prag)
2016-05-22 01:23:00回atst2:完全沒有檢討會議,我剛翻書才看到Sprint Retrosp
推 我也待過 把scrum當作是daily Waterful
作者:
GoalBased (Artificail Intelligence)
2016-05-22 02:02:00話說回來...你的狀況換公司應該比較有救
作者:
hicoy 2016-05-22 02:06:00貴公司跑的並不是scrum 只是很像而已...16個人開會根本是浪費時間 先拆成2~3個scrum
作者:
angusyu (〒△〒)
2016-05-22 02:45:00超討厭scrum，尤其是新創特愛拿來說嘴。最後還不是收攤，沒有比較強只讓RD很幹而已。不需要靠敏捷在那燃燒
作者:
Eos (美麗時光)
2016-05-22 02:59:00run過scrum, 結果最後花更多時間在修bugㄎ
沒retro還說是scrum XDScrum的流程最好是不要亂改啊
作者:
kingofsdtw (ä¸èƒ½é–’下來!!)
2016-05-22 06:52:00換公司…這樣產品我不敢用
作者: bab7171 2016-05-22 08:27:00
一個專這樣做可以，台灣是每個專案都這麼做
40min的daily meeting. 這應該有什麼誤會吧..
作者:
discoby (黑皮)
2016-05-22 08:57:00在台灣 有幾個說在玩敏捷的公司或團隊 有人敢大聲的說 主管或PM不曾試圖去影響RD決定每個task的開發時間的？每個案子都是由客戶或是主管或PM先決定好死線 才開始假裝玩敏捷的公司 滿地都是....
有些自以為在跑scrum，實際管理還是waterfall也沒什麼不好，有效率的開發最重要，怎麼run都可以整個sprint都在修bug也沒什麼不行,該花的時間就開task都跑scrum就是要把現實都呈現出來給整個團隊
作者:
EQQD (EQQD)
2016-05-22 10:15:0040 mins meeting 16人 planning meeting....你們還是多看點資訊再玩吧 跑scrum還在壓deadline 就...我不知道該說什麼了要做的是being Agile不是Doing Agile 台灣Scrum 跑起來跟waterfall有87%像 大概可以叫Waterscrum Scrum的功能是照妖鏡 因為團隊的透明讓你們可以發現問題的點在哪裡 但是Scrum絕對不會幫你解決問題 問題是你們團隊要自己解決的當你們發現了問題以後 要不要解決的決定權在你們手上你壓了Deadline, planning meeting還有任何意義？ 就跟瀑布流一樣給PM SA開就好 開什麼浪費時間的planning meeting?絕對不會有100%準確的開發辦法 前面的大大們都有提到 很多東西是你下去做才知道 因為sprint時間沒有到很長 所以可以修正調整
作者:
xevisu (大綠半糖少冰thx)
2016-05-22 10:26:00好假的敏捷～
作者:
Ekmund (是一隻小叔)
2016-05-22 11:14:00抱歉 我還是覺的每日會議很無意義進度可以寫表 有問題可以發群組 不可能每天都有狀況多到需要把所有人揪一起 更何況team越大個人變數越多 集合排會議室幹嘛的都佔時空資源 應該要視適性合理控制 而不是盲目照規矩sprint
作者:
maxqq (max)
2016-05-22 11:24:00Ek 大講的挺有道理，每日改成 slack 通知或許好很多
作者:
prag222 (prag)
2016-05-22 11:33:00開需求會議才是整個團隊,每日會議已改成小組但實際上班真的能做的工時 幾乎只有7hr之前有問過主管,sprint時間是不是有被縮短..因為感覺很趕實際上是一個sprint 2weeks塞了超過工作量的東西
作者:
prag222 (prag)
2016-05-22 11:38:00可是開發時間一樣是兩個禮拜沒有調整
作者: killmokom 2016-05-22 11:39:00
water-scrum-fall
作者: Ardy (endless rain) 2016-05-22 11:44:00
時間都是developer估的 包含UT跟整合測試 太趕下個sprint
作者:
nitero (nitero)
2016-05-22 12:06:00Scrum meeting 大概10~15分鐘就結束了主要是講自己遇到了什麼問題,
作者: beautyNeil 2016-05-22 12:08:00
你們那個根本不是scrum人數太多 開會時間過長 沒抓到精神 只學到招式
作者:
johnny94 (32767)
2016-05-22 12:48:00scrum 要 run 的先決條件就是團隊裡要有幾位資深經驗者，不是按照書上的指引就 run 的起來的
作者: KeySabre (KeySabreur) 2016-05-22 12:53:00
哪有daily開那麼久的 你們scrum master在睡覺嗎？
作者:
y3k (激流を制するは静水)
2016-05-22 13:16:00每天開會半個多小時 除非你們公司的RD性向都是開完會會元氣滿滿的那種 不然一定死得很難看(但是那種性向應該去當業務XD)
作者: dudu945 (低調的優雅) 2016-05-22 13:35:00
開會時間來拿開發還比較實在一點
作者:
M9722007 (nothing)
2016-05-22 16:37:00還遇過daily meeting 3小時的勒....
還有過開整天的...下班的時候回想：幹我今天做了啥XD
作者:
wuliou (wuliou)
2016-05-23 01:39:00這不就標準的假scrum
作者:
rexyeah (ccccccc)
2016-05-23 10:41:00scrum 40min是你們搞錯了吧..scrum不是討論用的..什麼叫導scrum... scrum只是agile的一個執行方式
作者:
f124 (....)
2016-05-23 10:57:00說的好聽叫scrum 說的難聽叫每天開會HL你
作者:
tsl3333 (我們都寂寞)
2016-05-23 11:36:00Daily meeting太久，重點 三大綱沒抓好。看板方法先行。理論不是適合每個團隊。可能中間有些流程要客製化。一步一步來。沒有人要你們一次登天
作者: TETZ (你今天宅了嗎?) 2016-05-24 03:45:00
假scrum吧 哪有人每天抓16人去開40min的會 說出去會被笑死
作者:
MysterySW (飯糰丸)
2016-05-24 09:15:00daily standup就講昨天做什麼今天要做什麼 是能講多久你們能開到40分鐘真不簡單我覺得scrum要在規模夠大時才有效果 幾十人小公司就還是waterfall就好
作者:
bndan (seed)
2016-05-24 18:18:00估工時不能老實(有外力) 隊伍能力參差不齊 這種團隊連合作能力都不一定有了 還想走敏捷開發 XD...scrum理論上人數不限 人多只是多切幾隊而已.但還是那句 隊員能力不能落差太大外 更重要的是 隊員必需是人 而不是其他的東西...然後外力介入就更不用講了 要玩一半的不如果直接用老方法跑稿不好還更穩 XD
作者: b9602003 2016-05-26 00:50:00
少一個真的懂scrum的master