第二部分：淺析項(xiàng)目開發(fā)模式：瀑布VS.敏捷

一、項(xiàng)目背景

這里要分析的案例項(xiàng)目是某網(wǎng)絡(luò)公司的一個(gè)真實(shí)項(xiàng)目，簡(jiǎn)稱為B項(xiàng)目。B項(xiàng)目是做一款WEB應(yīng)用產(chǎn)品，目標(biāo)用戶是某一特定范圍的網(wǎng)民，具有相似的愛好、某一年齡段、具備相似的關(guān)注點(diǎn)和生活習(xí)慣等。下面，簡(jiǎn)單介紹一下項(xiàng)目相關(guān)的情況：

項(xiàng)目人員組成：9人，其中，

項(xiàng)目經(jīng)理1人，負(fù)責(zé)整個(gè)項(xiàng)目的規(guī)劃與執(zhí)行；

產(chǎn)品工程師1人，負(fù)責(zé)產(chǎn)品定義，需求收集與分析，頁面以及美工設(shè)計(jì)；

研發(fā)工程師4人，負(fù)責(zé)技術(shù)選型，完成系統(tǒng)設(shè)計(jì)以及具體的開發(fā)工作；

測(cè)試工程師3人，設(shè)計(jì)測(cè)試用例，執(zhí)行測(cè)試任務(wù)，負(fù)責(zé)產(chǎn)品的質(zhì)量保證工作。

二、B項(xiàng)目遇到的問題

這個(gè)項(xiàng)目有一個(gè)比較復(fù)雜的客觀情況，也可以說是難點(diǎn)吧。那就是：這是一個(gè)新產(chǎn)品開發(fā)，受眾面較大，用戶的想法和需求很難預(yù)先獲得，或者說用戶可能也說不清楚哪些是他需要的或者喜歡的，產(chǎn)品到底是不是真的滿足客戶需求的事先評(píng)估再怎么做也做不到最準(zhǔn)確。這種困擾，在很多軟件開發(fā)項(xiàng)目中都存在。其實(shí)，用戶只是有個(gè)方向，大致的想法，具體是什么樣的，怎么操作比較順手，這些細(xì)節(jié)都是模糊的，含混不清的。這種情況，就必然會(huì)導(dǎo)致，事前集中花時(shí)間想把需求不完整、清楚，然后lockdown，這是不可能的。變更是必須的，客觀存在的。完整，清楚，更不用提，做不到。提前花整塊的時(shí)間來做需求，是不現(xiàn)實(shí)的。

如果按照慣例，采用瀑布式開發(fā)流程的話，那么，需求不清，變更頻繁對(duì)后續(xù)的開發(fā)測(cè)試工作有什么影響呢？

瀑布式開發(fā)模式，各個(gè)階段劃分得非常清晰，需求->設(shè)計(jì)->編碼->測(cè)試–>發(fā)布，一般周期都比較長(zhǎng)。如果，想讓各階段按部就班地進(jìn)行，那這個(gè)項(xiàng)目計(jì)劃就無比地復(fù)雜，要全面，要具體。項(xiàng)目成員不斷地開發(fā)出新模塊，最后都齊活了才進(jìn)行整體集成，將各個(gè)工程師所寫的編碼整合到一起，預(yù)測(cè)整體系統(tǒng)的行為，包括可靠性和性能等。如果需求發(fā)生變化，意味著什么？調(diào)整計(jì)劃，要花費(fèi)幾倍的精力，來調(diào)整計(jì)劃以及后續(xù)所有階段的工作。很可能之前所做的工作會(huì)被廢棄，架構(gòu)也要調(diào)整，導(dǎo)致大量的重復(fù)工作。這種浪費(fèi)對(duì)于項(xiàng)目來說是致命的，時(shí)間緊迫了，項(xiàng)目的節(jié)奏被打散了，很可能到了截止日期卻拿不出可用的產(chǎn)品，項(xiàng)目只好延期。

新產(chǎn)品研發(fā)，需求不甚清晰，這種情況下，劃分需求階段的做法是沒有意義的。顯然，瀑布式開發(fā)模式不太適合的。

三、B項(xiàng)目的解決方案

那怎么辦呢？這個(gè)項(xiàng)目是怎么做得呢？

