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

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

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

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

什麼是敏捷軟件開發呢？

敏捷開發是以用戶的需求進化爲核心，採用迭代、按部就班的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分紅多個子項目，各個子項目的成果都通過測試，具有可視、可集成和可運行的特徵。換言之，就是把一個大項目分爲多個相互聯繫、而又能夠獨立運行的小項目，並分別完成，從而實現快速開發的目的。

仍是具體來講下敏捷開發是如何實現的？

一、將大的系統拆分紅子項目。

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

  而敏捷方法是會將大的系統拆分紅一個個子項目，再把子系統拆分紅子模塊，儘可能減小模塊間的耦合性、增長其內聚性，這樣咱們能夠把團隊分紅多個小組，各組能夠同時做業。另外，當一個模塊需求發生變化時，對其它模塊的影響也不會太大，以實現下降開發難度的目的。

  在以前提到的房產信息網平臺建設中，咱們就將系統拆分紅自行成交、經紀成交、用戶權限管理、建委等外部接口、大宗資產、交易管理、平臺後臺管理、網站前端等模塊分別進行需求討論，需求討論後再將各模塊拆分紅各個對象，對象與對象間只是經過公有變量傳遞信息，儘可能減小與外部對象間產生關係。

總結：化整爲零個個擊破

二、團隊與客戶呆在一塊兒

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

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

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

三、用建模方式溝通

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

  在房產項目裏，咱們用原型與客戶討論需求，用ER圖溝通數據庫設計，用類圖來表達產品的對象，用部署圖肯定硬件部署環境及網絡結構，用活動圖來講明信息交互流程，用時序圖來表達在時間軸下對象間的交互。經過各類圖表來表達產品，利用這種方法會比較直觀，並且當發現錯誤修改起來也容易，不像利用文檔方式，修改不方便、維護困難，也不利於閱讀、理解。

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

四、勇於迎接變化

  市場環境是產品的風向標，咱們要隨時關注市場。爲了迎合市場，產品也要隨時變化。需求變化、設計變化……各類變化讓咱們焦頭爛額，但作爲產品人的咱們一樣也應該接受改變，只有產品的快速變化，才能很好的迎接將來。咱們歡迎變化，只要是合理的，哪怕是開發階段，需求也一樣可能發生變化。敏捷開發容許變化，經過變化給客戶帶來更大的競爭力。敏捷開發利用圖表來記錄需求，全部代碼都採用模塊式設計，將不一樣功能儘可能分割，減小關聯。這就是它可以、也勇於迎接變化的緣由。

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

五、儘早、持續的交付可運行的階段性成果

  以前我曾經說過，一個項目的失敗，通常不是技術緣由，可能是由於客戶對咱們失去信任。咱們須要持續的、不斷的給客戶以信任感，一種是咱們在客戶現場不斷的交流、溝通，讓客戶感覺到咱們的熱度。一樣，還須要儘早的、持續的給客戶提供相應的成果物（可運行的產品），讓客戶看到咱們的能力。固然，這樣還有另外一個好處是，可以把問題提前的暴露出來，不要羞羞答答像個小女人，不敢見人，只有提早暴露，才能提前解決，問題越晚暴露越難解決。

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

總結：爲了下降項目風險，儘早交付可運行程序

六、面對面的溝通

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

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

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

七、可工做的軟件是最主要的衡量標準

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

總結：作出可交付的軟件是項目的核心

八、保持恆定的開發速度

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

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

九、按期團隊優化

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

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

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

它爲團隊提供敏捷、任務、需求、缺陷、測試管理、WIKI、共享文件和日曆等功能模塊，幫助企業完成團隊協做和敏捷開發中的項目管理需求；更有甘特圖、看板、思惟導圖、燃盡圖等多維度視圖，幫助企業全面把控項目狀況。

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

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

總結：

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