探讨靈活開發在軟體開發中的應用

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

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

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

什麼是靈活軟體開發呢？

靈活開發是以使用者的需求進化為核心，采用疊代、循序漸進的方法進行軟體開發。在靈活開發中，軟體項目在建構初期被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可內建和可運作的特征。換言之，就是把一個大項目分為多個互相聯系、而又可以獨立運作的小項目，并分别完成，進而實作快速開發的目的。

還是具體來說下靈活開發是如何實作的？

1、将大的系統拆分成子項目。

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

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

在之前提到的房産資訊網平台建設中，我們就将系統拆分成自行成交、經紀成交、使用者權限管理、建委等外部接口、大宗資産、交易管理、平台背景管理、網站前端等子產品分别進行需求讨論，需求讨論後再将各子產品拆分成各個對象，對象與對象間隻是通過公有變量傳遞資訊，盡量減少與外部對象間産生關系。

總結：化整為零個個擊破

2、團隊與客戶呆在一起

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

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

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

3、用模組化方式溝通

利用模型與客戶溝通，用模型來擷取使用者需求，而不是通過大量的文檔，編寫文檔費時費力，而且效果不好。實際，對于我們大多數人來說并不喜歡花大量時間看各種文字和參數，而模型則會更直覺和立體。這裡我說的模型不是單指我們平時設計的原型，它包括用例圖、類圖、部署圖、狀态圖、活動圖、包圖、對象圖、原型圖、效果圖、E－R圖等，利用不同圖形表達出産品的不同次元，使産品豐富而立體。

在房産項目裡，我們用原型與客戶讨論需求，用ER圖溝通資料庫設計，用類圖來表達産品的對象，用部署圖确定硬體部署環境及網絡結構，用活動圖來說明資訊互動流程，用時序圖來表達在時間軸下對象間的互動。通過各種圖表來表達産品，利用這種方法會比較直覺，而且當發現錯誤修改起來也容易，不像利用文檔方式，修改不友善、維護困難，也不利于閱讀、了解。

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

4、敢于迎接變化

市場環境是産品的風向标，我們要随時關注市場。為了迎合市場，産品也要随時變化。需求變化、設計變化……各種變化讓我們焦頭爛額，但做為産品人的我們同樣也應該接受改變，隻有産品的快速變化，才能很好的迎接未來。我們歡迎變化，隻要是合理的，哪怕是開發階段，需求也同樣可能發生變化。靈活開發允許變化，通過變化給客戶帶來更大的競争力。靈活開發利用圖表來記錄需求，所有代碼都采用子產品式設計，将不同功能盡量分割，減少關聯。這就是它能夠、也敢于迎接變化的原因。

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

5、盡早、持續的傳遞可運作的階段性成果

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

在房産項目中，當天完成的内容在編譯沒問題後，會把修改的功能部署到平台伺服器上，以便于客戶随時能夠看到變化，了解項目進度。如有問題的話，也能夠盡早暴露出來。

總結：為了降低項目風險，盡早傳遞可運作程式

6、面對面的溝通

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

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

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

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

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

總結：做出可傳遞的軟體是項目的核心

8、保持恒定的開發速度

項目開發是一次長跑，短期内迅速的加速，并不是長跑的方式，我們應該持續的、勻速的跑步方式，這樣才能保證團隊成員能一直堅持到最後。靈活開發提供可持續的開發速度，這樣不僅團隊成員不至于疲憊，也有利于制定項目開發進度，控制開發周期。

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

9、定期團隊優化

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

10、配合使用靈活開發工具

CORNERSTONE

是一個一站式項目管理協作平台，适合各大靈活開發團隊，旨在幫助各大企業進行智能管理，解決研發項目管理痛點，它支援持續傳遞與內建，能夠透過各個次元跟蹤記錄項目進度，幫助團隊輕松配合完成目标。

它為團隊提供靈活、任務、需求、缺陷、測試管理、WIKI、共享檔案和月曆等功能子產品，幫助企業完成團隊協作和靈活開發中的項目管理需求；更有甘特圖、看闆、思維導圖、燃盡圖等多元度視圖，幫助企業全面把控項目情況。

同時，

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

此外，不僅是産品研發，銷售、營運、行政審批也可以使用

進行管理。使用統一的管理平台，對于企業來說無疑是大大降低了管理成本。

總結：
           

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

現在申請20人以下團隊即可免費使用。