敏捷的實質

從遊戲開始……

有個非常有意思的遊戲能夠幫助大家理解敏捷和傳統開發的差異。遊戲有兩個角色，一個是“老闆”，另一個是“員工”，在 2 分鐘內，“員工”需要在“老闆”的完全指揮下，即“向前一步，向後一步，停，向左一步，向右一步”，完成 60 步移動的任務。“員工”需要執行“老闆”的每一個指令，不允許做出相違背的動作。“老闆”則不參與行動，只發出指令指揮“員工”的活動。我們體驗這個遊戲時，當場 60% 的參與者成功完成了任務，大致估計出我們的工作效率是 50%*60%=30%。遊戲後，參與者被問及對這種行為方式的感受時，無論是“員工”還是“老闆”都表示非常不滿。

接著，大家又做了另一組遊戲。2 分鐘內參與者被要求獨立的、自主的完成 60 步移動任務，在這次遊戲裡，所有參與者任務相同，大家可以自行決定、並依據自己的判斷隨時調整其步伐方向，快慢。最後，我們發現所有參與者不但毫無折扣的按時完成了任務，因而工作效率也達到 100%*100%=100%，而且所有人對於這種新的工作方式更是產生了極大的興趣。

以上兩個遊戲方式的對比就折射出傳統開發（前者）與敏捷開發、測試活動方式的對比，其中優劣不言而喻。

而敏捷開發、敏捷測試又是怎樣一個概念呢？他們是否能夠幫助我們的團隊突破束縛，在日益激烈的競爭環境裡表現得更為出色呢 ? 請參考我的這個系列文章——“敏捷測試的最佳實踐”。

敏捷的價值

首先我們解釋一下什麼是敏捷，在字典中我們得到解釋，敏捷，即反應迅速、可以快速變化。如今敏捷開發已成為眾所周知的時髦 IT 詞彙，在這個領域裡敏捷又被詮釋為迭代的，快速應對需求變化，輕量級，並且簡潔。

圖 1. 面對客戶業務複雜度問題提出敏捷解決方案

IBM 重視敏捷開發，敏捷的軟體開發策略之也被廣泛推廣開來。中國軟體開發中心是 IBM 軟體部部署敏捷開發方法的重點實驗室之一。我們也是 IBM 中國軟體開發中心最早使用敏捷方法的開發、測試的團隊之一。這篇文章主旨為幫助那些願意採用敏捷，和正在採用敏捷開發、測試的團隊正確瞭解敏捷的實質。

筆者做敏捷專案已經近兩年時間，對於敏捷的理解，認為最為關鍵的是需要注意兩個方面，它們是“高度迭代”和“持續不斷的客戶反饋”。

• 高度迭代：迭代就是指產品的開發過程中，一個完整的開發活動周而復始的進行，產品的功能、效能、可用性在週期活動的疊加中不斷得到更新和加強。甚至指在一個迭代週期內產品活動也具顯著的週期性。同時，團隊間、團隊內部成員的高度協作及時幫助解決了各成員的依賴性問題，因此，也促進了各個成員工作的順利開展，保障了產品活動穩定的持續性、週期性。以測試為例，傳統開發模式下，測試人員可以因進入測試階段的條件不完全滿足而繼續的等待。而在高度迭代的敏捷專案裡，不同的是，我們希望測試人員能夠儘可能的做能夠做的工作，儘可能的早工作。“等待”在敏捷開發、敏捷測試範疇裡已是一種錯誤概念了。
• 持續不斷的客戶反饋：指在產品開發任何時期，代表專案業務（Business）的利益干係人（Stakeholder）都要參與到產品的需求分析，設計，以及其他活動的決策制定中來。致力於在短時間內幫助團隊實現將客戶的需求轉化為高質量的可消費產品，並轉化成利潤。

敏捷開發的商業價值

敏捷開發自 2001 年《敏捷宣言》（“AGILE MANIFESTO”） ¹ 的創生，經過多年的打磨和退火已經成為今天非常流行和有過許多成功案例的開發模式。正如前人所說，傳統的東西就是用來打破的，傳統的瀑布式開發模式必然逐漸退出歷史舞臺，敏捷開發、敏捷測試是在新環境裡產生出來的打破傳統的新開發模式。而敏捷也將會在將來，甚至現在轉化成更適合現代化軟體開發、測試團隊的方法和實踐。在本文的第一部分，我們以兩個遊戲類比了敏捷和傳統開發的差異，這裡為了進一步幫助大家對敏捷的價值有更清晰的理解，我們借鑑前人的研究結果：

