第10章信息系統(tǒng)開(kāi)發(fā)

第10章信息系統(tǒng)開(kāi)發(fā)10.1信息系統(tǒng)規(guī)劃10.2系統(tǒng)復(fù)雜性與需求的重要性10.3軟件開(kāi)發(fā)模型10.4敏捷開(kāi)發(fā)方法10.5系統(tǒng)分析與設(shè)計(jì)（結(jié)構(gòu)化方法）10.6系統(tǒng)分析與設(shè)計(jì)（面向?qū)ο蠓椒ǎ?第10章信息系統(tǒng)開(kāi)發(fā)3掌握軟件開(kāi)發(fā)模型掌握敏捷開(kāi)發(fā)方法了解信息系統(tǒng)規(guī)劃了解系統(tǒng)分析與設(shè)計(jì)的結(jié)構(gòu)化方法了解系統(tǒng)分析與設(shè)計(jì)的面向?qū)ο蠓椒▽W(xué)習(xí)目標(biāo)3案例廣東移動(dòng)管理信息系統(tǒng)云計(jì)算體系研究10.1信息系統(tǒng)規(guī)劃信息系統(tǒng)規(guī)劃是一個(gè)識(shí)別支持企業(yè)戰(zhàn)略和目標(biāo)的信息系統(tǒng)的過(guò)程。常見(jiàn)的信息系統(tǒng)規(guī)劃諾蘭階段模型法信息工程法價(jià)值鏈分析法企業(yè)系統(tǒng)規(guī)劃法關(guān)鍵成功要素法信息系統(tǒng)建設(shè)的六個(gè)階段（諾蘭模型）單系統(tǒng)獨(dú)立建設(shè)階段

引入數(shù)據(jù)處理系統(tǒng)，不關(guān)注系統(tǒng)的經(jīng)濟(jì)效益，用戶對(duì)信息系統(tǒng)抱著敬而遠(yuǎn)之的態(tài)度。

系統(tǒng)規(guī)模建設(shè)階段

信息技術(shù)應(yīng)用開(kāi)始擴(kuò)散，管理者開(kāi)始關(guān)注系統(tǒng)投資的經(jīng)濟(jì)效益，但還不存在實(shí)質(zhì)的控制。系統(tǒng)規(guī)劃發(fā)展階段

對(duì)管理信息系統(tǒng)的管控走向正規(guī)，啟動(dòng)了系統(tǒng)建設(shè)規(guī)劃和項(xiàng)目管理計(jì)劃。系統(tǒng)嘗試整合階段

從管理計(jì)算機(jī)轉(zhuǎn)向管理信息資源，開(kāi)始使用數(shù)據(jù)庫(kù)和遠(yuǎn)程通信技術(shù)，努力整合現(xiàn)有的信息系統(tǒng)。系統(tǒng)綜合支撐階段

系統(tǒng)從支持單項(xiàng)應(yīng)用發(fā)展到支持綜合應(yīng)用，組織開(kāi)始評(píng)估信息系統(tǒng)建設(shè)的成本和效益。全面信息化階段

