應(yīng)用禪道進(jìn)行敏捷軟件開(kāi)發(fā)過(guò)程管理課件

應(yīng)用禪道進(jìn)行敏捷軟件開(kāi)發(fā)過(guò)程管理應(yīng)用禪道進(jìn)行敏捷軟件開(kāi)發(fā)過(guò)程管理應(yīng)用禪道進(jìn)行敏捷軟件開(kāi)發(fā)過(guò)程管理敏捷宣言個(gè)體與交互重于過(guò)程和工具可用的軟件重于完備的文檔客戶協(xié)作重于合同談判響應(yīng)變化重于遵循計(jì)劃敏捷背后的十二個(gè)規(guī)則我們的最高目標(biāo)是，通過(guò)盡早和持續(xù)地交付有價(jià)值的軟件來(lái)滿足客戶。歡迎對(duì)需求提出變更——即使是在項(xiàng)目開(kāi)發(fā)后期。要善于利用需求變更，幫助客戶獲得競(jìng)爭(zhēng)優(yōu)勢(shì)。要不斷交付可用的軟件，周期從幾周到幾個(gè)月不等，且越短越好。項(xiàng)目過(guò)程中，業(yè)務(wù)人員與開(kāi)發(fā)人員必須在一起工作。要善于激勵(lì)項(xiàng)目人員，給他們以所需要的環(huán)境和支持，并相信他們能夠完成任務(wù)。無(wú)論是團(tuán)隊(duì)內(nèi)還是團(tuán)隊(duì)間，最有效的溝通方法是面對(duì)面的交談。可用的軟件是衡量進(jìn)度的主要指標(biāo)。敏捷過(guò)程提倡可持續(xù)的開(kāi)發(fā)。項(xiàng)目方、開(kāi)發(fā)人員和用戶應(yīng)該能夠保持恒久穩(wěn)定的進(jìn)展速度。對(duì)技術(shù)的精益求精以及對(duì)設(shè)計(jì)的不斷完善將提升敏捷性。要做到簡(jiǎn)潔，即盡最大可能減少不必要的工作。這是一門藝術(shù)。最佳的架構(gòu)、需求和設(shè)計(jì)出自于自組織的團(tuán)隊(duì)。團(tuán)隊(duì)要定期反省如何能夠做到更有效，并相應(yīng)地調(diào)整團(tuán)隊(duì)的行為。和瀑布式開(kāi)發(fā)相比較敏捷的開(kāi)發(fā)周期更短，最長(zhǎng)不超過(guò)一個(gè)月持續(xù)的交付可以工作的軟件。客戶的充分參與。坐在一起的團(tuán)隊(duì)，面對(duì)面的溝通和交流。團(tuán)隊(duì)的自組織和管理。敏捷開(kāi)發(fā)的兩種流行方式極限編程極限編程，偏重于開(kāi)發(fā)實(shí)踐。采用一系列的開(kāi)發(fā)實(shí)踐了保證代碼的質(zhì)量和按期交付。單元測(cè)試，持續(xù)集成，TDD，結(jié)對(duì)編程，重構(gòu)……scrum偏重于宏觀的項(xiàng)目管理，并沒(méi)有規(guī)定具體的開(kāi)發(fā)實(shí)踐。scrum+xp需要有一個(gè)合格的scrummasterscrummaster要協(xié)調(diào)PO和Team，保證迭代的完成。scrummaster像教練，保姆，要幫助團(tuán)隊(duì)解決困難，推動(dòng)團(tuán)隊(duì)前進(jìn)。但scrummaster和項(xiàng)目經(jīng)理很大的不同是scrummaster沒(méi)有決策的權(quán)力。所有的決策，應(yīng)當(dāng)由Team來(lái)完成。產(chǎn)品經(jīng)理角色的轉(zhuǎn)變不再是撰寫復(fù)雜的需求說(shuō)明書，而是將產(chǎn)品分解為一個(gè)個(gè)的userstory，并為期估計(jì)優(yōu)先級(jí)，進(jìn)行排序。對(duì)產(chǎn)品進(jìn)行規(guī)劃，制定發(fā)布計(jì)劃(releaseplan)積極參與項(xiàng)目過(guò)程，隨時(shí)和團(tuán)隊(duì)進(jìn)行溝通。驗(yàn)收產(chǎn)品，參加演示會(huì)議，獲得反饋。開(kāi)發(fā)人員的轉(zhuǎn)變由以前的被動(dòng)執(zhí)行，改為自我組織。項(xiàng)目過(guò)程中的決策，都是由團(tuán)隊(duì)自我完成。真正達(dá)到Teamwork。嘗試采用極限編程的開(kāi)發(fā)實(shí)踐，找到自己適用的實(shí)踐并執(zhí)行。（或者TDD）過(guò)程的變化計(jì)劃會(huì)議–產(chǎn)品經(jīng)理召集每天的站立會(huì)議–ScrumMaster召集每天更新自己的任務(wù)和燃盡圖演示會(huì)議總結(jié)會(huì)議借助于工具禪道核心功能組織管理部門管理、用戶管理、分組管理、分組管理、權(quán)限管理產(chǎn)品管理產(chǎn)品管理、需求管理、計(jì)劃管理、發(fā)布管理、路線圖項(xiàng)目管理項(xiàng)目管理、任務(wù)管理、項(xiàng)目需求管理、團(tuán)隊(duì)管理、工時(shí)管理、build管理、燃燒圖。質(zhì)量管理Bug管理、測(cè)試用例管理、測(cè)試任務(wù)管理。我的地盤TODO管理、我的需求、我的bug、我的任務(wù)……基于SCRUM的完整涵蓋產(chǎn)品管理、任務(wù)管理、測(cè)試管理的開(kāi)源管理軟件用戶角色系統(tǒng)管理員(Admin)系統(tǒng)管理員主要負(fù)責(zé)添加用戶，分配權(quán)限。產(chǎn)品人員(productowner)產(chǎn)品人員主要負(fù)責(zé)產(chǎn)品管理。開(kāi)發(fā)人員(developer)開(kāi)發(fā)人員負(fù)責(zé)產(chǎn)品的研發(fā)。測(cè)試人員(QA)測(cè)試人員保證產(chǎn)品的質(zhì)量。項(xiàng)目經(jīng)理(ProjectManagerorscrummaster)通過(guò)項(xiàng)目，協(xié)調(diào)產(chǎn)品人員，開(kāi)發(fā)人員，測(cè)試人員完成產(chǎn)品。scrum里面，該角色稱為scrummaster。基本概念組織視圖：部門結(jié)構(gòu)、用戶和分組產(chǎn)品視圖：產(chǎn)品、需求、計(jì)劃、發(fā)布和路線圖項(xiàng)目視圖(Sprint)：項(xiàng)目、任務(wù)、產(chǎn)品、需求、bug、build、燃燒圖、團(tuán)隊(duì)QA視圖：Bug、測(cè)試用例和測(cè)試任務(wù)我的地盤：todo、任務(wù)、項(xiàng)目、需求、bug禪道項(xiàng)目管理流程（Scrum軟件過(guò)程）首先產(chǎn)品人員維護(hù)需求列表，需求有優(yōu)先級(jí)和預(yù)計(jì)工時(shí)。召開(kāi)產(chǎn)品計(jì)劃會(huì)議(PlanningMeeting)，與會(huì)人員有產(chǎn)品、研發(fā)和測(cè)試，大家就當(dāng)前項(xiàng)目（固定的時(shí)間和人）所需要完成的需求達(dá)成一致，形成項(xiàng)目的需求列表。項(xiàng)目團(tuán)隊(duì)對(duì)需求進(jìn)行WBS任務(wù)分解(分割成完成時(shí)間不大于2天的若干子任務(wù))，開(kāi)始開(kāi)發(fā)。測(cè)試人員根據(jù)需求創(chuàng)建自己的測(cè)試用例。當(dāng)有版本提交以后，建立相應(yīng)的測(cè)試任務(wù)，記錄缺陷。研發(fā)人員修復(fù)bug。項(xiàng)目結(jié)束之后，大家召開(kāi)演示會(huì)議，團(tuán)隊(duì)向相關(guān)人員（產(chǎn)品人員及所有感興趣的人）展示該項(xiàng)目所取得的成果。大家提出的反饋由產(chǎn)品人員整理成為需求。開(kāi)始下一輪的循環(huán)。禪道和scrum的對(duì)應(yīng)產(chǎn)品管理產(chǎn)品管理是至關(guān)重要的一環(huán)添加產(chǎn)品維護(hù)產(chǎn)品模塊添加需求需求詳情需求處理流程計(jì)劃發(fā)布路線圖產(chǎn)品管理至關(guān)重要很多項(xiàng)目管理軟件中只有單純的任務(wù)管理，沒(méi)有產(chǎn)品管理。乃至很多的軟件將產(chǎn)品和項(xiàng)目混為一談。在禪道中，項(xiàng)目是一個(gè)動(dòng)態(tài)實(shí)施的過(guò)程，項(xiàng)目的產(chǎn)出是可以交付的產(chǎn)品。在禪道中，所有的一切都是圍繞產(chǎn)品展開(kāi)的。產(chǎn)品管理的核心是需求。在scrum里面，簡(jiǎn)化為story(用戶故事)。即像講故事一樣來(lái)描述一個(gè)需求。添加產(chǎn)品維護(hù)產(chǎn)品模塊產(chǎn)品模塊就像一棵樹(shù)，用來(lái)組織需求。提示添加需求(1)添加需求(2)添加需求的時(shí)候，應(yīng)該選擇對(duì)應(yīng)的模塊。如果有產(chǎn)品計(jì)劃，可以選擇相應(yīng)的計(jì)劃。默認(rèn)剛剛添加的需求為草稿，需要進(jìn)行評(píng)審。如果團(tuán)隊(duì)中不需要走評(píng)審流程，可以將“不需要評(píng)審”選上。需求可以上傳附件。需求詳情通過(guò)需求詳情頁(yè)面可以看到需求的所有信息，以及歷次的修改記錄。提示需求處理流程(1)需求有一個(gè)狀態(tài)(status)字段，總共有四種狀態(tài)，分別是草稿(draft)、激活(active)、已變更(changed)和已關(guān)閉(closed)。對(duì)應(yīng)為需求的流程操作共有：創(chuàng)建、變更、審核、關(guān)閉、激活。需求還有一個(gè)階段(stage)字段，用來(lái)描述激活的需求在研發(fā)過(guò)程中所處的階段。目前總共有等待、已計(jì)劃、已立項(xiàng)、開(kāi)發(fā)中、開(kāi)發(fā)完畢、測(cè)試中、測(cè)試完畢、已驗(yàn)收、已發(fā)布。需求的處理流程(2)變更需求審核關(guān)閉通過(guò)撤銷否？新增需求審核立項(xiàng)開(kāi)發(fā)測(cè)試驗(yàn)收發(fā)布通過(guò)拒絕否？拒絕，給出拒絕原因，關(guān)閉有待明確項(xiàng)目團(tuán)隊(duì)確認(rèn)變更任務(wù)、用例關(guān)閉繼續(xù)原來(lái)的研發(fā)過(guò)程有待明確驗(yàn)收發(fā)布需求所經(jīng)歷的各個(gè)階段未通過(guò)未通過(guò)添加計(jì)劃(plan)凡事預(yù)則立。計(jì)劃可以幫助產(chǎn)品人員宏觀把握產(chǎn)品，做到心中有數(shù)。提示為計(jì)劃關(guān)聯(lián)需求發(fā)布(release)路線圖計(jì)劃、發(fā)布、build和路線圖計(jì)劃主要是給產(chǎn)品人員規(guī)劃需求使用。它和實(shí)際的項(xiàng)目沒(méi)有直接的對(duì)應(yīng)關(guān)系。一個(gè)項(xiàng)目中做的需求可能和計(jì)劃完全一樣，也有可能涉及多個(gè)計(jì)劃。build是在項(xiàng)目過(guò)程中產(chǎn)生的，主要用來(lái)測(cè)試使用。build是對(duì)內(nèi)的。經(jīng)過(guò)若干項(xiàng)目之后，產(chǎn)品人員可以選擇發(fā)布一個(gè)版本，發(fā)布是對(duì)外的。而且發(fā)布肯定和一個(gè)build對(duì)應(yīng)。已經(jīng)發(fā)布的版本加上未來(lái)的plan，構(gòu)成產(chǎn)品的路線圖。項(xiàng)目管理添加項(xiàng)目組建團(tuán)隊(duì)關(guān)聯(lián)產(chǎn)品、需求分解任務(wù)工時(shí)管理燃燒圖build添加項(xiàng)目項(xiàng)目代號(hào)和團(tuán)隊(duì)名稱應(yīng)用團(tuán)隊(duì)自由設(shè)置，體現(xiàn)自主管理。提示組建團(tuán)隊(duì)每個(gè)人在項(xiàng)目中的角色可以自由設(shè)定，工時(shí)一般都應(yīng)小于8，因?yàn)榛旧厦總€(gè)人每天都需要處理一些其他事情。提示關(guān)聯(lián)產(chǎn)品一個(gè)項(xiàng)目可以關(guān)聯(lián)多個(gè)產(chǎn)品，禪道系統(tǒng)中，支持項(xiàng)目和產(chǎn)品之間的矩陣關(guān)系。提示關(guān)聯(lián)需求關(guān)聯(lián)需求的過(guò)程，是對(duì)產(chǎn)品中的需求列表進(jìn)行排序的過(guò)程，也是項(xiàng)目團(tuán)隊(duì)達(dá)成契約的過(guò)程。項(xiàng)目中的需求列表是產(chǎn)品視圖中的需求列表的子集。提示分解任務(wù)分解任務(wù)時(shí)，可以設(shè)置任務(wù)的類型，比如是設(shè)計(jì)，還是開(kāi)發(fā)。任務(wù)也可以不用關(guān)聯(lián)需求。任務(wù)需要給一個(gè)估計(jì)值。提示工時(shí)管理項(xiàng)目中每一個(gè)成員每天都應(yīng)該更新自己負(fù)責(zé)的任務(wù)的預(yù)計(jì)剩余時(shí)間。提示燃燒圖(burningdown)系統(tǒng)通過(guò)定時(shí)任務(wù)，自動(dòng)計(jì)算項(xiàng)目中所有未完任務(wù)預(yù)計(jì)剩余時(shí)間之和，畫出曲線圖。燃燒圖可以告訴我們很多東西。提示Buildbuild管理對(duì)于開(kāi)發(fā)來(lái)講是很重要的，它屬于scm的范疇。在禪道中，暫時(shí)將其簡(jiǎn)化。在項(xiàng)目開(kāi)發(fā)過(guò)程中，如果有若干功能已經(jīng)開(kāi)發(fā)完畢，需要提交測(cè)試，這是應(yīng)當(dāng)創(chuàng)建一個(gè)build，然后提交給QA進(jìn)行測(cè)試。后續(xù)的bug管理和測(cè)試任務(wù)管理都應(yīng)當(dāng)基于一個(gè)build展開(kāi)的。源代碼地址可以給出svn的存儲(chǔ)路徑或者其他版本控制系統(tǒng)的路徑。如果沒(méi)有源代碼地址，需要給出build包的存儲(chǔ)地址。提示質(zhì)量管理測(cè)試用例管理測(cè)試用例模塊添加測(cè)試用例測(cè)試用例詳情測(cè)試任務(wù)管理創(chuàng)建測(cè)試任務(wù)管理用例執(zhí)行用例查看結(jié)果創(chuàng)建BugBug管理Bug處理流程創(chuàng)建bug解決bug關(guān)閉bug激活bug編輯bug測(cè)試用例模塊測(cè)試用例有自己?jiǎn)为?dú)的模塊劃分，獨(dú)立于產(chǎn)品視圖中的模塊劃分。為什么獨(dú)立開(kāi)，是因?yàn)槭褂媒嵌炔煌?，產(chǎn)品視圖中的模塊是給產(chǎn)品人員使用的，而測(cè)試用例模塊是為了維護(hù)用例使用的。測(cè)試用例管理(1)當(dāng)項(xiàng)目關(guān)聯(lián)需求之后，QA人員應(yīng)當(dāng)針對(duì)當(dāng)前項(xiàng)目所要開(kāi)發(fā)的需求創(chuàng)建測(cè)試用例。雖然可以不寫測(cè)試用例，直接進(jìn)入bug測(cè)試環(huán)節(jié)，但這樣會(huì)有缺漏。在禪道系統(tǒng)中，測(cè)試用例是分步驟的。測(cè)試用例管理（2）測(cè)試用例詳情創(chuàng)建測(cè)試任務(wù)關(guān)聯(lián)測(cè)試用例執(zhí)行測(cè)試用例(1)執(zhí)行測(cè)試用例(2)用例執(zhí)行結(jié)果創(chuàng)建Bug如果某一次