小規模團隊的敏捷開發研究

摘要：敏捷開發是一種以人為核心、迭代、循序漸進的開發方法，是為了解決項目的復雜性，以最快最科學的方式實現需求的開發方式。軟件團隊中最常見的一種方式就是小規模團隊開發，一般保持在3到5人。在大量的中小規模公司中，只要公司生產的產品需要軟件支撐，都組建規模較小的團隊進行專門的軟件開發。本文通過對敏捷開發的介紹和對小規模團隊敏捷開發的應用，介紹如何在開發人數不多的情況下進行高效率、有序的和科學的開發工作，有效地提高團隊的生產力和價值。

關鍵詞：敏捷開發；軟件工程；模塊化；持續集成；最大化生產力

1 概述

敏捷開發不是一個時興的概念。2001年2月，一組由17位在DSDM、XP、Scrum、FSD等領域的專家組成的代表團齊聚美國猶他州，尋找敏捷、高效開發方法的共同點。最終，這些專家制定并宣布了敏捷開發宣言，并成立了敏捷聯盟。十年間，敏捷開發思想得到了全面的發展。在軟件工業界，敏捷開發已經成為眾多高效開發團隊的制勝法寶。中國的外企、外包公司和許多知名企業也都開始采用了敏捷方法。例如，騰訊內部幾乎所有的開發團隊都在實施敏捷方法。敏捷方法給這些企業帶來了巨大收益。據業內資深人士和長期從事敏捷咨詢的服務公司透露，采用敏捷開發的團隊一般會提高3-10倍的效率，軟件的質量也有了更加可靠的保證。同時，敏捷開發的應用也給團隊內的每個成員提供了良好的發展機會。他們的技術和合作水平都能得到相應的提高。

2. 敏捷開發思想

2.1 概念

敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。是為了解決項目的復雜性，以最快最科學的方式實現需求的開發方式。

在敏捷開發中，軟件項目的構建被切分成多個子項目和各個子階段，各個子項目和各個子階段的成果都經過測試，具備集成和可運行的特征，而各個子階段是串接在一起的，在上一個子階段完成和測試審查后才進行下一個子階段。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目和子階段，并分別完成，在此過程中軟件一直處于可使用和可演示狀態。

從上圖可以看出，敏捷開發具有以下幾點優勢：敏捷開發過程比傳統開發要為項目和產品帶來更低的風險（RISK）；敏捷開發擁著比傳統開發更大的透明度（VISIBILITY）；敏捷開發模式使產品和團隊自身都有很強的適應力（ADAPTABILITY）和生命力。

2.2 以人為核心

敏捷開發的關鍵思想是以人為核心，認為人是軟件開發過程中最為關鍵的因素，整個軟件開發過程能不能實現敏捷化，能不能最終取得完全的成功，主要是看在人這個因素上能不能處理得當。

敏捷開發中所指的“人”實際上是指兩個方面。一是開發設計者，即在軟件整個項目中的程序分析、構建、設計和測試等等相關人員。他們是項目開發的最終實現者，對軟件的質量、進度等起到決定性作用。二是客戶。這里的客戶不但是指軟件最終用戶，也可以指上級領導和大項目經理等這些本單位上層領導。敏捷開發的思想，就是以本設計團體為中心，和外界各類人員進行配合的過程。

2.3 開發人員的素質

作為項目的直接實現者，敏捷開發對開發人員指出明確的要求或價值觀，典型的具有這么幾個方面：溝通、簡單、勇氣、謙遜。分別介紹如下：

A. 溝通

敏捷開發認為，溝通是開發人員最重要的一項任務，只有不斷的溝通才能提高開發人員之間的默契，避免誤解和犯錯的可能性，提高代碼的準確率，并在一定程度上甚至是很大的程度上提高了軟件的開發效率。

溝通需要融洽的氛圍。在團隊內部要創造良好的人與人之間的關系，只有這樣才能以最大的可能性提高溝通的質量和效率。

B. 簡單

敏捷開發建議，可以用圖或模型的這些簡單的方式，甚至是一些簡單的工具，來描述程序的結構和思想，這種方法可以清晰地表達開發設計人員的想法，能以一種統一的方式在開發人員之間進行溝通，還能更容易地發現新的想法和改進。

C. 勇氣

在敏捷開發中，設計者尤其是高層人員開發人員，比如分析師和構建師，如果發現當初的決策證明是不合適的時候，就需要在短時間內放棄或重構（refactor）工作，修正方向，實施正確的調整，以最小的代價修正錯誤。這種情況下，這類人員的勇氣是非常重要的，能以最大的可能性減少項目的損失。

D. 謙遜

