九色国产,午夜在线视频,新黄色网址,九九色综合,天天做夜夜做久久做狠狠,天天躁夜夜躁狠狠躁2021a,久久不卡一区二区三区

打開APP
userphoto
未登錄

開通VIP,暢享免費電子書等14項超值服

開通VIP
瀑布式開發(fā)、迭代開發(fā)、敏捷開發(fā)、XP與SCRUM的區(qū)別

標簽:

瀑布式開發(fā)、迭代開發(fā),區(qū)別【都屬于,生命周期模型】

        兩者都是一種開發(fā)模式,就像設計模式一樣,考慮的角度不一樣,個人感覺談不到取代一說。
        傳統(tǒng)的瀑布式開發(fā),也就是從需求到設計,從設計到編碼,從編碼到測試,從測試到提交大概這樣的流程,要求每一個開發(fā)階段都要做到最好。特別是前期階段,設計的越完美,提交后的成本損失就越少。我現(xiàn)在從事的外包項目就是這樣的流程。
        迭代式開發(fā),不要求每一個階段的任務做的都是最完美的,而是明明知道還有很多不足的地方,卻偏偏不去完善它,而是把主要功能先搭建起來為目的,以最短的時間,最少的損失先完成一個“不完美的成果物”直至提交。然后再通過客戶或用戶的反饋信息,在這個“不完美的成果物”上逐步進行完善。
        這兩種開發(fā)模式都各自具有自己的特點,迭代式開發(fā)適合在一些需求信息不明確的項目中,這樣在開發(fā)過程中遇到需求的變化時,所帶來的影響要比瀑布式開發(fā)小。而現(xiàn)在的很多項目中,需求在項目進行中變化的事兒經常見,所以顯得迭代式開發(fā)的優(yōu)勢更明顯一些。
        但是,從本質上來說,二者都不過是一種開發(fā)的模式,即使是迭代式開發(fā),在每一個迭代的環(huán)節(jié)中,不也是此從需求到設計,從設計到編碼,從編碼到測試嗎?這不也是瀑布式模型的體現(xiàn)嗎?只不過這個瀑布式中的每一個階段不需要做到最優(yōu)化,都留一些任務到下一層迭代中去做而已。
        所以,我覺得面對不同的問題采用不同的模式,模式是為了方便我們開發(fā)而服務的,不是要求我們必須按照某一種模式從頭走到尾。
        就象迭代式開發(fā),我們其實也經常用到這種模式。比如說開發(fā)項目中的某一個模塊。我們先把能夠實現(xiàn)主要功能的代碼寫出來。比如一個查詢模塊,先從模塊的構思到設計再到編碼,先查詢功能的代碼,測試一遍查詢成功。這算是完成了第一層迭代。然后我們要再考慮一層迭代中的一些還未完成的細節(jié)問題,比如查詢的check,查詢結果的顯示以及查詢算法的優(yōu)化等等,這就是第二層迭代。
 
瀑布式開發(fā),敏捷開發(fā),區(qū)別【一種生命周期模型,項目管理方法集合】

