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

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

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

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

3)、功能預演(Spring Review)

4)、項目總結(Retrospect Meeting)

5)、結對編程(Pair Programming)

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

 二、敏捷團隊

１)、自組織文化

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

敏捷團隊的自組織特性弱化了團隊技術領導這個角色，強調自我管理和自我驅動。雖然這對工程師的素質要求更高，相對技術能力更難提高。但是，團隊導向很重要，我們努力營造這樣的氛圍，從小團隊做起，逐漸鍛煉和培養自組織團隊。相信在這樣的開發氛圍下，會讓我們做的更高效、更敏捷，可以走的更穩、更遠。

２）、追求一體化

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

 3）、追求全功能

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

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

三、質量保證

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

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

1）、外部質量保證

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

2)、內部質量保證

相對于外部質量，內部質量問題影響更為深遠，在開發開始階段就應該去保證。如通過單元測試、靜態代碼掃描(PMD\findbugs)、持續集成、重構、結對編程、code review等多種實踐活動來保證項目代碼的健康。

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

以下為本人在公司內部關于項目質量和工作效率郵件回復的一此意見和想法。

1、 談流程

不可否認流程的重要性，但我們需要根據具合格情況分析，不斷的梳理和優化我們的流程，讓流程更好的指導我們工作，而不是束縛。目前，我們的流程慢慢多了起來，感覺不如以前敏捷了。經過rpm改造后，無論在測試環節還是發布階段，較之前失去了很大的靈活性。測試階段，開發bugfix后想在測試環境驗證，每次必須重走aone的流程及打包布署，相比之前的build效率真的差了好多。當然，也許是我們項目組對這個流程熟練度、方法還不夠，很多環節有待改進。

發布階段，目前統一由SCM來發布，必然會導致開發對線上環境及發流程更加陌生，同我們提倡的打破邊界，敏捷響應有些相背。再者，SCM資源有限的原因，要支持ITU眾多產品線，能否應付的過來，始終是個問題。發布統一管理有好處，同樣也帶來了弊端，ITU不同于網站，大多數的技術團隊共同在維護在幾個應用，而itu的應用多、規模相對小、環境各異，這樣的產品線采用統一管理性價比不高。希望相應的owner，能不定期的搜集各產品線的意見和反饋，不斷的優化，讓我們的流程更合理。

2、 談自測

我們團隊一直在強調自測意識，也在這方面不斷的總結和改進。我覺的要提高自測，首先應讓每位開發同學形成較好的自測意識，而不是自上而下的命令式管理，只有自己有這方面的意，才會去思考、去想辦法，去實踐。再者，需要PM或技術經理去思考，目前階段實行自測會有什么困難，如沒有系統的自測方法、時間不充足（需要熟悉下階段的UC、下迭代的設計、單元測試補寫等），找到這些困難或問題，就容易對癥下藥了。最后，不斷總結和積累自測方式，優化項目流程。自測不是一種形式，而要追求效果，開發自測同樣需要計劃和方法，所以我們需要向QA同學請教，總結過去 bug常犯的錯誤，整理自己的check項。相信通過這樣的一些自測方法，能真正提高我們的項目質量，打破同QA的界線，我們的開發、測試資源比例可以得到更大的優化，將以前開發階段緊，測試階段松的狀況加以改善，使整個項目過程中的緊張度趨于平緩。

3、 談故障分

“盡量不要讓故障分成為大家包袱，可以考慮被實施產品對事故級和A類才對個人計故障分，B和C類故障分記在主管頭上！”，個人也比較支持駱駝的觀點。目前大家對線上故障都小心翼翼，大家對質量的意識很高，這當然是好事，但同時帶來的影響是效率低了。我的觀點是，作為增值服務的互聯網產品，我們更需要快速迭代增量提供用戶價值，盡快獲取用戶反饋并改善產品，產品推出的遲早，不僅影響獲得回報的時間，還影響到獲得價值的多少，錯過了一個時間窗口，產品可能就不再有任何價值。所以，我們需要找到一個平衡量點，可接受的質量狀況達到最大的效率。

從客戶第一角度談質量，某些時候，客戶可以接受服務偶而不可用重啟下，卻不能接受產品沒價值、交互性太差，操作太復雜。所以，對于客戶來說什么對他們更重要，就需要我們每個人去分析和評估。所以，我們一味只注重質量，而忽略客戶真實需求，那就太悲哀。我的觀點是，case by case，帶著這樣的觀點去思考和解決問題。

4、談敏捷項目團隊

從打破邊界，我想到了一體化的敏捷項目管理團隊，一個目標一致、自我管理的團隊，應該具備良好的目標意識和執行力，不僅能管好自己的一畝三分地，同時也能站在項目、團隊的角度看待問題。PD出現了問題，開發積極去彌補；開發出現了問題，QA積極去彌補，項目團隊的目標非常一致。每位項目組成員一定要把好每一關，萬不可把問題向下拋，因為還有開發或QA會把關，所以差不多就行了，這樣往往就是災難的開始。