工作一年多了，所在的公司採用敏捷開發。作為小團隊裡一名普通的開發者， 既體會到了敏捷的優點，也收穫了很多經驗教訓。在此記錄一下自己地感悟，如果有朝一日自己去領導一個敏捷開發團隊，要儘量想辦法避免和解決這些問題。

背景介紹：

公司的開發進度是大概每5－7周釋出一個小版本，這裡麵包括了1周的各種測試時間和1周的上過渡伺服器的時間，所以實際上code freeze一般是每個開發週期開始後的3－5周。本人所在的小團隊大約有5到6名開發，其中包括一名Team Leader，4名QA。 團隊也有一名PM, 但是遠在美國，一年見面溝通時間不足一個月。公司採用JIRA作為專案管理和追蹤的系統。每個開發週期會有很多Feature, 通常是每個Feature由一名開發負責coding，一名QA負責測試，而每名開發和QA會負責多個Feature. 某些非常大的Feature, 會由多名開發和QA組成一個更小的團隊共同開發。

Feature的複雜度和開發時間評估

在我加入公司的前半年，正好團隊在進行人事調整，除了Team Leader外，其他開發人員對每個Feature幾乎都沒有背景知識，更無從評估複雜度和所需時間, 所以所有Feature的評估幾乎都依賴於Team Leader一人。Team Leader經常性地估少了Feature所需時間（或者高估了開發的能力），過分樂觀的結果是開發和測試人員經常性地加班或者趕工，揹負了過多的壓力。另一方面，因為開發時間的倉促，也導致了Feature質量不高。

在後半年，由於Team Leader管理能力地提升，團隊成員逐漸瞭解自己負責的各個模組，加上團隊成員對之前評估不準確的種種抱怨，在Feature評估上有了一些改善。在每個開發週期開始前的例會上，Team Leader會和開發人員一個個地過這些Feature, 開發人員如果認為評估時間不準確，會給出自己的意見，然後Team Leader再跟高層管理者溝通，進行Feature的調整。個人認為，這件事情說明高質量高效率的敏捷開發對Team Leader和團隊成員的個人能力要求很高，並不是一個低門檻的開發方式。

與PM的溝通

團隊的PO (Product Owner) 職責主要由 PM 來擔任。我記得以前在看敏捷開發的一些成功經驗時，其中很重要的一條是說PO要和團隊天天在一起工作。但公司的情況是，PM都在美國，雖然會通過郵件甚至skype來聯絡，但是總有時間上的延遲以及溝通上的誤會和資訊的缺失。對於一些小Feature還沒有太大的影響，但是本人親身經歷了2個需求複雜，工程量和時間跨度巨大的Feature, 無法和PM在一起工作就帶來了各種個樣的問題。有一次，按照需求文件花了2周時間做完的部分，在和PM電話討論時被告知文件寫錯了，因而對底層程式碼又花了1周時間進行了大換血，浪費了寶貴的時間。更經常的場景是，因為無法實時地面對面地與PM溝通，當Feature大體完工後，PM會對各種細節給出超過20個修改意見，又是本可避免的巨大的時間開銷。 個人曾經非常希望在做其中一個大型Feature的時候去美國與PM一起工作，不過公司似乎完全沒有考慮過，所以只能咬牙堅持。不過如果以後自己做事情的話，一定會盡量避免這種“異地”問題。

團隊激勵與士氣

這是所在團隊最嚴重的問題之一。管理者沒有做出足夠的努力去了解每個團隊成員，很少進行team building之類的活動（一年好像只有2次），更沒有采用任何有效的激勵方式，直接造成了一些成員沒有積極性、情緒低落，甚至對工作完全失去興趣。所表現出來的就是產品質量低、效率差、不穩定。如果我是管理者，哪怕自己掏錢，也要隔一小段時間就帶其他成員去吃飯喝酒談心，去了解他們的想法和情緒，然後在工作中做出適當調整。如果有條件，更會給予優秀者豐厚的激勵，給非常不上進的人嚴厲地處罰，保持團隊士氣向上。

個人英雄主義完全不可取？

幾乎每個公司都在說要注重團隊合作，杜絕個人英雄主義，但本人的實踐感悟是，普通情況下團隊合作是對的，但是在一些時間緊、專案大的場景，個人英雄主義可能更能帶來更好的結果。從最後一個季度，我主要做了兩個大專案。第一個用時一個開發週期，只有我一個人負責。第二個用時3個週期，第一個週期主要我一個人，第二個週期4個開發人員，第三個開發週期還在進行中。因為第一個專案和第二個專案的第一個週期基本上就我一人，所以不存在什麼‘不同意見’的情況，都是我自己思考和做決定。雖然也會犯錯誤，但是都能保證在最短的時間完成最多的Feature，同時保證系統的performance和stability維持在一個高標準上。

問題就出在第二個專案的第二個開發週期，這時候其他幾位成員陸續進入共同開發，本以為能為我分擔很多工作，讓我更專心攻堅一些框架上的問題。結果由於大家在一些問題上的見解非常不一致，同時因為我沒有任何權力和資歷去做任何決定，所以造成了在很多問題上無休止地爭吵，以及一些實現上地互相妥協和返工，完全打亂了我自己的計劃和節奏。就個人標準而言，對第二階段的產品非常不滿意，在accuracy, performance, stability上都遠沒有達到我的預期。思考良久，覺得如果當初讓我主做這個專案時，賦予我一票決定權、一票否定權，然後給每個人的工作職責一個非常明確的劃分，不允許大家越界干擾其他人的工作，只可以定義‘介面‘來溝通，相信會比現在有一個更好的結果。

一言堂固然不可取，但過度Team Work有時帶來的更是負面作用，不僅耽誤了時間和進度，同時使產品因為各人不同的理念而變得四不像。其實敏捷開發很像打仗，因為要在有限時間和資源下攻取一個個陣地。這時，如果要派人帶兵去作戰，就一定要賦予這個人兵權，否則如果因大家意見不同而不聽命，互相扯皮，甚至互相拖後腿的話，會陷入很尷尬的境地。