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

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

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

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

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

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

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

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

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

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

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

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

每日的站立會(huì)議是匯報(bào)工作

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

一般，每日的站立會(huì)議包含三個(gè)問題：

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

• 今天的工作計(jì)劃；

• 遇到的困難。

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

• 昨天的工作成果匯報(bào)（昨天我忙了一整天）；

• 今天的工作計(jì)劃（今天我也很忙）；

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

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

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

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

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

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

完美的工作成果

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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