敏捷開發

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

可是在接觸敏捷開發這個體系以前，本身有機會作一個項目，那個時候我開始將本身認爲更有利於項目的管理工做作了一些應用，那個階段個人主要作法是：

一、項目中開始劃分更短的製品交互週期，而不是之前那樣等待產品開發完畢後發佈各類測試版本。
二、更充分與市場人員交流，在市場人員進行需求交底時，讓更多的甚至全體成員參與會議，瞭解產品的原始業務及需求。而且在過程當中有問題也及時的解答及溝通。
三、增強溝通力度，開發測試都在一塊兒天天都會開個小會，通報每日的工做成果，將本身的問題說出來。
四、不一樣以往的發佈頻率，測試從項目開始便要切入到產品生產過程，而不是等到最後全部功能都完成後。從而大大減小變更對計劃的影響。

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

後來本身有機會回到了老東家，開始本身帶團隊，很巧老東家被收購後開始推廣敏捷開發，只不過由於不是總部，因此此次沒有範本，徹底由我本身來組織及控制。很高興這個小團隊幾個月下來，我的以爲比較成功，固然後面也獲得了公司的承認。

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

需求在開發中的重要性

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

然而，事實卻不是想象這麼簡單，無數的例子說明了一點，僅僅在需求調研過程當中瞭解到的需求是沒法保證的。數不清的例子告訴咱們，需求是會變的，變的緣由不少。在極端的狀況下，有些客戶簽字的需求在開發完後，有須要變動也很正常。

因此需求是影響軟件開發的第一重要因素，需求來源於業務，咱們開發的產品不就是由於這些業務纔去作的嗎？如何需求都沒法把握好，還談什麼開發出好用的產品？

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

強調人與人的交流

無論怎麼樣開發過程當中主要仍是靠人的，並且軟件開發是個複雜的團體工程，一個小些的產品也會涉及到各種人：客戶、業務分析、管理人員、程序員、測試員等等。這麼多人在一塊兒作事情，有一方沒有處理好結果確定就會有問題。

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

這種例子可能你們常常經歷吧？

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

經過上面的步驟，就不至於在開發完成後才知道用戶的真實想法，由於不少用戶對軟件開發是沒有概念的，他只知道本身有某種需求，但最開始是沒有一個完整的概念的。因此就要經過不斷的讓用戶看到產品的模型，這個過程用戶纔會逐步的對產品產生概念。一樣的在過程當中客戶的提出需求變動也是在必定的可控制範圍以內，這樣一來能夠大大的減小軟件返工的狀況，天然就不會拖延計劃了。

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

強調文檔的做用

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

但敏捷真的不須要文檔嗎？我想不是的，如何把文檔作到好維護我想纔是最重要的。文檔到底指的指的什麼？什麼樣的算文檔？

提出上面兩個問題，咱們先想一想常常說的文檔的做用是什麼？不就是一個傳播工具嗎？能夠用做記錄、給他人看、用於之後查看。有不少方法可就解決了這個問題，好比wiki系統。維護一個wiki系統，能夠隨時寫，隨時維護，能夠方便的查找。嗯，多方便。

另一個問題就是什麼樣的工做須要造成文檔呢？

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

像這種關鍵的內容有份文檔仍是很重要的，不然隨着時間推移，誰也不能保證能記得住當時爲何會這麼幹。

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

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

團隊協做

一、減小對開發人員的干擾

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

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

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

大部分的人都不是超人，在一個時間段內處理超出本身負荷的工做是很難作好保質保量的。因此對於開發管理人員必定要考慮到這點，儘可能讓開發人員有比較好的工做進度環境，經過外界的方式來解決一些開發團隊的干擾。

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

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

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

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

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

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

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

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

三、發揮團隊人員的潛力

敏捷開發比較提倡開發任務由開發本身評估並認領工做任務，這樣能夠激發開發的潛在動力。

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

因此充分發揮好每一個人員的特色，讓人可以在本身感興趣的工做中，效果會不少。減小指派方式的任務的分配，充分發揮我的的主動性，這個團隊精神面貌也會好不少。

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

做爲團隊的Leader要參與到團隊的工做中去，好比一個開發主管必定要寫寫代碼，參與架構等對項目有關的事情，而不是在那裏分分任務。這樣團隊成員纔會以爲這個Leader很親近感。

特別是有些開發主管在帶隊後離團隊愈來愈遠，有時對於開發進度不如意時就說：「這麼個簡單功能怎麼會搞了這麼久？」，其實天天都在加班的同事內心想着：「有本事你來？」，即便這個小組長有這個能力，但對於團隊來講也不是一件好事，由於你們都抱有怨恨之心，還談什麼好好工做呢？這個小組長就是失職的。因此這種狀況下應該主動去了解進度滯後的緣由，而且本身要加入到解決問題的工做中去，而不是在邊上抱怨別人。

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

中國幾千年的文化，官本位一直影響着咱們，你們都想坐在那指揮，本身啥事也不用幹，想一想都愜意。在咱們這個行業是否是發現也很相似？你們都想着幹幾年當個小組長，而後升個部門經理，當上CTO迎娶白富美。

團隊的管理基本是事與人的管理，很是的傷腦和心。若是一個組織內，特別是小組織內「官」太多，協調就會很是的難，你們就會常常性的扯皮。

結束