敏捷開(kāi)發(fā)培訓(xùn)Agile-Development課件

敏捷開(kāi)發(fā)培訓(xùn)AgileDevelopment敏捷開(kāi)發(fā)培訓(xùn)AgileDevelopment敏捷開(kāi)發(fā)培訓(xùn)AgileDevelopment敏捷開(kāi)發(fā)培訓(xùn)AgileDevelopment敏捷開(kāi)發(fā)培訓(xùn)A1Content

AgileDevelopment介紹RUPXPScrum2022/12/112ContentAgileDevelopment介紹202AgileProcess-敏捷的開(kāi)發(fā)流程AgileProcess(敏捷的開(kāi)發(fā)流程)是一種軟件開(kāi)發(fā)流程的泛稱，幾項(xiàng)共通的特性：客戶及開(kāi)發(fā)人員形成密切合作的團(tuán)隊(duì)，因?yàn)榭蛻魺o(wú)法于初期定義完整的規(guī)格，而開(kāi)發(fā)人員于開(kāi)發(fā)過(guò)程中也常常無(wú)法知悉外在環(huán)境或業(yè)務(wù)的變動(dòng)，所以需要兩者密切合作方能開(kāi)發(fā)適用的軟件。項(xiàng)目最終的目標(biāo)是可執(zhí)行的程序，因此所有的中間產(chǎn)品必須經(jīng)過(guò)審慎評(píng)估，確認(rèn)有助于最終目標(biāo)，才需要制作中間產(chǎn)品。采用Iterative與Incremental方式分階段進(jìn)行，密集review是否符合需求。流程可以簡(jiǎn)單，但規(guī)劃與執(zhí)行必須嚴(yán)謹(jǐn)。強(qiáng)調(diào)團(tuán)隊(duì)合作，賦予高度的責(zé)任，團(tuán)隊(duì)有自主權(quán)得以因應(yīng)變化做調(diào)整2022/12/113AgileProcess-敏捷的開(kāi)發(fā)流程AgilePAgileDevelopment敏捷開(kāi)發(fā)是一種以人為核心、迭代、循序漸進(jìn)的開(kāi)發(fā)方法在敏捷開(kāi)發(fā)中，項(xiàng)目的構(gòu)建被切分成多個(gè)子項(xiàng)目，各個(gè)子項(xiàng)目的成果都經(jīng)過(guò)測(cè)試，具備集成和可運(yùn)行的特征。2022/12/114AgileDevelopment敏捷開(kāi)發(fā)是一種以人為核心、敏捷開(kāi)發(fā)核心價(jià)值(CoreValue)Individualsandinteractionsoverprocessesandtools

個(gè)人和交流重于過(guò)程和工具

Workingsoftwareovercomprehensivedocumentation

正在運(yùn)行的軟件本身重于復(fù)雜的文檔

Customercollaborationovercontractnegotiation

及客戶的溝通和交流重于使用合同約束客戶

Respondingtochangeoverfollowingaplan

