軟件工程一直是個很有趣的領域，相關工程論從早期的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可以節省開發時程
