掃一掃
服務近2000家企業，依托一系列實踐中打磨過的技術和產品，根據企業的具體業務問題和需求，針對性的提供各行業大數據解決方案。
敏捷軟件開發知多少
來源：未知 時間：2018-14-8 瀏覽次數：210次
一、對敏捷軟件開發和傳統瀑布模型開發方法的理解敏捷軟件開發是一種新型的軟件開發方法，強調開發人員與業務專家（客戶）之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發過程中人的作用，開發團隊不僅包括開發人員，還包括管理人員和客戶。它鼓勵團隊成員的相互交流通過反饋機制盡早糾正軟件中的錯誤，提高開發效率，同時為需求的調整提供更多機會，保證軟件向正確的方向發展。
傳統軟件開發與 敏捷軟件開發相比而言，傳統軟件開發如瀑布模型強調預見性，嚴格遵循計劃、分析、設計、編碼、測試和維護等幾個階段。瀑布模型開發各階段間具有嚴格的順序性和依賴性，必須等到前一階段的工作結束后才能開始下一階段的工作，前一階段的輸出文檔是后一階段的輸入文檔，只有前一階段的輸出文檔完全正確，后一階段才能獲得正確的結果。
- 極限編程(XP)：溝通，簡單，反饋，膽識，為四項基本準則，快速反饋，假設簡單，遞增更改，優質工作，為5條法則，幾乎無文檔。在所有的敏捷方法中,XP對日期產生的興趣最多,并且在對良好不定的問題領域的特殊實踐方面最為具體。
- SCRUM：特別強調開發隊伍和管理層的交流協作。每天,開發隊伍都會向管理層匯報進度,如果有問題,也會向管理層要求幫助解決。
- 動態系統開發方法：堅持功能在項目的全過程中都可以改變,當功能被允許改變時,通過使用時間框控制的目的就能達到。重視為項目營造一個正確的文化氛圍,如手冊中描述了項目有不同的側重點,并指出對于那些缺陷在傳統方法中轉變起來是多么的困難。也非常重視協作價值和原理,以及文檔。
- .功能驅動開發方法，短時間的迭代階段和可見可用的功能，適合于那些不確定或常變更的需求的系統。它抓住了軟件開發的核心問題領域,即正確和及時地構造軟件。
- 水晶系列方法：相對于其它敏捷方法,水晶系列方法強調軟件開發流程的紀律性,所以它比其它敏捷方法易于使用,但它的生產率不如Xp等其它敏捷方法。水晶系列與Xp一樣,都有以人為中心的理念,但在實踐上有所不同。人們一般很難嚴格遵循一個紀律約束很強的過程,因此,與Xp的高度紀律性不同,水晶系列方法試圖用最少紀律約束而仍能成功的方法,從而在產出效率與易于運作上達到一種平衡。
- 自適應軟件開發(ASD)：ASD強調開發方法的適應性，這一思想來源于復雜系統的混沌理論。ASD不像其他方法那樣有很多具體的實踐做法,它更側重為ASD的重要性提供最根本的基礎,并從更高的組織和管理層次來闡述開發方法為什么要具備適應性。
- 迭代式開發。整個開發過程被分為幾個迭代周期，每個迭代期是一個定長或不定長的時間塊，每個迭代周期持續的時間一般較短，通常為1~6 周。
- 開發團隊和用戶反饋推動產品開發。敏捷開發方法主張用戶能夠全程參與整個開發過程。這使需求變化和用戶反饋能動態管理并及時集成到產品中。同時，團隊也能及時對用戶的需求提供反饋意見。
- 開發團隊自我管理。擁有一個積極的、自我管理的、具備自由交流風格的開發團隊，是每個敏捷項目的必要條件。敏捷開發總是以人為中心建立開發的過程和機制，而非把過程和機制強加給人。
- 持續集成。新的功能或需求變化總是盡可能頻繁地被整合到產品中。一些項目是在每個迭代周期結束的時候集成，有些項目則每天都在集成。
- 增量交付。產品在每個迭代周期結束時被逐步交付使用，而不是在整個開發過程結束時一次性交付。每次交付的都是可被部署到用戶應用環境中的、能給用戶帶來即時效益和價值的產品
- 團隊建設：以團隊為單位，強調團隊建設，賦予高度的責任，支持開發、透明的交流環境；以項目經理為領導核心，團隊成員之間交付很少
- 管理流程：流程可以簡單，但規劃與執行必須嚴謹；復雜，繁瑣，靜態，變更成本大
- 用戶參與程度：強調用戶保持密切的聯系和交流；很少涉及用戶參與
- 業務需求：需求具有優先級次序，開發以增量方式逐步完成功能，有助于量化項目過程；假設需求是明確的，一旦需求變更勢必增加其余環節的復雜度
- 交付頻率：經常交付，交付周期短；項目結束時交付，交付周期長
- 文檔量：最必要最實用，高的應用度和閱讀度；產生大量中間文檔，低的應用度和閱讀度
敏捷方法明顯地降低了文檔的數量，甚至聲明代碼本身就是文檔。這就需要開發人員為代碼添加更多的注釋，但是對于不習慣敏捷開發或團隊新成員則很難做到，他們必須不斷詢問有經驗的開發人員，這樣會導致延遲迭代交付時間，甚至增加開發費用。而傳統開發則強調文檔對團隊成員的指導作用，開發人員可以在不知道項目細節的情況下完成開發。
敏捷開發中強調交互和客戶的參與。每次迭代前，團隊和客戶都將召開一個會議，團隊成員將介紹在這次迭代中所作的工作，而客戶則根據成員的介紹給出新的功能要求。實際中大部分情況，這種例會是非常乏味和沉悶的，因為團隊成員必須重復地向其他
成員和客戶展示自己負責的模塊，接受給出各種對需求的更改，而且每次迭代都是如此，通常為迭代分配的時間都是以周為單位的，開發人員經常感到時間不夠用，尤其是自己負責的模塊中包含一些復雜的算法時，時間就變得越緊，經常使得迭代延遲。而傳統開發中客戶不會參與開發過程，實現過程中開發人員只是根據文檔編寫代碼，然后交付最終產品。這樣開發人員不必關心那些頻繁的迭代會議，而且時間上更加寬泛，有利于開發出更好的產品。
敏捷開發對開發人員的個人技能要求更高。敏捷開發強調交互和客戶的參與，這就意味著每個團隊成員都要具備一定的個人能力和社交技能。每次迭代都必須給客戶提供完整的功能模塊，并且需要讓客戶明白當前的開發進程以及開發中遇到的一些問題，開發人員不但需要將自己的工作描述清楚，還得正確理解客戶提出的新需求，這需要具備較好的溝通技能。而實際中，不一定每一個開發人員都能具備這樣的技能，一旦某一個人不能正確理解一些重要信息，將可能導致下一次迭代不能準確交付，更糟糕的是，如果理解有誤，會使得開發的模塊中包含多余的功能，結果是對模塊進行修改，從而增加開發費用。因此，開發人員社交技能的提升將增加開發過程的穩定性。
敏捷開發允許增加需求也導致兩個設計中的問題：系統過于僵硬和機動性強。僵硬是指系統中一旦有更改的地方容易引起其他模塊的級聯改動。機動性是指可能由于需求改變而壓縮一些可重復使用的組件，這意味著大量的工作量和對系統整體穩健性帶來風險。如果系統中存在這些問題，會違反面向對象設計中的接口隔離原則，從而導致部署過程中的很多問題。
結束語：傳統軟件開發方法和 敏捷軟件開發方法各有利弊，任何一種方法都不是完美的，軟件開發項目管理的核心問題還是人的問題，在一定的管理機制制約之下，充分發揮和調動開發工程師個人工作積極性和主動性才能保證開發質量，至于管理模式和機制的選擇因地制宜不拘一格。
結束語：傳統軟件開發方法和 敏捷軟件開發方法各有利弊，任何一種方法都不是完美的，軟件開發項目管理的核心問題還是人的問題，在一定的管理機制制約之下，充分發揮和調動開發工程師個人工作積極性和主動性才能保證開發質量，至于管理模式和機制的選擇因地制宜不拘一格。
- 上一篇: 沒有了
- 下一篇: 北京軟件開發公司有哪些,軟件技術水平怎么樣