我對敏捷開發是源于10多年前看了一本關于迭代開發的書，從而對迭代開發有了一些興趣。從那時開始有了迭代開發的概念。隨著項目經驗的增加迭代的重要性也越發覺得明顯。隨后進入了提倡敏捷開發的公司，被迫式的接觸了許多“敏捷開發”，隨著項目經歷越來越多，慢慢的就開始有了更新的認識和想法。

但是在接觸敏捷開發這個體系之前，自己有機會做一個項目，那個時候我開始將自己認為更有利于項目的管理工作做了一些應用，那個階段我的主要做法是：

1、項目中開始劃分更短的制品交互周期，而不是以前那樣等待產品開發完畢后發布各種測試版本。
2、更充分與市場人員交流，在市場人員進行需求交底時，讓更多的甚至全體成員參與會議，了解產品的原始業務及需求。并且在過程中有問題也及時的解答及溝通。
3、加強溝通力度，開發測試都在一起每天都會開個小會，通報每日的工作成果，將自己的問題說出來。
4、不同以往的發布頻率，測試從項目開始便要切入到產品生產過程，而不是等到最后所有功能都完成后。從而大大減少變動對計劃的影響。

在做這些工作的時候我并不知道敏捷開發這個東西，直到在2010年進入一個公司非常提倡敏捷開發，已經有了迭代周期、backlog、站立會議、周例會等等，在這個團隊中對開發過程有各種規章要求，完全是制度化的，這在我加入的初期非常的不適應。事實上回頭想想，那種方式已經變的不敏捷了，完全是一種教條式的應用。

后來自己有機會回到了老東家，開始自己帶團隊，很巧老東家被收購后開始推廣敏捷開發，只不過因為不是總部，所以這次沒有范本，完全由我自己來組織及控制。很高興這個小團隊幾個月下來，個人覺得比較成功，當然后面也得到了公司的認可。

下面就敏捷開發分享一些應該著重注意的點，解決這些問題我想對任何開發團隊都會有很大的幫助。

需求在開發中的重要性

大量的開發過程告訴我，需求在軟件開發過程中是極其重要的。傳統的開發強調初期的需求調研及需要分析，這個過程對于一些正規的團隊會產生大量的文檔，而后交由開發展開產品生產。

然而，事實卻不是想象這么簡單，無數的例子說明了一點，僅僅在需求調研過程中了解到的需求是無法保證的。數不清的例子告訴我們，需求是會變的，變的原因很多。在極端的情況下，有些客戶簽字的需求在開發完后，有需要變更也很正常。

所以需求是影響軟件開發的第一重要因素，需求來源于業務，我們開發的產品不就是因為這些業務才去做的嗎？如何需求都無法把握好，還談什么開發出好用的產品？

然而如何做好需求呢？我想首先要確立需求的地位，然后只有通過不斷的溝通、嘗試、反饋向真實需求邁進。

強調人與人的交流

不管怎么樣開發過程中主要還是靠人的，而且軟件開發是個復雜的團體工程，一個小些的產品也會涉及到各類人：客戶、業務分析、管理人員、程序員、測試員等等。這么多人在一起做事情，有一方沒有處理好結果肯定就會有問題。

有這樣一個例子：客戶提出了一個會員管理功能需求，需求人員了解后組織了解決方案，于是交付了開發實現。而經過二個月無盡的黑夜之后交付，需求一看有個模塊做的有偏差，但是已經來不及修改了。交給客戶看后，發現這不是他們要的會員管理功能相差較大，另外在功能開發的這一段時間，客戶又有了新想法，要對原先需求做調整。

這種例子可能大家經常經歷吧？

這種問題在敏捷開發方法中提出了解決方法，就是通過不斷的交付可用的制品。看起來很抽象，其實很簡單。同樣是上面的例子：
? 客戶提出會員管理功能需求
? 需求人員在了解需求后與開發負責人商量，確定一個快迭代的開發計劃，每二周向客戶演示一次，并將這個計劃與客戶確認
? 確認后需求人員向全體成員講解需求背景故事
? 開發負責人組織并確定迭代計劃內容，明確每個迭代提交的產品目標、開發任務安排、測試跟蹤計劃
? 每個迭代過程中都由需求及測試進行確認每個任務的實現結果是否跑偏
? 后面就是每二周向客戶演示一次產品，并獲得客戶的反饋
? 根據客戶的反饋調整下個迭代計劃，并繼續下一個迭代
? 直到產品交付

