敏捷實踐中的好品質

假如你的團隊已經使用敏捷或者敏捷過程的某些內容有幾個月了，無論是開發人員、產品經理、架構師、QA，還是管理層，組織中的每個人可能都非常喜歡敏捷的這次首航。此時，你可以認為，你的團隊已經發現了一個合適的過程，並可以沿著這個過程走下去了。可需要提醒你一下：“別那麼快下結論！如果不小心的話，這個快樂的聚會可能會以你始料不及的速度結束。”

本文聚焦於某些行為模式，它會使團隊最大程度地認識到敏捷首航的好處，並保持該過程中得到的經驗。本文的前提是：你已經在你的組織中執行了敏捷過程。

成功的實踐者會注意到：敏捷更倚重於紀律，而不是幾個天才。因此，實踐的重中之重就是：把“人”放在第一位，聚焦於價值，頻繁地交付高質量的工作成果，通過有節奏重構進行持續改進。一般的團隊只要有紀律性，即使在敏捷實踐的初期，它也會獲得相當大的成效。如果我們這樣做了，隨著時間的推移，我們的言行就會積極地推動建立並重建我們團隊和專案所處的環境。

很多人都知道下面的學習三步法¹：

• 第一步，“照葫蘆畫瓢”，儘管沒能完全理解規則，依然按著它做事。
• 第二步，“邊做邊想”，隨著不斷地實踐這些規則並從所犯的錯誤中總結教訓，開始思考我們到底在做什麼，並觀察如何在更深的層次上實踐這些規則，看它們之間的關係是什麼樣的，當前面對的困難是什麼。
• 第三步，“無招勝有招”，當我們掌握了規則以後，我們就會忘記這些實踐，而只要做我們認為是正確的那些事情，使模式不留痕跡地融入到我們的工作中。

當我們堅持實踐敏捷的法則（如結對程式設計、TDD、編寫使用者故事、進行計劃遊戲）時，我們就建立了由這些實踐互互動補所形成的網，而這個網產生的效果要超出這幾個實踐單獨產生的效果之和（譯者注：1+1>2）。這些效果是我們始料不及的。一旦我們知道了這些益處，接下來的問題就是：我們怎樣才能保持這些收益並持續改進呢？這個問題的答案就是回顧（retrospective），它不僅使我們知道做錯了什麼，還有做對了什麼：即我們要鞏固和繼續堅持的東西。

輸入“Agile Karma”，可以得到從過去的示例中總結出下面的結論：

敏捷品質：是指一些根本原則，這些原則是依據那些專案參與者在每個迭代中總結前一個迭代的做法（也可能是錯誤的做法）並對其進行改善所獲得的經驗提煉出來的。

好的效果對每個團隊都不同，對每個團隊中的不同的人也不同。因為儘管根本原則都一樣，但每個團隊都會找到不同的方法來實踐它們。這就是為什麼說回顧（retrospectives）很重要，不僅要看什麼做得不好，還要回答“做對了什麼？”或“我們如何才能保持現有好的做法？”這樣可以幫助團隊保持士氣，表揚他們所做的事，不知不覺中，這就成了團隊走向成功的關鍵因素。

我們先分析一些例子，就會總結出：對於客戶團隊來說，什麼是好的敏捷品質，不同的團隊角色如何開展工作。那麼，你們團隊的好的共同品質是什麼樣的呢？

客戶的好品質

客戶是產品或專案的“司機”，保持並調整著方向，與團隊討論它，並提供反饋。通常客戶團隊由產品經理、資訊架構師、QA、可用性工程師等組成。

• 牽記最終的目標：敏捷軟體開發並不是建議你“只瞭解某個迭代內的業務，而不對整體業務進行全面瞭解”。針對其產品，你應該有一個清晰明瞭且完整的故事列表（story-board）。持續地溝通，使目標更清晰。
• 在迭代前做好作業： 在迭代會議之前，你應該完成以下內容：
  • 想清楚這次迭代的目標。
  • 清晰地定義故事。每個故事應該：
    • 有清晰且具體的目標。
    • 有清晰的可接受性準則。
  • 對於開發人員要進行開發的故事（Story），在迭代計劃之前要準備好測試用例。
  • 如果是新產品，應該有互動和流程圖，比如紙上畫的原型或條框。
• 尊重團隊的迭代計劃：一旦確定了迭代計劃，不要改變迭代範圍，在迭代中不許加入新的特性。
• 堅持頻繁演示：在新的迭代開始之前，團隊向客戶展示上個迭代結束後的成果。在整個迭代中，客戶能夠與開發人員一起工作，並在下一個迭代開始之前驗收本次迭代中做好的Story。

開發人員的好品質

開發團隊不僅包括寫程式碼的人，還包括那些為建立迭代結束時的可交付產物提供他們的各種技能的人。這個團隊決定如何提供客戶所要求的功能。

• 把客戶看作夥伴：在寫一個Story之前，你要真正理解客戶想要什麼，並給客戶提供更好的建議和設計。一旦完成了Story，向客戶解釋並得到使用者的反饋。
• 儘早溝通：不到等到迭代或釋出的最後時刻再溝通相關的問題和風險。如果你發現一些東西改變了你的評估，馬上通知你的專案經理。
• 更新計劃：每天根據你的評估以及Story的狀態來更新迭代計劃。
• 尊重業務優先順序：與你們不斷交付的業務價值相比，業務可以有它自己的議程。當你不能確定業務的優先順序時，就去問，不要假設。
• 尊重程式碼基線的質量(不要偷懶)
  • 堅持測試先行的開發及重構
  • 心中默唸“不做重複程式碼”的咒語。
  • 頻繁持續整合
  • 在提交程式碼之前，執行所有的測試
  • 不要對失敗的建構置之不理
  • 不要輕視架構
