敏捷式開發

2021-09-30 16:11:25 字數 2325 閱讀 2144

人與人之間的互動是複雜的,並且其效果從來都是難以預期的,但卻是工作中最重要的方面。

敏捷軟體開發宣言:

n      個體和互動         勝過      過程和工具

n      可以工作的軟體 勝過      面面俱到的文件

n      客戶合作             勝過      合同談判

n      響應變化             勝過      遵循計畫

雖然右項也有價值,但是我們認為左項具有更大的價值。

敏捷宣言遵循的原則:

n      我們最優先要做的是通過盡早的、持續的交付有價值的軟體來使客戶滿意。

n      即使到了開發的後期,也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。

n      經常性地交付可以工作的軟體,交付的間隔可以從幾個星期到幾個月,交付的時間間隔越短越好。

n      在整個專案開發期間,業務人員和開發人員必須天天都在一起工作。

n      圍繞被激勵起來的個體來構建專案。給他們提供所需的環境和支援,並且信任他們能夠完成工作。

n      在團隊內部,最具有效果並富有效率的傳遞資訊的方法,就是面對面的交談。

n      工作的軟體是首要的進度度量標準。

n      敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持乙個長期的、恆定的開發速度。

n      不斷地關注優秀的技能和好的設計會增強敏捷能力。

n      簡單是最根本的。

n      最好的構架、需求和設計出於自組織團隊。

n      每隔一定時間,團隊會在如何才能更有效地工作方面進行反省,然後相應地對自己的行為進行調整。

當軟體開發需求的變化而變化時,軟體設計會出現壞味道,當軟體**現下面任何一種氣味時,表明軟體正在腐化。

n      僵化性: 很難對系統進行改動,因為每個改動都會迫使許多對系統其他部分的其它改動。

n      脆弱性: 對系統的改動會導致系統中和改動的地方在概念上無關的許多地方出現問題。

n      牢固性: 很難解開系統的糾結,使之成為一些可在其他系統中重用的元件。

n      粘滯性: 做正確的事情比做錯誤的事情要困難。

n      不必要的複雜性: 設計中包含有不具任何直接好處的基礎結構。

n      不必要的重複性: 設計中包含有重複的結構,而該重複的結構本可以使用單一的抽象進行統一。

n      晦澀性: 很難閱讀、理解。沒有很好地表現出意圖。

敏捷團隊依靠變化來獲取活力。團隊幾乎不進行預先設計,因此,不需要乙個成熟的初始設計。他們更願意保持設計盡可能的乾淨、簡單,並使用許多單元測試和驗 收測試作為支援。這保持了設計的靈活性、易於理解性。團隊利用這種靈活性,持續地改進設計,以便於每次迭代結束生成的系統都具有最適合於那次迭代中需求的 設計。

為了改變上面軟體設計中的腐化味,敏捷開發採取了以下物件導向的設計原則來加以避免,這些原則如下:

n      單一職責原則(srp)

就乙個類而言,應該僅有乙個引起它變化的原因。

n      開放-封閉原則(ocp)

軟體實體應該是可以擴充套件的,但是不可修改。

n      liskov替換原則(lsp)

子型別必須能夠替換掉它們的基型別。

n      依賴倒置原則(dip)

抽象不應該依賴於細節。細節應該依賴於抽象。

n      介面隔離原則(isp)

不應該強迫客戶依賴於它們不用的方法。介面屬於客戶,不屬於它所在的類層次結構。

n      重用發布等價原則(rep)

重用的粒度就是發布的粒度。

n      共同封閉原則(ccp)

包中的所有類對於同一類性質的變化應該是共同封閉的。乙個變化若對乙個包產生影響,則將對該包中的所有類產生影響,而對於其他的包不造成任何影響。

n      共同重用原則(crp)

乙個包中的所有類應該是共同重用的。如果重用了包中的乙個類,那麼就要重用包中的所有類。

n      無環依賴原則(adp)

在包的依賴關係圖中不允許存在環。

n      穩定依賴原則(sdp)

朝著穩定的方向進行依賴。

n      穩定抽象原則(sap)

包的抽象程度應該和其穩定程度一致。

上述中的包的概念是:包可以用作包容一組類的容器,通過把類組織成包,我們可以在更高層次的抽象上來理解設計,我們也可以通過包來管理軟體的開發和發布。目的就是根據一些原則對應用程式中的類進行劃分,然後把那些劃分後的類分配到包中。

敏捷設計是乙個過程,不是乙個事件。它是乙個持續的應用原則、模式以及實踐來改進軟體的結構和可讀性的過程。它致力於保持系統設計在任何時間都盡可能得簡單、乾淨和富有表現力。

文件驅動式超敏捷開發

敏捷開發大家都不陌生,他對文件的態度是偏向於反對,但是也不是說一點文件都沒有。他的說法是 代替文件。於是就有了這樣的現象 各位前輩呀,為後來人著想著想呀!於是乎文件就成了乙個包袱乙個累贅,有還不如沒有。為啥會這樣呢?因為文件和 沒有直接關係,沒有 聯動 關係!那麼啥是聯動關係呢?我們舉個例子,pow...

瀑布式開發和敏捷開發的對比

瀑布模型開發 嚴格把軟體專案的開發分隔成各個開發階段 需求分析,要件定義,基本設計,詳細設計,編碼,單體測試,結合測試,系統測試等。使用里程碑的方式,嚴格定義了各開發階段的輸入和輸出。如果達不到要求的輸出,下一階段的工作就不展開。強調文件,在開發的後期才會看到軟體的模樣。在這種情況下,文件的重要性彷...

瀑布式開發和敏捷開發區別

敏捷開發,首先把客戶最關注的軟體原型先做出來,交付或者上線,在實際場景中去修改彌補需求中的不足,快速修改,再次發布版本。再次上線或者交付。通過一些敏捷實踐方式,細化story,可以提供更小的迭代。如此迴圈,直到使用者 客戶 滿意。適用於需求不明確的專案 創新性的專案或者需要搶占市場的專案。瀑布式開發...