敏捷開發從信任團隊開始

最近接觸了一個正在執行傳統瀑布式流程的開發團隊，發現不管是開發人員還是專案經理都非常想運用敏捷開發的模式。可惜開發人員有想法，而專案經理並不真正瞭解敏捷。目前的結果是一團亂，不論是開發的效率還是溝通的有效度都很低。

本文僅記錄一下個人對類似團隊的建議。

信任團隊

敏捷宣言價值觀背後有十二條原則，其中有一條是這樣寫到的：

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
激發每個個體來完成專案。給予他們所需的環境和支援，並且信任他們能完成任務。

當我詢問專案經理為什麼這個團隊不能使用敏捷開發時，得到的答覆是：“我們的人員素質不行。”：

1. 淨做些與工作無關的事
2. 推動專案進度很難
3. 幾個人盯一臺電腦，浪費時間

但這幾點其實在我的觀察中，卻變成了不錯的敏捷實踐：

1. 團隊會主動重構程式碼
2. 團隊會主動的安排工作的優先順序
3. 團隊會結對程式設計

其實專案經理這幾點看法無可厚非，首先說說「重構」，因為重構某種程度上可以理解為一種返工，這對瀑布式專案來說是走回頭路，代價很大。開發團隊適時的重構可以讓後續的工作更輕鬆的開展，而專案經理經常會忽視這一點。

而「任務優先順序」這件事上，傳統的模式是專案經理去指派各項任務，這種方式有一些弊端：臨時的任務太多，打斷工作的連續性；如果任務之間有相互依賴性，專案經理指定的優先順序將會失效。而Scrum這一敏捷實踐中的“專案經理”——Scrum Master卻承擔著保護團隊在迭代中免受干擾的責任，每個迭代的工作範圍是相對固定的，並由團隊自行挑選和承諾可交付的內容。

而多個資源做同一件事往往不是浪費時間，「結對程式設計」對於團隊的互相學習和監督、任務的透明化、程式碼規範化以及增強凝聚力都有非常正向的作用。

---

組建「自組織」團隊

敏捷開發團隊是「自組織」的（self-organizing team），自組織的團隊是平等的、主動的。很多人說要讓團隊達到自組織的狀態很難，我也非常同意，人難免有惰性。作為一個敏捷的推廣者或是專案的管理者，更要善於發現團隊中每個個體的閃光點以及不足之處。上面所說的團隊已經很有主動性了，而團隊如果已經習慣了指令式的管理，主動性匱乏，管理者也可以通過以下幾點來營造自組織的氛圍：

• 讓個體相信自己能在工作中充分發揮和實現價值

  團隊的目標是需要達成一致的，這沒錯，但是每個個體想要實現的價值通常不一樣。優秀的管理者能讓每個個體都發光發熱，都有奔頭，而不是讓某一個或幾個個體獨佔其功。很常見的一個例子就是不要讓同一個人一直負責同一個模組，這不僅會讓這個模組變得無法維護，也會豎起壁壘讓其他成員無法靠近。

• 建立透明的、暢所欲言的溝通渠道

  「開放」是Scrum的五個價值觀之一，敏捷宣言也強調了「面對面溝通」的重要性。專案知識的透明是絕對必要的，沒有對等的溝通，每個個體的工作頻率就會搭不上。而暢所欲言的文化的前提是傾聽的能力，別抹殺那些創意十足的想法。

• **確保團隊遵循平等的準則 **

  自組織不等於無紀律，管理者要建立適當的團隊共同遵守的準則。這裡所說的團隊包括管理者，所有專案的參與者應該是平等的，沒有等級、職位的高低之分。如果站會時專案經理坐著翹二郎腿，那就失去站會的所有意義，變成彙報會了，效率之低可想而知。

敏捷沒有固定的流程，更多的是一種文化和思想，要全面接納敏捷，就慢慢從組建團隊開始吧。

先寫到這裡，下一篇會介紹如何用工具減少不必要的工作。

《那些拯救程式設計師的「神器」 | 自動化敏捷開發》
《「便利貼」裡的專案管理 | 利用看板提升溝通效率》