軟件工程一直是個很有趣的領域，相關工程論從早期的CMMI、到近年流行(其實也不是近幾年，在台灣已經有聽到2005年就開始執行的專案)的敏捷(AGILE)開發，由於CMMI繁瑣的文件要求、瀑布式開發都讓人直覺認為執行一個專案最起碼要數月、半年、好幾年的時間，所以應運而生敏捷開發這個名詞，相關最著名的方法論為SCRUM，不小心這個方法個人帶的團隊有執行過；以下來探討一下人們對敏捷開發的迷思。
再次強調，敏捷式開發不是軟工方法，敏捷只是一種心理狀態的描述、一種工作環境的意念，如果公司文化沒有敏捷的意圖或是想法存在，導入任何方法都沒有用。
那SCRUM又是什麼，假如敏捷開發是個數學的應用問題，那SCRUM就是一套或許可以解決問題的公式，SCRUM只是一套方法、一種作業方式、一種運作模式、一種流程，SCRUM不是萬靈丹、SCRUM不是萬靈丹、SCRUM不是萬靈丹，因為很重要，所以要講三次。
迷思一：有了SCRUM就不用寫文件
一言以蔽之：SCRUM是利用大量的溝通、許多的定期會議取代文件撰寫，所以在時程上並不會大量減少耗費人時，因為這是一種挖東牆補西牆的概念。但好處是因為溝通頻率高，各角色間的思考誤解會有效減少，避免各說各話。CMMI最令人詬病的就是那一拖拉庫的文件，從
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在每個Sprint會訂立這次的衝刺的目標，團隊成員將PO寫User story根據優先權認領工作，然後開始執行，反覆衝刺。問題來了，如果User story規劃的不好，可能一個衝刺做不完、或是開發完根本無法整測、或是問題根本無解，這就跟導不導入SCRUM一點關係都沒有了，而是需求規劃、程式架構有問題，導致所有的工作根本沒有辦法系統性規劃在一次次的SCRUM時程衝刺完畢。
以上的問題可能會發生在一個運作好幾年的大型研發團隊，因為專案研發常常delay所以想訴諸新的軟體工程方法來解決。
那你會問："為什麼我要導入SCRUM？這樣我到底哪裡敏捷了？"
SCRUM能帶給你的是一個自主型團隊，一個擁有獨立思考、無痛抽換成員、增加成員後人時可以是線性成長，不用浪費在一堆無效溝通且沒有固定release的產出，快速且定期給客戶檢視成果，快速走向市場驗證你的商業模式。
迷思三：SCRUM的角色不能變動或重疊
一言以蔽之：請依照組織與文化調整你的SCRUM團隊。依個人帶領團隊的經驗，人不多但事情又多又雜，加上核心程式碼算是
SCRUM也有提到PO、SM必須是不同角色，老實說這在我的團隊根本不可能達成，因為人力完全不足。考量開發人力、測試人力、程式碼版控、PM、寫報告...多樣角色，我思考很久，就是忍痛把PM/PO/SM/寫報告全部往身上扛，把測試依據功能性來界定範圍盡量平均分分到各成員身上，再來就是把開發工作用SCRUM每兩週一次方式來定期追蹤。
初期團隊每天都執行Daily standing meeting，直到個人覺得團隊上了軌道(差不多半年)，我就只定期兩週開retrospective + DEMO meeting。當團隊可以在把事情說清楚、指定好負責人、著名限辦期限，事情能自動完成，代表已經上了軌道。
沒有留言:
張貼留言