敏捷開發要求開發團體中的每一位成員，都要擁有謙遜的美德，能聽取意見，并能認識到自己的不足。事實上，無論是開發人員還是客戶，項目小組的所有成員都要有他們自己的專業領域，都能夠為項目做出貢獻。一個有效的做法是假設參與項目的每一個人都要有相同的價值，都應該被尊重。這是營造高效率團體，促成項目成功的重要條件之一。

2.4 客戶交流

2.4.1 有效的溝通和參與

在敏捷開發思想中，與客戶的溝通是非常重要的。敏捷開發認為，必須始終保證開發過程中的方向的準確性，才能使開發具有實際價值，并最終取得成功。為了達到這個目標，就需要圍繞客戶開展工作，積極地與客戶進行深入溝通，保證需求目標的準確性。

敏捷開發的一個建議，就是讓客戶參與到開發過程來，客戶的身份是觀察員和顧問，對開發過程中可能出現的偏差，能及時得到更正，并且開發人員能在第一時間直接與客戶進行協商，解決問題，以最大可能提高開發的效率和準確度。

2.4.2 積極的反饋

對敏捷開發來說，反饋是非常重要的事情，通過積極的、連續的回饋，可以對客戶，和單位的上層領導增強信心，不但能展示軟件開發的進度，讓客戶和上層領導對軟件開發做到心中有數，而且還能及時發現開發過程可能出現的錯誤，并及時得到修正。因此，通過積極反饋這種方式，保證了項目健康的進行，和始終保持準確的進行方向。

敏捷開發的建議是，通過圖片或實際軟件演示的方式來展示當前項目的進展程度，采用這種直觀的方式可以使客戶和領導清楚了解項目的進展程度，而且也是對軟件開發的階段性簡單小結，具有積極意義。

2.5 項目管理

正如對客戶的積極反饋一樣，項目也要積極進行小結。這兩者的區別在于：反饋是按時間單位定期進行的，項目管理的小結是按項目的計劃安排進行的；反饋針對是客戶和領導相關人員，而項目的小結是開發團體內部的事務。

項目在規劃的時候，要劃分為若干的子階段和子項目，每個子階段和子項目完成，都要進行測試、審查和歸檔，以保證項目每一個階段和每一部分都達到目標。在此前提下，才能保證后續階段和后續的其它部分的開發的正確性，從而避免了在軟件開發后期才發現前期問題的重大事故。

2.6 開發策略

2.6.1 簡單策略

軟件開發的目標主要是解決當前要求的需求。因此，最簡單的解決方案就是最好的解決方案，不要實現額外的功能，盡量減少對未來的擴展的考慮，以最簡單的方式構建出軟件。如果日后需求有變更時，再來考慮和重構這個系統。

簡單的策略也指對工作的精簡。項目在設計過程中必然需要進行建模和編寫文檔等這些步驟，如果不是非常必須，可以簡化建模和編寫文檔的流程，有的甚至可以取消，以減少在意義不大的事情上注入過多的精力。

2.6.2 積極接受變化

客戶非常有可能在一開始并不能清楚地表達出自己的需求，在項目進行中甚至可能更改自己的需求。另外，團隊在開發過程中，很可能也會有變化，比如人事的調整、領導的策略的變化等等。因此，隨著項目的進行，項目環境也會在不停的變化，在開發方法中必須要能夠反映和應對這種現實。具體的方式就是積極的反饋進度，總結軟件開發階段，對可能的調整盡早開始。只有這樣，才能實現高效的應變性。

2.6.3 高質量的工作

好的軟件成果一定是基于高效率、專心的工作，如果工作效率低下，不但會影響工作進度，而且軟件中可能會出現大量的Bug，為軟件后期帶來更多的甚至成倍的工作量。發生這種情況，不如停止工作進行調整。

3 小規模團隊的敏捷開發

3.1 簡介

在軟件開發團隊中，以3至5人的小規模團體開發居多。一般常見于非軟件公司，因為軟件只是這些公司的附帶產品或支持產品，所以不需要進行大規模的開發，只需要小規模團隊就能完成所有的軟件開發任務。

小規模的團隊的敏捷開發方式，基本上是和典型的敏捷開發思想一致的。但由于規模效小，因此也具有一些鮮明的特點，在能動性上和效率上能保持更佳的水平。

3.2 特點

3.2.1 人員精簡

一支全面的敏捷項目開發的團隊，至少需要擁有具備不同職能的 7 名成員：1名UCD(User Centered Designer)，1名Visual Designer，1名測試人員（Tester），1名Information Developer和3名開發人員（Developer）。而對于小規模的團隊來說，人員數量一般是不足的，只有3到5 人，在這種情況下，一個人可能需要承擔多個不同的職能任務。

3.2.2 個人素質高

