前言

近幾年敏捷開發猶如旋風一般刮過國內的軟體開發公司，不管是一線網際網路大廠，還是大型國企亦或是二三十人的小公司幾乎都已經或試圖嘗試敏捷，但搞多的團隊絕大多數都失敗了。本週作者結合自身團隊經驗說一下在匯入敏捷之前需要做的幾件事。其實這類題目已經差不多寫爛了，但大多都是集中在理論上，實際使用遇到不少問題，所以這篇文章講的主要是實施層面，至於原理有時間再討論。

啟動的開始之前

敏捷活動的推動者的身份極為重要，如果你是一名開發者，想要嘗試推廣敏捷模式，你成功的機率極為渺茫。如果你是一名團隊管理者，那麼你成功的機率比一名普通的開發者要高一個數量級，但還是不高，保守估計不超過3成。如果你是一家公司的高層，能夠協調各種組織級的問題，同時擁有樂於挑戰經驗豐富的開發團隊，那麼恭喜你你離真正的敏捷並不遙遠，但比較諷刺的是這樣的公司本身就應該是相對敏捷了，並不需要大幅轉型。
為什麼對於大多數傳統企業來說實施敏捷怎麼這麼難，因為敏捷開發不僅僅是一種軟體開發模式和方法學，更是一種對於團隊文化甚至是組織形式的轉型。如果還想不到那麼可以嘗試著回答下面幾個問題。
1.你的組織如何評定團隊的績效？團隊有沒有KPI指標
2.你的組織如何評定員工的績效？
3.專案經理或負責人對於專案團隊成員的績效有無直接發言權？
4.軟體團隊是否擁有足夠的測試運維基礎設施？
5.你的團隊願景是什麼？

要做的事

思考為什麼匯入敏捷

關於敏捷對於你意味著什麼，這個問題永遠需要仔細的思考，如果你不確定，那麼你可以停下來，再想想。

徵求支援

這一點在初期極為重要，無數人倒在這一步。支援分為三個方面:
1.上級的支援。由於敏捷活動一般都是由喜歡新事物和挑戰的技術人員發起的，而上級的支援對於解決敏捷與組織流程的衝突中扮演著至關重要的作用。
2.一線技術人員的支援，敏捷開發是由一線的技術人員實施的，因此尋求他們的支援和理解將為敏捷轉型提供來自基層人民群眾的呼聲。
3.敏捷教練的支援，要匯入敏捷最好還是有一個教練或導師來輔助，這樣可以避免走不少彎路。

確定專案

一般敏捷匯入都會選擇先在試點專案上試驗，再逐步推開的模式。萬事開頭難，一個好的開始將極大的推進整個轉型過程，選擇試點專案最好選擇，規模適中，失敗影響較低的專案，不能選太小的，太小的專案無法體現出優勢更無法有利於推廣。

確定團隊

選擇的團隊也是很有講究的，最好選擇團隊氣氛較為活躍，對於新生事物能夠保持興趣，同時勇於挑戰，成員技術水平較高，並且責任心較強，成員要包括從設計，開發，測試。注意開始的團隊人員不宜過多，以5~7人為佳。

環境準備

為開發團隊準備一個獨立的房間，開放式開發環境，並且清空一面牆作為任務版，再搞一兩個白板即可。
同時最好有配合開發的持續整合系統，版本管理系統以及bug管理系統等。

結論

目前大部分將敏捷的資料大多集中在敏捷的形上，但比起方法來講團隊文化也許更能決定團隊效率。形敏而神不敏是一場註定的悲劇。