隨著市場的瞬息萬變和軟件行業的迅猛發展，傳統的瀑布式軟件開發模型因其漫長的開發與反饋週期，在搶佔市場先機和快速滿足用戶需求方面日漸失去競爭優勢。與此同時，敏捷開發以其快速迭代，持續滿足不斷變化的用戶需求而受到越來越多人的重視。
雖說敏捷開發更加適合現代快速變化的軟件開發行業，但是想要真正貫徹敏捷思想卻非一件易事，在敏捷的實踐過程中有很多常見的誤區需要引起大家的注意。
協作就意味著更多的會議
開會，開會，開會！程序員最煩的就是開會，而敏捷開發的會議實在太多了：每日的站立會議，每個迭代開始前的需求討論會議，迭代開始時的計劃會議，迭代結束時的驗收會議，之後還有回顧會議，以及各種數不清的小範圍會議。通常一個迭代為期兩週，十個工作日，80個小時，這些會議就要佔到20個小時以上，程序員哪還有時間寫代碼。更加討厭的是，代碼寫到一半被叫去開會，一下午都沒有效率可言了。
大家有這樣的感受，說到底還是沒有從思想上轉變過來。敏捷思想是一種深刻的文化變革，真正的敏捷需要團隊成員以及客戶之間及時的溝通與緊密協作。一味低著頭寫代碼，回頭才發現做出來的功能不是客戶想要的；又或者寫了半天前端代碼，才發現後臺的API已經變了，原來的參數都不能用了；又或者調查了半天的bug，第二天才知道整個功能都被刪除了；你不禁在心裡怒吼：“為什麼不早點告訴我？”而敏捷就是要通過及時頻繁的溝通，快速地對變化做出反應，將損失和風險降到最低。
完整的跨職能團隊就意味著很多人
理論上來講，一個完整的敏捷跨職能團隊應該具備完成業務目標的所有專業角色，包括：產品經理、前端開發人員、後臺開發人員、設計師、測試人員等等。各隊人馬加到一起必然形成一個龐大的團隊，規模如此龐大的團隊一起開會，分分鐘都是燒錢的感覺。
然而，敏捷開發雖然要求角色齊備，但在規模上應該有嚴格的控制，Scrum推薦的團隊規模在5-9人之間。這樣做目的在於：需要做出任何決策的時候，團隊可直接做決定，不需要請示領導，也不需要正式的會議，在工作桌旁找一個空地，或大家圍在白板前，一邊討論一邊做筆記，不會超過30分鐘就可做出決策，簡潔高效，而且團隊中的每個人都可以參與進來。
亞馬遜著名的兩個披薩原則，就是兩個披薩能夠吃飽的一個團隊規模。簡單來說，大概就是十來個人的團隊。只有在這樣的小團隊裡面，成員最具有活力，摩擦也最小，溝通成本又最低。而這樣的一個團隊有獨立的自主能力，所以最能產生出創新。
項目經理應該發揮領導的作用
正如第2條所述，一個完整的敏捷跨職能團隊要求角色齊備，但各個專業角色上的人數卻有嚴格的控制，所謂一個蘿蔔一個坑，有時甚至一個人負責多個角色（比如全棧開發人員），每個人都要負責好自己的專業領域。這是橫向的組織結構，並沒有層級。程序員不僅要寫好代碼，更重要的是與團隊人員溝通——分析和理解需求，討論解決方案，做好前後端以及其他接口，與測試人員分析和解決bug，向客戶演示並說明產品的使用方法等等。
而項目經理在團隊內的作用應該是協調和輔助，而不是上級對下級的領導。一個好的項目經理應該鼓勵程序員多多溝通，而不是做他們的“代言人”，更不能下達指示。哪怕對方是客戶或設計師，也應該由程序員與他們面對面的直接溝通，項目經理需要做的是幫他們聯繫相關的人員或安排會議（更像助理的角色）；或者是在他們遇到困難時幫助他們獲得更多關注。
每日的站立會議是彙報工作
敏捷開發最簡單也最容易實施的莫過於每日的站立會議，但是人們往往把這個會議當成了工作彙報會議，這其實是一個嚴重的誤區。
一般，每日的站立會議包含三個問題：
昨天的工作內容；
今天的工作計劃；
遇到的困難。
實踐過程中常見的形式：
昨天的工作成果彙報（昨天我忙了一整天）；
今天的工作計劃（今天我也很忙）；
沒有困難（我只負責寫代碼）；或困難很多（抱怨……）。
然而，這個會議真正的目的是促進團隊之間的溝通：
昨天的工作內容：這個API我做完了（前端可以用了）；這個功能我做完了（測試可以開始了）；這個問題解決了（謝謝各位的幫助）；等等。
今天的工作計劃：今天我要做這個畫面（如果API有問題我可能會找後端開發）；今天我要做這個API（前端很快就能拿到了）；今天我要做這個測試（有問題可能會給你們bug票）；今天我要和客戶開會（可能需求或計劃會有變化）；等等。
困難：我的這個畫面在等API（後端你可能需要調整工作優先順序或加快速度）；我的設計在等客戶反饋（你們可以先看看設計，但可能還會有變化）；我今天會聯繫客戶（幫你問問那個問題）；等等。
這個短暫的會議應該更像一個小廣播，每個人都可以接收到與自己的工作相關的最新消息。同時在你遇到困難時，也可以通過這個小廣播引起所有人的注意。
完美的工作成果
每個人都希望將自己的工作做到盡善盡美，通過展示完美的工作成果贏得領導的讚賞和同事們的欽佩。然而，在敏捷開發流程中，由於種種因素限制，完美的工作成果幾乎不存在：
時間限制：通常每個迭代只有兩週的時間，這其中包括設計、開發和測試等所有工作。
需求的不完整：敏捷是在迭代循環中不斷改善和擴展的過程。項目初始，我們只需要構建最小可行性產品，然後在它的基礎上通過迭代不斷改善和擴展。
框架的不完備：在迅速開發的過程中，我們無法考慮周全每一種極端情況或邊緣用例，也無法一次性將所有可能用到的技術和框架都包含進來，只能在必要的時候一點點添加和完善。
無時無刻不在的變化：客戶的需求會變，技術也在不斷更新，敏捷旨在迅速對這些變化做出響應，我們必須以開放的心態，隨時迎接即將到來的變化。
除了受種種的因素制約之外，提前向別人展示未能盡善盡美的工作也會有意想不到的收穫。比如在你展示的過程中，有人注意到了某些問題並及時提供了反饋，這樣你就可以及時修正，從而減少返工。在與同事探討的過程中，也許你會想到更方便更省事的解決辦法。所以，團隊成員之間應該展開親密的合作，也許你走到同事的座位旁看一眼就能幫他發現一個bug呢。
另外，還需要注意一點：在種種因素的制約下，我們需要按照重要程度與緊急程度來劃分工作優先級。相信大家都熟悉時間“四象限”，我們要利用有限的時間，為客戶提供最重要最緊急的功能。我知道這一點很難，但是我們都要學會放手不重要不緊急的工作，容忍“不完美”。
實施敏捷方法論就是向敏捷轉型
很多公司舉行每日的站立會議，以兩週的Sprint為迭代週期，再加上Jira等管理工具，就堂而皇之地說已成功轉型成了敏捷開發。然而仔細一看卻發現：在分任務的時候，有的用戶故事（user story）只有一個故事點（story point），而有的卻有十幾個（兩週的時間只有十個工作日！）；在定義需求的時候，一個頁面上有幾十個字段，也不管這些字段的重要性以及將來會不會使用，就與客戶挨個進行討論；在討論解決方案的時候，所有邊緣案例都要討論到，比如移動開發中考慮所有的設備類型；等等。種種跡象表明：他們本質上依然在遵循瀑布式開發流程！
這種形式主義根本無法貫徹敏捷的基本思想，結果只會適得其反，團隊成員在兩種模式的夾縫中束手束腳。
一個迭代週期內的工作不均衡
在軟件開發項目中，開發需要等設計，測試需要等開發，前端需要等後端，所以在迭代的頭幾天裡，設計和後端忙的不可開交，前端和測試無所事事；而迭代的最後幾天，測試加班加點，設計無聊得發慌；所以大家常常抱怨工作不均衡。
其實，這只是因為大家還沒有完全擺脫瀑布式的階段開發流程。在敏捷開發中，設計必須以開發人員提出的解決方案為基礎，同時測試人員也必須明白客戶的原始需求（而不是根據設計“推測”）；API等接口定義應該是由前後端共同商議決定，而且在接口確定下來（必要的時候甚至可以由測試人員提供一份模擬數據）之後，前後端可以嘗試並行開發；測試人員寫完測試用例也應該分享給所有人，一則幫助開發人員思考用戶用例，也可以向設計師確認需求；在迭代快結束的時候，我想測試的bug票也夠開發人員（代碼bug）和設計師（設計bug）忙了。
總結
敏捷開發是企業的一次深刻的文化變革，我們要以客戶為中心，以滿足客戶的需求為最高原則，促進團隊成員的溝通與協作，增強團隊的自主性和靈活性，高效地應對一切變化。同時，我們也要合理地安排工作優先級，按照輕重緩急，持續交付最重要最緊急的功能。
閱讀更多 科技風雲會 的文章
