互聯(lián)網(wǎng)的產(chǎn)品大都是面向海量用戶的服務(wù)，且用戶分布區(qū)域廣泛，其教育水平、習(xí)慣也大多不同，具有高度不確定性，我們必須非常關(guān)注用戶的行為和反饋。因而，在互聯(lián)網(wǎng)產(chǎn)品服務(wù)的整個用戶研究，需求分析、產(chǎn)品研發(fā)及交付服務(wù)的過程中，都采用探索式、適應(yīng)性的研發(fā)理念進(jìn)行產(chǎn)品的研發(fā)。通常，會把整個產(chǎn)品研發(fā)周期劃分為若干個迭代，采用迭代式的演進(jìn)過程，不斷的去交付新的產(chǎn)品特性，并通過觀察用戶的行為和反饋獲取，進(jìn)而隨時調(diào)整產(chǎn)品的思路和方向。一切以用戶價值為核心是互聯(lián)網(wǎng)產(chǎn)品最核心的特點，而以價值驅(qū)動的敏捷開發(fā)方法非常符合這一特點。

從阿里軟件開始，內(nèi)貿(mào)團(tuán)隊就一直在實行著敏捷項目管理實踐，通過小步快跑，快速迭代、增量交付用戶價值，不斷獲取用戶反饋，持續(xù)、快速的調(diào)整產(chǎn)品，驗證并適合用戶價值。正是通過這些實踐活動，我們以迭代的、增量的交付用戶價值，最大限度的保證產(chǎn)品朝著符合用戶實際需求方向發(fā)展。目前，在內(nèi)貿(mào)團(tuán)隊?wèi)?yīng)用較成熟的敏捷實踐活動有：

1)、迭代計劃(Sprint Planning Meeting)

2)、每日晨會(Daily Scrum Meeting) & 任務(wù)墻(Task Wall)

3)、功能預(yù)演(Spring Review)

4)、項目總結(jié)(Retrospect Meeting)

5)、結(jié)對編程(Pair Programming)

6)、其他技術(shù)實踐活動等

 二、敏捷團(tuán)隊

１)、自組織文化

如google、facebook等互聯(lián)網(wǎng)企業(yè)，他們很少甚至沒有特定的項目流程，通常怎么敏捷怎么做，具有濃厚的工程師驅(qū)動文化。我們則有較完整的開發(fā)流程指導(dǎo)和規(guī)范我們的項目研發(fā)工作，相比而言，喪失了一些靈活性和積極性，不利于我們工程師自我管理、自我驅(qū)動意識的培養(yǎng)。臃腫、缺乏靈活性的流程同互聯(lián)網(wǎng)產(chǎn)品快速更新、快速發(fā)展是不相適應(yīng)的，同時也弱化我們的責(zé)任心意識。除了遵守詳盡的流程，我們是否可以換個角度、換種方法，提倡和營造一種自我管理、自我驅(qū)動的開發(fā)文化，省卻一些并不能給我們帶來幫助卻影響效率的流程呢？

敏捷團(tuán)隊的自組織特性弱化了團(tuán)隊技術(shù)領(lǐng)導(dǎo)這個角色，強(qiáng)調(diào)自我管理和自我驅(qū)動。雖然這對工程師的素質(zhì)要求更高，相對技術(shù)能力更難提高。但是，團(tuán)隊導(dǎo)向很重要，我們努力營造這樣的氛圍，從小團(tuán)隊做起，逐漸鍛煉和培養(yǎng)自組織團(tuán)隊。相信在這樣的開發(fā)氛圍下，會讓我們做的更高效、更敏捷，可以走的更穩(wěn)、更遠(yuǎn)。

２）、追求一體化

一體化團(tuán)隊作為敏捷開發(fā)方法中最具精益思想基因的實踐，是指每個項目團(tuán)隊包括分析，開發(fā)，測試等角色，使團(tuán)隊滿足一個需求從設(shè)計，開發(fā)到測試各個階段順利完成，達(dá)到符合質(zhì)量標(biāo)準(zhǔn)并滿足需求的軟件。這種以項目/產(chǎn)品為單位的虛擬團(tuán)隊，坐在一起，全身心的為共同的目標(biāo)而努力，可以更好的凝聚項目組中的各種角色，消除部門墻。 

 3）、追求全功能

