敏捷開發(fā)知識(shí)體系整體框架

1敏捷開發(fā)知識(shí)體系整體框架1.1敏捷開發(fā)工程實(shí)踐1?1?1項(xiàng)目管理迭代開發(fā)風(fēng)險(xiǎn)價(jià)值生命周期多級(jí)項(xiàng)目規(guī)劃完整團(tuán)隊(duì)?每日站立會(huì)議*任務(wù)板燃盡圖1.1.2需求管理需求訂單業(yè)務(wù)流程草圖用例驅(qū)動(dòng)開發(fā)用戶故事1.1.3架構(gòu)演進(jìn)的架構(gòu)*演進(jìn)的設(shè)計(jì)*基于組件的架構(gòu)設(shè)計(jì)1.1.4開發(fā)結(jié)對(duì)編程測(cè)試驅(qū)動(dòng)開發(fā)?重構(gòu)代碼規(guī)范1.1.5測(cè)試單元測(cè)試*并行測(cè)試*測(cè)試管理1.1.6變更管理持續(xù)集成自動(dòng)構(gòu)建團(tuán)隊(duì)變更管理1?2敏捷開發(fā)管理實(shí)踐描述*定義和特征說(shuō)明主要角色主要活動(dòng)和最佳實(shí)踐*主要輸入輸出工作流程1?3敏捷開發(fā)工程實(shí)踐描述*定義和特征說(shuō)明應(yīng)用說(shuō)明案例說(shuō)明2敏捷開發(fā)核心價(jià)值觀和原則2.1敏捷軟件開發(fā)宣言*個(gè)體和互動(dòng)高于流程和文檔*工作的軟件高于詳盡的文檔*客戶合作高于合同談判響應(yīng)變化高于遵循計(jì)劃*也就是說(shuō)，盡管右項(xiàng)有其價(jià)值,我們更重視左項(xiàng)的價(jià)值.2.2敏捷軟件開發(fā)的核心價(jià)值觀敏捷開發(fā)的核心理念就是以最簡(jiǎn)單有效的方式快速打成目標(biāo)響,并在這個(gè)過(guò)程中及時(shí)地應(yīng)外界的變化，做出迅速的調(diào)整.2.2.1核心價(jià)值觀以人為本目標(biāo)導(dǎo)向客戶為先擁抱變化222敏捷開發(fā)的原則我們最重要的目標(biāo)，是通過(guò)持續(xù)不斷地及早交付有價(jià)值的軟件使客戶滿意。欣然面對(duì)需求變化，即使在開發(fā)后期也一樣。為了客戶的競(jìng)爭(zhēng)優(yōu)勢(shì)，敏捷過(guò)程掌控變化。經(jīng)常地交付可工作的軟件，相隔幾星期或一兩個(gè)月，傾向于采取較短的周期。業(yè)務(wù)人員和開發(fā)人員必須相互合作，項(xiàng)目中的每一天都不例外。激發(fā)個(gè)體的斗志，以他們?yōu)楹诵拇罱?xiàng)目。提供所需的環(huán)境和支援，輔以信任，從而達(dá)成目標(biāo)。不論團(tuán)隊(duì)內(nèi)外，傳遞信息效果最好效率也最高的方式是面對(duì)面的交談。可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn)。敏捷過(guò)程倡導(dǎo)可持續(xù)開發(fā)。責(zé)任人、開發(fā)人員和用戶要能夠共同維持其步調(diào)穩(wěn)定延續(xù)。堅(jiān)持不懈地追求技術(shù)卓越和良好設(shè)計(jì)，敏捷能力由此增強(qiáng)。以簡(jiǎn)潔為本，它是極力減少不必要工作量的藝術(shù)。?最好的架構(gòu)、需求和設(shè)計(jì)出自自組織團(tuán)隊(duì)。團(tuán)隊(duì)定期地反思如何能提高成效，并依此調(diào)整自身的舉止表現(xiàn)。3敏捷開發(fā)管理實(shí)踐ScrumScrum是一種迭代式增量軟件開發(fā)過(guò)程，通常用于敏捷軟件開發(fā)。Scrum包括了一系列實(shí)踐和預(yù)定義角色的過(guò)程骨架。Scrum中的主要角色包括同項(xiàng)目經(jīng)理類似的Scrum主管角色負(fù)責(zé)維護(hù)過(guò)程和任務(wù)，產(chǎn)品負(fù)責(zé)人代表利益所有者，開發(fā)團(tuán)隊(duì)包括了所有開發(fā)人員。Scrum中的角色3.1.1.1豬”角色*產(chǎn)品負(fù)責(zé)人(ProductOwner)通常由市場(chǎng)部門的人擔(dān)任敏捷教練(ScrumMaster)*通常由開發(fā)組組長(zhǎng)擔(dān)任開發(fā)團(tuán)隊(duì)(ScrumTeam)包括開發(fā)，需求，測(cè)試3.1.1.2雞”角色用戶軟件是為了某些人而創(chuàng)建！就像假如森林里有一棵樹倒下了，但沒有人聽到，那么它算發(fā)出了聲音嗎”，假如軟件沒有被使用，那么它算是被開發(fā)出來(lái)了么？”利益所有者（客戶，提供商）*影響項(xiàng)目成功的人，但只直接參與沖刺評(píng)審過(guò)程。管理者*為產(chǎn)品開發(fā)團(tuán)體架起環(huán)境的那個(gè)人3.1.2主要活動(dòng)和最佳實(shí)踐沖刺回顧會(huì)議(RetrospectiveMeeting)凳］.+.作*（盤十3?SprintBacklog”覇』沖劇龔審會(huì)段何*M'*F*用』仇均SCMiK測(cè)■尙亂OaiiyScrum-AliMCRUMf—■豪三fIHkTft<1AXKMM/沖敢塊別仝■彊，貶人w—的產(chǎn)乩*擔(dān)息Wprwl釣左M迭代0、Vj迭代式軟件開發(fā)兩層項(xiàng)目規(guī)劃(Two-LevelProjectPlanning)整體團(tuán)隊(duì)協(xié)作(WholeTeam)持續(xù)集成沖刺規(guī)劃會(huì)議(SprintPlanMeeting)每日站立會(huì)議沖刺復(fù)審會(huì)議(SprintDailyMeeting)(SprintReviewMeeting)3.1.3主要輸入輸出產(chǎn)品訂單(ProductBacklog)沖刺訂單(SpringBacklog)燃盡圖(BurndownChart)新的功能增量3.1.4工作流程3.1.4.1項(xiàng)目管理過(guò)程在Scrum項(xiàng)目管理過(guò)程中產(chǎn)品負(fù)責(zé)人獲取項(xiàng)目投資 ，并對(duì)整個(gè)產(chǎn)品的成功負(fù)責(zé)*產(chǎn)品負(fù)責(zé)人協(xié)調(diào)個(gè)中利益干系人，確定產(chǎn)品訂單中初始的需求清單及其優(yōu)先級(jí) ,完成項(xiàng)目商業(yè)價(jià)值分析和項(xiàng)目整體規(guī)劃，并任命合適的敏捷教練開展項(xiàng)目工作3.1.4.2項(xiàng)目開發(fā)過(guò)程在Scrum軟件開發(fā)過(guò)程中，每個(gè)沖刺就是較短的迭代，通常為2~4周.*在每個(gè)沖刺開始時(shí)，產(chǎn)品負(fù)責(zé)人和敏捷教練通過(guò)召開沖刺規(guī)劃會(huì)議和 ”兩層項(xiàng)目規(guī)劃”的最佳實(shí)踐制定沖刺訂單（類似迭代計(jì)劃）在每個(gè)沖刺迭代中，團(tuán)隊(duì)強(qiáng)調(diào)應(yīng)用”整體團(tuán)隊(duì)協(xié)作”的最佳實(shí)踐，通過(guò)保持可持續(xù)發(fā)展的工作節(jié)奏和每日站立會(huì)議，實(shí)現(xiàn)團(tuán)隊(duì)的自組織，自適應(yīng)和自管理，高效完成沖刺工作在每個(gè)沖刺結(jié)束時(shí)，團(tuán)隊(duì)都會(huì)召開沖刺復(fù)審會(huì)議，團(tuán)隊(duì)成員會(huì)在會(huì)上分別展示他們開發(fā)出的軟件(或其他有價(jià)值的產(chǎn)品)，并從產(chǎn)品負(fù)責(zé)人和其他利益關(guān)系人那里 ，得到反饋信息.在沖刺復(fù)審會(huì)議之后，團(tuán)隊(duì)會(huì)自覺招開沖刺回顧會(huì)議，回顧整個(gè)項(xiàng)目過(guò)程，討論哪些方法做的好哪些方面可以改進(jìn)，實(shí)現(xiàn)軟件交付過(guò)程的持續(xù)，自發(fā)的改進(jìn)XPOpenUpLean4敏捷開發(fā)工程實(shí)踐4.1迭代式開發(fā)敏捷迭代開發(fā)是指每次按照相同的開發(fā)方式短期的開發(fā)軟件的部分 ，或前期開發(fā)并不詳盡的軟件，每次開發(fā)結(jié)束獲得可以運(yùn)行的軟件，以供各方干系人觀測(cè)，獲得反饋，根據(jù)反饋適應(yīng)性的進(jìn)行后續(xù)開發(fā)，經(jīng)過(guò)發(fā)福多次開發(fā)，逐步增加軟件部分，逐步補(bǔ)充完善軟件，最終開發(fā)得到最后的軟件?每次反復(fù)開開發(fā)叫一次迭代，在Scrum中成為Sprint，中文常譯為”沖刺”.持續(xù)集成持續(xù)集成(Continuousintegration)是指當(dāng)代碼提交后，馬上啟動(dòng)自動(dòng)編譯，自動(dòng)部署金額自動(dòng)化測(cè)試來(lái)快速驗(yàn)證軟件，從而盡快的發(fā)現(xiàn)集成錯(cuò)誤.多級(jí)項(xiàng)目規(guī)劃多級(jí)項(xiàng)目/產(chǎn)品規(guī)劃，在軟件開發(fā)領(lǐng)域，是指以迭代開發(fā)為基礎(chǔ)，形成多層次的，逐步細(xì)化的項(xiàng)目或產(chǎn)品計(jì)劃?這些層層相關(guān)的項(xiàng)目/產(chǎn)品規(guī)劃包括：*項(xiàng)目/產(chǎn)品愿景*項(xiàng)目/產(chǎn)品路線圖版本發(fā)布計(jì)劃迭代計(jì)劃每日實(shí)現(xiàn)4.3.1項(xiàng)目/產(chǎn)品愿景在計(jì)劃階段，首先，項(xiàng)目stakeholder，項(xiàng)目/產(chǎn)品負(fù)責(zé)人將參與并組成工作組，他們負(fù)責(zé)闡述項(xiàng)目的重要性，給出項(xiàng)目成功失敗的關(guān)鍵標(biāo)準(zhǔn)以及項(xiàng)目整體層面 ”完成”的定義；在過(guò)程中，可以利用形成項(xiàng)目愿景的一些個(gè)工具 ，包括愿景盒子(VisonBox),業(yè)務(wù)收益矩陣(BusinessBenefitsMatrix),項(xiàng)目范圍矩陣(ScopeMatrix),滑動(dòng)器(Slider),成本收益矩陣(Cost/BenefitMatrix)等；最后，項(xiàng)目愿景需要使用盡量簡(jiǎn)要的文檔固定下來(lái)，并保證項(xiàng)目團(tuán)隊(duì)成員都能了解.該文檔需要包括：當(dāng)前的問(wèn)題機(jī)會(huì)描述和理由(描述項(xiàng)目的重要性)項(xiàng)目的價(jià)值項(xiàng)目如何和組織的戰(zhàn)略目標(biāo)達(dá)成一致*解決方案綜述項(xiàng)目包含的關(guān)鍵功能項(xiàng)目必須服從的技術(shù)和約束條件項(xiàng)目范圍項(xiàng)目的關(guān)鍵時(shí)間線*項(xiàng)目收益分析項(xiàng)目和其他項(xiàng)目的依賴性項(xiàng)目的相關(guān)風(fēng)險(xiǎn)以及如何消除項(xiàng)目/產(chǎn)品路線圖主要描述為了達(dá)到產(chǎn)品愿景而需要交付的關(guān)鍵功能和特性，這些特性基本處于Epic和特性層面，不包裹用戶故事(UserStory).它從時(shí)間的維度來(lái)表述對(duì)愿景的支持和實(shí)現(xiàn)?它從時(shí)間維度來(lái)表達(dá)對(duì)愿景的支持和實(shí)現(xiàn)?當(dāng)項(xiàng)目/產(chǎn)品需要發(fā)布多個(gè)版本時(shí)，項(xiàng)目線路圖就非常重要，否則，它和發(fā)布計(jì)劃相同，項(xiàng)目/產(chǎn)品線路圖由項(xiàng)目負(fù)責(zé)人和項(xiàng)目經(jīng)理維護(hù)，并保持更新?通常，會(huì)形成路線圖問(wèn)題或幻燈片，使用大圖標(biāo)顯示重要的里程碑，包含的功能和發(fā)布日期等，讓所有項(xiàng)目/產(chǎn)品相關(guān)人員都清楚產(chǎn)品各個(gè)組件的可能發(fā)布日程?版本發(fā)布計(jì)劃版本發(fā)布計(jì)劃由團(tuán)隊(duì)成員和項(xiàng)目/產(chǎn)品負(fù)責(zé)人共同制定，并通過(guò)版本發(fā)布計(jì)劃會(huì)議討論通過(guò)?它包括了當(dāng)前版本需要交付的，達(dá)成一致的關(guān)鍵功能，并經(jīng)過(guò)優(yōu)先級(jí)排序，可以包含EPIC和UserStory?版本發(fā)布計(jì)劃中常使用的概念包括：故事點(diǎn)，迭代團(tuán)隊(duì)速率和優(yōu)先級(jí)排序?通常，項(xiàng)目/產(chǎn)品負(fù)責(zé)人提出本次發(fā)布的目標(biāo)，團(tuán)隊(duì)成員根據(jù)目標(biāo)和功能特性的重要性對(duì)故事進(jìn)行排序，并依據(jù)團(tuán)隊(duì)速率覺得本次發(fā)布需要包含的故事點(diǎn) ?前幾次版本發(fā)布使用估算值，其準(zhǔn)確性隨著項(xiàng)目/產(chǎn)品的時(shí)間持續(xù)而逐步精確?版本發(fā)布計(jì)劃是劇本適應(yīng)性可調(diào)整的計(jì)劃，會(huì)隨著項(xiàng)目演進(jìn)而改變.4?3?4迭代計(jì)劃迭代計(jì)劃是對(duì)版本發(fā)布計(jì)劃的再次細(xì)化，同樣由團(tuán)隊(duì)成員和項(xiàng)目/產(chǎn)品負(fù)責(zé)人共同制定并聽過(guò)迭代計(jì)劃會(huì)議討論通過(guò).迭代會(huì)議負(fù)責(zé)兩件事情：根據(jù)當(dāng)前狀態(tài)確定是否需要對(duì)版本計(jì)劃做出更新為當(dāng)前的迭代計(jì)劃制定迭代計(jì)劃迭代計(jì)劃中常使用的概念包括：拆分Epic和UserStory,任務(wù)，任務(wù)估算?在迭代會(huì)議上，成員首先根據(jù)當(dāng)前的項(xiàng)目變化對(duì)發(fā)布計(jì)劃進(jìn)行更新 ，然后根據(jù)更新后的，重新排序過(guò)的故事制定當(dāng)前迭代需要完成的故事，并對(duì)這些故事進(jìn)行詳細(xì)的任務(wù)拆分?成員在認(rèn)領(lǐng)完任務(wù)后，會(huì)對(duì)任務(wù)的實(shí)現(xiàn)時(shí)間做出估算，估算值需要具體到這些估算信息可以方便任何成員追蹤任務(wù)的進(jìn)度.4.3.5每日實(shí)現(xiàn)沒事實(shí)現(xiàn)是團(tuán)隊(duì)成員完成任務(wù)的具體過(guò)程，它依據(jù)任務(wù)估算值并根據(jù)任務(wù)最終實(shí)現(xiàn)情況更新該值?在敏捷方法中，使用每日站會(huì)議來(lái)報(bào)告進(jìn)度?通過(guò)15分鐘的站立形式，團(tuán)隊(duì)成員報(bào)告故事或者任務(wù)的完成，未完成狀態(tài)，而解決層面的問(wèn)題則在會(huì)議之后處理.4.4完整團(tuán)隊(duì)Scrum團(tuán)隊(duì)必須具備的三個(gè)完整性：4.4.1團(tuán)隊(duì)職責(zé)完整性4.4?1?1產(chǎn)品負(fù)責(zé)人(ProductOwner)?確定產(chǎn)品的功能。*決定發(fā)布的日期和發(fā)布內(nèi)容。?為產(chǎn)品的收益(profitabilityoftheproduct)負(fù)責(zé)。根據(jù)市場(chǎng)價(jià)值確定功能優(yōu)先級(jí)。*在30天內(nèi)調(diào)整功能和調(diào)整功能優(yōu)先級(jí)。接受或拒絕接受開發(fā)團(tuán)隊(duì)的工作成果敏捷教練(ScrumMaster)負(fù)責(zé)監(jiān)督整個(gè)Scrum項(xiàng)目進(jìn)程，調(diào)整開發(fā)計(jì)劃保證團(tuán)隊(duì)資源完全可被利用并且全部是高產(chǎn)出的。保證各個(gè)角色及職責(zé)的良好協(xié)作。解決團(tuán)隊(duì)開發(fā)中的障礙。做為團(tuán)隊(duì)和外部的接口，屏蔽外界對(duì)團(tuán)隊(duì)成員的干擾。保證開發(fā)過(guò)程按計(jì)劃進(jìn)行，組織 DailyScrum,SprintReviewandSprintPlanningmeetings。4需要知道什么任務(wù)已經(jīng)完成，哪些任務(wù)已經(jīng)開始，哪些新的任務(wù)已發(fā)現(xiàn)，和哪些估計(jì)可能已經(jīng)發(fā)生變化.根據(jù)以上的情況更新反映每天完成的工作量以及還有多少?zèng)]有完成的燃盡圖*需要找出阻礙Scrum的障礙和依賴，根據(jù)優(yōu)先級(jí)指定計(jì)劃解決這些障礙個(gè)人問(wèn)題或沖突在 Scrum里是需要解決的。這些都需要被澄清，或通過(guò)內(nèi)部的溝通解決，或向管理層和HR尋求幫助解決ScrumMaster需要知道什么任務(wù)已經(jīng)完成，哪些任務(wù)已經(jīng)開始，哪些新的任務(wù)已發(fā)現(xiàn)，和哪些估計(jì)可能已經(jīng)發(fā)生變化。ScrumMaster需要根據(jù)以上的情況更新反映每天完成的工作量以及還有多少?zèng)]有完成的BurndownChart。ScrumMaster還必須仔細(xì)考慮進(jìn)展中的開放任務(wù)數(shù)，進(jìn)展中的工作需要得到最小化，以實(shí)現(xiàn)精益生產(chǎn)率的收益。ScrumMaster需要找出阻礙Scrum的障礙和依賴。他們需要的優(yōu)先次序和跟蹤。根據(jù)優(yōu)先級(jí)指定計(jì)劃解決這些障礙。其中有些問(wèn)題可以在團(tuán)隊(duì)內(nèi)部解決，有些則要團(tuán)隊(duì)之間的協(xié)調(diào)，還有的要管理層的介入來(lái)解決.4?4?1?3開發(fā)團(tuán)隊(duì)(ScrumTeam)具有不同特長(zhǎng)的團(tuán)隊(duì)成員，人數(shù)控制在 5-7個(gè)左右，跨職能，包括開發(fā)，需求，測(cè)試*弱化分工，每個(gè)人都參與設(shè)計(jì)，開發(fā)與測(cè)試*確定Sprint目標(biāo)和具體說(shuō)明的工作成果。*在項(xiàng)目向?qū)Х秶鷥?nèi)有權(quán)利做任何事情已確保達(dá)到 Sprint的目標(biāo)。向ProductOwner演示產(chǎn)品功能。團(tuán)隊(duì)素質(zhì)完整性*要具備很強(qiáng)的集體協(xié)作精神.*要具備良好的溝通能力必須能積極主動(dòng)的接受新的事物，要具備創(chuàng)新能力要具備極強(qiáng)的自我管理能力和積極主動(dòng)的精神4?4?3溝通的完整性*Sprint啟動(dòng)會(huì)每日站立會(huì)議?Sprint回顧會(huì)4?4?4案例4.5驗(yàn)收測(cè)試驅(qū)動(dòng)開發(fā)ATDDTDD只是開發(fā)人員的職責(zé)，通過(guò)單元測(cè)試用例來(lái)驅(qū)動(dòng)功能代碼的實(shí)現(xiàn)。ATDD在準(zhǔn)備實(shí)施一個(gè)功能或特性之前，首先團(tuán)隊(duì)需要定義出期望的質(zhì)量標(biāo)準(zhǔn)和驗(yàn)收細(xì)則，以明確而且達(dá)成共識(shí)的驗(yàn)收測(cè)試計(jì)劃（包含一系列測(cè)試場(chǎng)景）來(lái)驅(qū)動(dòng)開發(fā)人員的TDD實(shí)踐和測(cè)試人員的測(cè)試腳本開發(fā)。面向開發(fā)人員，強(qiáng)調(diào)如何實(shí)現(xiàn)系統(tǒng)以及如何檢驗(yàn)。*挑選用戶故事*為故事寫測(cè)試實(shí)現(xiàn)測(cè)試實(shí)現(xiàn)故事4.6結(jié)對(duì)編程結(jié)對(duì)編程可以看做是一種敏捷化的CodeReview4.7新結(jié)對(duì)編程兩位程序員新成結(jié)對(duì)小組，每人一臺(tái)電腦，坐在臨近的工位上，兩人合作完成一組功能（可以是兩個(gè)或多個(gè)獨(dú)立的模塊）的設(shè)計(jì)，代碼實(shí)現(xiàn).但對(duì)已某一個(gè)模塊來(lái)說(shuō)設(shè)計(jì)和代碼是分開的，一個(gè)人負(fù)責(zé)設(shè)計(jì)，另一個(gè)人負(fù)責(zé)寫代碼，對(duì)于其他模塊則反之.4.8確定沖刺計(jì)劃4.8.1定義和說(shuō)明目的:ST和PO共同決定在接下來(lái)的沖刺周期內(nèi)的目標(biāo)以及那些功能和任務(wù)需求要完成主要角色：ST,PO,SM?主要輸入：Productbacklog,團(tuán)隊(duì)的能力主要輸出：SprintBacklog沖刺會(huì)議分兩個(gè)部分1?解決本次沖刺要完成哪些需求2?解決這些選擇的需求要如何被完成4?8?2案例4.9故事點(diǎn)估算故事點(diǎn)是表述一個(gè)用戶故事，一項(xiàng)功能或一件工作的整體大小的一種度量單位.數(shù)值本身不重要，重要的是這些故事之間對(duì)比體現(xiàn)相對(duì)大小.4.9.1計(jì)劃撲克?開始時(shí)，美人得到一張撲克，上面有任務(wù)點(diǎn)(？,0,1/2,1,2,3,5,8,13,20,40,100,無(wú)窮).?代表無(wú)法估算無(wú)窮代表故事太大開始對(duì)故事進(jìn)行估算，先由PO介紹這個(gè)故事的描述?接著澄清問(wèn)題每一個(gè)組員從撲克中挑選可以代表這個(gè)故事的卡片 ，集體亮牌最高分和最低分的組員像團(tuán)隊(duì)做出解釋全組成員自由討論幾分鐘重新打分，直到全組統(tǒng)一.敏捷估算2.0(AgileEstmating2.0)?P0像團(tuán)隊(duì)成員介紹每一個(gè)用戶故事，確保所有需求相關(guān)的問(wèn)題都在做估算前得到解決整個(gè)團(tuán)隊(duì)參與游戲：一次由一人將一個(gè)故事卡片放在合適的位置 ，規(guī)模小的在左，規(guī)模大的在右，一樣大的豎排.輪流移動(dòng)故事卡片，直到整個(gè)團(tuán)隊(duì)都認(rèn)同白板上故事卡的排序?yàn)橹?.團(tuán)隊(duì)將故事點(diǎn)(StoryPoint)分配給每個(gè)故事.需求訂單(ProductBacklog)記錄用戶需求的列表，包括產(chǎn)品所有需要的特征.每一項(xiàng)包含了需求標(biāo)題，描述，重要性，故事點(diǎn)(或其他表示大小的數(shù)字)需求訂單式開放的，團(tuán)隊(duì)每個(gè)成員都可以編寫和維護(hù)在整個(gè)項(xiàng)目開放生命周