對(duì)變化的快速響應(yīng)重于跟隨計(jì)劃2022/12/115敏捷開(kāi)發(fā)核心價(jià)值(CoreValue)Individua敏捷開(kāi)發(fā)原則(Principles)最高目標(biāo)是通過(guò)快速的和經(jīng)常的發(fā)布軟件滿足客戶的需要提交軟件的周期為幾個(gè)星期到幾個(gè)月產(chǎn)生正確的軟件是衡量進(jìn)度的首要標(biāo)準(zhǔn)主動(dòng)接受需求的改變而不是拒絕商務(wù)人員和開(kāi)發(fā)人員工作在一起個(gè)人必須有動(dòng)力，要?jiǎng)?chuàng)造環(huán)境支持他們的要求，信任他們最有效的交流方法是面對(duì)面的交流最好的結(jié)構(gòu)，需求和設(shè)計(jì)來(lái)自于自組織的團(tuán)隊(duì)（self-organizingteam），允許任何人提出想法和建議持續(xù)改進(jìn)設(shè)計(jì)和編碼鼓勵(lì)正常工作，減少長(zhǎng)時(shí)間加班保持簡(jiǎn)單，減少不必要的部分，認(rèn)識(shí)到簡(jiǎn)單的設(shè)計(jì)比復(fù)雜的設(shè)計(jì)更難（simpledesignishardertoproduce）定期調(diào)整過(guò)程，獲得更高效率2022/12/116敏捷開(kāi)發(fā)原則(Principles)最高目標(biāo)是通過(guò)快速的和經(jīng)敏捷開(kāi)發(fā)的設(shè)計(jì)原則SRP單一職責(zé)原則SRP：SingleResponsibilityPrincipleOCP開(kāi)放封閉原則OCP：Open－ClosePrincipleLSPLiskov替換原則LSP：LiskovSubstitutionPrincipleDIP依賴倒置原則DIP：DependencyInvertionPrincipleISP接口隔離原則ISP：InterfaceSeparatePrinciple2022/12/117敏捷開(kāi)發(fā)的設(shè)計(jì)原則SRP2022/12/107敏捷開(kāi)發(fā)-迭代計(jì)劃最新版本驗(yàn)收測(cè)試發(fā)布計(jì)劃迭代計(jì)劃開(kāi)發(fā)項(xiàng)目周期2022/12/118敏捷開(kāi)發(fā)-迭代計(jì)劃最新版本驗(yàn)收測(cè)試發(fā)布計(jì)劃迭代計(jì)劃開(kāi)發(fā)項(xiàng)目周敏捷開(kāi)發(fā)-迭代計(jì)劃2022/12/119敏捷開(kāi)發(fā)-迭代計(jì)劃2022/12/109名詞解釋故事故事是客戶想要系統(tǒng)做的事情，適合在一至兩個(gè)迭代內(nèi)完成，并且是可測(cè)試的，他不一定是商業(yè)價(jià)值的直接體現(xiàn)。迭代迭代是一個(gè)周期在2-4周，能夠完成當(dāng)前團(tuán)隊(duì)所能實(shí)現(xiàn)的，最具商業(yè)價(jià)值的功能，并可以提供一個(gè)可工作的小版本供發(fā)布。VelocityVelocity翻譯為項(xiàng)目周轉(zhuǎn)時(shí)間。代表團(tuán)隊(duì)在給定周期內(nèi)能夠完成多少商業(yè)價(jià)值，以便用于衡量將來(lái)該團(tuán)隊(duì)能夠提供的商業(yè)價(jià)值。也即昨天的天氣。2022/12/1110名詞解釋故事故事是客戶想要系統(tǒng)做的事情，適合在一至兩個(gè)迭代名詞解釋優(yōu)先級(jí)優(yōu)先級(jí)主要考慮商業(yè)價(jià)值，同時(shí)兼顧市場(chǎng)風(fēng)險(xiǎn)、商業(yè)風(fēng)險(xiǎn)、技術(shù)風(fēng)險(xiǎn)等因素在內(nèi)的一個(gè)衡量數(shù)字，優(yōu)先級(jí)越高通常意味著其商業(yè)價(jià)值越高風(fēng)險(xiǎn)系數(shù)風(fēng)險(xiǎn)系數(shù)綜合商業(yè)環(huán)境、項(xiàng)目資源、技術(shù)以及項(xiàng)目環(huán)境等等因素在內(nèi)的一個(gè)衡量數(shù)字，它是優(yōu)先級(jí)的重要衡量指標(biāo)之一。它通常出現(xiàn)在故事中。風(fēng)險(xiǎn)系數(shù)較大意味著優(yōu)先級(jí)也較大。負(fù)載因子負(fù)載因子是綜合項(xiàng)目成員的技術(shù)能力、技能集、精神狀態(tài)等等因素，對(duì)于團(tuán)隊(duì)成員的一個(gè)負(fù)載系數(shù)。2022/12/1111名詞解釋優(yōu)先級(jí)優(yōu)先級(jí)主要考慮商業(yè)價(jià)值，同時(shí)兼顧市場(chǎng)風(fēng)險(xiǎn)、商名詞解釋理想時(shí)間理想時(shí)間排除一切可能的外界干擾，同時(shí)排除自身的精神狀態(tài)，職業(yè)態(tài)度等等因素，完成某項(xiàng)工作所需要的時(shí)間。實(shí)際時(shí)間實(shí)際時(shí)間理想時(shí)間乘上負(fù)載因子任務(wù)任務(wù)分配到項(xiàng)目成員，從故事切分的出來(lái)。通常任務(wù)時(shí)間不應(yīng)該超過(guò)10個(gè)實(shí)際工作日。2022/12/1112名詞解釋理想時(shí)間理想時(shí)間排除一切可能的外界干擾，同時(shí)排除自1.RUP2.XP3.Scrum2022/12/11131.RUP2.XP3.Scrum2022/12/101RUP-RationalUnifyProcessRUP為IBMRational提出的軟件開(kāi)發(fā)流程內(nèi)容含蓋Businessmodeling,RequirementModeling,LogicalDesign,Implementation,Testing,Deployment等軟件開(kāi)發(fā)生命周期的直接工作及ProjectManagement,Change&ConfigurationManagement，Environmentsupport等支持性工作。2022/12/1114RUP-RationalUnifyProcessRUPRUP的主要精神項(xiàng)目進(jìn)行采用Iterative程序分階段漸進(jìn)地完成項(xiàng)目功能；廣泛使用VisualModeling于商業(yè)需求分析、系統(tǒng)分析及系統(tǒng)設(shè)計(jì)；強(qiáng)調(diào)架構(gòu)設(shè)計(jì)；對(duì)每項(xiàng)工作所需要的技術(shù)、工具、做法、模板、檢查項(xiàng)目均有詳細(xì)的定義，架構(gòu)完備且具有可調(diào)整的彈性。2022/12/1115RUP的主要精神項(xiàng)目進(jìn)行采用Iterative程序分1.RUP2.XP3.Scrum2022/12/11161.RUP2.XP3.Scrum2022/12/101XP-eXtremeProgramming極限編程，最輕量級(jí)的開(kāi)發(fā)流程，其最主要的精神是『在客戶有系統(tǒng)需求時(shí)，給予及時(shí)滿意的可執(zhí)行程序』，所以最適合需求快速變動(dòng)的項(xiàng)目強(qiáng)調(diào)客戶所要的是workable的執(zhí)行碼，所以把及撰寫程序無(wú)關(guān)的工作降至最低，并要求客戶與開(kāi)發(fā)人員最好以side-by-side的方式一起工作2022/12/1117XP-eXtremeProgramming極限編程，最XP強(qiáng)調(diào)4個(gè)因素交流(communication)，XP要求程序員之間以及和用戶之間有大量而迅速的交流簡(jiǎn)單（simplicity），XP要求設(shè)計(jì)和實(shí)現(xiàn)簡(jiǎn)單和干凈反饋（feedback）通過(guò)測(cè)試得到反饋，盡快提交軟件并根據(jù)反饋修改勇氣（courage）。勇敢的面對(duì)需求和技術(shù)上的變化2022/12/1118XP強(qiáng)調(diào)4個(gè)因素交流(communication)，XP要求XP開(kāi)發(fā)流程開(kāi)發(fā)人員隨時(shí)可以和客戶進(jìn)行有效溝通，撰寫userstories以確認(rèn)需求。簡(jiǎn)易快速的系統(tǒng)設(shè)計(jì)，撰寫?yīng)毩⒌尿?yàn)證程序以解決特殊困難的問(wèn)題，找出算法即可丟棄驗(yàn)證程序。規(guī)劃多次小型階段的項(xiàng)目計(jì)劃，以最快速度完成每一階段的程序交付客戶，客戶負(fù)責(zé)Acceptancetests；Coding前必須完成UnitTest及Acceptancetests程序，所有模塊整合前都須經(jīng)過(guò)UnitTests；開(kāi)發(fā)人員必須快速響應(yīng)Bug與需求變更；要求二人一組使用一臺(tái)計(jì)算機(jī)設(shè)計(jì)程序，當(dāng)一人coding時(shí)，另一人負(fù)責(zé)思考與設(shè)計(jì)；程序必須符合程序規(guī)范，并常做程序的重構(gòu)(Refactoring)。2022/12/1119XP開(kāi)發(fā)流程2022/12/1019XP原則和實(shí)踐-Planning-userstoriesuserstoriesUserstories類似usecase，描述用戶所見(jiàn)的系統(tǒng)功能，但避免使用大量的文檔，userstories由用戶編寫（不僅限于描述用戶界面）。Userstories使用用戶的語(yǔ)言編寫，不使用技術(shù)性的語(yǔ)言，每個(gè)userstories限于幾句話。Userstories用于在releaseplan會(huì)議上對(duì)開(kāi)發(fā)時(shí)間進(jìn)行評(píng)估，也用于產(chǎn)生驗(yàn)收測(cè)試（acceptancetest），必須使用可以自動(dòng)進(jìn)行的驗(yàn)收測(cè)試保證軟件的正確性。Userstories及傳統(tǒng)的用戶需求的區(qū)別在于詳細(xì)的程度，userstories并不會(huì)確定需求的每個(gè)細(xì)節(jié)，它只是用來(lái)簡(jiǎn)單的描述系統(tǒng)功能，供開(kāi)發(fā)人員進(jìn)行估計(jì)開(kāi)發(fā)進(jìn)度，在開(kāi)發(fā)過(guò)程中開(kāi)發(fā)人員和用戶會(huì)不斷的交流以討論細(xì)節(jié)問(wèn)題。Userstory應(yīng)該專注于功能，不應(yīng)該過(guò)分注重用戶界面等細(xì)節(jié)。一般一個(gè)userstoriy在1-3周的時(shí)間完成，如果估計(jì)超過(guò)3周，說(shuō)明userstory太大了，需要細(xì)分.2022/12/1120XP原則和實(shí)踐-Planning-userstoriesuXP原則和實(shí)踐-Planning-releaseplanreleaseplan召開(kāi)一個(gè)releaseplan會(huì)議，產(chǎn)生releaseplan。Releaseplan將用于指定每個(gè)iteration的計(jì)劃。開(kāi)發(fā)人員對(duì)每個(gè)userstory估計(jì)開(kāi)發(fā)時(shí)間（在不被打斷，無(wú)其他工作情況下的開(kāi)發(fā)時(shí)間，包括測(cè)試），用戶對(duì)userstories給出優(yōu)先級(jí)，releaseplan會(huì)議并不制訂每個(gè)iteration的計(jì)劃。Releaseplan要用戶，開(kāi)發(fā)人員和管理者都同意，在完成功能范圍（scope），使用資源（resource）,時(shí)間（time）和質(zhì)量(quality)上達(dá)成一致（一般質(zhì)量是不能改變的）2022/12/1121XP原則和實(shí)踐-Planning-releaseplanrXP原則和實(shí)踐-Planning-smallreleasesmallreleaseoftenandsmallrelease是XP的一個(gè)原則，每個(gè)release完成一些用戶有意義的功能集合，盡快的提交給用戶以獲得反饋，及時(shí)調(diào)整，提交的越晚，調(diào)整越困難。2022/12/1122XP原則和實(shí)踐-Planning-smallreleaseXP原則和實(shí)踐-Planning-projectvelocityprojectvelocity團(tuán)隊(duì)在開(kāi)發(fā)過(guò)程中要收集數(shù)據(jù)，以便于對(duì)自己的開(kāi)發(fā)速度進(jìn)行評(píng)估，用于以后的releazseplan2022/12/1123XP原則和實(shí)踐-Planning-projectvelocXP原則和實(shí)踐-Planning-iterationiteration每個(gè)smallrelease的周期稱為iteration，每個(gè)iteration約為1-3周，在一個(gè)項(xiàng)目中保持每個(gè)iteration的時(shí)間相等，不要超前制定計(jì)劃，每個(gè)iteration的計(jì)劃在iteration的開(kāi)始時(shí)制定。這樣能夠更靈活的應(yīng)付變化。不要急于完成本次iteration沒(méi)有包括的功能。要注重每個(gè)iteration的時(shí)間限制，當(dāng)團(tuán)隊(duì)覺(jué)得不能按時(shí)完成iteration時(shí)，召開(kāi)一次iterationplan會(huì)議，重新評(píng)估，減少一些userstories。2022/12/1124XP原則和實(shí)踐-Planning-iterationiterXP原則和實(shí)踐-Planning-iterationplaniterationplan在每個(gè)iteration開(kāi)始的時(shí)候召開(kāi)會(huì)議，從releaseplan中選擇還沒(méi)有實(shí)現(xiàn)的用戶最迫切需要的userstories。上一個(gè)iteration中沒(méi)有通過(guò)驗(yàn)收測(cè)試的功能也要在這個(gè)iteration中實(shí)現(xiàn)?？梢愿鶕?jù)上一個(gè)iteration的實(shí)踐調(diào)整團(tuán)隊(duì)速度。Userstories和失敗的測(cè)試被分解成programmingtask，task使用技術(shù)語(yǔ)言編寫，作為iterationplan的詳細(xì)描述。程序員主動(dòng)領(lǐng)取task并估計(jì)完成時(shí)間，每個(gè)task應(yīng)該在1-3天內(nèi)完成，超過(guò)3天的task應(yīng)該被細(xì)分。如果整個(gè)團(tuán)隊(duì)需要的時(shí)間多于或少于規(guī)定的iteration時(shí)間，調(diào)整userstories。2022/12/1125XP原則和實(shí)踐-Planning-iterationplaXP原則和實(shí)踐-Planning-movepeoplearoundmovepeoplearound不要使每個(gè)開(kāi)發(fā)人員局限于一項(xiàng)工作，不要使某項(xiàng)工作依賴于一個(gè)開(kāi)發(fā)人員，增加知識(shí)共享，減少信息孤島，多進(jìn)行交流和培訓(xùn)。當(dāng)項(xiàng)目中的所有人對(duì)所有模塊都了解并可以進(jìn)行開(kāi)發(fā)時(shí)是效率最高的，鼓勵(lì)開(kāi)發(fā)人員在不同iteration中開(kāi)發(fā)不同的模塊。2022/12/1126XP原則和實(shí)踐-Planning-movepeopleaXP原則和實(shí)踐-Planning-stand-upmeetingstand-upmeeting每天工作開(kāi)始之前，開(kāi)5-10分鐘的stand-up會(huì)議（站立會(huì)議），站立的目的是為了強(qiáng)迫節(jié)省時(shí)間，會(huì)議的目的是交流，提出存在的問(wèn)題，但不要在會(huì)議上解決問(wèn)題。開(kāi)一個(gè)所有人員參加的短會(huì)比多個(gè)個(gè)別人員參加的會(huì)議要高效。在會(huì)議上提出的問(wèn)題可以由少數(shù)人討論解決，這個(gè)少數(shù)人參加的會(huì)議如果涉及到代碼，可以在計(jì)算機(jī)前討論。2022/12/1127XP原則和實(shí)踐-Planning-stand-upmeetXP原則和實(shí)踐-Planning-fixXPwhenitbreaksfixXPwhenitbreaksXP并不是一成不變的，當(dāng)團(tuán)隊(duì)覺(jué)得需要修改的時(shí)候，可以根據(jù)自己的情況進(jìn)行修改，任何修改都要經(jīng)過(guò)整個(gè)團(tuán)隊(duì)的討論和達(dá)成一致2022/12/1128XP原則和實(shí)踐-Planning-fixXPwheniXP原則和實(shí)踐-Designing-1Simplicity保持簡(jiǎn)單的設(shè)計(jì)，在完成同樣的功能的情況下，選擇簡(jiǎn)單的設(shè)計(jì)，不要急于設(shè)計(jì)沒(méi)有計(jì)劃的功能，應(yīng)該認(rèn)識(shí)到：keepingadesignsimpleishardworkSystemmetaphor使用統(tǒng)一的術(shù)語(yǔ)描述系統(tǒng)，在用戶，管理者和開(kāi)發(fā)人員之間使用統(tǒng)一的術(shù)語(yǔ)。這將使交流清晰。CRCcard使用CRC(Class,Responsibilities,andCollaboration)card進(jìn)行系統(tǒng)設(shè)計(jì)，鼓勵(lì)更多的人參加設(shè)計(jì)。每個(gè)CRC卡片表示系統(tǒng)中一個(gè)對(duì)象，寫上對(duì)象的名字，責(zé)任和每個(gè)責(zé)任需要交互的其他對(duì)象?？梢阅M對(duì)象之間的交互。CRC卡片是易于理解的，但是是非正式的，如果需要正式的文檔，要將卡片轉(zhuǎn)換為相應(yīng)的文檔。spikesolutionneveraddfunctionearlyrefactoringwheneverandwherever2022/12/1129XP原則和實(shí)踐-Designing-1SimplicityXP原則和實(shí)踐-Designing-2spikesolution使用spikesolution減低風(fēng)險(xiǎn)，當(dāng)遇到技術(shù)難題或設(shè)計(jì)問(wèn)題時(shí)，使用簡(jiǎn)單的程序進(jìn)行測(cè)試，找出問(wèn)題，在不同的解決方法之間進(jìn)行評(píng)估。在早期進(jìn)行實(shí)驗(yàn)可以有效的降低風(fēng)險(xiǎn)。neveraddfunctionearly不要過(guò)早的設(shè)計(jì)沒(méi)有計(jì)劃的功能，在一個(gè)需求經(jīng)常變化的環(huán)境中，過(guò)早的設(shè)計(jì)經(jīng)常是沒(méi)有用的。refactoringwheneverandwhereverXP鼓勵(lì)對(duì)設(shè)計(jì)和代碼經(jīng)常進(jìn)行重構(gòu)（Refactoring），目的是去除冗余，提高質(zhì)量，保持設(shè)計(jì)簡(jiǎn)單。重構(gòu)必須以完全測(cè)試為檢驗(yàn)條件2022/12/1130XP原則和實(shí)踐-Designing-2spikesolutXP原則和實(shí)踐-Coding-1customerisalawaysavailable用戶是項(xiàng)目組的成員之一，用戶的參加貫穿整個(gè)開(kāi)發(fā)過(guò)程，用戶及開(kāi)發(fā)人員之間的交流是重要的codingstandard使用統(tǒng)一的編碼標(biāo)準(zhǔn)，這是保持代碼整潔和共享代碼的基礎(chǔ)codingunittestfirsttestfirst是XP的一個(gè)特點(diǎn)，在編寫代碼之前先編寫單元測(cè)試代碼，單元測(cè)試代碼和代碼由同一個(gè)程序員完成。先編寫測(cè)試代碼可以使程序員更好的理解需求，避免直接編碼造成的理解偏差，對(duì)需求的不清晰，可以在編寫測(cè)試代碼時(shí)就發(fā)現(xiàn)。測(cè)試代碼也是檢驗(yàn)程序是否完成的標(biāo)準(zhǔn)。編碼工作應(yīng)該是以下工作的循環(huán)：

