探討敏捷開發在軟體開發中的應用

在軟體工程領域，有過很多軟體開發模型，如瀑布模型、快速原型模型、增量模型、螺旋模型、演化模型、噴泉模型、 RAD 模型、敏捷軟體開發模型、 XP 極端模型。這麼多的模型各有各的應用場景、各有各的適用範圍，但我認為最實用開發模型還是敏捷軟體開發。

中國式軟體開發思路是什麼樣的呢？從我接觸過的大多軟體專案來看，基本都有一個共同特點——就是必須快，客戶都是急脾氣，恨不得今天立項，明天就要你拿出產品來。

面對公司和客戶如此快節奏的要求，我們有辦法嗎？人們從生產、生活中總結出來一套即高效又優質的開發模式——敏捷軟體開發。

什麼是敏捷軟體開發呢？

敏捷開發是以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視、可整合和可執行的特徵。換言之，就是把一個大專案分為多個相互聯絡、而又可以獨立執行的小專案，並分別完成，從而實現快速開發的目的。

還是具體來說下敏捷開發是如何實現的？

1、 將大的系統拆分成子專案。

  以前我們接受過的思想是立項後先要需求調研、分析，調研後出各種調研報告及需求說明書，需求搞定後，再進行概要設計（ UE 設計、 UI 設計、互動設計、資料庫設計、框架設計），概要設計完成後再進行詳細設計……這樣一個週期下來，耗費太長，當進度進入下一階段，當上一階段有問題時，會影響到整個專案流程的各個階段。

  而敏捷方法是會將大的系統拆分成一個個子專案，再把子系統拆分成子模組，儘量減少模組間的耦合性、增加其內聚性，這樣我們可以把團隊分成多個小組，各組可以同時作業。另外，當一個模組需求發生變化時，對其它模組的影響也不會太大，以實現降低開發難度的目的。

  在之前提到的房產資訊網平臺建設中，我們就將系統拆分成自行成交、經紀成交、使用者許可權管理、建委等外部介面、大宗資產、交易管理、平臺後臺管理、網站前端等模組分別進行需求討論，需求討論後再將各模組拆分成各個物件，物件與物件間只是透過公有變數傳遞資訊，儘量減少與外部物件間產生關係。

總結：化整為零個個擊破

2、 團隊與客戶呆在一起

為了降低溝通成本，我們團隊所有人員直接開到客戶現場，隨時與客戶溝通，透過面對面的溝通，減少了理解偏差。在專案的各個階段，我們一直與客戶保持零距離接觸，隨時交流、溝通。透過這種辦法，可以第一時間獲取需求、第一時間解決問題，減少出錯的可能性，提高開發效率，保證開發質量。而且，透過這種方式會更容易取得客戶信任，客戶能夠隨時瞭解到專案的工作狀態、工作進度。當相互間具備了信任關係後，餘下的工作也會變得輕鬆、愉快。

在房產專案裡，我們在客戶現場辦公，定期開會討論需求和設計，當有一些小的不確定問題，團隊成員會直接找到客戶相關人確認。在整個專案週期中沒有發生過大的需求變化。

總結：與客戶面對面的交流，降低交流成本，促進相互信任。

3、 用建模方式溝通

  利用模型與客戶溝通，用模型來獲取使用者需求，而不是透過大量的文件，編寫文件費時費力，而且效果不好。實際，對於我們大多數人來說並不喜歡花大量時間看各種文字和引數，而模型則會更直觀和立體。這裡我說的模型不是單指我們平時設計的原型，它包括用例圖、類圖、部署圖、狀態圖、活動圖、包圖、物件圖、原型圖、效果圖、 E － R 圖等，利用不同圖形表達出產品的不同維度，使產品豐富而立體。

  在房產專案裡，我們用原型與客戶討論需求，用 ER 圖溝通資料庫設計，用類圖來表達產品的物件，用部署圖確定硬體部署環境及網路結構，用活動圖來說明資訊互動流程，用時序圖來表達在時間軸下物件間的互動。透過各種圖表來表達產品，利用這種方法會比較直觀，而且當發現錯誤修改起來也容易，不像利用文件方式，修改不方便、維護困難，也不利於閱讀、理解。

總結：利用模型來代替文件進行交流。

4、敢於 迎接變化

  市場環境是產品的風向標，我們要隨時關注市場。為了迎合市場，產品也要隨時變化。需求變化、設計變化……各種變化讓我們焦頭爛額，但做為產品人的我們同樣也應該接受改變，只有產品的快速變化，才能很好的迎接未來。我們歡迎變化，只要是合理的，哪怕是開發階段，需求也同樣可能發生變化。敏捷開發允許變化，透過變化給客戶帶來更大的競爭力。敏捷開發利用圖表來記錄需求，所有程式碼都採用模組式設計，將不同功能儘量分割，減少關聯。這就是它能夠、也敢於迎接變化的原因。

    提到了敏捷的一個很重要思想就是“勇於迎接變化”。就有人說了，你一定不是技術出身的吧。做技術的就討論變化，最不允許的就是確定的需求再修改。當產品經理與技術人員溝通時，當談的一個複雜性操作時，經常說：“你確定不會修改了吧，如果你確定需求不變，我就做！”，你要答應了，再找技術修改時哪就等於堵死了自己的後路。實際，哪能一定有不修改的需求呢？我們做產品不也是時刻在迎接市場的考驗嗎？在大海上航行，當風向變化，我們的大船不也得時刻準備掉頭，準備調整。變化，本身就是為了適應，沒有變化，就等於沒有進步。但作為產品經理的我們，能做的應該是利用自己的智慧和敏銳的市場洞察力，儘量的去感知風向，儘量的控制需求，在需求發現初期就做好充足的調研。怕變化，不是辦法，在專案初期就要做好靈活可調整的方案，如果需求真的變化了，我們應該怎麼辦，這才是敏捷的思想，需求的變化，我們誰能阻攔得了呢？