瀑布模型的特點(傳統(tǒng)的開發(fā)方式)
1、強調文檔
前一個階段的輸出就是下一個階段的輸入,文檔是個階段銜接的唯一信息。所以很多開發(fā)人員好象是在開發(fā)文檔,而不是開發(fā)軟件,因為要到開發(fā)的后期才可以看到軟件的“模樣”。
2、沒有迭代與反饋。瀑布模型對反饋沒有涉及,所以對變化的客戶需求非常不容易適應。瀑布就意味著沒有回頭路。
3、管理人員喜歡瀑布模型的原因是把文檔理解為開發(fā)的速度,可以方便地界定不同階段的里程碑。
敏捷開發(fā)
極限編程的思想體現(xiàn)了適應客戶需求的快速變化,激發(fā)開發(fā)者的熱情,也是目前敏捷開發(fā)思維的重要支持者。
敏捷軟件開發(fā)是一個開發(fā)軟件的管理新模式,用來替代以文件驅動開發(fā)的瀑布開發(fā)模式。
敏捷開發(fā)集成了新型開發(fā)模式的共同特點,它重點強調:
1.敏捷就是“快”??觳趴梢赃m應目前社會的快節(jié)奏,要快就要發(fā)揮個人的個性思維多一些個性思維的增多。
2.客戶參與。以人為本,客戶是軟件的使用者,是業(yè)務理解的專家,沒有客戶的參與,開發(fā)者很難理解客戶的真實需求。
3.強調軟件開發(fā)的產品是軟件,而不是文檔。文檔是為軟件開發(fā)服務的,而不是開發(fā)的主體。
4.設計周密是為了最終軟件的質量,但不表明設計比實現(xiàn)更重要。
5.迭代。軟件的功能是客戶的需求,界面的操作是客戶的“感覺”。對迭代的強調是縮短了軟件版本的周期。
6.小版本??焖俟δ艿恼宫F(xiàn),看似簡單,但對于復雜的客戶需求合理地分割與總體上的統(tǒng)一,要很好地二者兼顧是不容易的。

迭代開發(fā),敏捷開發(fā),區(qū)別【一種生命周期模型,項目管理方法集合】

        迭代開發(fā)是一種軟件開發(fā)的生命周期模型,與其對應的還有瀑布模型、螺旋模型等等
        敏捷開發(fā)是多種軟件開發(fā)項目管理方法的集合,其中包括了XP、Scrum等十幾種開發(fā)模式,這些開發(fā)方法有些共同點,比如重視響應變更,重視實現(xiàn)客戶的價值,重視開發(fā)人員的自身發(fā)展等等,其核心體現(xiàn)在他們著名的四句原則中.這些開發(fā)方法基本都傾向于采用迭代的軟件開發(fā)生命周期模型.
        簡單來說,迭代模型是敏捷開發(fā)普遍使用的軟件生命周期模型,敏捷開發(fā)所包含的內容比迭代模型寬泛的多.
敏捷開發(fā)中,XP與SCRUM的區(qū)別

區(qū)別之一:  迭代長度的不同

XP的一個Sprint的迭代長度大致為1~2周, 而Scrum的迭代長度一般為 2~ 4周.

區(qū)別之二: 在迭代中, 是否允許修改需求

XP在一個迭代中,如果一個User Story(用戶素材, 也就是一個需求)還沒有實現(xiàn), 則可以考慮用另外的需求將其替換, 替換的原則是需求實現(xiàn)的時間量是相等的。 而Scrum是不允許這樣做的,一旦迭代開工會完畢, 任何需求都不允許添加進來,并有Scrum Master嚴格把關,不允許開發(fā)團隊收到干擾

區(qū)別之三: 在迭代中,User Story是否嚴格按照優(yōu)先級別來實現(xiàn)

XP是務必要遵守優(yōu)先級別的。 但Scrum在這點做得很靈活, 可以不按照優(yōu)先級別來做,Scrum這樣處理的理由是: 如果優(yōu)先問題的解決者,由于其它事情耽擱,不能認領任務,那么整個進度就耽誤了。 另外一個原因是,如果按優(yōu)先級排序的User Story #6和#10,雖然#6優(yōu)先級高,但是如果#6的實現(xiàn)要依賴于#10,則不得不優(yōu)先做#10.

區(qū)別之四:軟件的實施過程中,是否采用嚴格的工程方法,保證進度或者質量

Scrum沒有對軟件的整個實施過程開出養(yǎng)個工程實踐的處方。要求開發(fā)者自覺保證,但XP對整個流程方法定義非常嚴格,規(guī)定需要采用TDD, 自動測試, 結對編程,簡單設計,重構等約束團隊的行為。因此,原作者認為, 這點上,XP的做法值得認同的,但是卻把敏捷帶入了一個讓人困惑的矛盾, 因為xp的理念,結合敏捷模式,表達給團隊的信息是“你是一個完全自我管理的組織, 但你必須要實現(xiàn)TDD, 結對編程, ...等等”

 

