工作一年多了，所在的公司採用敏捷開發。作為小團隊裡一名普通的開發者， 既體會到了敏捷的優點，也收穫了很多經驗教訓。在此記錄一下自己地感悟，如果有朝一日自己去領導乙個敏捷開發團隊，要盡量想辦法避免和解決這些問題。
背景介紹：
公司的開發進度是大概每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有時帶來的更是負面作用，不僅耽誤了時間和進度，同時使產品因為各人不同的理念而變得四不像。其實敏捷開發很像打仗，因為要在有限時間和資源下攻取乙個個陣地。這時，如果要派人帶兵去作戰，就一定要賦予這個人兵權，否則如果因大家意見不同而不聽命，互相扯皮，甚至互相拖後腿的話，會陷入很尷尬的境地。
程式設計中的一些感悟
1 學習應該從基礎打起，不要一開始就嘗試最高深的技術。2 每看一本書，不要說這章我以前學習過了，也掌握的很好，因此我可以跳過這一章看更重要的了。3 對於作業，遇到不會的盡量不要立刻向別人請教。如果實在解決不了的問題，可以先完成你會的，然後把一些特別的難點提煉出來，向高手請教。3 不要指望書本和行家能...
人生中的一些感悟
1 從小沒有培養好性格的人，以後要付出時間的代價去換取相應的認知，可能是一年，十年或者半輩子。而我超過六年。3 愚蠢的人會被眼前的果凍吸引，即使注意到遠處的牛排。許多人因為電子遊戲提供的短暫成就感而忽視了自己的夢想。4 大部分人都有這樣一種缺點 不見棺材不落淚，或者以為自己理解了，而實際上只是表面的...
程式設計中的一些感悟
這篇感悟寫的不錯，特此轉貼 1 學習應該從基礎打起，不要一開始就嘗試最高深的技術。2 每看一本書，不要說這章我以前學習過了，也掌握的很好，因此我可以跳過這一章看更重要的了。3 對於作業，遇到不會的盡量不要立刻向別人請教。如果實在解決不了的問題，可以先完成你會的，然後把一些特別的難點提煉出來，向高手請...