正式的信息資源計(jì)劃和控制系統(tǒng)投入使用，信息資源管理的效用充分體現(xiàn)出來(lái)。10.1信息系統(tǒng)規(guī)劃——諾蘭諾蘭模型是第一個(gè)描述信息系統(tǒng)發(fā)展階段的抽象化模型諾蘭模型的假設(shè)：企業(yè)只有不斷學(xué)習(xí)才能推動(dòng)階段間的轉(zhuǎn)移10.1信息系統(tǒng)規(guī)劃——BSP企業(yè)系統(tǒng)規(guī)劃（BusinessSystemPlanning，BSP）法是對(duì)企業(yè)管理信息系統(tǒng)進(jìn)行規(guī)劃和設(shè)計(jì)的結(jié)構(gòu)化方法BSP法主要基于利用信息技術(shù)和信息系統(tǒng)支持企業(yè)運(yùn)營(yíng)的思想，是把企業(yè)目標(biāo)轉(zhuǎn)化為信息系統(tǒng)戰(zhàn)略的全過(guò)程BSP方法所支持的目標(biāo)是企業(yè)各層次的目標(biāo)，實(shí)現(xiàn)這種支持需要許多子系統(tǒng)。10.1信息系統(tǒng)規(guī)劃——CSF關(guān)鍵成功因素法（CriticalSuccessFactors，CSF）可用來(lái)幫助進(jìn)行信息系統(tǒng)規(guī)劃和需求分析。關(guān)鍵成功因素總是與那些能確保企業(yè)具有競(jìng)爭(zhēng)能力的方面相關(guān)的。在不同類型的業(yè)務(wù)活動(dòng)中，關(guān)鍵成功因素會(huì)有很大的不同，即使在同一類型的業(yè)務(wù)活動(dòng)中，在不同時(shí)間內(nèi)，其關(guān)鍵成功因素也會(huì)不同。如產(chǎn)品性價(jià)比、用戶體驗(yàn)、品牌理念……10.1信息系統(tǒng)規(guī)劃——比較主要優(yōu)點(diǎn)在于它對(duì)信息系統(tǒng)問(wèn)題提出了一個(gè)全面的觀點(diǎn)；而且能夠明確顯示信息系統(tǒng)功能在哪方面影響企業(yè)由于該模型的范圍僅限于企業(yè)內(nèi)的信息系統(tǒng)功能，成長(zhǎng)階段方法基本上是一個(gè)效率導(dǎo)向型方法成長(zhǎng)階段法使信息技術(shù)人員與其他人員一起考查企業(yè)工作的過(guò)程；而且能幫助企業(yè)對(duì)數(shù)據(jù)類有一個(gè)清晰的了解沒(méi)有指明哪個(gè)信息系統(tǒng)應(yīng)用最為重要，因此，其分析結(jié)果必須在能夠定出信息系統(tǒng)應(yīng)用優(yōu)先次序的更大架構(gòu)內(nèi)解釋企業(yè)系統(tǒng)規(guī)劃法目的是要確定企業(yè)成功最重要的因素，并確保企業(yè)獲得信息系統(tǒng)應(yīng)用的支援。因此其重點(diǎn)放在商業(yè)環(huán)境下取得成功的關(guān)鍵因素上此方法注重企業(yè)的競(jìng)爭(zhēng)性和有效性關(guān)鍵成功因素法10.2系統(tǒng)復(fù)雜性與需求的重要性系統(tǒng)需求環(huán)節(jié)中的主要問(wèn)題（1）缺少規(guī)劃和設(shè)計(jì)環(huán)節(jié)，軟件的結(jié)構(gòu)隨著不斷的修改越來(lái)越糟，導(dǎo)致無(wú)法繼續(xù)修改；（2）忽略需求環(huán)節(jié)，再精心設(shè)計(jì)的軟件也可能很難匹配用戶的需求，導(dǎo)致要么被拒絕，要么花費(fèi)昂貴的代價(jià)重建。（3）沒(méi)有考慮測(cè)試和程序的可維護(hù)性，也沒(méi)有任何文檔，軟件的維護(hù)十分困難。10.2系統(tǒng)復(fù)雜性與需求的重要性（續(xù)）圖10-1需求變更對(duì)系統(tǒng)開(kāi)發(fā)成本的影響越早開(kāi)始寫(xiě)代碼，花費(fèi)的時(shí)間越長(zhǎng)！10.3軟件開(kāi)發(fā)模型軟件開(kāi)發(fā)模型(SoftwareDevelopmentModel)是指軟件開(kāi)發(fā)全部過(guò)程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架。軟件開(kāi)發(fā)過(guò)程包括需求分析、設(shè)計(jì)、編碼和測(cè)試等階段，有時(shí)也包括維護(hù)階段。典型開(kāi)發(fā)模型生命周期模型（Lifecyclemodel）原型模型（Prototypemodel）螺旋模型（Spiralmodel）敏捷模型（Agilemodel）10.3軟件開(kāi)發(fā)模型（續(xù)）10.3.1生命周期模型（瀑布模型）圖10-2生命周期模型確定系統(tǒng)、設(shè)定范疇、指定計(jì)劃需求分析，避免后續(xù)階段出現(xiàn)需求變更構(gòu)建未來(lái)系統(tǒng)的技術(shù)藍(lán)圖技術(shù)框架、數(shù)據(jù)庫(kù)和程序單元測(cè)試（通常由開(kāi)發(fā)人員完成）、功能測(cè)試、系統(tǒng)集成測(cè)試以及用戶接受測(cè)試保障系統(tǒng)持續(xù)滿足業(yè)務(wù)需求，并進(jìn)行必要的修補(bǔ)10.3軟件開(kāi)發(fā)模型（續(xù)）10.3.1生命周期模型——局限性該模型假設(shè)用戶能夠在項(xiàng)目開(kāi)始階段就明確自己的需求，并且能夠清楚地表達(dá)給開(kāi)發(fā)人員缺乏靈活性，是個(gè)線性的過(guò)程，不便于通過(guò)必要的迭代或并發(fā)活動(dòng)澄清本來(lái)不夠明確的需求要求階段之間產(chǎn)生大量詳盡的文檔，作為后續(xù)開(kāi)發(fā)工作的依據(jù)。需求，設(shè)計(jì)階段的問(wèn)題10.3軟件開(kāi)發(fā)模型（續(xù)）10.3.2快速原型模型原型的必要性在于：用戶需要借助具體的設(shè)計(jì)來(lái)描述需求；用戶缺乏想象設(shè)計(jì)效果的能力；用戶沒(méi)有能力對(duì)技術(shù)設(shè)計(jì)文檔作評(píng)論；幾乎不可能為用戶界面提供一種完全、一致、可用的描述；有利于盡早開(kāi)始進(jìn)行有用戶參與的連續(xù)性測(cè)試。10.3軟件開(kāi)發(fā)模型（續(xù)）10.3.2快速原型模型（續(xù)）圖10-3快速原型模型舉例：紀(jì)檢監(jiān)察部網(wǎng)站改版10.3軟件開(kāi)發(fā)模型（續(xù)）10.3.3螺旋模型螺旋模型將生命周期模型和快速原型模型結(jié)合起來(lái)，強(qiáng)調(diào)其他模型所忽略的風(fēng)險(xiǎn)分析，比快速原型模型更加適合于大型復(fù)雜系統(tǒng)螺旋模型沿著螺線進(jìn)行若干次迭代：制定計(jì)劃明確該階段的目標(biāo)從風(fēng)險(xiǎn)角度分析備選方案實(shí)施開(kāi)發(fā)客戶評(píng)價(jià)開(kāi)發(fā)結(jié)果，提出建議10.3軟件開(kāi)發(fā)模型（續(xù)）10.3.3螺旋模型（續(xù)）圖10-4螺旋模型10.3軟件開(kāi)發(fā)模型（續(xù)）10.3.3螺旋模型——局限性說(shuō)服大客戶接受這樣的演進(jìn)式系統(tǒng)開(kāi)發(fā)可能比較困難，合同管理和項(xiàng)目控制都比較難螺旋模型強(qiáng)調(diào)風(fēng)險(xiǎn)分析，因此對(duì)軟件開(kāi)發(fā)人員要求較高，他們必須擅長(zhǎng)識(shí)別和評(píng)估風(fēng)險(xiǎn)10.3軟件開(kāi)發(fā)模型（續(xù)）10.3.4敏捷模型敏捷模型是應(yīng)對(duì)快速變化和不確定性需求的一種