不難發(fā)現(xiàn),這四個區(qū)別顯見的是: Scrum非常突出Self-Orgnization, XP注重強有力的工程實踐約束

作者建議, 在管理模式上啟用Scrum, 而在實踐中,創(chuàng)造一個適合自己項目組的XP(“start with Scrum and then invent your own version of XP.”)

 

SCRUM介紹


        回顧一下我所認識的scrum,算是對自己知識的一個梳理。
        scrum到底是什么,書中都說,它不是方法學,不是過程,而是一個框架。我并沒有太理解這句話,所以先把scrum中都有些什么來說一下。

 

        時間:scrum把時間分成一個個的sprint,也就是迭代周期。這個周期以2-6個星期為宜,但目前使用的最多的,是一個月,即四個星期。

        每一個sprint的開始和結束都會有一個會議,叫做sprint計劃sprint演示,這很好理解,計劃時計劃做什么,演示時演示做完的東西。然后,并不是演示完了就完事的,sprint還有一個回顧會議,用來對這個sprint進行回顧,哪些做的好,哪些做的不好。這就是改進。

        組成sprint的每天中,都會有每日例會,叫做每日站會,所以謂站會,即是時間非常短的會議,眾所周知的,沒完沒了的會議總是讓我們,厭倦不已。而這種站會,我想差不多是從這方面來考慮的。

 

        人物:scrum中有scrum master, product owner和scrum團隊。我理解scrum master就是project manager,而product owner就是product manager,團隊還是那個團隊,只是這里的團隊,在規(guī)模上有一定的限制,它要求人員不要太多,不要太少,3-12個,通常4人團隊比較多見,當然這個具體還得看實際情況來定。團隊中開發(fā)測試人員比是1:1,即pair work。

 

        scrum中的需求,采用story的形式進行描述,整個產品的需求,被列成product backlog,而每一個迭代周期要做什么,是在每個sprint的計劃會議上進行挑選的,根據(jù)po對backlog標記的優(yōu)先級,團隊對其進行estimate并挑選出這個sprint里能完成的story,scrum master把它們列入計劃中。

        backlog有一個用于統(tǒng)計的東西,叫做燃盡圖。從字面理解,就是燃燒掉多少的圖,即sprint backlog中的被完成了多少,每完成一個story,就燃燒掉一個story。產品backlog有產品燃盡圖,sprint有sprint燃盡圖。

 

        以上基本就是我了解的一些scrum知識點,其中忽略了工具部分和工作開展方式部分。因為采用什么工具或采用什么方式來實現(xiàn),我認為是根據(jù)實際情況來定的,而且,在每個sprint回顧會議中,這些東西都會被改進。使用excel或白板來記錄story或backlog并不重要,重要的是,你是否有story或backlog。

 

        所謂框架,是不是就是一種模式?真的很想理解這里的這個詞。有知道的,請賜教。

瀑布式開發(fā)、迭代開發(fā)、敏捷開發(fā)、XP與SCRUM的區(qū)別


本站僅提供存儲服務,所有內容均由用戶發(fā)布,如發(fā)現(xiàn)有害或侵權內容,請點擊舉報。
打開APP,閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
敏捷開發(fā)之Scrum掃盲篇
話題
項目管理--敏捷開發(fā)在項目中使用
汽車行業(yè)軟件開發(fā)可否借鑒軟件行業(yè)的開發(fā)模式?
敏捷or瀑布:你還在糾結嗎?
B2C商城用戶注冊流程設計范式
更多類似文章 >>
生活服務
熱點新聞
分享 收藏 導長圖 關注 下載文章
綁定賬號成功
后續(xù)可登錄賬號暢享VIP特權!
如果VIP功能使用有故障,
可點擊這里聯(lián)系客服!

聯(lián)系客服