1編寫測(cè)試代碼

2運(yùn)行測(cè)試程序，確認(rèn)失敗

3編寫實(shí)現(xiàn)這個(gè)測(cè)試程序要求功能的代碼，不需要實(shí)現(xiàn)其他的功能，只需要實(shí)現(xiàn)剛剛滿足測(cè)試程序的功能

4運(yùn)行測(cè)試程序，確認(rèn)成功

實(shí)踐證明，testfirst方式需要的編碼實(shí)踐少于先編碼，后寫測(cè)試代碼2022/12/1131XP原則和實(shí)踐-Coding-1customerisalXP原則和實(shí)踐-Coding-2PairProgrammingPairprogramming是XP的特色，它要求兩個(gè)程序員在一臺(tái)計(jì)算機(jī)上同時(shí)進(jìn)行編程工作。共用鼠標(biāo)和鍵盤，通常一個(gè)人進(jìn)行戰(zhàn)略上的思考，程序架構(gòu)和函數(shù)，類之間的關(guān)系，一個(gè)人進(jìn)行輸入和戰(zhàn)術(shù)上的思考，完成函數(shù)和類。兩個(gè)人可以經(jīng)常交換角色。sequentialintegration要保證源代碼庫(kù)的狀態(tài)是可標(biāo)識(shí)的，同一時(shí)間，只允許一個(gè)pair的程序進(jìn)行整和和測(cè)試，這樣可以縮小問(wèn)題產(chǎn)生的范圍。不同的pair可以在自己的機(jī)器上隨時(shí)進(jìn)行整和和測(cè)試.integrateoften只要有可能就進(jìn)行代碼整合，周期可以在幾個(gè)小時(shí)，最好不要超過(guò)一天。2022/12/1132XP原則和實(shí)踐-Coding-2PairProgrammiXP原則和實(shí)踐-Coding-3共同擁有代碼鼓勵(lì)每個(gè)人對(duì)項(xiàng)目中的任何人提出新的想法，任何開(kāi)發(fā)人員對(duì)項(xiàng)目中的任何代碼都可以進(jìn)行增加功能，改正錯(cuò)誤和重構(gòu)。優(yōu)化工作放在最后先使系統(tǒng)能夠正常工作，不要猜測(cè)系統(tǒng)的瓶頸，要實(shí)際測(cè)量NOovertime

不要長(zhǎng)時(shí)間的加班，大多數(shù)加班并不能挽回已有的延遲，連續(xù)超過(guò)兩個(gè)星期的加班說(shuō)明有問(wèn)題存在。向一個(gè)已經(jīng)延遲的項(xiàng)目填加人員也不是一個(gè)好的選擇。2022/12/1133XP原則和實(shí)踐-Coding-32022/12/1033XP原則和實(shí)踐-Testing-1所有的代碼都有單元測(cè)試單元測(cè)試是XP的基石，XP中的單元測(cè)試應(yīng)該是可以自動(dòng)進(jìn)行的，所以可以很快的進(jìn)行所有的單元測(cè)試，單元測(cè)試應(yīng)該在編碼之前創(chuàng)建。單元測(cè)試的代碼和代碼一起release，沒(méi)有單元測(cè)試的代碼不能夠release。使用自動(dòng)單元測(cè)試可以系統(tǒng)整合時(shí)節(jié)省大量的發(fā)現(xiàn)錯(cuò)誤和改正的時(shí)間。單元測(cè)試越完善，節(jié)省的時(shí)間越多。代碼在release前必須通過(guò)所有的單元測(cè)試發(fā)現(xiàn)bug后，首先增加測(cè)試在實(shí)際運(yùn)行中發(fā)現(xiàn)bug,首先增加acceptancetest，然后增加unittest，在增加完測(cè)試后在查找和修改代碼，增加的測(cè)試保證同樣的錯(cuò)誤不會(huì)再出現(xiàn)acceptancetestacceptancetest根據(jù)userstories在iterationplan會(huì)議上創(chuàng)建，它也應(yīng)該可以自動(dòng)運(yùn)行以便可以經(jīng)常運(yùn)行。2022/12/1134XP原則和實(shí)踐-Testing-1所有的代碼都有單元測(cè)試21.RUP2.XP3.Scrum2022/12/11351.RUP2.XP3.Scrum2022/12/103ScrumScrum2022/12/1136ScrumScrum2022/12/1036Scrum特點(diǎn)自我管理的團(tuán)隊(duì)以“sprint”為周期迭代的產(chǎn)品開(kāi)發(fā)以一系列“產(chǎn)品Backlog”記錄了產(chǎn)品需求沒(méi)有特定的工程實(shí)踐慣例在以生成規(guī)則創(chuàng)造的敏捷開(kāi)發(fā)環(huán)境交付產(chǎn)品是其中一種“敏捷方法”2022/12/1137Scrum特點(diǎn)自我管理的團(tuán)隊(duì)2022/12/1037SCRUM開(kāi)發(fā)流程

