Re: [請益] 主管工時都估太短

作者: cactus1021 (我要撞飛一切)   2016-05-25 11:35:01
個人自己帶過SCRUM,也跟過其他人帶的,
只能說不管是被帶(凹工時)、還是帶人(自己要事先準備很多東西),
都是很辛苦的@@
(謎之音:好像也有不辛苦就能帶SCRUM的人,那我保證辛苦的就是被你帶的人...)
(謎之音:好像也有不辛苦就能帶SCRUM的人,那我保證辛苦的就是被你帶的人...)
(謎之音:好像也有不辛苦就能帶SCRUM的人,那我保證辛苦的就是被你帶的人...)
但因為公司文化,我必須調整SCRUM框架預設的運作模式,求融入既有制度,
以下分享個人帶SCRUM(九人團隊)看到的一些現況
原文傳送門:http://sean666666.blogspot.tw/2015/05/scrum-mythos.html
[前言]
敏捷式開發不是軟工方法,敏捷只是一種心理狀態的描述、一種工作環境的意
念,如果公司文化沒有敏捷的意圖或是想法存在,導入任何方法都沒有用。
那SCRUM又是什麼,假如敏捷開發是個數學的應用問題,那SCRUM就是一套或許可以解
決問題的公式,SCRUM只是一套方法、一種作業方式、一種運作模式、一種流程,SCRUM不
是萬靈丹、SCRUM不是萬靈丹、SCRUM不是萬靈丹,因為很重要,所以要講三次。
[迷思一:有了SCRUM就不用寫文件]
一言以蔽之:SCRUM是利用大量的溝通、許多的定期會議取代文件撰寫,所以在時程上並
不會大量減少耗費人時,因為這是一種挖東牆補西牆的概念。但好處是因為溝通頻率高,
各角色間的思考誤解會有效減少,避免各說各話。
CMMI最令人詬病的就是那一拖拉庫的文件,從肥滋滋的客戶拿著錢需求來找你開始,
一直到開發完成、測試完成,全部都是一連串的交付文件,包含每個月研發團隊開的會也
要記錄,所以CMMI常常被罵到臭頭的都是這件事情。但用了SCRUM之後,難道就真的可以
避開這些阿雜的事情嗎?
CMMI設定的SA、SD、PG、Tester便缺少了文字依循,所以SCRUM放入了幾項元素:會
議(快速、經常性的)、User Story。
因應軟體開發這種腦力高度集中的產業,資訊需要快速交流、有效溝通,SCRUM的模
型裡面針對溝通部分導入大量的會議,包含Daily standing meeting、Sprint
retrospective meeting、DEMO meeting...
所有的SCRUM教科書都說Daily standing meeting是一種每天要所有團隊成員以站立
的方式開一個10 - 15分鐘的會,那這個會要幹什麼,一言以蔽之就是要資訊通透,會議
中要求每個人只要說明前一天做了什麼、今天要做什麼、遇到什麼問題需要協助...
你真的以為會議都會在15分鐘內就結束嗎?
除非你真是個非常有經驗Scrum Master相當會掌握會議僅度 or 技術能力很強可以理
解每個成員想要表達的事情,一個理想的Daily standing meeting執行上其實不簡單,提
供個人經驗分享。
此外Retrospective meeting一定要把會議討論的重點跟調整方向記錄下來,口說無
憑、時過境遷,很多事情不寫下來或是當下沒有決議,進度檢討流於空談。這種會議文件
也不需要長篇大論,基本上就是一張A4就綽綽有餘,紀載會議時間、與會人員、決議事項
、待辦事項(包含人、事、時)即可。
[迷思二:SCRUM可以節省開發時程]
一言以蔽之:SCRUM無法減少研發時程,但有其它很棒的效益。
SCRUM在每個Sprint會訂立這次的衝刺的目標,團隊成員將PO寫User story根據優先
權認領工作,然後開始執行,反覆衝刺。問題來了,如果User story規劃的不好,可能一
個衝刺做不完、或是開發完根本無法整測、或是問題根本無解,這就跟導不導入SCRUM一
點關係都沒有了,而是需求規劃、程式架構有問題,導致所有的工作根本沒有辦法系統性
規劃在一次次的SCRUM時程衝刺完畢。
以上的問題可能會發生在一個運作好幾年的大型研發團隊,因為專案研發常常delay
所以想訴諸新的軟體工程方法來解決。
那你會問:"為什麼我要導入SCRUM?這樣我到底哪裡敏捷了?"
SCRUM能帶給你的是一個自主型團隊,一個擁有獨立思考、無痛抽換成員、增加成員
後人時可以是線性成長,不用浪費在一堆無效溝通且沒有固定release的產出,快速且定
期給客戶檢視成果,快速走向市場驗證你的商業模式。
[迷思三:SCRUM的角色不能變動或重疊]
一言以蔽之:請依照組織與文化調整你的SCRUM團隊。
依個人帶領團隊的經驗,人不多但事情又多又雜,加上核心程式碼算是撿屍繼承來的
,所以我沒有辦法很乾淨導入夢想中的敏捷方法,例如code review、continuous
integration、pair programming、auto testing...
SCRUM也有提到PO、SM必須是不同角色,老實說這在我的團隊根本不可能達成,因為
人力完全不足。考量開發人力、測試人力、程式碼版控、PM、寫報告...多樣角色,我思
考很久,就是忍痛把PM/PO/SM/寫報告全部往身上扛,把測試依據功能性來界定範圍盡量
平均分分到各成員身上,再來就是把開發工作用SCRUM每兩週一次方式來定期追蹤。
初期團隊每天都執行Daily standing meeting,直到個人覺得團隊上了軌道(差不多
半年),我就只定期兩週開retrospective + DEMO meeting。當團隊可以在把事情說清楚
、指定好負責人、著名限辦期限,事情能自動完成,代表已經上了軌道。
[結語]
看法也許有誤,歡迎提出指教討論。
作者: goldduck (哥達鴨)   2016-05-25 16:34:00
事情能解決最重要 哪種方法只是工具
作者: leicheong (睡魔)   2016-05-26 23:24:00
這沒甚麼. 我都在要去茶水間(通常代表工作完成到某一段落或工作不順利需要放鬆一下再繼續)的時候才順便報告進度, 一天不會花多於30秒時間在這上SA還是可以清楚我在做甚麼.有些事情大家都認同該這樣的話, 不必死跟規條更有效率

Links booklink

Contact Us: admin [ a t ] ucptt.com