成功實施敏捷之十薦

　　我并不是第一個寫“高效的敏捷實施之十大習慣”此類文章的人，我也肯定不會是最后一個。事實上我并不想又創建出這么個長長的列表，因為有太多類似的列表充斥著敏捷實施的世界

　　曾有人報道Ken Schwaber說過在所有試圖實施Scrum的團隊中大約只有30%的團隊能夠成功。但Ken在他的博客上說他并不記得這么說過，反而指出大約只有30%的團隊能夠成為“出色的開發組織”。

　　而我認為這條引用有趣之處在于它符合眾多變更管理的案例。正如變更專家哈佛教授John Kotter經常提到的有70%的重大變更將會以失敗而告終。

　　然而當你真正研究下數據，你會發現這個預測并不樂觀。有一天當我授完課，有人問我：“我們能做些什么來保證我們能成為那30%成功的團隊之一?”——那個時刻我知道我會創建這個列表。 并不是說10這個數字有什么魔力，這個列表也可以是7項或12項，這個列表的數目可以是這三個數字中的任意一個。但當我真正把所有的列表項放在一起時，我發現比起其他我能想到的，或者那些不那么有效的項，10項是不多也不少。

　　因此，這個世界又多了一個“十大”列表。

　　1) 找一塊真正的白板

　　“我把霰彈槍裝進阿迪達斯運動包，又往里塞了四雙網球襪，把包包填實在。這完全不是我的風格，可我要的正是這種效果：如果他們覺得你是個兇悍家伙，就跟他們玩技術;如果他們覺得你是個技術型，就跟他們玩兇悍。我是技術型，所以我決定兇悍點，越兇越好。”William Gibson的短篇故事——Johnny Mnemonic中如是說。

　　我非常確定的是，成功實施敏捷的團隊與沒能完成敏捷實施的團隊之間最簡單最大的區別就在于，他們使用了一塊真正的實體白板。

　　我明白有些團隊覺得搞一塊真正的白板很難做到，我也明白有些團隊分散在不同地域以至于無法共用實體白板，我也明白可以通過計算機技術(電子白板)來實現白板功能，但我仍然堅持我的觀點。如果你能搞來一塊真正的白板，讓大多數但不一定全部團隊成員都能看到，那你就會接近成功。

　　這似乎很難解釋我這么建議的理由，但你必須去親自嘗試它，體會它。我個人感覺當抽象的、理論的軟件世界遇見真正白板和卡片時會發生奇妙的事情。

　　讓你的工作具體化僅僅是個開始，學會如何看懂白板上的內容并根據這些開始工作則更為重要。

　　2) 啟動數據收集并使用統計數據

　　開發速率、燃盡圖、發現的Bug、記錄的Bug等等。在軟件開發的很多情況下，度量數據的名聲都不好，但這是由于人們并未很好地選擇合適的度量數據，或者收集與使用的不當所造成，并不能代表度量數據是無用的。你至少需要度量你的開發速率并創建一個燃盡圖或一個累計流量圖。

　　敏捷的優雅之處在于你只需去度量它的一些簡單的度量數據。一旦度量太過復雜以至于人們無法理解，那就無法從中受益了。正如白板，度量數據只因自身價值而變得有用，切勿變成一種學習儀器。

　　3) 聘用一位教練或顧問

　　雖然我必須承認你完全可以自己實施敏捷模式，我仍然愿意冒著被大家指控為自己攬活的風險，如此建議。你可以看書、做實驗、看一些課程。但這樣做將使得整個敏捷模式的流程變得緩慢并且增加了風險以至于你無法成為那30%成功的團隊。更糟的是敏捷實施將變得冗長并引入更多的風險。

　　個人而言，很難區分敏捷實施教練和敏捷實施顧問，一般來說他們有能力完成以下各項：

　　觀察、檢驗、詢問并質疑你所正在進行的活動的想法

　　對選擇何種實踐和流程并對如何更好地實施它們提供建議

　　提供他們所見的成功或失敗案例，以及其他團隊是如何解決類似的問題

　　你可能需要和不同的顧問一起工作，因為很少有人可以了解所有的流程、實踐、技術、產品及戰略基準。對非常大的團隊而言，有必要找一個全職顧問。盡管我所經歷的大部分成功項目所采用的模式是“輕觸型教導”結合之后章節所講到的“引導”變更模式。

　　我并不認為你需要聘用一個全職顧問對敏捷模式進行教導但我建議把這項工作做成可持續性的。之前我曾實踐過并寫過有關“輕觸型教導”，在這種模式下我間隔地回公司進行敏捷模式的教導，有時候可能每個月去一次或者更頻繁，有時候少一些，但討論一直持續著。

　　4) 別光說不練

　　請別光說不練，行動永遠比空談有效，你無法預見將發生的所有困難與問題直到你真正開始去做敏捷模式。你花在空談如何去做卻從不開始的時間越長，越可能建立起不切實際的期望，最終使之變成又一個管理層的噱頭。

　　你可以無時無刻地談論它，并為之做計劃，但除了親身投入進去并開始進行敏捷模式別無他法。邊做邊學習邊改善，使用一些度量手段去了解正在發生的事情。切勿浪費大好時間去尋找成功案例，而應該自己去完成一個成功案例。

　　特別不要花時間困擾究竟是做極限編程(XP)還是Scrum，精益(Lean)還是特性驅動開發(FDD)，動態系統開發方式(DSDM)還是看板(Kanban)。這些幾乎都大同小異，最終你不得不創建一種屬于自己的混合模式。

　　5) 為每個人提供培訓并進行小組討論

　　團隊并不會因為管理層認為“這就應該是敏捷”而變得敏捷起來，但很不幸，現實中這還是會發生。有些團隊成員會閱讀相關書籍，但大多數人不會，或者看后就忘記。

　　花點時間告訴人們什么是敏捷模式很值得 ——或者至少告訴他們敏捷模式對你們的組織意味著什么?，F今大多數技術人員對“敏捷模式”都不陌生，但他們能記住多少，結果是好是壞卻是天差地別的，團隊必須開始形成共識。

　　但千萬不要僅限于此，花點時間讓人們說說敏捷模式對他們而言意味著什么，什么是他們喜歡的，什么是他們不喜歡的，什么是他們會做的，而什么是他們不會去做的。敏捷模式是一項團體項目，除非他們形成共識，不然他們只會各顧各地做。這項討論必須始于培訓初級階段，以有助于團隊形成自身特有的共同認識。

　　6) 要激勵、要引導、不要生拉硬拽

　　任何一名在公司工作過幾年的員工總能不幸地見證管理層自上而下地硬拽最新的變更方案：業務流程重組(BPR)、ISO 9000、Sig Sigma、CRM等等。某些人拍腦瓜想到某些點子，然后開動變更機器將點子推行下去。

原文轉自：http://www.kjueaiud.com