軟件開(kāi)發(fā)論。敏捷開(kāi)發(fā)方法Scrum極限編程（ExtremeProgramming,常縮寫(xiě)為XP）敏捷統(tǒng)一過(guò)程（AgileUnifiedProcess,?？s寫(xiě)為AUP）10.3軟件開(kāi)發(fā)模型（續(xù)）10.3.4敏捷模型（續(xù)）圖10-5理想的XP生命周期10.4敏捷開(kāi)發(fā)方法—以Scrum為例Scrum，暫譯為“密集沖刺”，這是種輕量級(jí)敏捷項(xiàng)目管理方法，特別適合在需求多變不確定的情況下，以快速迭代和增量式開(kāi)發(fā)軟件系統(tǒng)和產(chǎn)品。三個(gè)基本原則是高可視度、頻繁檢查和適應(yīng)高可視度（Visibility）指確保中間環(huán)節(jié)的可觀察性；頻繁檢查（Inspection）提供了及時(shí)評(píng)估中間成果和發(fā)現(xiàn)問(wèn)題的可能；適應(yīng)（Adaptation）就是調(diào)整，對(duì)不符合標(biāo)準(zhǔn)的過(guò)程和操作進(jìn)行修改和完善。Scrum敏捷項(xiàng)目管理目錄敏捷的背景與動(dòng)機(jī)敏捷宣言及原則敏捷方法的實(shí)踐Scrum的角色Scrum流程和工作產(chǎn)品26Scrum是英語(yǔ)中橄欖球運(yùn)動(dòng)的一個(gè)專業(yè)術(shù)語(yǔ)，表示“爭(zhēng)球”，有時(shí)也翻譯成“密集沖刺”。軟件項(xiàng)目的復(fù)雜性橫軸代表需求的復(fù)雜度縱軸表示技術(shù)的復(fù)雜度還有人力資源的復(fù)雜度27敏捷開(kāi)發(fā)模型舉例——互聯(lián)網(wǎng)時(shí)代的出版模式作者最開(kāi)始的時(shí)候并沒(méi)有想出一本書(shū)，而只是把多年的積累梳理出來(lái)寫(xiě)成了博客，憑借博客的成功最后得到了出版商和紙版讀者的認(rèn)可。在寫(xiě)成本書(shū)的過(guò)程中，作者是漸進(jìn)式的進(jìn)行的，每寫(xiě)完一個(gè)章節(jié)，放到博客上去征求讀者的反饋，很多反饋意見(jiàn)在后面的章節(jié)或修訂中及時(shí)地體現(xiàn)出來(lái)，這樣就形成了與讀者之間的良好反饋，在出版之前就鎖定了大量的讀者。這就是敏捷開(kāi)發(fā)提倡的“增量迭代、及時(shí)交付”的思想。這種模式能最大程度地不偏離客戶需求的本質(zhì)。目錄敏捷的背景與動(dòng)機(jī)敏捷宣言及原則敏捷方法的實(shí)踐Scrum的角色Scrum流程和工作產(chǎn)品29敏捷價(jià)值觀之敏捷宣言30敏捷開(kāi)發(fā)的核心思想是：以人為本，適應(yīng)變化。敏捷價(jià)值觀之敏捷宣言-1個(gè)體和交互勝過(guò)過(guò)程和工具人是軟件項(xiàng)目獲得成功最為重要的因素合作、溝通能力以及交互能力比單純的軟件編程能力和工具更為重要方法和工具是死的，人是活的，人要是太“面”或者協(xié)作不好，再?gòu)?qiáng)大的方法和工具都是白扯；31敏捷價(jià)值觀之敏捷宣言-2可以工作的軟件勝過(guò)面面俱到的文檔過(guò)多的面面俱到的文檔往往比過(guò)少的文檔更糟軟件開(kāi)發(fā)的主要和中心活動(dòng)是創(chuàng)建可以工作的軟件直到迫切需要并且意義重大時(shí)，才進(jìn)行文檔編制編制的內(nèi)部文檔應(yīng)盡量短小并且主題突出32敏捷價(jià)值觀之敏捷宣言-3客戶合作勝過(guò)合同談判客戶不可能做到一次性地將他們的需求完整清晰地表述在合同中為開(kāi)發(fā)團(tuán)隊(duì)和客戶的協(xié)同工作方式提供指導(dǎo)的合同才是最好的合同33敏捷價(jià)值觀之敏捷宣言-4響應(yīng)變化勝過(guò)循環(huán)計(jì)劃變化是軟件開(kāi)發(fā)中存在的現(xiàn)實(shí)計(jì)劃必須有足夠的靈活性與可塑性短期的迭代的計(jì)劃比中長(zhǎng)期計(jì)劃更有效JiangsuMicrosoftTechnologyCenter34敏捷開(kāi)發(fā)的12個(gè)原則我們最優(yōu)先要做的是通過(guò)盡早的、持續(xù)的交付有價(jià)值的軟件來(lái)使客戶滿意。即使到了開(kāi)發(fā)的后期，也歡迎改變需求。經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾周到幾個(gè)月，交付的時(shí)間間隔越短越好。在整個(gè)項(xiàng)目開(kāi)發(fā)期間，業(yè)務(wù)人員和開(kāi)發(fā)人員必須天天都在一起工作。圍繞被激勵(lì)起來(lái)的個(gè)人來(lái)構(gòu)建項(xiàng)目。在團(tuán)隊(duì)內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對(duì)面的交談。