通過上面的步驟，就不至于在開發完成后才知道用戶的真實想法，因為很多用戶對軟件開發是沒有概念的，他只知道自己有某種需求，但最開始是沒有一個完整的概念的。所以就要通過不斷的讓用戶看到產品的模型，這個過程用戶才會逐步的對產品產生概念。同樣的在過程中客戶的提出需求變更也是在一定的可控制范圍之內，這樣一來可以大大的減少軟件返工的情況，自然就不會拖延計劃了。

而這個過程中，需求已經完成了一個真正的過渡，不再是一頭重的情況了。他讓需求從客戶那快速的反饋到開發團隊中。同樣的，在開發不斷的交付制品時，需求也更加及時的了解到產品的進度，把握開發人員開發的功能是否符合需求。
當然這并不是一個標準做法，不同的團隊可以有不同的處理方式。這里只是想強調需求需要更多的投入到開發過程中去，及時的與客戶溝通交流，了解到客戶的真實想法。

強調文檔的作用

我覺得很多對敏捷開發的一個誤解就是不需要文檔，敏捷開發并未拋棄文檔。只是更強調更有效的方式使用文檔。在很多傳統開發方法中，特別是很多很正規的開發團隊對文檔的要求非常苛刻。然而事實是文檔不易管理，最痛苦的是不好維護，文檔需要隨著變化而變化，比如需求調整、技術架構升級、產品維護等等。如果要保證文檔的一致性，太難了。特別是對于一些無法進行有效管理的開發團隊就更加明顯，經常是軟件已經幾個版本了，文檔卻是兩年前的。

但敏捷真的不需要文檔嗎？我想不是的，如何把文檔做到好維護我想才是最重要的。文檔到底指的指的什么？什么樣的算文檔？

提出上面兩個問題，我們先想想經常說的文檔的作用是什么？不就是一個傳播工具嗎？可以用作記錄、給他人看、用于以后查看。有很多方法可就解決了這個問題，比如wiki系統。維護一個wiki系統，可以隨時寫，隨時維護，可以方便的查找。嗯，多方便。

另外一個問題就是什么樣的工作需要形成文檔呢？

記得在前一家公司，維護一個10多年的老系統修改一個公式計算的BUG，但是怎么也不知道這個復雜的公式是什么意思，問過了公司大部分的人也無人可解。這時想，如果當初有那么一份文檔，謝天謝地。

像這種關鍵的內容有份文檔還是很重要的，否則隨著時間推移，誰也不能保證能記得住當時為什么會這么干。

記得多年前一次記筆記的經歷，我看了一篇文章了解了DELPHI實現單實例模式的方法，這種方法很酷。于是整理成了筆記寫在了wiki上，第二天就得到了回復，幫助到了別外產品開發組的同事。

嗯，文檔就是這樣他具有傳播性，你不可能跑去跟所有人說出你的想法，但是文檔卻更容易達成。他也有傳承性，有些文檔也許10多年后又起了重要作用。

團隊協作

1、減少對開發人員的干擾

曾經接手一個產品的開發，最初遇到一個很頭痛的問題，原先寫好的迭代計劃，而且工作量也較大，大家都在忙著。即便在這樣的狀態下，客服人員卻經常跑來找某個程序員A維護各種系統問題，程序員A在一次維護中竟然導致了系統數據出現大面積錯誤。程序員A心理上承受著巨大的壓力，而每天的這些問題又不得不解決，加之新版本又有很重的開發任務無法完成，最終導致整個開發計劃變更。

我無法再忍受，找到了需求及客服的負責人，溝通后發現這些問題很多都是重復性的，主要是因為原先系統的不足。于是回去組織人員做了幾個后臺臨時功能，并交付給了客服人員，之后就沒有再來找過這位程序員A。后續我又找到了客服負責人，要求不能直接找開發人員解決這類問題，并與負責人約定了處理過程。

這是個例子，在實際情況中還有很多這種事情，甚至有很多開發人員要直接面對客戶。我想對于職能型團隊來說，開發團隊最好是減少這些方面的干憂。當然對于一個人包干的情況就不討論了。

大部分的人都不是超人，在一個時間段內處理超出自己負荷的工作是很難做好保質保量的。所以對于開發管理人員一定要考慮到這點，盡量讓開發人員有比較好的工作進度環境，通過外界的方式來解決一些開發團隊的干擾。

我接觸過的很多程序員都很反感這種干擾，雖然有些人在這種全面的工作強度下成長很快，但是并非所有人都適應，長期下來會有怨恨和不快，工作效率會下降。心情舒暢還是很重要的，記得有一次迭代總結時，有個程序員總結說：發現心情舒暢自己的工作效率很高。呵呵。我想你也有同感吧。

