隨著市場的瞬息萬變和軟件行業(yè)的迅猛發(fā)展，傳統(tǒng)的瀑布式軟件開發(fā)模型因其漫長的開發(fā)與反饋周期，在搶占市場先機和快速滿足用戶需求方面日漸失去競爭優(yōu)勢。與此同時，敏捷開發(fā)以其快速迭代，持續(xù)滿足不斷變化的用戶需求而受到越來越多人的重視。

雖說敏捷開發(fā)更加適合現(xiàn)代快速變化的軟件開發(fā)行業(yè)，但是想要真正貫徹敏捷思想卻非一件易事，在敏捷的實踐過程中有很多常見的誤區(qū)需要引起大家的注意。

協(xié)作就意味著更多的會議

開會，開會，開會！程序員最煩的就是開會，而敏捷開發(fā)的會議實在太多了：每日的站立會議，每個迭代開始前的需求討論會議，迭代開始時的計劃會議，迭代結束時的驗收會議，之后還有回顧會議，以及各種數(shù)不清的小范圍會議。通常一個迭代為期兩周，十個工作日，80個小時，這些會議就要占到20個小時以上，程序員哪還有時間寫代碼。更加討厭的是，代碼寫到一半被叫去開會，一下午都沒有效率可言了。

大家有這樣的感受，說到底還是沒有從思想上轉變過來。敏捷思想是一種深刻的文化變革，真正的敏捷需要團隊成員以及客戶之間及時的溝通與緊密協(xié)作。一味低著頭寫代碼，回頭才發(fā)現(xiàn)做出來的功能不是客戶想要的；又或者寫了半天前端代碼，才發(fā)現(xiàn)后臺的API已經變了，原來的參數(shù)都不能用了；又或者調查了半天的bug，第二天才知道整個功能都被刪除了；你不禁在心里怒吼：“為什么不早點告訴我？”而敏捷就是要通過及時頻繁的溝通，快速地對變化做出反應，將損失和風險降到最低。

完整的跨職能團隊就意味著很多人

理論上來講，一個完整的敏捷跨職能團隊應該具備完成業(yè)務目標的所有專業(yè)角色，包括：產品經理、前端開發(fā)人員、后臺開發(fā)人員、設計師、測試人員等等。各隊人馬加到一起必然形成一個龐大的團隊，規(guī)模如此龐大的團隊一起開會，分分鐘都是燒錢的感覺。

然而，敏捷開發(fā)雖然要求角色齊備，但在規(guī)模上應該有嚴格的控制，Scrum推薦的團隊規(guī)模在5-9人之間。這樣做目的在于：需要做出任何決策的時候，團隊可直接做決定，不需要請示領導，也不需要正式的會議，在工作桌旁找一個空地，或大家圍在白板前，一邊討論一邊做筆記，不會超過30分鐘就可做出決策，簡潔高效，而且團隊中的每個人都可以參與進來。

亞馬遜著名的兩個披薩原則，就是兩個披薩能夠吃飽的一個團隊規(guī)模。簡單來說，大概就是十來個人的團隊。只有在這樣的小團隊里面，成員最具有活力，摩擦也最小，溝通成本又最低。而這樣的一個團隊有獨立的自主能力，所以最能產生出創(chuàng)新。

項目經理應該發(fā)揮領導的作用

正如第2條所述，一個完整的敏捷跨職能團隊要求角色齊備，但各個專業(yè)角色上的人數(shù)卻有嚴格的控制，所謂一個蘿卜一個坑，有時甚至一個人負責多個角色（比如全棧開發(fā)人員），每個人都要負責好自己的專業(yè)領域。這是橫向的組織結構，并沒有層級。程序員不僅要寫好代碼，更重要的是與團隊人員溝通——分析和理解需求，討論解決方案，做好前后端以及其他接口，與測試人員分析和解決bug，向客戶演示并說明產品的使用方法等等。

而項目經理在團隊內的作用應該是協(xié)調和輔助，而不是上級對下級的領導。一個好的項目經理應該鼓勵程序員多多溝通，而不是做他們的“代言人”，更不能下達指示。哪怕對方是客戶或設計師，也應該由程序員與他們面對面的直接溝通，項目經理需要做的是幫他們聯(lián)系相關的人員或安排會議（更像助理的角色）；或者是在他們遇到困難時幫助他們獲得更多關注。

每日的站立會議是匯報工作

敏捷開發(fā)最簡單也最容易實施的莫過于每日的站立會議，但是人們往往把這個會議當成了工作匯報會議，這其實是一個嚴重的誤區(qū)。

一般，每日的站立會議包含三個問題：

• 昨天的工作內容；

• 今天的工作計劃；

• 遇到的困難。

實踐過程中常見的形式：

• 昨天的工作成果匯報（昨天我忙了一整天）；

• 今天的工作計劃（今天我也很忙）；

• 沒有困難（我只負責寫代碼）；或困難很多（抱怨……）。

然而，這個會議真正的目的是促進團隊之間的溝通：

• 昨天的工作內容：這個API我做完了（前端可以用了）；這個功能我做完了（測試可以開始了）；這個問題解決了（謝謝各位的幫助）；等等。