圖 2. 敏捷與傳統開發的比較

首先敏捷開發過程比傳統開發要為專案和產品帶來更低的風險（RISK）。為什麼呢？傳統開發缺乏持續的客戶反饋 , 產品一旦從需求階段退出，整個開發團隊近似封閉工作，團隊雖努力去實現曾經認定的目標，但因月有陰晴圓缺，市場需求也瞬息萬變（例如提出需求的客戶已經退休）。這使得產品在數月後，數年後釋出時已經失去了佔領甚至進入市場的最佳契機。

而如果你還在考慮使用傳統開發模式用現在乃至將來一、兩年的時間來開發一個結構複雜，精益求精而又功能龐大的產品，那麼你得好好做好失敗的準備了。而正是因為出於對這種風險的考慮，越來越多的人認識到敏捷開發要比傳統開發能夠為企業帶來更大的利潤空間和更低的投資風險。

其次，利益干係人（Stakeholder）的頻繁參，與使得團隊在產品開發的各個環節遇到的種種問題得到了及時的解決。因此，我們認為敏捷開發擁著比傳統開發更大的透明度（VISIBILITY）。作為老闆，專案的負責人一定對這樣的開發模式帶來的可控性充滿了嚮往。

團隊或者產品的適應能力（ADAPTABILITY）也決定著其生命力，因為敏捷開發模式鼓勵團隊採納新技術，歡迎變化，並能夠快速應對之，使得產品和團隊自身都有很強的適應力和生命力。而在傳統模式裡，當需求變更時，複雜的變更管理流程要求通過正式討論、審批，也備以足夠的文件和說明來支援每次“決策”。這不但帶來了人力，物力的浪費，更重要的是它嚴重延長了企業投資到利益回報的週期。而只有擁有反應迅速的敏捷開發才能夠幫助企業贏取市場，降低風險。

以上我們談及了敏捷開發擁有的比傳統開發能為企業帶來更大的商業價值和提供企業更大的發展空間。而對於個人而言，筆者認為敏捷開發也提供給了個人更多的發展機會和提出了更高的要求。以下是筆者從個人角度做出的分析。

敏捷開發有益於個人發展

敏捷專案首先擁有一支支小規模但職能全面的團隊，在這樣一個普通的敏捷團隊裡，擁有具備不同職能的 7 名成員，1 名 UCD(User Centered Designer)，1 名 Visual Designer，1 名測試人員（Tester）， 1 名 Information Developer 和 3 名開發人員（Developer）。因此，每一支敏捷團隊中的設計、開發、測試、美工、文件等等工作分屬給了這個團隊裡不同的，唯一的人。每個人在團隊裡因而必須具有對其所涉及領域強的責任心和領導力。就測試而言，測試人員就是好比一輛跑車裡的唯一的駕駛員，專案就好比這輛跑車，測試人員需要及時修正行駛方向的偏差，確保這輛車在正確的道路上穩步前行。如果，測試人員沒有具備足夠的責任心和領導力，只是人云亦云，恐怕這種測試要與不要沒什麼分別，敏捷專案的質量也更讓人擔憂，而敏捷也就失去了原有的意義。因此，作為唯一的測試人員，他（她）將擁有對測試的所有權，計劃、設計並且執行所有的測試工作。而也因為擁有了更多的主人翁精神，積極的工作熱情，測試人員勇敢的面對工作中的各種挑戰，學習新的知識和努力培養自己的工作技能。敏捷無疑對個人發展產生了很大的推動作用。

敏捷團隊中的每個人，需定時和團隊的其他成員坐下來看看團隊的整體進度，計劃下一步工作，並一起探討所遭遇問題的解決方案。也需適時的尋求團隊中其他成員的幫助解決時下緊要的問題。通過頻繁的合作與溝通，個人的協作能力、溝通能力也得到了較大的提高。下面我們具體就這兩個方面進一步談談敏捷開發是如何幫助提高個人的協作能力和溝通能力的。

敏捷開發培養了個人的協作能力

與傳統開發不同，敏捷開發更加側重以人為本，發揮人的積極性，以此提高團隊的工作效率。真正實現以結果為導向的職場守則。作為團隊的一份子，無論是測試、開發人員，還是設計人員，他們都將為團隊成敗擔當不可或缺的責任。團隊是高度協作的團隊，個人除了做好本職工作外，敏捷開發模式要求個人能夠了解和爭取更多的擴充套件性的工作，也能幫助團隊其他成員解決他們的遇到的各種獨特問題，以加快實現團隊的統一目標，即在更少的時間裡生產出能夠推向市場的可靠產品。