2、不要忽略測試人員在開發階段的作用

曾經多少次在項目發布前加班到深夜2點的情景還歷歷在目，那種感覺即快樂又痛苦。由于和客戶簽定的合同的交付日期就要到了，產品卻遲遲未集成完成，測試只能干等著上網聊QQ。就在下班前的一刻發布了，測試開始了緊張的測試，在屏幕閃動中，一個個的BUG提交，直到流程都無法都走不下去，測試無奈了。第二天就要發布，實施人員就等著制品第二天出差。只有不斷的改，再發布，無盡的循環。直到大家都憔悴的看著老大，終于老大說：還剩下的這幾個問題無關緊要，大家回去吧。

幾個月的開發過去后在總結會上，只能抱怨測試資源不足，時間太短，需求更改太多，需求更改后測試不知道。無數的問題一次一次的出現在同樣的總結會議上。

上面的這個例子很多人應該經歷過，真的測試只有最后一刻才能體現價值嗎？我想不是的。

在后面的項目中我總結了這個問題的，針對每個開發任務要求進行測試驗證。而測試如何驗證呢？他需要知道這個開發任務的需求是如何，提前做好測試計劃及測試用例，在接到開發制品后測試并提交BUG，這個工作是可以開發過程中就能不斷的進行的。保證每一個任務的質量，可以大大減少后期集成的錯誤量。

另外根據敏捷開發的思想，測試團隊在開發過程中也需要加強與開發團隊的交流，甚至有必要組成虛擬團隊，位置調整到一起，這樣可以及時快速的交流，參加開發團隊的站立會議同樣可以及時了解到開發的實際情況及進度，反過來把握測試計劃及測試內容。

特別是測試從另一個角度來審視需求，這樣也可以一定程度上發現或者改善需求上的不足。

3、發揮團隊人員的潛力

敏捷開發比較提倡開發任務由開發自己評估并認領工作任務，這樣可以激發開發的潛在動力。

之前在做一個新產品時，需要使用java，而我們團隊是使用C#的，面臨轉型問題。而有一位同事很感興趣，于是我就讓他負責前期的框架探索與搭建。結果就是這位小伙工作效率很高，我最初給他的目標全部都完成了。最有意思的是后面產品開始研發時，這位小伙已經成為了團隊的大牛，大家有問題都找他解決。也正是因為這個過程，這位小伙被全面激活，也在大家面前展示了能力。甚至在小伙離職時也被領導給予大幅漲薪來挽留。只不過誰又能想象到這位小伙進入我團隊之前是因為被定為裁員的目標而調劑過來的呢!

所以充分發揮好每個人員的特點，讓人能夠在自己感興趣的工作中，效果會很多。減少指派方式的任務的分配，充分發揮個人的主動性，這個團隊精神面貌也會好很多。

4、管理者不要離團隊太遠

作為團隊的Leader要參與到團隊的工作中去，比如一個開發主管一定要寫寫代碼，參與架構等對項目有關的事情，而不是在那里分分任務。這樣團隊成員才會覺得這個Leader很親近感。

特別是有些開發主管在帶隊后離團隊越來越遠，有時對于開發進度不如意時就說：“這么個簡單功能怎么會搞了這么久？”，其實每天都在加班的同事心里想著：“有本事你來？”，即使這個小組長有這個能力，但對于團隊來說也不是一件好事，因為大家都抱有怨恨之心，還談什么好好工作呢？這個小組長就是失職的。所以這種情況下應該主動去了解進度滯后的原因，并且自己要加入到解決問題的工作中去，而不是在邊上抱怨別人。

5、小組織不要搞太多的官

中國幾千年的文化，官本位一直影響著我們，大家都想坐在那指揮，自己啥事也不用干，想想都愜意。在我們這個行業是不是發現也很類似？大家都想著干幾年當個小組長，然后升個部門經理，當上CTO迎娶白富美。

團隊的管理基本是事與人的管理，非常的傷腦和心。如果一個組織內，特別是小組織內“官”太多，協調就會非常的難，大家就會經常性的扯皮。

結束

與敏捷開發結緣也有幾年，從開始的抵觸到后面的認可經歷了許多，這個過程并不是一蹴而就的，需要花時間花精力，特別是要去實踐、總結。

還有我覺得是不能太教條，很多事情都要有懷疑的心，然后去實踐總結，找到合適自己團隊的方式方法。