由于團隊的規模較小，所以對個人能力就會要求高。一方面，一個人往往要承擔多個方面的開發和相關工作，要求開發人員具有它所承擔的這些方面的專業知識和一定的經驗，以使開發人員能夠勝任工作的需要。另一方面，為了應對的人員的暫時調整，開發人員需要承擔的任務也會發生變化，因此也需要開發人員具有他所面對的新方向的技術技能。總之，小規模團體中，個人素質的要求是比較高的，能夠勝任多方面的工作任務。

3.2.2 加強協作溝通能力

協作和溝通對小規模的團隊開發顯得異常重要。因為小規模的團隊中的人員較少，有效的協作和溝通，將成倍提高的開發的速度和效率，從而在一定程度上彌補人員較少所帶來的不足。如果能達到一定的默契和精干，開發的速度甚至可能超過中等規模的團隊。由此可見，對于小規模團隊，良好的協作和溝通是實現敏捷開發的關鍵之一。

3.2.3 決策由團隊做出

由于團隊人員較少，每個人都具有舉足輕重的地位。因此，大部分決策都可以由團隊里的全部人員共同討論商量而定。這樣不但可以在一定程度上保證決策的正確性，還能同步設計人員的設計思想，使所有人步調一致，方向一致，從而提高開發的效率。

3.2.4 容易激發創新意識

小規模團隊中的每位開發人員都負責著多個方面的開發任務。在這種情況下，每一位開發人員對他們所負責的部分的開發效率和質量都起到了決定性作用，并賦予了更多的自由度和靈活性，更容易發揮創新意識。

4 項目實例分析

4.1 項目背景

2008年年初，筆者所在單位和陜西省某煤管局簽訂了一份公路檢重的合同。本合同是要在其所管瞎的三個收費站上安裝全套的動態自動計量系統，用于對過往的運煤車輛進行稱重和登記。本系統的軟件部分，不但要求控制全套動態計重系統的運作，同時要求對車輛進行管理，能夠自動計算車輛的凈重，而且要求能夠監控整個系統的運作，具有聯動報警功能，同時對于每個站點的情況和整個系統的車輛信息，具有網絡查詢功能。由筆者任組長，帶領另外三人組成一個小規模的開發團體，共同完成軟件部分的開發和設計工作。

4.2 需求分析

需求分析的制訂用了比較長的時間。

首先是下現場調研，搞清楚各個站點的實現情況，包括了計算機使用情況、網絡情況及車輛計費流程等等。期間，也對站上的工作人員的情況進行了了解，對他們的計算機的使用能力進行了匯總。

其次，重點和煤管局負責本次項目的機電科的相關人員進行了深入分析和溝通，在此基礎上，和客戶一起，將軟件部分所有的功能進行了匯總，對各個功能進行了詳細說明，對軟件的所有功能板塊的邏輯關系進行了圖表繪制。完成這些任務后，確定了技術基本需求分析文檔。

4.3 Demo開發和初步評審

在已有的需求分析的基礎上，需要著手進行Demo程序的開發。Demo程序是一個演示程序，它的目的是展示軟件的大致結構和使用方式。Demo程序在快速地開發完成后，和客戶一起評審這個程序，完成后，該軟件的開發階段就正式啟動。

4.4 開發環境與過程

4.4.1 客戶監督

為了在軟件開發過程中最大程度地實現和滿足客戶的實現意圖，及開發人員能及時與客戶之間進行溝通，并展示開發進度。本項目在開發過程中，專門請入煤管局機電科的一名技術人員作為顧問定期地來本單位，展示工程進展情況，并糾正需求中不足或不明確的地方。

4.4.2 工作環境

軟件小組有專門的辦公室，所有的人都在同一個開發環境中工作。辦公室中有飲水機、茶點，還有一個大白板及一個小型的會議桌。

每周標準40小時工作制，不提倡加班。每天早上所有人員首先碰個頭，了解系統各個方面的進展情況，解決之前遇到的各類問題。工作時間里，每位人員都積極進行自己的工作，并和其他人之間進行經常性溝通，保持活躍的氣氛，和高效率的工作狀態。

工作時可以聽音樂，但不能影響其他人。

4.4.3 持續集成

開發團隊是由四個人組成的，分別負責:主體開發；數據庫和網絡開發；硬件模塊和流程模塊開發；文檔管理、集成測試和項目協調。

本項目分為四個開發階段，每個階段又分為若干個結點。在到每一個結點時，就進行系統集成一次，保證包括測試在內的每個部分都能正確地集成在一起使用。每個部分都要通過測試樁和測試用例的測試，以保證已開發的內容沒有錯誤，并保證已開發的內容準確地實現了既定的要求。