SCRUM開(kāi)發(fā)流程是AgileProcess的一種，以英式橄欖球爭(zhēng)球隊(duì)形(Scrum)為名，基本假設(shè)是『開(kāi)發(fā)軟件就像開(kāi)發(fā)新產(chǎn)品，無(wú)法一開(kāi)始就能定義FinalProduct的規(guī)程，過(guò)程中需要研發(fā)、創(chuàng)意、嘗試錯(cuò)誤，所以沒(méi)有一種固定的流程可以保證項(xiàng)目成功』。Scrum將軟件開(kāi)發(fā)團(tuán)隊(duì)比擬成橄欖球隊(duì)，有明確的最高目標(biāo)，熟悉開(kāi)發(fā)流程中所需具備的最佳典范及技術(shù)，具有高度自主權(quán)，緊密地溝通合作，以高度彈性解決各種挑戰(zhàn)，碓保每天、每個(gè)階段都朝向目標(biāo)有明確的推進(jìn)，因此SCRUM非常適用于產(chǎn)品開(kāi)發(fā)項(xiàng)目。2022/12/1138SCRUM開(kāi)發(fā)流程SCRUM開(kāi)發(fā)流程是AgilePSCRUM開(kāi)發(fā)流程(cont.)SCRUM開(kāi)發(fā)流程通常以30天為一個(gè)迭代周期，每個(gè)迭代周期叫做一個(gè)Sprint，由客戶提供新產(chǎn)品的需求規(guī)格開(kāi)始，開(kāi)發(fā)團(tuán)隊(duì)及客戶于每一個(gè)階段開(kāi)始時(shí)挑選該完成的規(guī)格部份，開(kāi)發(fā)團(tuán)隊(duì)必須盡力于30天后交付成果，團(tuán)隊(duì)每天用15分鐘開(kāi)會(huì)檢視每個(gè)成員的進(jìn)度與計(jì)劃，了解所遭遇的困難并設(shè)法排除，決定第二天的任務(wù)安排.SCRUM較為有特色的，是它特別強(qiáng)調(diào)開(kāi)發(fā)隊(duì)伍和管理層的交流協(xié)作。每天，開(kāi)發(fā)隊(duì)伍都會(huì)向管理層匯報(bào)進(jìn)度，如果有問(wèn)題，也會(huì)向管理層要求幫助解決。2022/12/1139SCRUM開(kāi)發(fā)流程(cont.)SCRUM開(kāi)發(fā)流程通常以Scrum總體骨架迭代每30天DailySCRUM每24小時(shí)高優(yōu)先級(jí)可運(yùn)行的軟件工作項(xiàng)分解產(chǎn)品訂單ProductBacklog迭代訂單SprintBacklog新的功能增量迭代規(guī)劃會(huì)議SprintPlan一般不超過(guò)8小時(shí)。前4個(gè)小時(shí)：產(chǎn)品負(fù)責(zé)人向團(tuán)隊(duì)展示最高優(yōu)先級(jí)的產(chǎn)品，團(tuán)隊(duì)則向他詢問(wèn)產(chǎn)品Backlog的內(nèi)容、目的、含義及意圖。后4小時(shí)：團(tuán)隊(duì)計(jì)劃本Sprint的安排迭代復(fù)審會(huì)議SprintReview一般4個(gè)小時(shí)，由團(tuán)隊(duì)成員向產(chǎn)品負(fù)責(zé)人額其他利益相關(guān)人展示Sprint周期內(nèi)的產(chǎn)品開(kāi)發(fā)情況迭代回顧會(huì)議SprintRetrospective一般3個(gè)小時(shí)，ScrumMaster將鼓勵(lì)團(tuán)隊(duì)在SCRUM過(guò)程框架和實(shí)踐范圍內(nèi)，對(duì)開(kāi)發(fā)過(guò)程做出修改，使它在下一個(gè)Sprint周期中更加有效和令人愉快每日站立會(huì)議DailyScrumMeeting在簡(jiǎn)會(huì)上，每個(gè)成員主要回答三個(gè)問(wèn)題;–自上次SCRUM簡(jiǎn)會(huì)后的一天了（昨天），你做了什么?–從現(xiàn)在到下次SCRUM簡(jiǎn)會(huì)的一天里（今天），你要做什么?–在實(shí)現(xiàn)SCRUM及項(xiàng)目目標(biāo)的工作中，你遇到哪些困難嗎?產(chǎn)品負(fù)責(zé)人Scrum主管開(kāi)發(fā)團(tuán)隊(duì)2022/12/1140Scrum總體骨架迭代DailySCRUM高優(yōu)先級(jí)可運(yùn)行的順序vs.重疊開(kāi)發(fā)過(guò)程Scrum并非以一段時(shí)間集中完成一個(gè)過(guò)程...而是將所有過(guò)程中必須的每一部分集中在這段時(shí)間內(nèi)完成需求設(shè)計(jì)代碼測(cè)試2022/12/1141順序vs.重疊開(kāi)發(fā)過(guò)程Scrum并非以一段時(shí)間集中完成一Scrum結(jié)構(gòu)框架產(chǎn)品所有者ScrumMaster團(tuán)隊(duì)職能迭代計(jì)劃迭代驗(yàn)收迭代回顧每天召開(kāi)的scrum會(huì)議儀式產(chǎn)品backlog迭代backlog進(jìn)度曲線圖產(chǎn)出2022/12/1142Scrum結(jié)構(gòu)框架產(chǎn)品所有者職能迭代計(jì)劃儀式產(chǎn)品backlScrumTeam自組織的團(tuán)隊(duì)跨功能團(tuán)隊(duì)沒(méi)有角色區(qū)分最少2個(gè),最多7個(gè)對(duì)工作交付負(fù)責(zé)只要交付工作需求,授權(quán)做任何事情.2022/12/1143ScrumTeam自組織的團(tuán)隊(duì)2022/12/1043Scrum角色及職責(zé)火腿雞蛋！三思過(guò)后我決定不和你開(kāi)餐館了。因?yàn)槲胰硇耐度耄阒粻可嫒雰?nèi)！2022/12/1144Scrum角色及職責(zé)火腿雞蛋！三思過(guò)后我決定不和你開(kāi)餐館了。Chickens&PigsPigs:ScrumTeam成員:他們承諾對(duì)迭代目標(biāo)交付負(fù)責(zé)Chickens:項(xiàng)目組有關(guān)的成員,但并不專注于項(xiàng)目以觀察者的形式參加Scrummeeting2022/12/1145Chickens&PigsPigs:ScrumTeaProductOwnerBacklog優(yōu)先級(jí)制定開(kāi)發(fā)的版本規(guī)劃必須確保驅(qū)動(dòng)開(kāi)發(fā)的需求只有一份受管理層,客戶等影響但僅PO有權(quán)調(diào)整Backlog及相關(guān)成員協(xié)同工作來(lái)確定ProductBacklog的items消除關(guān)于Backlog的疑惑,確保理解一致,消除干擾2022/12/1146ProductOwnerBacklog優(yōu)先級(jí)制定開(kāi)發(fā)的版本ScrumMasterScrumMaster職責(zé)確保SCRUM的成功實(shí)施SCRUM實(shí)踐和規(guī)定,保護(hù)團(tuán)隊(duì)以免受干擾項(xiàng)目管理的代表2022/12/1147ScrumMasterScrumMaster職責(zé)202Sprint交付產(chǎn)品的固定的時(shí)間箱.建議2-3周迭代包括design,coding,testing,anddocumentation一旦迭代開(kāi)始,僅ScrumTeam能增加或者刪除Sprintbacklog中的items當(dāng)?shù)哪繕?biāo)變的沒(méi)有意義的時(shí)候,才能終止迭代開(kāi)發(fā)對(duì)于ProductBacklog,不允許迭代內(nèi)的需求變更：需求優(yōu)先級(jí)調(diào)整僅存在于迭代之間2022/12/1148Sprint交付產(chǎn)品的固定的時(shí)間箱.建議2-3周2022/1如何定義Sprint團(tuán)隊(duì)自己從產(chǎn)品的backlog中選擇一些他們能夠完成的任務(wù)作為迭代的backlog迭代backlog被創(chuàng)建任務(wù)被確認(rèn)并且每一任務(wù)估計(jì)工作量應(yīng)該在1-16小時(shí)左右迭代的backlog的確定是團(tuán)隊(duì)協(xié)作的結(jié)果，而不是只有scrummaster的決定概要設(shè)計(jì)已經(jīng)討論過(guò)為了選擇好去處度過(guò)這個(gè)假期，我需要先看到酒店的照片.編寫后臺(tái)和中間層(8小時(shí))編寫界面(4)編寫測(cè)試用例(4)寫類foo(6)更新性能測(cè)試用例(4)2022/12/1149如何定義Sprint團(tuán)隊(duì)自己從產(chǎn)品的backlog中選擇一些DailyScrum每天15分鐘，團(tuán)隊(duì)面對(duì)面站立成圈晨會(huì)是為項(xiàng)目信息同步可視化,不是為了解決問(wèn)題避免無(wú)關(guān)的討論2022/12/1150DailyScrum每天15分鐘，團(tuán)隊(duì)面對(duì)面站立成圈2團(tuán)隊(duì)成員需要回答3個(gè)問(wèn)題昨天你做了什么?1今天你將要做什么?2你有需要幫助的地方嗎?3對(duì)于ScrumMaster來(lái)說(shuō)這些問(wèn)答不是工作進(jìn)度報(bào)告他們是團(tuán)隊(duì)成員彼此的承諾2022/12/1151團(tuán)隊(duì)成員需要回答3個(gè)問(wèn)題昨天你做了什么?1今天你將要做什么?BurnDown2022/12/1152BurnDown2022/12/1052迭代結(jié)果的驗(yàn)收?qǐng)F(tuán)隊(duì)需要演示所完成的迭代工作典型的做法是使用演示形式展示新功能或者底層架構(gòu)的實(shí)現(xiàn)非正式的2小時(shí)的提前準(zhǔn)備不需要正式演示文檔整個(gè)團(tuán)隊(duì)都需要參加邀請(qǐng)所有關(guān)注產(chǎn)品的人參加2022/12/1153迭代結(jié)果的驗(yàn)收?qǐng)F(tuán)隊(duì)需要演示所完成的迭代工作2022/12/1迭代的回顧周期性的回顧，總結(jié)工作中的經(jīng)驗(yàn)和教訓(xùn)一般15–30分鐘在每個(gè)迭代結(jié)束時(shí)開(kāi)始做整個(gè)團(tuán)隊(duì)都需要參加ScrumMaster產(chǎn)品所有者團(tuán)隊(duì)可能還包括客戶2022/12/1154迭代的回顧周期性的回顧，總結(jié)工作中的經(jīng)驗(yàn)和教訓(xùn)2022/12產(chǎn)品backlog需求項(xiàng)目中待完成的工作列表理想的是每一個(gè)待完成的工作都將對(duì)客戶和用戶產(chǎn)生價(jià)值產(chǎn)品所有者將對(duì)這個(gè)列表進(jìn)行優(yōu)先級(jí)排序每個(gè)迭代開(kāi)始前優(yōu)先級(jí)的排序工作還需要再度修正一組產(chǎn)品backlog2022/12/1155產(chǎn)品backlog需求一組產(chǎn)品backlog2022/1產(chǎn)品backlog的樣例Backlog列表估計(jì)量顧客可以酒店預(yù)定3顧客可以取消預(yù)定.5顧客可以提前更改預(yù)定的日期.3酒店工作人員可以出具RevPAR(revenue-per-available-room)報(bào)告8提高對(duì)突發(fā)事情的處理能力8...30...502022/12/1156產(chǎn)品backlog的樣例Backlog列表估計(jì)量顧客可以管理迭代的backlog團(tuán)隊(duì)的個(gè)人將要簽收其將擁有的工作工作不是單向的分配對(duì)于剩余工作量的估計(jì)每天需要更新團(tuán)隊(duì)中任何人都可以添加，刪減或者更改迭代中的工作項(xiàng)目為了迭代目標(biāo)以及將發(fā)布的結(jié)果而工作如果對(duì)將要面對(duì)的困難不清楚，最好先定義一個(gè)相對(duì)工作量較大的工作項(xiàng)目然后適時(shí)在以后將其分散成較小額工作量的幾個(gè)部分更新每個(gè)項(xiàng)目的剩余工作量2022/12/1157管理迭代的backlog團(tuán)隊(duì)的個(gè)人將要簽收其將擁有的工作2迭代backlog的樣例任務(wù)MonTuesWedThurFri編寫用戶界面848編寫中間層1612104測(cè)試中間層81616118編寫在線幫助12編寫Foo類88888增加對(duì)錯(cuò)誤的日志記錄842022/12/1158迭代backlog的樣例任務(wù)MonTuesWedThurFr迭代燃盡圖2022/12/1159迭代燃盡圖2022/12/1059謝謝謝謝60敏捷開(kāi)發(fā)培訓(xùn)AgileDevelopment敏捷開(kāi)發(fā)培訓(xùn)AgileDevelopment敏捷開(kāi)發(fā)培訓(xùn)AgileDevelopment敏捷開(kāi)發(fā)培訓(xùn)AgileDevelopment敏捷開(kāi)發(fā)培訓(xùn)A61Content