這里所指的全功能是希望項目團(tuán)隊能打破工程師角色之間的邊界，如研發(fā)、測試和前端工程師的界線，消除開發(fā)、測試流程中一些潛在浪費(fèi)，提高效率。在項目團(tuán)隊內(nèi)部通過角色互換，不限角色的結(jié)對工作，加強(qiáng)不同角色，不同模塊間的知識傳遞，打破技術(shù)壁壘，幫助員工從不同視角理解項目，鍛煉技能，進(jìn)而增加團(tuán)隊均衡生產(chǎn)的能力。

為什么要提倡打破邊界？項目整體效率依賴于項目過程中各環(huán)節(jié)的工作效率，而整體效率的優(yōu)化往往依賴于均衡生產(chǎn)(精益思想的按需生產(chǎn))，即消除生產(chǎn)的波峰(過度生產(chǎn))和波谷(生產(chǎn)不足)，只有局部效率的增加無法直接轉(zhuǎn)換為整體效率的增加(就象桶能裝多少水，決定于最短的那塊板)。整體效率的優(yōu)化要求IT團(tuán)隊消除技能壁壘，培養(yǎng)多面手，根據(jù)計劃的的變動，彈性地調(diào)整任務(wù)，達(dá)到各角色和流程之間的平衡。

三、質(zhì)量保證

我們追求開發(fā)效率，同時也注重項目質(zhì)量。如何去保證質(zhì)量？就象美國的一位教授愛德化.戴明（W.Edwards Deming）所說：“我們應(yīng)該停止依靠大量檢驗來保證質(zhì)量，而是要改進(jìn)工藝流程，從一開始就生產(chǎn)出優(yōu)質(zhì)的產(chǎn)品”。我們要在整個開發(fā)過程中多個環(huán)節(jié)去保證質(zhì)量。同時，質(zhì)量保證是整個團(tuán)隊的責(zé)任，就如同前面所說的追求全功能團(tuán)隊，打破邊界。

至于在哪些環(huán)節(jié)采用哪些實踐，我們先做個分類，按是否能被系統(tǒng)用戶感知將質(zhì)量問題區(qū)分內(nèi)部質(zhì)量和外部質(zhì)量。外部質(zhì)量指能直接被系統(tǒng)用戶感知，如運(yùn)行緩慢，不可操作或是操作復(fù)雜就屬于外部質(zhì)量低劣。而不能直接為系統(tǒng)用戶所直接感知的要素，對產(chǎn)品鍵壯性、可維護(hù)性有深遠(yuǎn)影響的問題就屬于外部質(zhì)量，如系統(tǒng)設(shè)計的一致性、代碼可讀性、邏輯完整性等。內(nèi)部質(zhì)量對用戶的影響比較間接，但比外部質(zhì)量意義更深遠(yuǎn)。一般來說，系統(tǒng)內(nèi)部質(zhì)量優(yōu)秀，外部質(zhì)量仍有可能很差。而內(nèi)部質(zhì)量差的系統(tǒng)，外部質(zhì)量肯定也不怎么樣。

1）、外部質(zhì)量保證

在外部質(zhì)量保證上，大部分會在開發(fā)后期介入，可以通過性能測試、自動化測試及工程師的功能測試來保證，通過這些實踐活動發(fā)現(xiàn)并保證例如運(yùn)行緩慢、不可操作等質(zhì)量問題不會存在。針對交互特別復(fù)雜的web應(yīng)用，可以更多的考慮采用webui自動化測試工具，如selenium、pwaitr(b2b)、automan(淘寶)等，可以很好的完成那些簡單、重復(fù)的TC用例，可以大大提高測試效率，解決測試工程師的資源瓶頸。

2)、內(nèi)部質(zhì)量保證

相對于外部質(zhì)量，內(nèi)部質(zhì)量問題影響更為深遠(yuǎn)，在開發(fā)開始階段就應(yīng)該去保證。如通過單元測試、靜態(tài)代碼掃描(PMD\findbugs)、持續(xù)集成、重構(gòu)、結(jié)對編程、code review等多種實踐活動來保證項目代碼的健康。

除了一些實踐活動去檢查代碼質(zhì)量外，更為重要的是研發(fā)工程師對內(nèi)部質(zhì)量的重視，如果工程師沒有形成良好的質(zhì)量意識，很可能這些實踐也只是停留于形式，并不能帶來較好的結(jié)果。如我們在開發(fā)過程中的編碼規(guī)范、單元測試的質(zhì)量及覆蓋率，code review的及時性及問題是否持續(xù)跟進(jìn)等等。此外，有選擇的采用結(jié)對編程實踐，有助于質(zhì)量的提高。