引入需求池，擁抱變化，迭代式開發(fā)，快速應(yīng)對(duì)變化。需求不是不能提前做到完整、清晰嘛，好，那就分為短期和長(zhǎng)期兩部分。長(zhǎng)期表示前進(jìn)的方向，宏偉的目標(biāo)，這是確定的而且基本不會(huì)變化的。短期目標(biāo)，就是在目前掌握信息的水平上想清楚多少就完成多少用戶需求。這些想好的，確定的，明確的需求不斷地放入需求池中。研發(fā)工程師，就從這些已經(jīng)確定的需求中不斷地取出需求，設(shè)計(jì)，編碼，測(cè)試，產(chǎn)出。產(chǎn)品工程師拿到產(chǎn)出進(jìn)行評(píng)估，各種范圍的評(píng)估，甚至拿給部分用戶進(jìn)行評(píng)估。然后得到反饋，就這樣，不斷地邊做邊想便評(píng)估，不清楚的需求自然就慢慢變得清晰起來，又可以納入到需求池中，作為下一次的迭代的目標(biāo)。

我們來看這個(gè)變化，需求管理方式的變化導(dǎo)致項(xiàng)目開發(fā)流程也發(fā)生了變化：如果想快速的推出 產(chǎn)品給產(chǎn)品工程師評(píng)估，就要盡量的并行工作，減少串行，縮短bug反饋和修復(fù)的時(shí)間間隔，那么研發(fā)工程師和測(cè)試工程師就不能像瀑布式一樣，嚴(yán)格的串行。研發(fā)工程師交給測(cè)試工程師的就不能是一個(gè)瑣碎的零件，而應(yīng)該是端到端的可見的功能，用戶使用的一個(gè)功能。再往前推，那產(chǎn)品工程師提出的需求就不能是零件，而應(yīng)該是一個(gè)feature，而且要足夠的小，最好是1天之內(nèi)的工作量。根據(jù)B項(xiàng)目成員的能力水平，這個(gè)迭代周期，他們選擇了2周，2周給出一個(gè)評(píng)估版本。

很顯然，B項(xiàng)目采用了敏捷開發(fā)的模式。

四、敏捷模式和瀑布式有何區(qū)別

瀑布式開發(fā)模型分為若干階段：需求分析、系統(tǒng)設(shè)計(jì)、編碼和單元測(cè)試、系統(tǒng)集成，以及運(yùn)行和維護(hù)等幾個(gè)基本階段。瀑布模型做了4個(gè)主要假設(shè)：

如果我們花時(shí)間來理解的話，存在著一套定義相當(dāng)明確的需求

在開發(fā)過程中，需求的變化非常小，使我們能夠應(yīng)付，而不用重新構(gòu)思或者修改我們的計(jì)劃

系統(tǒng)集成是一個(gè)適當(dāng)且必要的過程，我們能夠在架構(gòu)和計(jì)劃的基礎(chǔ)上合理地預(yù)測(cè)系統(tǒng)集成的運(yùn)行情況

創(chuàng)建一個(gè)大型的新軟件應(yīng)用程序所需要的軟件創(chuàng)新和研發(fā)工作，是可以按照預(yù)先制定的時(shí)間表進(jìn)行的

但是，很遺憾，現(xiàn)實(shí)情況表明這4個(gè)假設(shè)都是錯(cuò)誤的，很難站得住腳的。

假設(shè)1，已經(jīng)在B項(xiàng)目中被證實(shí)是不存在的了。即使是在最擅長(zhǎng)的行業(yè)領(lǐng)域，客戶想法的變化，獨(dú)特化，都是沒有辦法保證需求是可以一下子就全面到位的。

假設(shè)2，確定需求和交付系統(tǒng)之間的時(shí)間間隔越長(zhǎng)，變化也就越多。如果開發(fā)速度很慢而變化發(fā)生的太快，那情況就很糟了。

假設(shè)3，系統(tǒng)集成會(huì)順利進(jìn)行？別開玩笑了，這個(gè)假設(shè)的前提是，只要進(jìn)行適當(dāng)?shù)挠?jì)劃和分析，我們就可以預(yù)測(cè)復(fù)雜系統(tǒng)那個(gè)的所有組件系統(tǒng)工作的情況。現(xiàn)實(shí)情況，告訴我們，前期所有的分析，既不能預(yù)知也不能控制系統(tǒng)集成的過程。問題過于復(fù)雜，變化不斷發(fā)生；項(xiàng)目進(jìn)行期間技術(shù)不斷革新；關(guān)于集成的假設(shè)都是錯(cuò)誤的，并且發(fā)現(xiàn)錯(cuò)誤時(shí)已經(jīng)為時(shí)太晚。

假設(shè)4，計(jì)劃其實(shí)是一種預(yù)測(cè)，只能反映預(yù)測(cè)的精確程度，但并不見得能夠反映實(shí)際情況，尤其是超大的計(jì)劃。超出4周，就基本上是胡說了，變化太快。

