關于
敏捷方法論的
文章已經很多了。其中，相當一部分文章講述了敏捷方法技術方面的問題，比如
測試驅動開發和持續集成。同樣，還有相當一部分文章討論了敏捷 方法論的應用問題，例如發布計劃，跟蹤生產率，如何使用度量數據對過程“調優”，甚至讓公司里的業務人員確信需要采納一種特別的方法。讀過這些有關敏捷方 法的文章后，很容易讓人產生一種感覺，即通過購買一套工具并遵從一系列看上去很簡單的實踐，就算采納了像極限編程和Scrum這樣的敏捷方法。然而，現實 世界的經驗表明，成功地采納敏捷要比那復雜得多。它涉及到如何培養一些正確的做事態度來建立信任，鼓勵交流與協作，最終讓人們更加適應，并產生高效。
敏捷方法常常被描述為以人為中心，而不是強調技術，并有充分的理由來說明這一點。然而，雖然敏捷宣言強 調了“個體和交互勝于過程和工具”的重要性，但它并沒有清晰地闡明如何處理這個重要的社會性維度。在強調技術的業務中，這些都太簡單，無法概觀個人態度在 項目團隊中的強大影響力。要想知道哪種態度可以促進（或阻撓）敏捷的采納，我們要問一個問題：“在成功的開發者和管理者之中，我們能發現那些與眾不同的行 為嗎？”，更重要的問題是 “這些行為是由什么態度驅動的呢？”
很多開發者習慣于獨立
工作，花費大部分的時間來閱讀規范，并完成設計和編碼。在前敏捷環境（pre-agile environment）中，一些開發者甚至戴耳機聽音樂，不聽來自辦公室的“噪音”。采納極限編程的開發者發現其自身已經融入到更加社會化的環境了，在 這種環境下，成功依賴于與同伴和客戶更緊密的協作。另外，經典的前敏捷開發是個體獨自“擁有”那些設計和編碼。在敏捷環境下，工作任務由團隊共同決定： 沒有誰能獨自擁有某段代碼。這種態度的調整可能特別具有挑戰性。
剛接觸敏捷開發的人可能習慣于在那種將自身劃分成子系統再進行開發的項目。他們習慣于依據各子系統之間互聯的高層次規范，獨自負責某個子系統的設計。剛接 觸集體代碼所有制的開發者很容易被他們不得不掌握的代碼的數量嚇倒。與此同時，很少的技術文檔（甚至沒有技術文檔）和快速變化的代碼基線（包括那些熟悉的 類名和方法名都有可能在短時間內發生變化）很可能加劇這種情況。但是，敏捷方法論（特別是極限編程）要求編程人員有很強的編碼能力。通過對缺乏經驗和富有 經驗的敏捷開發人員的觀察，很容易就可以看出不僅僅是技能問題，態度也是非常關鍵的。
表1：傳統團隊與敏捷團隊的對比
表一在代碼級別上列出了一些傳統團隊與敏捷團隊的不同。富有經驗的敏捷開發者有不同的編碼方法。他們傾向于靈活編碼，而不是等到整個設計都很完善了再進行 開發。另外，他們還傾向于把編碼視為
學習和探索的機會。例如，遇到一個問題時，他們總是通過編寫一個小的概念驗證模型或“技術原型（spike solution）”使問題具體化，而不是構建一個復雜的模型或者通過自然語言描述來說明各種行為。同樣，敏捷開發者更愿意去閱讀第三方的代碼。有時候， 他們想做一些力所能及的改進；有時候他們這么做只是為了學習一種新的設計方法。最后，通過盡可能地讓類、方法以及與潛在的方法調用鏈等相互獨立，以便僅了 解局部代碼就足夠了，這樣就不用去花很多時間去研究整個子系統或應用。所有這些差異能更好地使開發者發現并處理編碼中出現的問題，而不是僅僅使用高超的編 碼技能完成任務而已。
拿結對編程為例。對于采納敏捷方法論（尤其是極限編程）的團隊來說，結對編程是最有爭議的幾個問題之一，因為它需要兩個開發人員共同完成同一段代碼。雖然 一個開發者可能具有杰出的設計能力并精通開發平臺，但作為一個高效的XP開發者，他還必須能夠溝通思想，協作進行測試，提供可能的實現方案，并在某個實現 策略上達成共識。很多開發者不愿意進行結對編程，并不是因為他們不會編碼，而是因為他們不熟悉結對編程。有個開發者在他的blog中寫道：“結對編程會使 他們暴露他們真正的知識和技能水平”。獨立編程時，別人只會看到編碼結果。而結對編程時，不順利的開始和早期犯的錯誤都會被別人看到。這時肯定會有一種壓 迫感，甚至對高水平的開發者也是一樣，要花上一段時間才能習慣。值得牢記的是：當你了解了其它團隊成員，并且熟悉每個參與者的個性之后，結對編程就會變得 容易起來。
大多數成功的極限編程者對使用各種語言編程、學習新的設計方法都相當感興趣，特別是閱讀已存在的代碼。這些成功的開發者愿意通過嘗試做一些小的練習來“實 踐”編碼。他們可能會通過編寫一些小工具或參與開源項目進行實驗。在這里，著重強調“實踐”是非常重要的。好的敏捷開發者常常通做一些事情來掌握知識和技 術，而不僅僅通過閱讀了解它。
“極限編程是共產主義……”這就是某個開發者對結對編程的牽強解釋。他提到，在XP中的編碼使大家分享了的各自的經驗，他嘲笑“集體代碼所有制”，并對所 有開發人員可及接觸所有領域的工作以便能夠編寫任意部分的代碼這一事實嗤之以鼻。我與這個開發者聊過一段時間以后，才明白他的想法實際上是為了與他人競爭 以保住“飯碗”。他擔心同一團隊中以及不同團隊間的競爭問題。與別人一起工作意味著允許別人看到他是怎樣解決問題的，用了什么工具，這就使別人有機會學到 他的訣竅。他對結對編程的反感表明，在敏捷團隊中需要解決個人英雄式開發和“飯碗”問題。結對編程很自然地使開發者向同事敞開胸懷，分享領域知識，并時刻 準備把你的方法與大家分享。
一個極度自信的開發者也可能會拋開結對編程這一方式。有時面對生產速率下降而一個成員獨立工作可以使其提高的情況下會發生這樣的事。另外，當一對開發者中 的某個人能力不濟，而另一個人就會把“結對”變成“個人秀”。 還有一些時候，其中的一個開發者可能急不可耐地想完成任務，因為一些個人原因驅使他盡快完成用戶故事，可能最顯而易見的原因就是“野心”：試圖通過展示技 術能力成為團隊領導者，或得到其它晉升機會。這樣的態度很容易使結對褪變成一個“得分比賽”，比賽的目標就是看誰能贏，而不是設法完成有意義的工作。
過少的發言權也可能是成為一個問題。一個開發者很少主動關心他的結對任務的話，很可能他就會被他的伙伴所領導。在這種情況下，這個開發者實際上是放棄了很多在設計和代碼質量上的責任。
塑造敏捷教練
至此，我們僅討論了在開發者中發生的常見實踐問題。然而，創建和維護一個具有敏捷態度的開發團隊也是教練和其他領導者最重要的責任。這些領導者必須為他們的團隊建立一套好的樣例并成為真正的教練，而不是成為只有“教練”頭銜的團隊成員。
最有效的領導技能之一就是建立一整套好的樣例。開發團隊會建立一整套規則，比如所有的產品代碼要結對編寫，所有的產品代碼都要先寫測試等等。只有團隊成員 堅信這些規則是非常重要的，這些規則才會起作用。然而，“說了不做”真的是太容易了。例如，團隊領導者向團隊成員宣布：“構建失敗了，我們現在最重要的任 務就是修復它。”剛聽到時一定會信以為真，可是接下來的話卻不是那么回事了，“我第一個發現了這個問題，原本應該由我來修復它，可是我太忙了。”他的行動 使其對這件事的重要性大打折扣。別人會認為，構建可能是現在最重要的事，也可能不是。作為一個團隊領導者，讓別人看到他正在與一個開發者一起修復這個構建 是很平常的事情。這么做可以向團隊成員進一步表明，構建是一個非常重要的事。
好的教練并不僅僅是知道如何教開發人員技巧，還要鼓勵開發人員務實思考，并高效協作。這有點與Ken Schwaber所描述的ScrumMaster 的角色相似，即該角色對鼓勵團隊協作負有責任。當教練拒絕解釋而直接用自己的知識來解決問題或者以命令的口氣來領導團隊時，這就是一個不太好的信號。
我想，最好從外面請一個人來作為“教練”幫助團隊，而不應該是團隊的固定成員。如果教練是團隊中的一個固定成員，那么會存在利益沖突：有時他要幫團隊成員，以便提高團隊能力和效率；而有時他要客觀地評估團隊，在團隊成員之間做一些比較。就象Kent Beck在他的《Extreme Programming Explained》一書中所提到的，一個教練應該有一個目標，即幫助團隊成長，最終達到不再需要教練。一個好的教練需要一定的自信和情緒控制力，也需要技術能力和經驗。
鏟除潛在的問題
有幾個潛在的因素會對團隊態度產生負面影響。一些團隊成員很擔心：他們的團隊領導做改革只是為了進一步達到個人目標，而不是為了使團隊做得更好。另一部分 成員不愿意面對變化的原因是怯于表達。另外一個特別麻煩的問題就是：誰不喜歡自己得到夸獎，并可以批評別人呢？可是我們真正需要的是虛心地接受批評和學 習。
在軟件業，很多創新可以得到個人獎勵。寫東西和在會議上講演顯然都會提升個人形象。技術領導者、教練或處于同樣角色的人就處于一種可以引入變化的位置上。 我們應當意識到，盡管我們鼓勵創新，但變化也有可能帶有破壞性或給已經高效工作的團隊更大的壓力。因此，和團隊一起進行回顧找到解決方案要比由領導宣布某 種改進策略要好得多。
“激勵整個團隊擁抱變化要比使用權力來執行對他們自己及業務有利的某些變化好的多”。對于領導者來說，能認識到這一點是非常重要的。正如一個開發人員抱怨 說：“這么做只能使我們更傷心。他們只想通過會議來使他們看起來更有權力。”他認為在他的團隊中，只是為了使團隊中一兩個權威人士顯得更專業就將某種革新 強加在團隊之上，甚至不顧這會使軟件交付的每日任務更難完成。所以另一個關鍵之處就是要認識到每個人都需要穩定性和安全感，而過多的變化會使其很快動搖。
然而有時很明顯的是，人們已經根深蒂固地反對那種尚未發現的變化。不管已經有多少人的擔憂被巧妙地說了出來，還是會有更多的擔憂不斷涌現，這是經常發生的 事情。很可能那些提出個人擔憂的人就有某種個人或動機問題需要改進，這是好事，但說出來以后并不一定會感到舒服一些。例如，很多人可能會對極限編程提出一 些技術和業務方面的異議。很少有人會坦言真正困擾他們的到底是什么。例如，你不可能聽到：“使用XP意味著固定的工作時間，所以我不能到學校接我的女 兒。”
當團隊成員發現他們可能要使用某種新的技術平臺來構建一些產品時，同樣的事情也會發生。一些開發人員強烈反對這樣做，他們的理由就是“我們需要多考慮一些 技術問題，例如可擴展性、學習和維護成本、工具的質量等等”。幾個月以后，我們就會發現，真正的原因是很多開發人員不想花時間去研究被提及的新平臺，因為 他們感到學習新技術平臺會證明他們的個人學習能力不行。從專業角度來看，盡管職業發展、就業能力和工作與生活的平衡都都是很正常的問題，但對于個體來說， 還是很難消除這種擔心。
在培養敏捷團隊中的最后一個潛在因素就是需要一點謙虛的品德。在敏捷團隊中，謙虛有很多好處。其一就是它減少那種反生產力的“得分式(point scoring)”競爭的可能性。這正是與XP中的“做最簡單的事”相吻合的心態，正象Steve McConnell在《Code Complete》中所指出的，它鼓勵開發人員寫可讀性更高的代碼。當你想批評別人，尤其是當他正努力采用敏捷方法的時候，你就該學習如何保持謙虛的心態 了。雖然別人有缺點，但當你看到了一個缺點并自問“我曾經犯過同樣的錯誤嗎”時，這才是重要的。你可能無法改正別人的缺點，但你肯定可以從中學到東西。
結論
在敏捷團隊中培養高效的態度和工作方式是一個復雜而關鍵的活動。很多試圖進行敏捷項目的人把焦點放在業務上。盡管業務很重要，但是一定要記住：項目干系人 都是人。他們也有他們的個人需求和關心的事情。一個成功的自組織的項目團隊需要每一個參與者都能真誠地來推動各方面的改進。敏捷不是被“統治”出來的，但 是，假如給予那些具有能動性的團隊成員進行自我組織的自由，那么敏捷是能培養出來的。