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

看板Soft_Job (軟體人)作者cactus1021 (我要撞飛一切)時間9年前 (2016/05/25 11:35)推噓1(1推 0噓 5→)

留言6則, 2人參與討論串10/10 (看更多)

個人自己帶過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。當團隊可以在把事情說清楚、指定好負責人、著名限辦期限，事情能自動完成，代表已經上了軌道。 [結語] 看法也許有誤，歡迎提出指教討論。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.136.249.37 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1464147305.A.047.html ※ 編輯: cactus1021 (114.136.249.37), 05/25/2016 11:45:57