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

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

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

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

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

完整的跨職能團(tuán)隊(duì)就意味著很多人

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

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

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

項(xiàng)目經(jīng)理應(yīng)該發(fā)揮領(lǐng)導(dǎo)的作用

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

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

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

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

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

• 昨天的工作內(nèi)容；

• 今天的工作計劃；

• 遇到的困難。

實(shí)踐過程中常見的形式：

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

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

• 沒有困難（我只負(fù)責(zé)寫代碼）；或困難很多（抱怨……）。

然而，這個會議真正的目的是促進(jìn)團(tuán)隊(duì)之間的溝通：

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

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

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

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

完美的工作成果

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

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

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

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

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

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

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

實(shí)施敏捷方法論就是向敏捷轉(zhuǎn)型

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

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

一個迭代周期內(nèi)的工作不均衡

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

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

總結(jié)

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