這裡再次提及高度協作，筆者認為高度的團隊協作主要表現為以下特點：

1. 團隊成員積極分享經驗，知識，自我培養所需技能和自我成長；
2. 團隊成員相互幫助，願意成為他人後備隊員，隨時做好準備投入新的戰鬥，因而保障了團隊的高昂士氣和強大的生命力。
3. 任何決策是團隊共同的決策，工作是團隊共同的工作，團隊工作的最後成果因而也是來自團隊中每個人的辛勤培養和貢獻。而團隊的失敗更是整個團隊的失敗，絕不會是某個人的單方面的過失。這種榮辱與共，共生共息的信念將讓團隊的力量超過團隊各個力量之和。同時，專案團隊的工作效率在團隊成員技能的提升和信念的鞏固中不斷提高

敏捷開發鍛鍊了個人溝通能力

我們把團隊看做一個高度協作整體的同時，不可忽視的是團隊內部仍存在的各種矛盾，對這些問題的聽之任之將破壞團隊的凝聚力、生產力。這中間反映出來的很多問題不是敏捷方式獨有，但團隊成員因為敏捷，學會了自己解決各種問題。而相應的溝通能力也隨著問題的解決得到很大幅度的提高。

在過去的專案經驗中，我們不難發現種種人與人之間矛盾的產生。而經典的矛盾論也讓我們不得不的接受，矛盾是永遠存在的，但這並沒有什麼可怕。而是一旦我們發現了矛盾的存在，就要迅速找到解決辦法，這也是團隊的相當重要的工作。尤其是在團隊組建初期，團隊開始採納新開發模式時，鍛鍊團隊解決如下矛盾的工作非常重要：

• 測試人員是質量的工程師，開發人員是產品的締造者，在對質量標準的認同上常有不一致（當然，傳統開發也會產生）；
• UCD 的設計實時反應使用者需要，但有時不能顧及程式碼的可實現性；
• 開發人員而卻更喜歡用想當然的理解，和習慣的方式填寫程式碼，甚至主觀的抵制接受新設計思想和拒絕新型別缺陷的修復，因此與團隊的整體目標、出發點產生分歧；
• 從整個專案組織結構看來，敏捷團隊之間（一個專案通常有多個敏捷團隊組成，各個團隊有自己的側重點）存在設計，開發的不一致性，這使得產品在整合階段產生額外的成本。

正如前面所論述，矛盾總是有能夠解決的途徑，敏捷專案的組織中用管理方式去幹預是一種直接、快速的方式，而今天敏捷方法論者們更加推崇的是鼓勵團隊內部進行很好的交流和溝通後自行解決。也正是通過不斷加強團隊間和團隊內部的相互理解，不但矛盾得到很好的解決（解鈴還須繫鈴人嘛），個人的交流和溝通技能也得到了進一步提高。

敏捷開發培養了個人的創新意識

創新能夠為企業帶來新發展契機，創造新價值，因此，創新對於企業還是個人而言都非常之重要。不斷培養員工的創新能力、鼓勵創新活動也是幾乎所有企業的人才培養戰略之一。而敏捷開發恰恰就是要打破傳統的模式，形成全新的敏捷開發、敏捷測試方法、實踐和過程，並鼓勵團隊採用新技術和技術創新。因此，團隊的每個人需要能夠創造性的工作，並樂於接受新事物，通過不斷的改進、突破過時的做法，努力提高團隊的工作效率，來適應產品的增量發展需要。

而也因為敏捷開發模式對於很多團隊仍很陌生，在運用敏捷開發的過程中我們會遭遇許多新挑戰、新困難。如何處理這些問題，解決方案本身就是無以借鑑的，自主創新才是唯一出路。

舉個例子，敏捷專案初期，產品停留在原型論證和底層架構初步設計中，產品功能不多，複雜度較小，一般的手動測試就可以將質量保障做好。產品的中後期，因不斷有新需求、新功能的加入，產品複雜度增大。團隊倘若仍僅憑固有的手動測試方式來覆蓋產品的各個功能、非功能點需求只恐怕是力不從心了。因此，考慮用自動化測試來提高團隊工作效率是可取的方法之一。但是，當產品發展到中後期，也沒有富餘的資源可以被抽取出來做自動化測試了。即使現招聘新人，也因為新人對產品不瞭解，只怕自動化測試的效果也未如人願。那我們是否應該在開發活動的初期就嘗試自動化測試的設計、並自動化一部分功能測試呢？也未然，因為在產品開發初期，產品的功能和介面的變動會比較大，自動化測試收入產出比異常低。因此，何時、何地、如何設計、運用自動化測試來幫助降低人力成本，提高測試效率是需要我們大膽創新的。