• 今天的工作計劃：今天我要做這個畫面（如果API有問題我可能會找后端開發(fā)）；今天我要做這個API（前端很快就能拿到了）；今天我要做這個測試（有問題可能會給你們bug票）；今天我要和客戶開會（可能需求或計劃會有變化）；等等。

• 困難：我的這個畫面在等API（后端你可能需要調整工作優(yōu)先順序或加快速度）；我的設計在等客戶反饋（你們可以先看看設計，但可能還會有變化）；我今天會聯(lián)系客戶（幫你問問那個問題）；等等。

這個短暫的會議應該更像一個小廣播，每個人都可以接收到與自己的工作相關的最新消息。同時在你遇到困難時，也可以通過這個小廣播引起所有人的注意。

完美的工作成果

每個人都希望將自己的工作做到盡善盡美，通過展示完美的工作成果贏得領導的贊賞和同事們的欽佩。然而，在敏捷開發(fā)流程中，由于種種因素限制，完美的工作成果幾乎不存在：

• 時間限制：通常每個迭代只有兩周的時間，這其中包括設計、開發(fā)和測試等所有工作。

• 需求的不完整：敏捷是在迭代循環(huán)中不斷改善和擴展的過程。項目初始，我們只需要構建最小可行性產品，然后在它的基礎上通過迭代不斷改善和擴展。

• 框架的不完備：在迅速開發(fā)的過程中，我們無法考慮周全每一種極端情況或邊緣用例，也無法一次性將所有可能用到的技術和框架都包含進來，只能在必要的時候一點點添加和完善。

• 無時無刻不在的變化：客戶的需求會變，技術也在不斷更新，敏捷旨在迅速對這些變化做出響應，我們必須以開放的心態(tài)，隨時迎接即將到來的變化。

除了受種種的因素制約之外，提前向別人展示未能盡善盡美的工作也會有意想不到的收獲。比如在你展示的過程中，有人注意到了某些問題并及時提供了反饋，這樣你就可以及時修正，從而減少返工。在與同事探討的過程中，也許你會想到更方便更省事的解決辦法。所以，團隊成員之間應該展開親密的合作，也許你走到同事的座位旁看一眼就能幫他發(fā)現(xiàn)一個bug呢。

另外，還需要注意一點：在種種因素的制約下，我們需要按照重要程度與緊急程度來劃分工作優(yōu)先級。相信大家都熟悉時間“四象限”，我們要利用有限的時間，為客戶提供最重要最緊急的功能。我知道這一點很難，但是我們都要學會放手不重要不緊急的工作，容忍“不完美”。

實施敏捷方法論就是向敏捷轉型

很多公司舉行每日的站立會議，以兩周的Sprint為迭代周期，再加上Jira等管理工具，就堂而皇之地說已成功轉型成了敏捷開發(fā)。然而仔細一看卻發(fā)現(xiàn)：在分任務的時候，有的用戶故事（user story）只有一個故事點（story point），而有的卻有十幾個（兩周的時間只有十個工作日！）；在定義需求的時候，一個頁面上有幾十個字段，也不管這些字段的重要性以及將來會不會使用，就與客戶挨個進行討論；在討論解決方案的時候，所有邊緣案例都要討論到，比如移動開發(fā)中考慮所有的設備類型；等等。種種跡象表明：他們本質上依然在遵循瀑布式開發(fā)流程！

這種形式主義根本無法貫徹敏捷的基本思想，結果只會適得其反，團隊成員在兩種模式的夾縫中束手束腳。

一個迭代周期內的工作不均衡

在軟件開發(fā)項目中，開發(fā)需要等設計，測試需要等開發(fā)，前端需要等后端，所以在迭代的頭幾天里，設計和后端忙的不可開交，前端和測試無所事事；而迭代的最后幾天，測試加班加點，設計無聊得發(fā)慌；所以大家常常抱怨工作不均衡。

其實，這只是因為大家還沒有完全擺脫瀑布式的階段開發(fā)流程。在敏捷開發(fā)中，設計必須以開發(fā)人員提出的解決方案為基礎，同時測試人員也必須明白客戶的原始需求（而不是根據(jù)設計“推測”）；API等接口定義應該是由前后端共同商議決定，而且在接口確定下來（必要的時候甚至可以由測試人員提供一份模擬數(shù)據(jù)）之后，前后端可以嘗試并行開發(fā)；測試人員寫完測試用例也應該分享給所有人，一則幫助開發(fā)人員思考用戶用例，也可以向設計師確認需求；在迭代快結束的時候，我想測試的bug票也夠開發(fā)人員（代碼bug）和設計師（設計bug）忙了。

總結

敏捷開發(fā)是企業(yè)的一次深刻的文化變革，我們要以客戶為中心，以滿足客戶的需求為最高原則，促進團隊成員的溝通與協(xié)作，增強團隊的自主性和靈活性，高效地應對一切變化。同時，我們也要合理地安排工作優(yōu)先級，按照輕重緩急，持續(xù)交付最重要最緊急的功能。