我對敏捷開發是源於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迎娶白富美。

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

借力于敏捷開發工具

目前很多大公司都推出了自己的敏捷開發工具，我逐一瞭解和試用過，個人比較推薦華為去年推出的華為軟體開發雲，華為的研發實力就不多說了，裡面的Scrum敏捷開發相對來說還是很容易上手的。而且是雲上服務，即開即用，可以實現開發和運維同步迭代，快速開發，快速反饋。

結束

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

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