AgileDevelopment介紹RUPXPScrum2022/12/1162ContentAgileDevelopment介紹202AgileProcess-敏捷的開(kāi)發(fā)流程AgileProcess(敏捷的開(kāi)發(fā)流程)是一種軟件開(kāi)發(fā)流程的泛稱，幾項(xiàng)共通的特性：客戶及開(kāi)發(fā)人員形成密切合作的團(tuán)隊(duì)，因?yàn)榭蛻魺o(wú)法于初期定義完整的規(guī)格，而開(kāi)發(fā)人員于開(kāi)發(fā)過(guò)程中也常常無(wú)法知悉外在環(huán)境或業(yè)務(wù)的變動(dòng)，所以需要兩者密切合作方能開(kāi)發(fā)適用的軟件。項(xiàng)目最終的目標(biāo)是可執(zhí)行的程序，因此所有的中間產(chǎn)品必須經(jīng)過(guò)審慎評(píng)估，確認(rèn)有助于最終目標(biāo)，才需要制作中間產(chǎn)品。采用Iterative與Incremental方式分階段進(jìn)行，密集review是否符合需求。流程可以簡(jiǎn)單，但規(guī)劃與執(zhí)行必須嚴(yán)謹(jǐn)。強(qiáng)調(diào)團(tuán)隊(duì)合作，賦予高度的責(zé)任，團(tuán)隊(duì)有自主權(quán)得以因應(yīng)變化做調(diào)整2022/12/1163AgileProcess-敏捷的開(kāi)發(fā)流程AgilePAgileDevelopment敏捷開(kāi)發(fā)是一種以人為核心、迭代、循序漸進(jìn)的開(kāi)發(fā)方法在敏捷開(kāi)發(fā)中，項(xiàng)目的構(gòu)建被切分成多個(gè)子項(xiàng)目，各個(gè)子項(xiàng)目的成果都經(jīng)過(guò)測(cè)試，具備集成和可運(yùn)行的特征。2022/12/1164AgileDevelopment敏捷開(kāi)發(fā)是一種以人為核心、敏捷開(kāi)發(fā)核心價(jià)值(CoreValue)Individualsandinteractionsoverprocessesandtools

個(gè)人和交流重于過(guò)程和工具

Workingsoftwareovercomprehensivedocumentation

正在運(yùn)行的軟件本身重于復(fù)雜的文檔

Customercollaborationovercontractnegotiation

及客戶的溝通和交流重于使用合同約束客戶

Respondingtochangeoverfollowingaplan