敏捷方法的共同點

以上我們通過商業、個人發展兩個方面講述了敏捷開發的價值和意義。那什麼才是敏捷開發呢？在業界又有那些方法是敏捷開發的具體實現呢？各種方法有什麼共同點嗎？通過下文對各類敏捷方法的共性分析，我們也將進一步瞭解敏捷的實質。

敏捷方法

業界流行的敏捷開發的方法有許多（要了解各類敏捷方法和分類請參閱本文參考資料中文獻），我們需要根據專案大小，性質來選擇合適自己的敏捷方法。比如說 XP（極限程式設計，eXtreme Programming）更加適合小型專案 3-5 人的團隊。Scrum，DSDM (Dynamic Systems Development Methodology) 等更加適合大型團隊的專案開發。而敏捷開發也不是一成不變放之四海皆準的準則，而是一個方法的最佳實踐。各個團體和企業也不斷定製著自己的最佳遊戲規則。VersionOne 的敏捷開發的調研報告中很好的對比了各個方法被業界採納的比例（見下 圖 3）。這個圖表就是 2007 年對來自 71 個國家 1700 多人的調查結果的說明。

圖 3. 流行的敏捷方法

除了圖例中的方法外還有 Crystal, Lean Software Development, Feature Driven Development, Xbreed, RUP 等等。

敏捷方法的共性

雖然各種敏捷方法的名稱、所需環境、適合的團隊有很大差異，但是他們擁有相似、相同的以下幾大特點：

• 擁抱變化（Embrace the change）

無論是多麼明智，多麼正確的決定，也有可能在日後發生改變。因此，團隊要能夠充分理解我們的利益干係人（Stakeholder）和客戶代表為什麼經常提出新的需求和設計要求，一句話，就是心中有數“唯一不變的是變化”。團隊更要信任 利益干係人（Stakeholder）做出的每次決定和需求的調整都是將產品開發推向更正確的發展方向，新變化將進一步降低風險，實現團隊最大化利益，理解這是適應市場變化的必然行為。

而在接受變化的同時，我們應該積極的向 利益干係人（Stakeholder）和客戶代表反映實現活動中暴露出來的可能的設計缺陷和錯誤。在實際工作中，團隊成員應該用優先順序制度來劃分事情和目標先後順序，在迭代週期內對於還沒有最終決定的設計方案可以予以後來實現、測試，不用急於投入資源展開全面的開發、測試活動。這樣一來，開發測試團隊也會人員也將更加適應，真正擁抱變化。

• 客戶的參與（With Customer Representative on site）

首先誰是客戶（Customer），客戶代表（Customer Representative） 呢？利益干係人（Stakeholder），或者我們可以理解為我們的客戶（Customer），產品的最終使用者（End user），內部使用者（Insider），商業夥伴（Business Partner）。利益干係人（Stakeholder）作為團隊中最瞭解業務（Business）的人物將幫助開發團隊的快速達到目標和做出適時決策。開發團隊擁有很好的技術但在業務（Business）方面他們需要 利益干係人（Stakeholder）的幫助。而通常在敏捷的開發專案中，團隊中的任何一個人若需要幫助時，只要簡單的邀請大家參加一個 15 分鐘會議，或一封郵件、一個電話便可以解決。

但是，如果利益干係人（Stakeholder）各執一詞怎麼辦呢？為解決這個問題，將 Product Owner 引入到討論中來，作為 Product Owner 他可以作為是 利益干係人（Stakeholder）的代表，能夠在分歧中做最後抉擇。因此，通過這樣的客戶代表的參與，團隊更好的瞭解了所做事情的價值和意義，其工作效率也因而得到很大提高。

利益干係人（Stakeholder）能夠幫助團隊中的每一個人更好，更快的完成了工作，他們的直接參與成為了敏捷開發、敏捷測試的重要前提。

• 較少的文件（With less documents）

敏捷開發更重視生產出可用的產品而不是詳細文件。而時常有發覺文件又是無論敏捷還是傳統開發、測試不可或缺的一部分。筆者認為，傳統開發的文件在敏捷開發裡仍有大用，只是原來十來頁的內容精煉到現在的一頁半頁。