敏捷開(kāi)發(fā)的12個(gè)原則工作的軟件是首要的進(jìn)度度量標(biāo)準(zhǔn)。敏捷過(guò)程提倡平穩(wěn)的開(kāi)發(fā)節(jié)奏；發(fā)起人、開(kāi)發(fā)者和用戶應(yīng)該能夠保持一個(gè)長(zhǎng)期的、恒定的開(kāi)發(fā)速度。不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計(jì)會(huì)增強(qiáng)敏捷能力。簡(jiǎn)單化是根本（不做過(guò)度設(shè)計(jì)和預(yù)測(cè)）。最好的構(gòu)架、需求和設(shè)計(jì)出自于自組織的團(tuán)隊(duì)。每隔一定時(shí)間，團(tuán)隊(duì)會(huì)在如何才能更有效地工作方面進(jìn)行反思并對(duì)自己的行為進(jìn)行相應(yīng)調(diào)整。目錄敏捷的背景與動(dòng)機(jī)敏捷宣言及原則敏捷方法的實(shí)踐

Scrum的角色Scrum流程和工作產(chǎn)品37敏捷關(guān)鍵實(shí)踐1——增量迭代每個(gè)迭代有一個(gè)大約為1～4周的時(shí)間框，在SCRUM里稱為一次沖刺（超過(guò)1個(gè)月的詳細(xì)計(jì)劃往往偏差很大）每次迭代都應(yīng)該有明確的目標(biāo)每次迭代都應(yīng)該有明確的可演示的工作成果迭代過(guò)程中項(xiàng)目團(tuán)隊(duì)?wèi)?yīng)該盡量免受打擾迭代可以將項(xiàng)目的壓力分解到每個(gè)小的階段，風(fēng)險(xiǎn)也能同時(shí)分解38敏捷關(guān)鍵實(shí)踐2——面對(duì)面交流雖然如今通訊工具花樣繁多，但面對(duì)面交流在某些場(chǎng)合下仍然是不可替代的；敏捷開(kāi)發(fā)把交流缺失問(wèn)題考慮在內(nèi)，要求團(tuán)隊(duì)成員彼此直接協(xié)作，盡量創(chuàng)造面對(duì)面交流的機(jī)會(huì)；尤其當(dāng)業(yè)務(wù)分析師和軟件開(kāi)發(fā)人員一起工作的時(shí)候，面對(duì)面的交流是很重要的。匿名共享需求文檔只會(huì)打開(kāi)曲解和誤解之門(mén)，更不用說(shuō)書(shū)面信息比口頭交流還要慢很多。39敏捷方法的其它實(shí)踐結(jié)對(duì)編程每日站立短會(huì)用戶故事團(tuán)隊(duì)工作室頻繁發(fā)布自組織團(tuán)隊(duì)重構(gòu)40目錄敏捷的背景與動(dòng)機(jī)敏捷宣言及原則敏捷方法是什么？敏捷方法的實(shí)踐Scrum的角色Scrum流程和工作產(chǎn)品41Scrum框架42www.海頤軟件Scrum角色Scrum角色之ProductOwner產(chǎn)品負(fù)責(zé)人（ProductOwner）的職責(zé)如下：確定產(chǎn)品的功能。決定發(fā)布的日期和發(fā)布內(nèi)容。為產(chǎn)品的profitabilityoftheproduct(ROI)負(fù)責(zé)。根據(jù)市場(chǎng)價(jià)值確定功能優(yōu)先級(jí)。每個(gè)Sprint（即迭代周期），根據(jù)需要調(diào)整功能和優(yōu)先級(jí)（每個(gè)Sprint開(kāi)始前調(diào)整）。接受或拒絕接受開(kāi)發(fā)團(tuán)隊(duì)的工作成果。44Scrum角色之ScrumMaster作為T(mén)eamLeader和Productowner緊密地工作在一起，他可以及時(shí)地為團(tuán)隊(duì)成員提供幫助。他必須:保證團(tuán)隊(duì)資源完全可被利用并且全部是高產(chǎn)出的。保證各個(gè)角色及職責(zé)的良好協(xié)作。解決團(tuán)隊(duì)開(kāi)發(fā)中的障礙。做為團(tuán)隊(duì)和外部的接口，屏蔽外界對(duì)團(tuán)隊(duì)成員的干擾。保證開(kāi)發(fā)過(guò)程按計(jì)劃進(jìn)行，組織DailyScrum,SprintReviewandSprintPlanningmeetings。45Scrum角色之ScrumTeam一般情況人數(shù)在5-9個(gè)左右團(tuán)隊(duì)要跨職能（包括開(kāi)發(fā)人員、測(cè)試人員、用戶界面設(shè)計(jì)師等）團(tuán)隊(duì)成員需要全職。（有些情況例外，比如數(shù)據(jù)庫(kù)管理員）在項(xiàng)目向?qū)Х秶鷥?nèi)有權(quán)利做任何事情已確保達(dá)到Sprint的目標(biāo)。高度的自我組織能力。向ProductOwner演示產(chǎn)品功能。團(tuán)隊(duì)成員構(gòu)成在sprint內(nèi)不允許變化。46目錄敏捷的背景與動(dòng)機(jī)敏捷宣言及原則敏捷方法是什么？敏捷方法的實(shí)踐Scrum的角色Scrum流程和工作產(chǎn)品4710.4敏捷開(kāi)發(fā)方法—以Scrum為例10.4.2Scrum的過(guò)程框架圖10-6Scrum過(guò)程框架Sprints(沖刺)Scrum的項(xiàng)目過(guò)程由一系列的Sprint組成。Sprint的長(zhǎng)度一般控制在2-4周。通過(guò)固定的周期保持良好的節(jié)奏。產(chǎn)品的設(shè)計(jì)、開(kāi)發(fā)、測(cè)試都在Sprint期間完成。Sprint結(jié)束時(shí)交付可以工作的軟件。在Sprint過(guò)程中不允許發(fā)生變更。49Scrum框架50Scrum儀式之Sprint計(jì)劃會(huì)議計(jì)劃會(huì)議要有足夠的時(shí)間取出部分產(chǎn)品需求做成sprint需求，并寫(xiě)成索引卡確定并細(xì)分每一個(gè)索引卡的故事（Story）進(jìn)行工作認(rèn)領(lǐng)（不是分配）確定每日站立會(huì)議的時(shí)間和地點(diǎn)確定好評(píng)審會(huì)議和回顧會(huì)議的日期Scrum儀式之Sprint計(jì)劃會(huì)議JiangsuMicrosoftTechnologyCenter52Scrum儀式之每日Scrum會(huì)議(DailyScrum)每日Scrum會(huì)議，即團(tuán)隊(duì)每日例會(huì)，條件允許的話，每天都應(yīng)該在同樣的時(shí)間和地點(diǎn)，組織所有成員站立進(jìn)行。最好是每天早晨開(kāi)，一般15分鐘左右，時(shí)間比較短，也有利于團(tuán)隊(duì)成員安排好當(dāng)天的工作。只有團(tuán)隊(duì)成員可以在例會(huì)上發(fā)言，其他人員有興趣可以參加，但只能旁聽(tīng)，不能發(fā)言。每日Scrum會(huì)議由ScrumMaster主持，Scrum團(tuán)隊(duì)所有成員輪流回答以下3個(gè)問(wèn)題：昨天我完成了什么工作？今天我打算做什么？我在工作中遇到了什么困難？JiangsuMicrosoftTechnologyCenter53場(chǎng)景展示-每日站立會(huì)議Scrum任務(wù)板(TaskBoard)JiangsuMicrosoftTechnologyCenter56任務(wù)板（墻）展現(xiàn)了在Sprint過(guò)程中所有要完成的任務(wù)。在Sprint過(guò)程中我們要不斷的更新它。如果某個(gè)開(kāi)發(fā)人員想到了一個(gè)任務(wù)他就可以把這個(gè)任務(wù)寫(xiě)下來(lái)放在任務(wù)墻上。無(wú)論每日站會(huì)過(guò)程中或者之后，如果估計(jì)發(fā)生了變化，任務(wù)會(huì)根據(jù)變化在任務(wù)墻上做相應(yīng)的調(diào)整。通常的任務(wù)板是下面這個(gè)樣子:場(chǎng)景展示-任務(wù)看板Scrum儀式之Sprint評(píng)審會(huì)議Sprint評(píng)審會(huì)用來(lái)演示在這個(gè)Sprint中開(kāi)發(fā)的產(chǎn)品功能給ProductOwner.ProductOwner會(huì)組織這階段的會(huì)議并且邀請(qǐng)相關(guān)的干系人參加。團(tuán)隊(duì)展示Sprint中完成的功能一般是通過(guò)現(xiàn)場(chǎng)演示的方式展現(xiàn)功能和架構(gòu)不要太正式團(tuán)隊(duì)成員都要參加可以邀請(qǐng)所有人參加JiangsuMicrosoftTechnologyCenter59Scrum儀式之Sprint回顧會(huì)議JiangsuMicrosoftTechnologyCenter60團(tuán)隊(duì)的定期自我檢視，發(fā)現(xiàn)什么是好的，什么是不好的。一般控制在15-30分鐘每個(gè)Sprint都要做全體參加ScrumMaster產(chǎn)品負(fù)責(zé)人團(tuán)隊(duì)可能的客戶或其它干系人Sprint回顧會(huì)議上，全體成員討論有哪些好的做法可以啟動(dòng)，哪些不好的做法不能再繼續(xù)下去了，哪些好的做法要繼續(xù)發(fā)揚(yáng)。Scrum框架61Scrum物件之產(chǎn)品訂單(ProductBacklog)一個(gè)需求的列表。一般情況使用用戶故事來(lái)表示backlog條目理想情況每個(gè)需求項(xiàng)都對(duì)產(chǎn)品的客戶或用戶有價(jià)值Backlog條目按照商業(yè)價(jià)值排列優(yōu)先級(jí)優(yōu)先級(jí)由產(chǎn)品負(fù)責(zé)人來(lái)排列在每個(gè)Sprint結(jié)束的時(shí)候要更新優(yōu)先級(jí)的排列JiangsuMicrosoftTechnologyCenter62Scrum物件之產(chǎn)品訂單(ProductBacklog)JiangsuMicrosoftTechnologyCenter63Imp：重要性；Est：大致相當(dāng)于一個(gè)“理想的人天（man-day）”Scrum物件之沖刺訂單(SprintBacklog)管理Sprint的backlog:團(tuán)隊(duì)成員自己挑選任務(wù)，而不是指派任務(wù)對(duì)每一個(gè)任務(wù)，每天要更新剩余的工作量估算每個(gè)團(tuán)隊(duì)成員都可以修改Sprintbacklog，增加、刪除或者修改任務(wù)JiangsuMicrosoftTechnologyCenter64Scrum物件之燃盡圖(BurnDownChart)656667推薦書(shū)籍：《人月神話》第1章焦油坑第2章人月神話第3章外科手術(shù)隊(duì)伍第4章貴族專制、民主政治和系統(tǒng)設(shè)計(jì)第5章畫(huà)蛇添足第6章貫徹執(zhí)行第7章為什么巴比倫塔會(huì)失敗第8章胸有成竹第9章削足適履第10章提綱挈領(lǐng)第11章未雨綢繆第12章干將莫邪第13章整體部分第14章禍起蕭墻第15章另外一面第16章沒(méi)有銀彈……1、人月神話：向一個(gè)已經(jīng)延后的項(xiàng)目中投入更多的人力資源只會(huì)讓它更延后2、沒(méi)有銀彈：沒(méi)有一種策略，技術(shù)或者技巧可以極大地提高程序員的生產(chǎn)力10.5系統(tǒng)分析與設(shè)計(jì)—結(jié)構(gòu)化方