對(duì)變化的快速響應(yīng)重于跟隨計(jì)劃2022/12/1165敏捷開(kāi)發(fā)核心價(jià)值(CoreValue)Individua敏捷開(kāi)發(fā)原則(Principles)最高目標(biāo)是通過(guò)快速的和經(jīng)常的發(fā)布軟件滿足客戶的需要提交軟件的周期為幾個(gè)星期到幾個(gè)月產(chǎn)生正確的軟件是衡量進(jìn)度的首要標(biāo)準(zhǔn)主動(dòng)接受需求的改變而不是拒絕商務(wù)人員和開(kāi)發(fā)人員工作在一起個(gè)人必須有動(dòng)力，要?jiǎng)?chuàng)造環(huán)境支持他們的要求，信任他們最有效的交流方法是面對(duì)面的交流最好的結(jié)構(gòu)，需求和設(shè)計(jì)來(lái)自于自組織的團(tuán)隊(duì)（self-organizingteam），允許任何人提出想法和建議持續(xù)改進(jìn)設(shè)計(jì)和編碼鼓勵(lì)正常工作，減少長(zhǎng)時(shí)間加班保持簡(jiǎn)單，減少不必要的部分，認(rèn)識(shí)到簡(jiǎn)單的設(shè)計(jì)比復(fù)雜的設(shè)計(jì)更難（simpledesignishardertoproduce）定期調(diào)整過(guò)程，獲得更高效率2022/12/1166敏捷開(kāi)發(fā)原則(Principles)最高目標(biāo)是通過(guò)快速的和經(jīng)敏捷開(kāi)發(fā)的設(shè)計(jì)原則SRP單一職責(zé)原則SRP：SingleResponsibilityPrincipleOCP開(kāi)放封閉原則OCP：Open－ClosePrincipleLSPLiskov替換原則LSP：LiskovSubstitutionPrincipleDIP依賴倒置原則DIP：DependencyInvertionPrincipleISP接口隔離原則ISP：InterfaceSeparatePrinciple2022/12/1167敏捷開(kāi)發(fā)的設(shè)計(jì)原則SRP2022/12/107敏捷開(kāi)發(fā)-迭代計(jì)劃最新版本驗(yàn)收測(cè)試發(fā)布計(jì)劃迭代計(jì)劃開(kāi)發(fā)項(xiàng)目周期2022/12/1168敏捷開(kāi)發(fā)-迭代計(jì)劃最新版本驗(yàn)收測(cè)試發(fā)布計(jì)劃迭代計(jì)劃開(kāi)發(fā)項(xiàng)目周敏捷開(kāi)發(fā)-迭代計(jì)劃2022/12/1169敏捷開(kāi)發(fā)-迭代計(jì)劃2022/12/109名詞解釋故事故事是客戶想要系統(tǒng)做的事情，適合在一至兩個(gè)迭代內(nèi)完成，并且是可測(cè)試的，他不一定是商業(yè)價(jià)值的直接體現(xiàn)。迭代迭代是一個(gè)周期在2-4周，能夠完成當(dāng)前團(tuán)隊(duì)所能實(shí)現(xiàn)的，最具商業(yè)價(jià)值的功能，并可以提供一個(gè)可工作的小版本供發(fā)布。VelocityVelocity翻譯為項(xiàng)目周轉(zhuǎn)時(shí)間。代表團(tuán)隊(duì)在給定周期內(nèi)能夠完成多少商業(yè)價(jià)值，以便用于衡量將來(lái)該團(tuán)隊(duì)能夠提供的商業(yè)價(jià)值。也即昨天的天氣。2022/12/1170名詞解釋故事故事是客戶想要系統(tǒng)做的事情，適合在一至兩個(gè)迭代名詞解釋優(yōu)先級(jí)優(yōu)先級(jí)主要考慮商業(yè)價(jià)值，同時(shí)兼顧市場(chǎng)風(fēng)險(xiǎn)、商業(yè)風(fēng)險(xiǎn)、技術(shù)風(fēng)險(xiǎn)等因素在內(nèi)的一個(gè)衡量數(shù)字，優(yōu)先級(jí)越高通常意味著其商業(yè)價(jià)值越高風(fēng)險(xiǎn)系數(shù)風(fēng)險(xiǎn)系數(shù)綜合商業(yè)環(huán)境、項(xiàng)目資源、技術(shù)以及項(xiàng)目環(huán)境等等因素在內(nèi)的一個(gè)衡量數(shù)字，它是優(yōu)先級(jí)的重要衡量指標(biāo)之一。它通常出現(xiàn)在故事中。風(fēng)險(xiǎn)系數(shù)較大意味著優(yōu)先級(jí)也較大。負(fù)載因子負(fù)載因子是綜合項(xiàng)目成員的技術(shù)能力、技能集、精神狀態(tài)等等因素，對(duì)于團(tuán)隊(duì)成員的一個(gè)負(fù)載系數(shù)。2022/12/1171名詞解釋優(yōu)先級(jí)優(yōu)先級(jí)主要考慮商業(yè)價(jià)值，同時(shí)兼顧市場(chǎng)風(fēng)險(xiǎn)、商名詞解釋理想時(shí)間理想時(shí)間排除一切可能的外界干擾，同時(shí)排除自身的精神狀態(tài)，職業(yè)態(tài)度等等因素，完成某項(xiàng)工作所需要的時(shí)間。實(shí)際時(shí)間實(shí)際時(shí)間理想時(shí)間乘上負(fù)載因子任務(wù)任務(wù)分配到項(xiàng)目成員，從故事切分的出來(lái)。通常任務(wù)時(shí)間不應(yīng)該超過(guò)10個(gè)實(shí)際工作日。2022/12/1172名詞解釋理想時(shí)間理想時(shí)間排除一切可能的外界干擾，同時(shí)排除自1.RUP2.XP3.Scrum2022/12/11731.RUP2.XP3.Scrum2022/12/101RUP-RationalUnifyProcessRUP為IBMRational提出的軟件開(kāi)發(fā)流程內(nèi)容含蓋Businessmodeling,RequirementModeling,LogicalDesign,Implementation,Testing,Deployment等軟件開(kāi)發(fā)生命周期的直接工作及ProjectManagement,Change&ConfigurationManagement，Environmentsupport等支持性工作。2022/12/1174RUP-RationalUnifyProcessRUPRUP的主要精神項(xiàng)目進(jìn)行采用Iterative程序分階段漸進(jìn)地完成項(xiàng)目功能；廣泛使用VisualModeling于商業(yè)需求分析、系統(tǒng)分析及系統(tǒng)設(shè)計(jì)；強(qiáng)調(diào)架構(gòu)設(shè)計(jì)；對(duì)每項(xiàng)工作所需要的技術(shù)、工具、做法、模板、檢查項(xiàng)目均有詳細(xì)的定義，架構(gòu)完備且具有可調(diào)整的彈性。2022/12/1175RUP的主要精神項(xiàng)目進(jìn)行采用Iterative程序分1.RUP2.XP3.Scrum2022/12/11761.RUP2.XP3.Scrum2022/12/101XP-eXtremeProgramming極限編程，最輕量級(jí)的開(kāi)發(fā)流程，其最主要的精神是『在客戶有系統(tǒng)需求時(shí)，給予及時(shí)滿意的可執(zhí)行程序』，所以最適合需求快速變動(dòng)的項(xiàng)目強(qiáng)調(diào)客戶所要的是workable的執(zhí)行碼，所以把及撰寫程序無(wú)關(guān)的工作降至最低，并要求客戶與開(kāi)發(fā)人員最好以side-by-side的方式一起工作2022/12/1177XP-eXtremeProgramming極限編程，最XP強(qiáng)調(diào)4個(gè)因素交流(communication)，XP要求程序員之間以及和用戶之間有大量而迅速的交流簡(jiǎn)單（simplicity），XP要求設(shè)計(jì)和實(shí)現(xiàn)簡(jiǎn)單和干凈反饋（feedback）通過(guò)測(cè)試得到反饋，盡快提交軟件并根據(jù)反饋修改勇氣（courage）。勇敢的面對(duì)需求和技術(shù)上的變化2022/12/1178XP強(qiáng)調(diào)4個(gè)因素交流(communication)，XP要求XP開(kāi)發(fā)流程開(kāi)發(fā)人員隨時(shí)可以和客戶進(jìn)行有效溝通，撰寫userstories以確認(rèn)需求。簡(jiǎn)易快速的系統(tǒng)設(shè)計(jì)，撰寫?yīng)毩⒌尿?yàn)證程序以解決特殊困難的問(wèn)題，找出算法即可丟棄驗(yàn)證程序。規(guī)劃多次小型階段的項(xiàng)目計(jì)劃，以最快速度完成每一階段的程序交付客戶，客戶負(fù)責(zé)Acceptancetests；Coding前必須完成UnitTest及Acceptancetests程序，所有模塊整合前都須經(jīng)過(guò)UnitTests；開(kāi)發(fā)人員必須快速響應(yīng)Bug與需求變更；要求二人一組使用一臺(tái)計(jì)算機(jī)設(shè)計(jì)程序，當(dāng)一人coding時(shí)，另一人負(fù)責(zé)思考與設(shè)計(jì)；程序必須符合程序規(guī)范，并常做程序的重構(gòu)(Refactoring)。2022/12/1179XP開(kāi)發(fā)流程2022/12/1019XP原則和實(shí)踐-Planning-userstoriesuserstoriesUserstories類似usecase，描述用戶所見(jiàn)的系統(tǒng)功能，但避免使用大量的文檔，userstories由用戶編寫（不僅限于描述用戶界面）。Userstories使用用戶的語(yǔ)言編寫，不使用技術(shù)性的語(yǔ)言，每個(gè)userstories限于幾句話。Userstories用于在releaseplan會(huì)議上對(duì)開(kāi)發(fā)時(shí)間進(jìn)行評(píng)估，也用于產(chǎn)生驗(yàn)收測(cè)試（acceptancetest），必須使用可以自動(dòng)進(jìn)行的驗(yàn)收測(cè)試保證軟件的正確性。Userstories及傳統(tǒng)的用戶需求的區(qū)別在于詳細(xì)的程度，userstories并不會(huì)確定需求的每個(gè)細(xì)節(jié)，它只是用來(lái)簡(jiǎn)單的描述系統(tǒng)功能，供開(kāi)發(fā)人員進(jìn)行估計(jì)開(kāi)發(fā)進(jìn)度，在開(kāi)發(fā)過(guò)程中開(kāi)發(fā)人員和用戶會(huì)不斷的交流以討論細(xì)節(jié)問(wèn)題。Userstory應(yīng)該專注于功能，不應(yīng)該過(guò)分注重用戶界面等細(xì)節(jié)。一般一個(gè)userstoriy在1-3周的時(shí)間完成，如果估計(jì)超過(guò)3周，說(shuō)明userstory太大了，需要細(xì)分.2022/12/1180XP原則和實(shí)踐-Planning-userstoriesuXP原則和實(shí)踐-Planning-releaseplanreleaseplan召開(kāi)一個(gè)releaseplan會(huì)議，產(chǎn)生releaseplan。Releaseplan將用于指定每個(gè)iteration的計(jì)劃。開(kāi)發(fā)人員對(duì)每個(gè)userstory估計(jì)開(kāi)發(fā)時(shí)間（在不被打斷，無(wú)其他工作情況下的開(kāi)發(fā)時(shí)間，包括測(cè)試），用戶對(duì)userstories給出優(yōu)先級(jí)，releaseplan會(huì)議并不制訂每個(gè)iteration的計(jì)劃。Releaseplan要用戶，開(kāi)發(fā)人員和管理者都同意，在完成功能范圍（scope），使用資源（resource）,時(shí)間（time）和質(zhì)量(quality)上達(dá)成一致（一般質(zhì)量是不能改變的）2022/12/1181XP原則和實(shí)踐-Planning-releaseplanrXP原則和實(shí)踐-Planning-smallreleasesmallreleaseoftenandsmallrelease是XP的一個(gè)原則，每個(gè)release完成一些用戶有意義的功能集合，盡快的提交給用戶以獲得反饋，及時(shí)調(diào)整，提交的越晚，調(diào)整越困難。2022/12/1182XP原則和實(shí)踐-Planning-smallreleaseXP原則和實(shí)踐-Planning-projectvelocityprojectvelocity團(tuán)隊(duì)在開(kāi)發(fā)過(guò)程中要收集數(shù)據(jù)，以便于對(duì)自己的開(kāi)發(fā)速度進(jìn)行評(píng)估，用于以后的releazseplan2022/12/1183XP原則和實(shí)踐-Planning-projectvelocXP原則和實(shí)踐-Planning-iterationiteration每個(gè)smallrelease的周期稱為iteration，每個(gè)iteration約為1-3周，在一個(gè)項(xiàng)目中保持每個(gè)iteration的時(shí)間相等，不要超前制定計(jì)劃，每個(gè)iteration的計(jì)劃在iteration的開(kāi)始時(shí)制定。這樣能夠更靈活的應(yīng)付變化。不要急于完成本次iteration沒(méi)有包括的功能。要注重每個(gè)iteration的時(shí)間限制，當(dāng)團(tuán)隊(duì)覺(jué)得不能按時(shí)完成iteration時(shí)，召開(kāi)一次iterationplan會(huì)議，重新評(píng)估，減少一些userstories。2022/12/1184XP原則和實(shí)踐-Planning-iterationiterXP原則和實(shí)踐-Planning-iterationplaniterationplan在每個(gè)iteration開(kāi)始的時(shí)候召開(kāi)會(huì)議，從releaseplan中選擇還沒(méi)有實(shí)現(xiàn)的用戶最迫切需要的userstories。上一個(gè)iteration中沒(méi)有通過(guò)驗(yàn)收測(cè)試的功能也要在這個(gè)iteration中實(shí)現(xiàn)?？梢愿鶕?jù)上一個(gè)iteration的實(shí)踐調(diào)整團(tuán)隊(duì)速度。Userstories和失敗的測(cè)試被分解成programmingtask，task使用技術(shù)語(yǔ)言編寫，作為iterationplan的詳細(xì)描述。程序員主動(dòng)領(lǐng)取task并估計(jì)完成時(shí)間，每個(gè)task應(yīng)該在1-3天內(nèi)完成，超過(guò)3天的task應(yīng)該被細(xì)分。如果整個(gè)團(tuán)隊(duì)需要的時(shí)間多于或少于規(guī)定的iteration時(shí)間，調(diào)整userstories。2022/12/1185XP原則和實(shí)踐-Planning-iterationplaXP原則和實(shí)踐-Planning-movepeoplearoundmovepeoplearound不要使每個(gè)開(kāi)發(fā)人員局限于一項(xiàng)工作，不要使某項(xiàng)工作依賴于一個(gè)開(kāi)發(fā)人員，增加知識(shí)共享，減少信息孤島，多進(jìn)行交流和培訓(xùn)。當(dāng)項(xiàng)目中的所有人對(duì)所有模塊都了解并可以進(jìn)行開(kāi)發(fā)時(shí)是效率最高的，鼓勵(lì)開(kāi)發(fā)人員在不同iteration中開(kāi)發(fā)不同的模塊。2022/12/1186XP原則和實(shí)踐-Planning-movepeopleaXP原則和實(shí)踐-Planning-stand-upmeetingstand-upmeeting每天工作開(kāi)始之前，開(kāi)5-10分鐘的stand-up會(huì)議（站立會(huì)議），站立的目的是為了強(qiáng)迫節(jié)省時(shí)間，會(huì)議的目的是交流，提出存在的問(wèn)題，但不要在會(huì)議上解決問(wèn)題。開(kāi)一個(gè)所有人員參加的短會(huì)比多個(gè)個(gè)別人員參加的會(huì)議要高效。在會(huì)議上提出的問(wèn)題可以由少數(shù)人討論解決，這個(gè)少數(shù)人參加的會(huì)議如果涉及到代碼，可以在計(jì)算機(jī)前討論。2022/12/1187XP原則和實(shí)踐-Planning-stand-upmeetXP原則和實(shí)踐-Planning-fixXPwhenitbreaksfixXPwhenitbreaksXP并不是一成不變的，當(dāng)團(tuán)隊(duì)覺(jué)得需要修改的時(shí)候，可以根據(jù)自己的情況進(jìn)行修改，任何修改都要經(jīng)過(guò)整個(gè)團(tuán)隊(duì)的討論和達(dá)成一致2022/12/1188XP原則和實(shí)踐-Planning-fixXPwheniXP原則和實(shí)踐-Designing-1Simplicity保持簡(jiǎn)單的設(shè)計(jì)，在完成同樣的功能的情況下，選擇簡(jiǎn)單的設(shè)計(jì)，不要急于設(shè)計(jì)沒(méi)有計(jì)劃的功能，應(yīng)該認(rèn)識(shí)到：keepingadesignsimpleishardworkSystemmetaphor使用統(tǒng)一的術(shù)語(yǔ)描述系統(tǒng)，在用戶，管理者和開(kāi)發(fā)人員之間使用統(tǒng)一的術(shù)語(yǔ)。這將使交流清晰。CRCcard使用CRC(Class,Responsibilities,andCollaboration)card進(jìn)行系統(tǒng)設(shè)計(jì)，鼓勵(lì)更多的人參加設(shè)計(jì)。每個(gè)CRC卡片表示系統(tǒng)中一個(gè)對(duì)象，寫上對(duì)象的名字，責(zé)任和每個(gè)責(zé)任需要交互的其他對(duì)象?？梢阅M對(duì)象之間的交互。CRC卡片是易于理解的，但是是非正式的，如果需要正式的文檔，要將卡片轉(zhuǎn)換為相應(yīng)的文檔。spikesolutionneveraddfunctionearlyrefactoringwheneverandwherever2022/12/1189XP原則和實(shí)踐-Designing-1SimplicityXP原則和實(shí)踐-Designing-2spikesolution使用spikesolution減低風(fēng)險(xiǎn)，當(dāng)遇到技術(shù)難題或設(shè)計(jì)問(wèn)題時(shí)，使用簡(jiǎn)單的程序進(jìn)行測(cè)試，找出問(wèn)題，在不同的解決方法之間進(jìn)行評(píng)估。在早期進(jìn)行實(shí)驗(yàn)可以有效的降低風(fēng)險(xiǎn)。neveraddfunctionearly不要過(guò)早的設(shè)計(jì)沒(méi)有計(jì)劃的功能，在一個(gè)需求經(jīng)常變化的環(huán)境中，過(guò)早的設(shè)計(jì)經(jīng)常是沒(méi)有用的。refactoringwheneverandwhereverXP鼓勵(lì)對(duì)設(shè)計(jì)和代碼經(jīng)常進(jìn)行重構(gòu)（Refactoring），目的是去除冗余，提高質(zhì)量，保持設(shè)計(jì)簡(jiǎn)單。重構(gòu)必須以完全測(cè)試為檢驗(yàn)條件2022/12/1190XP原則和實(shí)踐-Designing-2spikesolutXP原則和實(shí)踐-Coding-1customerisalawaysavailable用戶是項(xiàng)目組的成員之一，用戶的參加貫穿整個(gè)開(kāi)發(fā)過(guò)程，用戶及開(kāi)發(fā)人員之間的交流是重要的codingstandard使用統(tǒng)一的編碼標(biāo)準(zhǔn)，這是保持代碼整潔和共享代碼的基礎(chǔ)codingunittestfirsttestfirst是XP的一個(gè)特點(diǎn)，在編寫代碼之前先編寫單元測(cè)試代碼，單元測(cè)試代碼和代碼由同一個(gè)程序員完成。先編寫測(cè)試代碼可以使程序員更好的理解需求，避免直接編碼造成的理解偏差，對(duì)需求的不清晰，可以在編寫測(cè)試代碼時(shí)就發(fā)現(xiàn)。測(cè)試代碼也是檢驗(yàn)程序是否完成的標(biāo)準(zhǔn)。編碼工作應(yīng)該是以下工作的循環(huán)：

