應(yīng)用禪道進行敏捷軟件開發(fā)過程管理課件

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