敏捷主義者相信文件不是最佳的溝通方式，他們鼓勵通暢的交流和溝通，要求避免和減少陳詞濫調和空頭支票。尤其是複雜的文件說明只是增加了溝通成本，因而敏捷開發、測試的文件不需要長篇累讀，需要的是簡潔，清晰。任何一段清楚的文字，甚至一張圖片，照片，一封記錄著會議記錄的郵件都是我們認可的敏捷文件。因為是無論是通過文字板書的檔案還是其他的溝通方式和載體都是為了幫助團隊進行更高效的交流和溝通。只有團隊保持著溝通上、理解上的一致後才能夠充分發揮出團隊最佳戰鬥力。但凡這是幫助團隊有效溝通的方式，敏捷開發是不會放棄的。

• 最大化的生產力（Maximize Productivity）

敏捷開發模式要最大化的提高團隊的工作效率。無論是依靠剪除冗餘的文件工作，還是提供民主的、通暢的溝通平臺都是為了幫助團隊能夠集中有限的精力處理有意義的問題。據調查，通常人會在兩個、多個任務並行的情況下產生出出最高工作效率。而敏捷也恰恰使用了各種方法得到團隊的最大生產力。

敏捷開發的 Scrum 模式，要求在計劃階段，團隊成員主動定製迭代週期的所有工作任務，因此，本身從團隊開始迭代活動的那時起，已經在在多重工作的壓力下緊張工作了。而在日常的迭代生產活動裡，各個成員需要當眾簡單彙報當天的工作進度和承諾下一個 24 小時的工作計劃。因此，通過增加敏捷人員的工作的透明度，無形之中，團隊成員的生產力進一步得到提高。

• 測試驅動開發（Test Driven Development）

測試驅動開發，是讓開發人員在編寫功能程式碼之前，根據對需求的理解先設計和編寫單元測試程式碼。先思考如何對將要實現的功能進行驗證，再考慮功能的實現。然後迭代的增加新功能的單元測試和功能程式碼編寫，直到完成全部功能的開發。

• 自動化冗餘工作（Automate the redundant work）

將團隊成員從冗餘的勞動中解放出來，無論是自動化的測試還是自動化工具的開發只要能夠節約成本都是敏捷開發、敏捷測試的目標。

• 民主的團隊（Democracy in team）

敏捷團隊是一支民主的團隊，團隊關係是平行的，每個團隊成員能夠平等的參與討論，決策。傳統開發的垂直的官僚機構在敏捷開發中已是過時的。

• 尊重團隊（Respect to team）

敏捷團隊的決定權交有團隊自己，決定是團隊統一制定。無論是產品設計方案還是產品的功能實現都是的最佳結果。團隊脫離了任何一個成員的工作都是不完整的，所以我們應當足夠尊重其他成員的勞動果實和表達對其他成員的充分信任。尊重團隊，尊重團隊中的每一個成員都是敏捷開發的原則之一。

你敏捷了嗎？

你敏捷了嗎？經過上面的學習，我們應該已經瞭解了敏捷的實質，並且筆者認為如果您的團隊已經表現出上述的特點，那麼您的團隊已經敏捷了。但是，往往很難做到如此理想的敏捷。而同時，我們需指出敏捷與否也並非我們的最終目標，我們的目標是能夠通過學習敏捷的方法和最佳實踐來開發可以適用於自身特點的方法和過程，幫助專案靈敏的適應市場變化，讓我們變得敏捷起來。

因此，我們依然希望進一步幫助大家瞭解如何變得敏捷，而首先，還是讓我們學習大師留給我們的一套基本準則幫助我們判斷專案開發敏捷與否吧。通過按照此標準的衡量，我們將容易得出專案是否敏捷的結論，也能夠因地制宜的找到問題所在，最終實現敏捷。

Scott W. Ambler 在其文章 How Agile Are You？ 中指出了以下七條原則幫助大家來判斷什麼專案是敏捷的專案。

1. 專案中有利益干係人（Stakeholder）的參與
2. 團隊擁有並且可隨時執行的迴歸測試
3. 關注產品自身而不是冗餘的文件
4. 專案開發擁有嚴格的原始碼管理、版本控制
5. 開發能夠積極面對和響應專案需求變化
6. 團隊作為整體直接擔負專案責任
7. 能夠自動化重複性的活動

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-408756/，如需轉載，請註明出處，否則將追究法律責任。