其實(shí)，不是瀑布式模型概念錯(cuò)誤了，而是從瀑布式模式被提出到現(xiàn)在這30多年來，我們都錯(cuò)誤的理解瀑布式模型。其實(shí)，瀑布式模型的應(yīng)用是有前提條件的。Royce在1970年發(fā)表的《管理大型軟件系統(tǒng)的開發(fā)》中，提到：這個(gè)模型建議在關(guān)鍵的原型階段之后應(yīng)用，在原型階段首先要充分的理解所要應(yīng)用的關(guān)鍵技術(shù)以及客戶的實(shí)際需求。

瀑布式開發(fā)模式想得很美好，但是，在殘酷的現(xiàn)實(shí)面前，卻因?yàn)槿狈`活性，適應(yīng)性不佳而漸漸被放棄。與此同時(shí)，業(yè)界不斷探尋適合軟件項(xiàng)目的開發(fā)模式，其中，敏捷軟件開發(fā)模式越來越得到大家的關(guān)注和采用。接下來，讓我們看看有何不同。

圖二敏捷顛覆了瀑布模式的傳統(tǒng)假設(shè)

圖二顯示，瀑布模式傾向于需求（功能）而不是評(píng)估資源和日期（成本和日程）。在敏捷中，假設(shè)是不同的：日期和資源是固定的，因此，為了滿足日期的要求，需求必定是可變的。這是敏捷的關(guān)鍵原則：任何事情都安排在時(shí)間盒內(nèi)完成。這條原則迫使團(tuán)隊(duì)篩選最高優(yōu)先級(jí)的需求，首先交付最高客戶價(jià)值的條目。同時(shí)，這條原則迫使團(tuán)隊(duì)承認(rèn)，我們不知道什么時(shí)候交付什么，僅知道哪個(gè)時(shí)間段。

在概念上，敏捷是簡(jiǎn)單的，但是卻改變了大多數(shù)事情。

圖三敏捷帶來的變化

圖三通過對(duì)比的方式描述了敏捷帶來的變化，可以說這些變化都是顛覆瀑布模式的。

敏捷讓團(tuán)隊(duì)和組織從遵循計(jì)劃發(fā)展到能夠響應(yīng)變化。這是從傳統(tǒng)的工作分解結(jié)構(gòu)到基于優(yōu)先級(jí)實(shí)現(xiàn)故事和需求的“以交付價(jià)值為中心”的轉(zhuǎn)變。最重要的就是可執(zhí)行的、經(jīng)過測(cè)試的并可以使用的代碼。計(jì)劃是靈活的，可以調(diào)整。實(shí)際交付是在當(dāng)時(shí)情況下能夠達(dá)到的最好情況。實(shí)際交付可以發(fā)布。

瀑布模式下，管理固定了范疇、期限和資源，并且為團(tuán)隊(duì)明確了技術(shù)方向，同時(shí)也為團(tuán)隊(duì)的效率負(fù)責(zé)。在敏捷方法中，正好相反。管理指明方向，團(tuán)隊(duì)競(jìng)標(biāo)，并計(jì)劃如何在規(guī)定的時(shí)間框架內(nèi)完成盡可能多的工作。為了實(shí)現(xiàn)目標(biāo)，團(tuán)隊(duì)必須有自我組織的能力。團(tuán)隊(duì)制定技術(shù)決策，并根據(jù)需要在執(zhí)行中糾正。

敏捷模式下，管理工作是排除組織內(nèi)的干擾，信任團(tuán)隊(duì)能夠?qū)崿F(xiàn)目標(biāo)。團(tuán)隊(duì)完全負(fù)責(zé)交付產(chǎn)品，并且負(fù)責(zé)滿足時(shí)間期限和交付質(zhì)量。其實(shí)隨著所看到的工作進(jìn)展，每個(gè)迭代不斷交付的產(chǎn)品，這種信任感不斷增加。

在敏捷方法中，團(tuán)隊(duì)不用投入幾個(gè)月來構(gòu)建詳細(xì)的軟件需求規(guī)范、架構(gòu)模型。團(tuán)隊(duì)的注意力集中在盡早交付科技城的有價(jià)值的需求模塊。盡早交付有助于測(cè)試，證實(shí)對(duì)于需求和架構(gòu)的假設(shè)，來避免風(fēng)險(xiǎn)。如果軟件不可用，團(tuán)隊(duì)就需要重新調(diào)整，直到可用。這種方法增加了用戶的可視化，甚至用戶可以在團(tuán)隊(duì)工作環(huán)境中配置或評(píng)估迭代的產(chǎn)出，允許用戶的持續(xù)反饋。管理和用戶不必再一邊祈禱團(tuán)隊(duì)能夠做出正確的東西，一邊默默地等上幾個(gè)月。

編碼方式是不同的。在瀑布模式下，開發(fā)人員對(duì)所有的功能同時(shí)編碼，最后產(chǎn)生一個(gè)大的，完全的軟件包。而在敏捷模式下，整個(gè)團(tuán)隊(duì)首先集中精力解決最早、最明確、最高優(yōu)先級(jí)的功能。持續(xù)地集成，不延緩測(cè)試。僅生成一種代碼：測(cè)試過的、工作良好的、及成果的代碼。反饋及時(shí)并且持續(xù)，每個(gè)隊(duì)員都知道，為了實(shí)現(xiàn)迭代的目標(biāo)，每天應(yīng)該在什么位置，完成什么事情。

敏捷模式下，對(duì)測(cè)試組織的影響是實(shí)質(zhì)性的。測(cè)試不再是生命周期的一個(gè)階段，而是持續(xù)的行為。測(cè)試人員不在測(cè)試沒有經(jīng)過測(cè)試的大塊代碼，而是測(cè)試系統(tǒng)，包括已經(jīng)完成的單元代碼和經(jīng)過準(zhǔn)入測(cè)試的代碼。這種轉(zhuǎn)變，要求項(xiàng)目組必須開展代碼集成和自動(dòng)化測(cè)試。測(cè)試水平隨著測(cè)試者參與技術(shù)決策以及測(cè)試自動(dòng)化的開發(fā)而得到增強(qiáng)。測(cè)試人員不再是純手工的測(cè)試執(zhí)行者。而是水平提高，等同于研發(fā)人員。

規(guī)劃并沒有在敏捷模式中消失，實(shí)際上，應(yīng)用得更加充分了。在兩個(gè)層次上都要做規(guī)劃：為產(chǎn)品發(fā)布制定整體計(jì)劃，為迭代制定的細(xì)致規(guī)劃。根據(jù)迭代的推進(jìn)，規(guī)劃也是滾動(dòng)式的進(jìn)行，在開發(fā)過程中不僅制定一次規(guī)劃，在每次發(fā)布和迭代的前期都要進(jìn)行規(guī)劃。規(guī)劃不再是粗略的和即興的，變成了系統(tǒng)和常規(guī)。

規(guī)劃被極大地簡(jiǎn)化，每次都是在提前知道確定日期的情況，再來篩選feature的。追蹤也變得簡(jiǎn)單，每天的站會(huì)和平凡的演示顯示出實(shí)際的項(xiàng)目進(jìn)展。計(jì)劃和實(shí)際之間不再隔著深深地鴻溝。

上文我們提到過：日期和范疇相比，總是優(yōu)先考慮日期。更確切地說，迭代長(zhǎng)度決定開發(fā)范疇，而不是范疇決定開發(fā)周期的長(zhǎng)度。在計(jì)劃驅(qū)動(dòng)的的方法中，范圍決定時(shí)間，范圍和時(shí)間在每個(gè)規(guī)劃周期和每次重大變化中都會(huì)發(fā)生改變。由于敏捷模式下，固定時(shí)間，并根據(jù)時(shí)間來定義范圍，所以，團(tuán)隊(duì)能夠自由的根據(jù)需要進(jìn)行，將注意力持續(xù)集中在到期需要完成的任務(wù)上。即使因?yàn)槟承┰?，交付的結(jié)果缺少有效的功能而成為未完成的任務(wù)，那么也不用擔(dān)心，因?yàn)?，下一次迭代僅需要兩周時(shí)間，一個(gè)月或者兩個(gè)月之后的下一次發(fā)布將是可用的。

敏捷崇尚時(shí)間盒內(nèi)創(chuàng)建小塊的可工作的代碼。軟件項(xiàng)目大多飽受需求不清，變化太快，就像B項(xiàng)目一樣。但是，又沒有足夠的能力把敏捷方法一次性的投入到開發(fā)流程中，那就從時(shí)間盒入手吧。這是敏捷模式的重要?jiǎng)恿?。?dāng)團(tuán)隊(duì)掌握這個(gè)技巧后，自然就會(huì)帶來敏捷方法集中的其他特征和辦法。

以上來自百度文庫

愛華網(wǎng)本文地址 » http://www.klfzs.com/a/25101015/283574.html