每次進行集成的時候，都把集成的結果演示給客戶，讓客戶了解當前軟件的進度。

4.4.4 編程

編程是代碼的最終實現過程，為了保證代碼的正確性和高效率的實現，做到了以下幾點：

一是所有開發人員編程風格一致，變量前綴名稱、函數名稱和注釋的格式等等，都采用統一的標準。軟件的界面也都采用相同的風格。

二是采取相互檢查的機制，即采用自由組隊的方式，相互檢查對方的代碼。如果發現問題和難點，可以大家一起出主意，保持良好的工作氣氛。

4.4.5 測試

測試主要分為兩部分：一部分是設計人員自己的測試；另一部分是系統集成測試。

設計人員的測試，不做檢查，但是提倡進行，并做一定記錄，以保證在最后系統集成測試的通過率。系統集成測試包括了針對軟件的全部測試，包括了功能測試、整合測試、負荷測試和系統測試等。在系統集成測試這一步，團隊里私下規定，誰的錯誤最多，就要受到一定的懲罰，例如一周的值日等等。而多次集成測試中保持無錯誤者，則可獲得物質獎勵。

4.5 項目驗收

在軟件開發的最后一步，就是項目的驗收。驗收工作是在客戶相關人、軟件組長、項目經理之間進行的。通過驗收后，隨即在各個站點和煤管局安裝了系統，并試運行，還培訓了各個站點的工作人員，制定了計算機、系統使用的各類注意事項。在這些完成后，開始進行資料、代碼和文檔的歸檔工作。

5 小規模團隊開發的經驗總結

5.1 提倡和保護個人的創新意識

創新能夠為企業帶來新發展契機，創造新價值。因此，創新對于企業還是個人而言都非常重要的。小規模團隊中的每一個人都需要創新意識，只有這樣才能實現新技術的突破，解決遭遇到的許多新挑戰、新困難，每個人都能獨擋一面，并成為他們所負責方向的專家。

5.2 技術風格統一，格調一致

風格一致是非常重要的。對敏捷開發來說，只有和所在團隊規定的格式一致時，代碼和成果才有意義。因為只有這樣才能方便地對其他人的代碼的理解，對于人事上調動，原工作人員的大量工作成果也能得到保留。需要指出的是，對于小規模團隊開發來說，要盡量避免人事調動，因為每個人在團隊所在地位是其他人不能取代的，人事的調動必然會影響到團隊的整體結構，也可能會大大影響正在進行項目的進度。

5.3 要創造最大化的生產力

小規模團隊由于人員較少，其開發目標應更重視是有效率地生產出可用的產品而不是詳細文檔。可以避免一些不常用的文檔的糾葛，對于一些必須的文檔，內容也可以簡潔從事。對于小規模團隊而言，文檔的繁多并不能從任何方面促進工作的效率，同時文檔也不是最佳的溝通方式，直接的交流和溝通才是最有效的，復雜的文檔說明只會增加溝通成本。因而小規模團隊的敏捷開發，測試的文檔不需要長篇累讀，需要的是簡潔，清晰。任何一段清楚的文字，甚至一張圖片、照片都是我們認可的敏捷文檔。

小規模團隊的敏捷開發模式要最大化的提高團隊的工作效率。無論是依靠剪除冗余的文檔工作，還是提供民主的、通暢的溝通平臺都是為了幫助團隊能夠集中有限的精力處理有意義的問題。

5.4 民主的團隊和榮辱與共

小規模的團隊應該是一支民主的團隊，團隊關系是平行的，每個團隊成員能夠平等的參與討論，決策。這是非常重要的事情。團隊脫離了任何一個成員的工作都必然是不完整的。所以我們應當足夠尊重其他成員的勞動果實和表達對其他成員的充分信任。推薦的方法是面對面交流、每日匯報、回顧會議。要求能夠開展生動有趣的會議，提煉和開發全員的想法，并盡量減少勾心斗角。

參考文獻

[1]《敏捷開發的藝術》，James Shore，Shane Warden，機械工業出版社，2009年。

[2]《Visual Studio 2010：助力敏捷開發》，CSDN，2010年。

[3]《精益和敏捷開發大型應用實戰》，Craig Larman， Bas Vodde，機械工業出版社，2010年

[4]《敏捷開發走過十年》，鄒大斌，計算機世界，2010年

[5]《敏捷軟件開發：原則、模式與實踐》，Robert C. Martin，清華大學出版社，2003年

[6]《欲善敏捷開發 先利敏捷工具》，IT168.com，2008年

[7]《精益和敏捷開發大型應用實戰》，(加拿大)Craig Larman，機械工業出社，2010年

[8]《可伸縮敏捷開發：企業級最佳實踐》，Dean Leffingwell，電子工業出版社，2009年