【正文】 傳統(tǒng)的瀑布模型相比較，迭代過程具有以下優(yōu)點(diǎn)：　　降低了在一個增量上的開支風(fēng)險。轉(zhuǎn)自項目管理者聯(lián)盟轉(zhuǎn)自項目管理者聯(lián)盟　　降低了產(chǎn)品無法按照既定進(jìn)度進(jìn)入市場的風(fēng)險。項目管理者聯(lián)盟　　加快了整個開發(fā)工作的進(jìn)度。轉(zhuǎn)自項目管理者聯(lián)盟　　由于用戶的需求并不能在一開始就作出完全的界定，它們通常是在后續(xù)階段中不斷細(xì)化的。 項目管理培訓(xùn)八、統(tǒng)一軟件開發(fā)過程RUP的十大要素項目管理培訓(xùn)1. 開發(fā)前景 2. 達(dá)成計劃 項目管理者聯(lián)盟3. 標(biāo)識和減小風(fēng)險 4. 分配和跟蹤任務(wù)轉(zhuǎn)自項目管理者聯(lián)盟5. 檢查商業(yè)理由6. 設(shè)計組件構(gòu)架7. 對產(chǎn)品進(jìn)行增量式的構(gòu)建和測試 8. 驗證和評價結(jié)果 9. 管理和控制變化 10. 提供用戶支持 轉(zhuǎn)自項目管理者聯(lián)盟讓我們逐一的審視這些要素，看一看它們什么地方適合ＲＵＰ，找出它們能夠成為十大要素的理由。 有一個清晰的前景是開發(fā)一個滿足涉眾真正需求的產(chǎn)品的關(guān)鍵。 前景給更詳細(xì)的技術(shù)需求提供了一個高層的、有時候是合同式的基礎(chǔ)。它捕獲了非常高層的需求和設(shè)計約束，讓前景的讀者能理解將要開發(fā)的系統(tǒng)。最后，由于前景構(gòu)成了“項目是什么？”和“為什么要進(jìn)行這個項目？”，所以可以把前景作為驗證將來決策的方式之一。 “產(chǎn)品的質(zhì)量只會和產(chǎn)品的計劃一樣好。SDP必須在整個項目中被維護(hù)和更新。同時也指導(dǎo)了其他過程內(nèi)容（原文：process ponents）的計劃：項目組織、需求管理計劃、配置管理計劃、問題解決計劃、QA計劃、測試計劃、評估計劃以及產(chǎn)品驗收計劃。 在較簡單的項目中，對這些計劃的陳述可能只有一兩句話。 軟件開發(fā)計劃的格式遠(yuǎn)遠(yuǎn)沒有計劃活動本身以及驅(qū)動這些活動的思想重要。” “達(dá)成計劃”—和列表中第8條一起—抓住了RUP中項目管理流程的要點(diǎn)。 3. 標(biāo)識和減小風(fēng)險 項目組標(biāo)識的每一個風(fēng)險都應(yīng)該有一個相應(yīng)的緩解或解決計劃。 4. 分配和跟蹤任務(wù)轉(zhuǎn)自項目管理者聯(lián)盟在RUP中，定期的項目狀態(tài)評估提供了講述、交流和解決管理問題、技術(shù)問題以及項目風(fēng)險的機(jī)制。進(jìn)度應(yīng)該定期跟蹤，如有必要，更新應(yīng)該被發(fā)布。） 這些項目“快照”突出了需要引起管理注意的問題。），定期的評估使經(jīng)理能捕獲項目的歷史，并且消除任何限制進(jìn)度的障礙或瓶頸。 商業(yè)理由從商業(yè)的角度提供了必要的信息，以決定一個項目是否值得投資。它提供了進(jìn)行項目的理由，并建立經(jīng)濟(jì)約束。 商業(yè)理由應(yīng)該給項目創(chuàng)建一個簡短但是引人注目的理由，而不是深入研究問題的細(xì)節(jié)，以使所有項目成員容易理解和記住它。6. 設(shè)計組件構(gòu)架 項目經(jīng)理圈子即主要的部分是什么？他們又是怎樣結(jié)合在一起的？ RUP提供了一種設(shè)計、開發(fā)、驗證構(gòu)架的很系統(tǒng)的方法。 要陳述和討論軟件構(gòu)架，你必須先創(chuàng)建一個構(gòu)架表示方式，以便描述構(gòu)架的重要方面。每個視圖都描述了某一組涉眾所關(guān)心的正在進(jìn)行的系統(tǒng)的某個方面。這個文檔使系統(tǒng)構(gòu)架師和其他項目組成員能就與構(gòu)架相關(guān)的重大決策進(jìn)行有效的交流。 在RUP中實(shí)現(xiàn)和測試流程的要點(diǎn)是在整個項目生命周期中增量的編碼、構(gòu)建、測試系統(tǒng)組件，在先啟之后每個迭代結(jié)束時生成可執(zhí)行版本。然后，在構(gòu)建階段的每次迭代中，組件不斷的被集成到可執(zhí)行、經(jīng)過測試的版本中，不斷地向最終產(chǎn)品進(jìn)化。8. 驗證和評價結(jié)果 評估決定了迭代滿足評價標(biāo)準(zhǔn)的程度，還包括學(xué)到的教訓(xùn)和實(shí)施的過程改進(jìn)。 這兒的關(guān)鍵是既關(guān)注過程問題又關(guān)注產(chǎn)品問題。（原文：The sooner you fall behind, the more time you will have to catch up.） 9. 管理和控制變化 其目的是考慮所有的涉眾需求，盡可能的滿足，同時仍能及時的交付合格的產(chǎn)品。重要的是，變更的提出和管理過程始終保持一致。變更請求提供了相應(yīng)的手段來評估一個變更的潛在影響，同時記錄就這些變更所作出的決策。10. 提供用戶支持 項目組至少要給用戶提供一個用戶指南（也許是通過聯(lián)機(jī)幫助的方式提供），可能還有一個安裝指南和版本發(fā)布說明。最后，通過一個材料清單（BOM表，即Bill of Materials）清楚地記錄應(yīng)該和產(chǎn)品一起交付哪些材料。例如，他會問，需求在哪兒呢？他們不重要嗎？我會告訴他我為什么沒有把它們包括進(jìn)來?！?剛開始我對此非常驚訝（我有軍方的宇航開發(fā)背景）。但是他們的確沒有得到這樣的陳述。 因此，我接著問他們另外一個問題：“好的，那么你們的產(chǎn)品的前景是什么呢？”。然后，我們非常順利的就第一個要素（“開發(fā)一個前景”）中列出的問題進(jìn)行了溝通，需求也自然而然的流動著（原文：and the requirements just flow naturally.）。請記住，我的清單僅僅意味著進(jìn)行進(jìn)一步討論的一個起點(diǎn)。它建立了簡潔和清晰的過程結(jié)構(gòu)，為開發(fā)過程提供較大的通用性。可以說RUP是一個非常好的開端，但并不完美，在實(shí)際的應(yīng)用中可以根據(jù)需要對其進(jìn)行改進(jìn)并可以用OPEN和OOSP等其他軟件過程的相關(guān)內(nèi)容對RUP進(jìn)行補(bǔ)充和完善。 人有過什么經(jīng)驗，遇到過什么恐懼的事，就會形成設(shè)法避免這種事情的方法學(xué)。而發(fā)明XP的人可能一直是在小團(tuán)隊里做項目，項目團(tuán)隊只有5個人，項目總是會因為沒有滿足用戶價值而被Cancel，開發(fā)公司也蒙受損失，因此注重與用戶的交流、反饋，強(qiáng)調(diào)快速、靈活。那么對于軟件項目來說，是否可以使用同一種軟件開發(fā)方法來對不同類型、規(guī)模、復(fù)雜度的項目來進(jìn)行開發(fā)呢，顯然是不合理的。我對此是理解并贊同的，但是我對RUP卻一直保持一種相對謹(jǐn)慎的態(tài)度。 對于各種類型的軟件項目，RUP并未給出具體的自身裁減及實(shí)施策略，總有些無依據(jù)可循的感覺。在一些小型軟件項目、特別是不可預(yù)測的軟件項目開發(fā)中，面臨著各種緊急需求、面臨著時間壓力，沿用RUP是很難應(yīng)付自如的。所以它還是很有利于知識的積累和共享的。相比RUP用交流溝通取代詳盡的文檔，強(qiáng)調(diào)團(tuán)隊的主動、自律、自我組織和自發(fā)管理。對于項目管理者來說，他們會認(rèn)為敏捷開發(fā)方法弱化了知識管理的概念，而實(shí)際上敏捷開發(fā)注重的是最有價值的知識的積累和沉淀。 如何靈活應(yīng)對各種項目風(fēng)險、如何最大化優(yōu)先滿足用戶價值、又如何能夠有效的控制項目開發(fā)過程、如果做好項目過程中的知識管理，是每一個軟件項目管理者都需要深入思考的問題。在RUP裁剪的同時，適宜的融合敏捷開發(fā)的各種實(shí)踐。在 RUP 中融合了 XP 技術(shù)時，才會得到過程的正確量，既滿足了項目所有成員的需要，又解決了所有主要的項目風(fēng)險問題。對于團(tuán)隊越來越分散，代碼量越來越大，或者構(gòu)架沒有很好定義的情況，您需要做一些其他工作。RUP 是一個框架，可以從 RUP 出發(fā)，在必要時以一組更健壯的技術(shù)來擴(kuò)展 XP。RUP最佳實(shí)踐包括：1. 迭代開發(fā) 2． 管理需求 3． 使用基于組件的構(gòu)架 4． 可視建模 5． 持續(xù)的質(zhì)量驗證 6． 控制變更 不斷的在代碼中尋找復(fù)雜點(diǎn)并且立刻進(jìn)行移除 測試驅(qū)動開發(fā)：用戶編寫測試內(nèi)容以對故事進(jìn)行測試。在編寫代碼前先編寫測試內(nèi)容 重構(gòu)：這是一項簡化技術(shù)，用來移除代碼中的重復(fù)內(nèi)容和復(fù)雜之處 結(jié)對編程：團(tuán)隊中的兩個成員使用同一臺計算機(jī)開發(fā)所有的代碼。這就意味這每個人都可以在任何時候變更任何代碼 持續(xù)集成：每天多次創(chuàng)建和集成系統(tǒng)，只要任何實(shí)現(xiàn)任務(wù)完成就要進(jìn)行 每周 40 個小時：程序員在疲勞時無法保證最高效率。而對軟件技術(shù)平衡的思考也可以說是技術(shù)成熟的開始吧。在軟件項目開發(fā)過程中，應(yīng)該能夠識別、分析不同軟件項目的特點(diǎn)，采用相對適合的開發(fā)實(shí)踐來適應(yīng)軟件開發(fā)過程，保證對軟件開發(fā)的有效支持，以便能夠創(chuàng)造出“足夠好的”軟件。軟件開發(fā)過程學(xué)習(xí)總結(jié)目的：初步理解CMM、RUP、XP分別是怎樣的過程，弄懂其關(guān)鍵步驟，分析其優(yōu)劣及適應(yīng)情況。By Robin Zhang. :Robinsz 一、 CMM1. 綜述CMM2－CMM3，可以看作是一個嚴(yán)謹(jǐn)?shù)?，傳統(tǒng)瀑布式的開發(fā)體系。但它提供了一個目標(biāo)：一個可重復(fù)賦值成功經(jīng)驗的開發(fā)體系應(yīng)該是怎樣的。2).CMM2是一套已定義的項目管理過程，CMM3是總結(jié)不同項目的經(jīng)驗，最終形成組織（公司）的一套過程標(biāo)準(zhǔn)。4).CMM與CMMI的區(qū)別：前者僅限于軟件工程,后者還包括其他學(xué)科的CMM，如系統(tǒng)工程等；前者一般意味著瀑布過程，后者支持迭代方法。項目執(zhí)行中好的經(jīng)驗可以在別的項目中重復(fù)，軟件開發(fā)有了一定的保證?！?. 關(guān)鍵過程包括：CMM2：項目計劃、需求管理、配置管理、質(zhì)量管理、項目過程控制。需求評審,設(shè)計評審,代碼評審培訓(xùn)計劃3. 適用情況1).中大型軟件企業(yè)，同時進(jìn)行多個項目、產(chǎn)品的研發(fā)（必須有一套體系以便管理、控制）。3)適合用瀑布式過程開發(fā)的項目。缺點(diǎn)：因瀑布過程需要，要求需求凍結(jié)，導(dǎo)致需求過程要求非常高。5. 其他企業(yè)上到一定規(guī)模，偏重產(chǎn)品開發(fā)時，可以考慮上CMM。 RUP1．2．迭代開發(fā)過程及產(chǎn)出：見：《UML和設(shè)計模式》第一頁。2)第一個迭代計劃1）2） 需求基線1）按迭代計劃進(jìn)行開發(fā)2）每個迭代都實(shí)現(xiàn)一個用例集，包含一個設(shè)計編碼測試過程。業(yè)務(wù)建模領(lǐng)域模型2)確定最重要的用例需求初步基線。R挑選部分重要用例，開始建設(shè)計模型R對迭代內(nèi)的用例進(jìn)行更詳細(xì)的設(shè)計S 1）實(shí)現(xiàn)部分重要且風(fēng)險大的用例，以驗證并確定架構(gòu)設(shè)計。S根據(jù)用例編寫測試用例測試已實(shí)現(xiàn)迭代功能，編寫新迭代的測試用例s項目計劃書(前景文檔)、高層用例模型、最重要用例規(guī)格說明書、(概要設(shè)計說明書？)、開發(fā)環(huán)境(總體軟件架構(gòu)、開發(fā)規(guī)范) 80%詳細(xì)需求規(guī)格書(用例集及補(bǔ)充說明書)、用例模型、領(lǐng)域模型及設(shè)計模型，部分詳細(xì)設(shè)計文檔，部分測試用例，產(chǎn)生一個可執(zhí)行的原型(實(shí)現(xiàn)部分重要用例) 內(nèi)部發(fā)版，可用于測試的完整產(chǎn)品。產(chǎn)出23． 優(yōu)劣5．三、 XPXp注重人的因數(shù)，提倡盡量敏捷輕量級的過程。一)、Xp的缺點(diǎn)：1. 要求客戶現(xiàn)場參與。除非是分段來確認(rèn)（如迭代結(jié)束時）。目前還很難做到，因為編寫測試腳本需要花費(fèi)不少精力，一般項目無法做到。3. 缺少文檔、設(shè)計支持。二）、xp可借鑒的地方1. 對整個開發(fā)過程：迭代開發(fā)、持續(xù)集成2. 對特定迭代：編碼規(guī)范、保持設(shè)計靈活(允許需求改動)3. 設(shè)計編碼過程：測試驅(qū)動、重構(gòu)(用在編碼過程中，以客戶端來“測試驅(qū)動”業(yè)務(wù)邏輯層、以重構(gòu)減少重復(fù)代碼)參考：四、實(shí)用過程X Process：RUP+XP，并達(dá)到CMM23考慮目前國內(nèi)項目現(xiàn)況：需求調(diào)研先行，但需求不明確導(dǎo)致需求變更。1. 過程：取RUP的過程過程還是取項目啟動、細(xì)化、構(gòu)建、交付四個過程。細(xì)化階段：確定用戶需要、產(chǎn)品特性并確認(rèn)優(yōu)先級、風(fēng)險；確定80%需求，編寫需求規(guī)格書。已制定迭代計劃。 構(gòu)建階段：按計劃迭代開發(fā)。 交付階段：提交客戶測試，作小的修改。項目總結(jié)、關(guān)閉報告。3. 使用CMM的關(guān)鍵域的規(guī)范流程，以達(dá)到CMM23的效果在RUP的四個階段中，應(yīng)用CMM的關(guān)鍵域，來保證各種產(chǎn)出的質(zhì)量。三者的關(guān)系如下：1. RUP：是由用例驅(qū)動、迭代增量開發(fā)的過程，主要定義了各個階段應(yīng)該做什么，做到什么程度。3. XP：主要關(guān)注編碼階段的一些最佳實(shí)踐。強(qiáng)調(diào)“交流；簡單；反饋；實(shí)事求是”。4. 下面是按傳統(tǒng)瀑布式的過程，來考察三種過程方法在各個階段的活動及產(chǎn)出。過程RUPCMMXP項目啟動先啟項目計劃、風(fēng)險列表、過程控制、配置計劃、概要需求列表等客戶盡可能參與需求調(diào)研先啟、精化(用例模型)需求管理、需求評審、需求基線客戶盡可能參與分析設(shè)計精化、構(gòu)建(領(lǐng)域模型、設(shè)計模型)設(shè)計評審、軟件配置、培訓(xùn)計劃靈活設(shè)計、需求變更編碼實(shí)現(xiàn)構(gòu)建、啟動、精華(代碼)代碼評審、需求變更控制測試驅(qū)動開發(fā)、重構(gòu)、編碼規(guī)范、日構(gòu)建、小版本發(fā)布、簡單實(shí)現(xiàn)測試構(gòu)建、精化質(zhì)量管理Unit Test文檔及實(shí)施等交付RUP與Scrum的對話作者：IBM摘要　　現(xiàn)在使用RUP的軟件項目可以很容易地從Scrum原則中獲益，即使已經(jīng)開始的項目也是如此。 作者闡述了軟件開發(fā)團(tuán)隊在已有RUP環(huán)境中加入Scrum理念的技術(shù)。它可以很好地迎合你的軟件開發(fā)過程的需要，還可以容納其他技術(shù)。本文介紹了Scrum的一些重要特性，并闡述了可以讓你在已有RUP環(huán)境中加入Scrum理念的技術(shù)。 Scrum是一種靈活的軟件管理過程，它可以幫助你駕馭迭代，遞增的軟件開發(fā)過程。這個輕量的過程可以作為包裝器，也就是說你可以把Scrum與其它靈活的過程框架組合起來，比如說RUP。 Scrum提供了一種經(jīng)驗方法，它使得團(tuán)隊成員能夠獨(dú)立地，集中地在創(chuàng)造性的環(huán)境下工作。Scrum一詞來源于橄欖球運(yùn)動，暗指這種情況：“在橄欖球比賽中，雙方前鋒站在一起緊密相連，當(dāng)球在他們之間投擲時他們奮力爭球。 Scrum認(rèn)為軟件的開發(fā)不應(yīng)使用和一般制造業(yè)相同的方法，也就是不應(yīng)采用一種反復(fù)的模式?，F(xiàn)代軟件工程的主要挑戰(zhàn)包括上市時間，投資回報，以及影響顧客的需要等。 Scrum區(qū)別于其他開發(fā)過程之處是什么？假設(shè)你是一個Scrum項目的初次觀察者，那么最顯而易見的不同將是每天的短會，通常在每天的同一時間在同一個房間內(nèi)舉行。 *自上次Scrum會議后你做了什么？ *你在工作中遇到了哪些困難？ 由于一個Scrum團(tuán)隊最多由7人組成，會議應(yīng)當(dāng)不超過15分鐘。他傾聽每個成員的發(fā)言并設(shè)法解決會議中提到的各種障礙。Scrum會議不同于項目會議，對團(tuán)隊來說，它起到了快速簡報的作用。 對于人數(shù)多于7人的項目團(tuán)隊，Scrum建議與其擴(kuò)大團(tuán)隊規(guī)模不如將團(tuán)隊分組。分組后各個子團(tuán)隊就可以并行工作了，而且Scrum管理者可以通過Scrum會議對各個子團(tuán)隊的工作進(jìn)行同步。 更多時候，成員可以身