世界上沒有銀色子彈
劇透警告
對於軟體專案管理方法，始終沒這麼引起我的興趣。畢竟第一線研發工程師的日常，忙著找解法和實作程式碼才是工作重心，至於專案範圍、時程主要還是讓專案經理煩心。然而最近怡好參與一個採用Scrum管理方法的新專案，一開始難免一頭霧水進退失據，想來只好反求諸己，拿這本敏捷與Scrum軟體開發速成來補補知識量，以便更快調整好步調完成任務。
愛書人總會被書所關照，隨意挑選的一本Scrum著作，出乎意料地是言簡意賅的精典作品。有別於瀑布流程將軟體開發劃分成需求收集、設計、編寫程式和測試，採用一切都得事前設計的思維(BDUF-Big Design Up Front)。敏捷開發則是主張漸進的累積，以一點點的需求收集、一點點的設計、一點點的編寫程式和交付一點點的價值貫穿整個專案。敏捷價值觀如下:
個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商
回應變化 重於 遵循計畫
不過理想很豐滿，現實很骨感，這種顛覆傳統的專案管理手法，前提必定要出資者理解與採用，不然若是瀑布思維的客戶遇到敏捷思維的開發團隊，雙方對做完了的定義完全不同，肯定會導致衝突與齟齬。
在Scrum團隊成員分成三類角色，代表客戶提出需求與排定優先順序的產品負責人，主導Scrum流程與會議的Scrum教練，以及實際從事開發任務的團體成員。三個角色各司其職卻又要充分的協同作業以獲得團隊共識。由於敏捷開發與瀑布法的差異甚多，如果團隊成員沒被明確告知各個角色之間的責任，將會出現不可預測的管理風險。最明顯的例子就是在瀑布法位於最未端的測試，在改敏捷開發時必須融入在每個小週期內完成，甚至是連系統開發文件也被包含在一點點的設計工作裡。也因此採用敏捷開發的團隊多半也樂於懷抱測試驅動開發的程式撰寫流程。
敏捷與Scrum軟體開發速成是本值得一看的佳作，特別是想瞭解Scrum管理的獨特之處。然而這些理論與觀念，如何真正促成專案的成功，最終的變數還是執行的Scrum團隊成員。這也是Scrum管理沒有明確聲明的前提，團隊成員必須擁有相當程度的實務經驗與技術能力，因為產品負責人只負責提出客戶需求，要怎麼如質如實地打造出堅若磐石的軟體，反而是由團隊成員主動反饋、規劃和實作。軟體開發的道路上，不論是管理手法或是技術架構，本來就沒有可以一勞永逸地適應各種場合的解決方案。如果以為敏捷開發是可以確保專案開發神功護體的銀色子彈，那可誤會大了。
天天爆殺 
今日66折 
博客來
博客來
博客來
博客來
博客來
常見問題
線上客服
客服信箱