1編寫測(cè)試代碼

2運(yùn)行測(cè)試程序，確認(rèn)失敗

3編寫實(shí)現(xiàn)這個(gè)測(cè)試程序要求功能的代碼，不需要實(shí)現(xiàn)其他的功能，只需要實(shí)現(xiàn)剛剛滿足測(cè)試程序的功能

4運(yùn)行測(cè)試程序，確認(rèn)成功

實(shí)踐證明，testfirst方式需要的編碼實(shí)踐少于先編碼，后寫測(cè)試代碼2022/12/1191XP原則和實(shí)踐-Coding-1customerisalXP原則和實(shí)踐-Coding-2PairProgrammingPairprogramming是XP的特色，它要求兩個(gè)程序員在一臺(tái)計(jì)算機(jī)上同時(shí)進(jìn)行編程工作。共用鼠標(biāo)和鍵盤，通常一個(gè)人進(jìn)行戰(zhàn)略上的思考，程序架構(gòu)和函數(shù)，類之間的關(guān)系，一個(gè)人進(jìn)行輸入和戰(zhàn)術(shù)上的思考，完成函數(shù)和類。兩個(gè)人可以經(jīng)常交換角色。sequentialintegration要保證源代碼庫(kù)的狀態(tài)是可標(biāo)識(shí)的，同一時(shí)間，只允許一個(gè)pair的程序進(jìn)行整和和測(cè)試，這樣可以縮小問(wèn)題產(chǎn)生的范圍。不同的pair可以在自己的機(jī)器上隨時(shí)進(jìn)行整和和測(cè)試.integrateoften只要有可能就進(jìn)行代碼整合，周期可以在幾個(gè)小時(shí)，最好不要超過(guò)一天。2022/12/1192XP原則和實(shí)踐-Coding-2PairProgrammiXP原則和實(shí)踐-Coding-3共同擁有代碼鼓勵(lì)每個(gè)人對(duì)項(xiàng)目中的任何人提出新的想法，任何開(kāi)發(fā)人員對(duì)項(xiàng)目中的任何代碼都可以進(jìn)行增加功能，改正錯(cuò)誤和重構(gòu)。優(yōu)化工作放在最后先使系統(tǒng)能夠正常工作，不要猜測(cè)系統(tǒng)的瓶頸，要實(shí)際測(cè)量NOovertime