• 保持團隊協作
  • 頻繁地要求得到資訊
  • 即使你很忙，也要為他人提供幫助
  • 承擔別人不想承擔的任務
  • 公開承認隊友的貢獻

內部教練或技術Leader的好品質

與對Agile的瞭解程度相比，技術Leader可能更瞭解團隊及技術。在行政位置上，這可能使他們比顧問更有優勢，可能會彌補他們在敏捷實踐方面的經驗不足。

• 堅決地指導：這是個艱鉅的工作，尤其是與外部顧問指導相比。只要有耐心，隨著時間的推移，你最終會被大家接受。不要放棄－做正確的事一定會得到大家的尊重。
• 錘鍊你的技術能力：為了成為一個發揮效力的教練，堅持作為團隊的一員是非常重要的。如果你的技術能力不濟的話，每天提高一點兒。
• 不要讀得太多：在讀下一本書之前，先理解其基本思想，並把它們傳達給整個團隊。
• 發現良師益友：很多資深教練從其他人的幫助中獲益。反過來，他們也願意回答你的問題並提出自己的見解。吸收這種不同見解可能是明智之舉。如果在本地找不到敏捷興趣小組，那線上論壇就可能是一個尋求幫助的好去處。
• 設法讓關鍵人員和管理層“擰成一股繩”：不要喪失你的威信。你還是要對你的老闆和其它重要的人員負責。設法讓他們團結在一起，使新的方法得到他們的信任。

諮詢顧問的好品質

諮詢顧問是一個有經驗的“受僱槍手”，他可以帶領團隊或組織戰勝採納敏捷過程中所要面對的挑戰。這樣可以縮短學習曲線，並使其平滑過度。但它不能代替團隊的自學習性。一旦顧問離開團隊，自學習性會保持並指導這個過程。

• 根據需求進行定製：學習定製過程，以便滿足業務目標且適應公司的文化，而且要有充分的理由。如果公司文化不允許迭代，那就先嚐試兩個星期的迭代，但一定要確保管理層認識到了這種折衷方案帶來的風險。
• 多聽，多學：一個高效的教練一定是一個好聽眾和學生。不要衝上來就把你的想法和知識強加於團隊。
• 認識到批評者的價值：是的，有些人不喜歡敏捷，但你不能忽視他們的想法而只關心支援你的人的想法。批評者會提供一些重要的資訊，而且可能成為有價值的團隊成員。
• 握住你的槍：當團隊堅持要放棄某個基本實踐時，問他們是否知道"放棄這個實踐的話，如何才能補償它帶來的損失。"幫助團隊應對它帶來的風險。如果他們堅持這樣做，最好說"我以前沒這麼做過。讓我們一起來解決這個問題"，而不是給團隊一個自己都不知道會帶來什麼結果的建議。
• 謙恭地提供幫助：保護並恢復所有參與者的自尊。
• 知道什麼時候轉到幕後：當團隊開始採納敏捷並且變得更主動時，知道如何轉到幕後。如果必要的話，讓他們自己做決定，讓他們自己從錯誤中學習。

專案經理的好品質

實踐證明，這個角色很難定義（在不同的上下文中會有不同的意思，而且差別還比較大）它常常是幾個角色的混合體。我們決定對這個角色另眼相看，現在把它排除在這篇文章之外。（同時,我們也希望得到讀者的建議。)

上層管理者的好品質

每個專案中，上層管理者都是一個關鍵的專案干係人，但也是最少控制交付物的人。通過對實施工作提供強有力的支援，管理者可以保持溝通渠道通暢，並對所出現的重大障礙做出快速反應。

• 公開支援這個行動：在你的公司會議或季度會議上，公開表態，堅決支援這個過程。這樣將會促進敏捷的引入。
• 別期望出現奇蹟：“我花了很多錢，卻什麼也沒得到！”。團隊需要時間去定製和培養他們的過程，最終才能看到結果。組織級的挑戰越大，花費的時間就越長。要時刻牢記：再好的過程也不能解決團隊本身的問題。
• 避免日期驅動的誘惑：“就這麼定啦（Just get it done）”的口頭禪(bravado)需要改為“讓我們研究一下，是否通過改變工作範圍來滿足這個日期要求”。
• 不要草率地在公司範圍內全面推行：初步嘗試取得成功以後，你可能會熱衷於在全組織範圍內推廣這個過程。在推行之前，一定要確保你真正地理解了這種方法的內涵和約束。
• 在談論敏捷之前一定花時間去真正地理解它：既然團隊是敏捷的了，你就會想與您的朋友或其它公司討論敏捷。而此時可能是您多讀一些相關知識的最佳時間。在這一點上，您與那些比您多知道一些敏捷知識的人溝通時，敏捷興趣小組成員會對您很有幫助。

希望這會使您考慮一些問題，例如：既然當您感到壓力卻不想放棄時，你的團隊在做什麼呢？為什麼不在下一個回顧（retrospective）上花些時間，使您的團隊從您這裡得到更多的資訊呢？當事情發生變化時，別忘記時刻去更新它的狀態。您知道事情一定是會有變化的!

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