個人自己帶過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。當團隊可以在把事情說清楚
、指定好負責人、著名限辦期限，事情能自動完成，代表已經上了軌道。
[結語]
看法也許有誤，歡迎提出指教討論。