不要長(zhǎng)時(shí)間的加班，大多數(shù)加班并不能挽回已有的延遲，連續(xù)超過(guò)兩個(gè)星期的加班說(shuō)明有問(wèn)題存在。向一個(gè)已經(jīng)延遲的項(xiàng)目填加人員也不是一個(gè)好的選擇。2022/12/1193XP原則和實(shí)踐-Coding-32022/12/1033XP原則和實(shí)踐-Testing-1所有的代碼都有單元測(cè)試單元測(cè)試是XP的基石，XP中的單元測(cè)試應(yīng)該是可以自動(dòng)進(jìn)行的，所以可以很快的進(jìn)行所有的單元測(cè)試，單元測(cè)試應(yīng)該在編碼之前創(chuàng)建。單元測(cè)試的代碼和代碼一起release，沒(méi)有單元測(cè)試的代碼不能夠release。使用自動(dòng)單元測(cè)試可以系統(tǒng)整合時(shí)節(jié)省大量的發(fā)現(xiàn)錯(cuò)誤和改正的時(shí)間。單元測(cè)試越完善，節(jié)省的時(shí)間越多。代碼在release前必須通過(guò)所有的單元測(cè)試發(fā)現(xiàn)bug后，首先增加測(cè)試在實(shí)際運(yùn)行中發(fā)現(xiàn)bug,首先增加acceptancetest，然后增加unittest，在增加完測(cè)試后在查找和修改代碼，增加的測(cè)試保證同樣的錯(cuò)誤不會(huì)再出現(xiàn)acceptancetestacceptancetest根據(jù)userstories在iterationplan會(huì)議上創(chuàng)建，它也應(yīng)該可以自動(dòng)運(yùn)行以便可以經(jīng)常運(yùn)行。2022/12/1194XP原則和實(shí)踐-Testing-1所有的代碼都有單元測(cè)試21.RUP2.XP3.Scrum2022/12/11951.RUP2.XP3.Scrum2022/12/103ScrumScrum2022/12/1196ScrumScrum2022/12/1036Scrum特點(diǎn)自我管理的團(tuán)隊(duì)以“sprint”為周期迭代的產(chǎn)品開(kāi)發(fā)以一系列“產(chǎn)品Backlog”記錄了產(chǎn)品需求沒(méi)有特定的工程實(shí)踐慣例在以生成規(guī)則創(chuàng)造的敏捷開(kāi)發(fā)環(huán)境交付產(chǎn)品是其中一種“敏捷方法”2022/12/1197Scrum特點(diǎn)自我管理的團(tuán)隊(duì)2022/12/1037SCRUM開(kāi)發(fā)流程

SCRUM開(kāi)發(fā)流程是AgileProcess的一種，以英式橄欖球爭(zhēng)球隊(duì)形(Scrum)為名，基本假設(shè)是『開(kāi)發(fā)軟件就像開(kāi)發(fā)新產(chǎn)品，無(wú)法一開(kāi)始就能定義FinalProduct的規(guī)程，過(guò)程中需要研發(fā)、創(chuàng)意、嘗試錯(cuò)誤，所以沒(méi)有一種固定的流程可以保證項(xiàng)目成功』。Scrum將軟件開(kāi)發(fā)團(tuán)隊(duì)比擬成橄欖球隊(duì)，有明確的最高目標(biāo)，熟悉開(kāi)發(fā)流程中所需具備的最佳典范及技術(shù)，具有高度自主權(quán)，緊密地溝通合作，以高度彈性解決各種挑戰(zhàn)，碓保每天、每個(gè)階段都朝向目標(biāo)有明確的推進(jìn)，因此SCRUM非常適用于產(chǎn)品開(kāi)發(fā)項(xiàng)目。2022/12/1198SCRUM開(kāi)發(fā)流程SCRUM開(kāi)發(fā)流程是AgilePSCRUM開(kāi)發(fā)流程(cont.)SCRUM開(kāi)發(fā)流程通常以30天為一個(gè)迭代周期，每個(gè)迭代周期叫做一個(gè)Sprint，由客戶提供新產(chǎn)品的需求規(guī)格開(kāi)始，開(kāi)發(fā)團(tuán)隊(duì)及客戶于每一個(gè)階段開(kāi)始時(shí)挑選該完成的規(guī)格部份，開(kāi)發(fā)團(tuán)隊(duì)必須盡力于30天后交付成果，團(tuán)隊(duì)每天用15分鐘開(kāi)會(huì)檢視每個(gè)成員的進(jìn)度與計(jì)劃，了解所遭遇的困難并設(shè)法排除，決定第二天的任務(wù)安排.SCRUM較為有特色的，是它特別強(qiáng)調(diào)開(kāi)發(fā)隊(duì)伍和管理層的交流協(xié)作。每天，開(kāi)發(fā)隊(duì)伍都會(huì)向管理層匯報(bào)進(jìn)度，如果有問(wèn)題，也會(huì)向管理層要求幫助解決。2022/12/1199SCRUM開(kāi)發(fā)流程(cont.)SCRUM開(kāi)發(fā)流程通常以Scrum總體骨架迭代每30天DailySCRUM每24小時(shí)高優(yōu)先級(jí)可運(yùn)行的軟件工作項(xiàng)分解產(chǎn)品訂單ProductBacklog迭代訂單SprintBacklog新的功能增量迭代規(guī)劃會(huì)議SprintPlan一般不超過(guò)8小時(shí)。前4個(gè)小時(shí)：產(chǎn)品負(fù)責(zé)人向團(tuán)隊(duì)展示最高優(yōu)先級(jí)的產(chǎn)品，團(tuán)隊(duì)則向他詢問(wèn)產(chǎn)品Backlog的內(nèi)容、目的、含義及意圖。后4小時(shí)：團(tuán)隊(duì)計(jì)劃本Sprint的安排迭代復(fù)審會(huì)議SprintReview一般4個(gè)小時(shí)，由團(tuán)隊(duì)成員向產(chǎn)品負(fù)責(zé)人額其他利益相關(guān)人展示Sprint周期內(nèi)的產(chǎn)品開(kāi)發(fā)情況迭代回顧會(huì)議SprintRetrospective一般3個(gè)小時(shí)，ScrumMaster將鼓勵(lì)團(tuán)隊(duì)在SCRUM過(guò)程框架和實(shí)踐范圍內(nèi)，對(duì)開(kāi)發(fā)過(guò)程做出修改，使它在下一個(gè)Sprint周期中更加有效和令人愉快每日站立會(huì)議DailyScrumMeeting在簡(jiǎn)會(huì)上，每個(gè)成員主要回答三個(gè)問(wèn)題;–自上次SCRUM簡(jiǎn)會(huì)后的一天了（昨天），你做了什么?–從現(xiàn)在到下次SCRUM簡(jiǎn)會(huì)的一天里（今天），你要做什么?–在實(shí)現(xiàn)SCRUM及項(xiàng)目目標(biāo)的工作中，你遇到哪些困難嗎?產(chǎn)品負(fù)責(zé)人Scrum主管開(kāi)發(fā)團(tuán)隊(duì)2022/12/11100Scrum總體骨架迭代DailySCRUM高優(yōu)先級(jí)可運(yùn)行的順序vs.重疊開(kāi)發(fā)過(guò)程Scrum并非以一段時(shí)間集中完成一個(gè)過(guò)程...而是將所有過(guò)程中必須的每一部分集中在這段時(shí)間內(nèi)完成需求設(shè)計(jì)代碼測(cè)試2022/12/11101順序vs.重疊開(kāi)發(fā)過(guò)程Scrum并非以一段時(shí)間集中完成一Scrum結(jié)構(gòu)框架產(chǎn)品所有者ScrumMaster團(tuán)隊(duì)職能迭代計(jì)劃迭代驗(yàn)收迭代回顧每天召開(kāi)的s