建立敏捷團隊的敏捷思維

什麼是「敏捷思維」

敏捷的議題快速並且廣泛地興起，雖然敏捷觀念及方法的好處很多，該如何實作會比較有效呢？需要從敏捷思維的建立先做起。
「敏捷思維」並非是一套制式的規範，而是一種mindset，一種認知，以及是一種文化，可以讓團隊成員對敏捷精神及作法有基本的認識，當團隊成員都有了比較一致的思考方式時，自然會形成一個團隊文化。

本文會舉出在建立敏捷團隊過程中，必要的兩個敏捷思維。並且在一般專案的執行中，論及在台灣企業運作的客戶專案，常會有的既有的思維，會使得「敏捷思維」在建構敏捷團隊時有哪些難行之處。

一、全員參與

敏捷團隊的全員參與是極重要的敏捷思維。

這點是大多數專案與產品團隊非常容易忽略的。在台灣的企業與組織文化中，慣常用Top-down從上到下與統一指示的的決策模式。團隊會在辦公室中「想像」 使用者的需求、或是由開發者的觀點，認為使用者要什麼，或者直接是由主管來拍板定案。

敏捷思維是以團隊為運作的核心，團隊成員必須有個共同的目標，讓團隊的運作可以交付End-to-End的產品或服務。

1.    使用者為中心

依據agile manifesto敏捷宣言（2001）裡頭的精神：「敏捷本身不是方法，他代表的是一種價值觀與理論，個體互動高於流程與工具，文件只是一個幫助的工具，但真正的價值是個體與軟體互動的需求」

讓使用者能全程參與，建立起持續且即時取得使用者回饋的機制，並在每日的工作內不斷地實踐出來，是敏捷團隊成員能逐步發展出使用者為中心思維的關鍵。

敏捷團隊成員須重視換位思考，彼此參與大家在團隊中擔任的角色體驗，每個人都要對於產品與服務負責，技術與用戶體驗在敏捷中是不分界線的。

2. 引入敏捷模式提升團隊默契與生產力

打造出透明的團隊文化，讓成員有足夠的管道與空間發揮，勇於提出想法、接受挑戰。也因此，團隊成員得以跳脫原本的職能框架，相關屬性人力產生互援協作的可能性。

將「敏捷精神」植入為團隊的 DNA ，在每兩週的 Scrum Sprint運作中 ，透過Daily Standup Meeting、Sprint Review Meeting、Sprint Planning meeting與Sprint Review Meeting，讓每個人都敢於發表想法、提出改善建議的全員參與精神。

討論可採用實體或線上的Kanban、memo，讓每個人能夠更有參與感，可以更專注去看到團隊運作的狀況與遭遇的問題。

3. 跨職能的敏捷團隊

為了更快反應市場的動態變化，團隊需要有足夠的自主權、並且能針對產品或服務進行改善，並非被動式的等候工作指令或是依賴其他成員的工作結果。例如，傳統軟體開發流程分為「前端團隊」與「後端團隊」，在一般的工作流程中，不論哪個團隊都要依靠另一個團隊才能完成工作，而這就不符合跨職能的敏捷團隊。

當然，在現實中單靠敏捷團隊的自主運作，要做到100%的「End-to-End服務」是有難度的，但這是敏捷所追求的終極目標。由此可以看出敏捷是一個彼此自我優化與彼此學習的過程。

在平時打造出透明的團隊文化，讓團隊有足夠的管道與空間發揮，勇於提出想法、接受挑戰。也因此，團隊成員得以跳脫傳統軟體開發的職能框架，尋求相關屬性人力產生互援協作的可能性。

二、自我組織敏捷團隊 : self design team

敏捷方法之所以需要一個高度自律的團隊，就是希望能透過「對團隊的充分授權」，達到「團隊自主扛起專案成敗責任（Ownership）」的成果。因此，這個團隊最好可以自我組織和自我管理，以達到最大的成效，因為自發性所組成的團隊，所產生的合作默契和凝聚力，必然會比由主管直接指派組成的團隊要好得多！

不過，這種做法企業組織必須要有足夠的人力資源，並且已有敏捷式專案管理的良好經驗才行。因為，唯有體驗過敏捷方法的緊密合作遊戲規則後，大家才知道該找什麼樣個性特質的夥伴來組隊合作。因此，光憑有敏捷方法經驗這一點，其實是還不夠的。

我們知道，任何專案都有其立案的目的和目標（例如，時間、預算、該完成的功能/特色等），這些是專案眾多限制條件中的一部份，還有另外一部分限制條件則可能來自於客戶的要求，或是來自於現有技術的極限。組成的同仁們必須充分瞭解這些專案限制條件，才知道該找什麼樣職能條件的夥伴們來組成團隊，以自主獨立完成專案，不需太多團隊以外的支援，這也就是所謂的「跨職能完整戰力團隊」。

然而，理想歸理想，現實是現實。在實際的專案執行中，特別是台灣企業的階層式組織文化，往往會仰賴「主管群」的工作分派與決策制定，並要賦予職務上的權限。完全要靠著團隊可完美、自主性的運作，在台灣的企業組織文化確有難度。因此，適度地取捨和折衷方案是必需的，這也是為什麼應該讓「主管群」們來參與遴選決策，而非由「一個人」來決定的原因。

套用敏捷方法的精神，「組建敏捷團隊」這個任務本身其實也應該是「敏捷」的。就是先快速讓團隊成形並成行，運行幾個Sprint來觀察看看團隊的狀況之後，再決定怎麼調整敏捷團隊的成員組成，這樣一定能夠讓敏捷團隊運行地愈來愈順暢。團隊順了，事情自然就順了，專案自然就能順利成功！