5、 儘早、持續的交付可執行的階段性成果

  之前我曾經說過，一個專案的失敗，一般不是技術原因，多是因為客戶對我們失去信任。我們需要持續的、不斷的給客戶以信任感，一種是我們在客戶現場不斷的交流、溝通，讓客戶感受到我們的熱度。同樣，還需要儘早的、持續的給客戶提供相應的成果物（可執行的產品），讓客戶看到我們的能力。當然，這樣還有另一個好處是，能夠把問題提早的暴露出來，不要羞羞答答像個小女人，不敢見人，只有提前暴露，才能提早解決，問題越晚暴露越難解決。

在房產專案中，當天完成的內容在編譯沒問題後，會把修改的功能部署到平臺伺服器上，以便於客戶隨時能夠看到變化，瞭解專案進度。如有問題的話，也能夠儘早暴露出來。

總結：為了降低專案風險，儘早交付可執行程式

6、 面對面的溝通

  最快的交流方式就是面對面的溝通，在敏捷開發中，最提倡的方式是減少哪此冗餘的、效率低下的溝通方式，用最快速的方法來直接溝通。讓技術人員、設計人員、客戶等所有團隊成員都在一起辦公，減少資訊交流的斷路，讓溝通變得順暢。

  在房產專案中，當有問題不理解，需要交流時，都是直接找我，我不清楚的直接找客戶。當我不在時，同事們也會直接與客戶進行溝通，任何人都可以直接獲取需求。

總結：直接溝通，減少中間環節

7、 可工作的軟體是最主要的衡量標準

  出再多的文件、再多的中間產物，都沒有出結果來得真切。客戶最觀心的不是中間物，而是成果物。對於敏捷軟體開發來說，可以工作的軟體是評測開發進度的最主要衡量標準。唱的再好，也不如做的好，做事要落地，實實在在、踏踏實實是敏捷開發的核心，不玩花拳繡腿。

總結：做出可交付的軟體是專案的核心

8、 保持恆定的開發速度

  專案開發是一次長跑，短期內迅速的加速，並不是長跑的方式，我們應該持續的、勻速的跑步方式，這樣才能保證團隊成員能一直堅持到最後。敏捷開發提供可持續的開發速度，這樣不僅團隊成員不至於疲憊，也有利於制定專案開發進度，控制開發週期。

總結：專案開發過程是長跑，不要一開始就衝刺

9、 定期團隊最佳化

  我們會每隔一段時間進行一次團隊建設，進行批評與自我批評，找出工作中的問題及影響個人與團隊發展的瓶頸。我們透過交流、溝通方式找出團隊及成員間的問題，然後進行自我調整，透過不斷的最佳化、升級自有團隊，打造出一個能戰鬥的隊伍。

10、 配合使用敏捷開發工具

  CORNERSTONE 是一個一站式專案管理協作平臺， 適合各大敏捷開發團隊，旨在幫助各大企業進行智慧管理，解決研發專案管理痛點，它支援持續交付與整合，能夠透過各個維度跟蹤記錄專案進度，幫助團隊輕鬆配合完成目標。

  它為團隊提供敏捷、任務、需求、缺陷、測試管理、 WIKI、共享檔案和日曆等功能模組，幫助企業完成團隊協作和敏捷開發中的專案管理需求；更有甘特圖、看板、思維導圖、燃盡圖等多維度檢視，幫助企業全面把控專案情況。

  同時， CORNERSTONE還自帶檔案儲存和共享、文件協作功能，並且可以實現團隊之間的實時溝通。換句話說，選用 CORNERSTONE，可以不需要再挑選文件協作工具、檔案儲存和共享工具、團隊內部溝通工具。

  此外，不僅是產品研發，銷售、運營、行政審批也可以使用 CORNERSTONE進行管理。使用統一的管理平臺，對於企業來說無疑是大大降低了管理成本。

     總結：

如果專案管理者能夠很好的運用敏捷開發思想，就相當於在遊戲世界裡擁有了法器，美食世界裡掌握了烹飪之道。在敏捷開發裡還有許多其它思想，但有的思想本人並不太認同，如用“測試驅動開發”，在中國與在國外不同，在國外有ＣＭＭＩ，對測試要求非常高，測試實際就是質量檢查部門、質量控制部門，有著很高的許可權，對測試人員也是更加尊重和認同。在國內，公司多重開發而輕測試，從你公司測試人員與開發人員的薪水上就能看得出來，誰更受重視。想讓測試人員驅動開發，在目前的現狀中有些難以做到。有時我想，前人已經總結出了那麼多好的思想，確實應該多學學、多看看、多用用，但拿來的思想並不一定全適用，每種思想都有著自己的成長土壤，不是隻要多施肥、多澆水就能長出好莊稼。有時，也要看看，植物的習性，是否更適應我們的環境。 CORNERSTONE 現在申請20人以下團隊即可免費使用。