敏捷開發(fā)過程.docx

Scrum敏捷開發(fā)過程實戰(zhàn)產(chǎn)品級，大團隊的敏捷實戰(zhàn)方法需求結(jié)構(gòu)化需求描述版本規(guī)劃迭代計劃日?；顒訄F隊建設與傳統(tǒng)灌輸理念的培訓不同，此實戰(zhàn)培訓中不只包含“按客戶價值進行優(yōu)先級排序”“利用自組織團隊發(fā)揮主觀能動性”等含糊的指導性思想，更在每個階段均介紹一種或多種直接可以使用的方法來完成落地。按照實際項目的開發(fā)順序，培訓分為三個環(huán)節(jié)，其主要內(nèi)容如下：l 需求結(jié)構(gòu)化與需求描述（主要受眾為產(chǎn)品負責人Product Owner、團隊骨干）n 將產(chǎn)品愿景轉(zhuǎn)換為可實現(xiàn)的業(yè)務需求；n 將高層業(yè)務需求分解為具備層級結(jié)構(gòu)的需求樹；n 編寫用戶故事，面向用戶使用場景而非產(chǎn)品功能描述單條需求；l 版本規(guī)劃與迭代計劃（主要受眾為產(chǎn)品負責人、Scrum Master，團隊骨干）n 在宏觀層面上，確認整個產(chǎn)品中所有子系統(tǒng)的優(yōu)先級，并將其順序計劃到版本和迭代中；n 在微觀層面上，利用Scrum計劃會估算每個迭代中任務的工作量；l 日?；顒优c團隊建設（主要受眾為Scrum Master，團隊成員）n 日?；顒又?，利用每日立會、故事板、看板跟進開發(fā)進度；n 團隊建設中，利用自組織團隊、松結(jié)對編程等方法建立師徒制度，在實際工作中培養(yǎng)隊員；n 在大型、跨職能團隊研發(fā)時的團隊結(jié)構(gòu)與工作方式l 附：敏捷設計與工程實踐（僅出現(xiàn)于3天培訓中，主要受眾為團隊成員及技術(shù)管理者）n 如果從用戶故事經(jīng)過簡單設計得到代碼結(jié)構(gòu)n 如何利用用戶故事來產(chǎn)生、管理測試用例n 如何利用用戶故事來管理變更、缺陷和客戶反饋課程將圍繞每個小組實際工作中各自產(chǎn)品或項目的自身需求展開，通過對其進行結(jié)構(gòu)化、用戶故事化、用戶建模、模擬計劃會估算、設定驗收標準等，從而演練Scrum各個環(huán)節(jié)所需的技能。知識及案例講解約占70%，實際練習約占30%。注：本大綱中以一個易于理解的電子商務系統(tǒng)的研發(fā)為例，實際應用時可應用于銀行、電信、政府、電子商務、互聯(lián)網(wǎng)社區(qū)娛樂、儀器儀表等各種主流行業(yè)。第一天0 概述本階段培訓通過簡短介紹，讓學員大致了解敏捷開發(fā)的歷史及其嘗試解決的問題。l 敏捷開發(fā)嘗試解決的問題l Scrum及其歷史n 產(chǎn)品負責人 Product Ownern 產(chǎn)品負責人團隊n 產(chǎn)品負責人的職責現(xiàn)場演練：分組并推選Product Owner1 第一階段：需求結(jié)構(gòu)化與需求描述本階段培訓旨在從頭到尾打通需求，即從感性的產(chǎn)品愿景分解到可供開發(fā)的具體需求條目。傳統(tǒng)敏捷開發(fā)使用“條目化”的方法來表達需求。但具體分解和描述需求的方法停留在“每個故事交付一個客戶價值”“從客戶價值角度描述需求”等非常含糊、難以落地的層面上。這導致分析所得的需求個體差別很大，難以作為大型、長期產(chǎn)品研發(fā)的正式工程文檔。本課程引入了QUML作為分界用戶故事的基礎，通過三層需求完成從產(chǎn)品愿景到可開發(fā)任務的分解：*配圖中的三層分解流程見下文分步描述。三層需求分別為業(yè)務愿景（左上圖），業(yè)務操作（左下圖中的方框，即史詩故事），業(yè)務數(shù)據(jù)（右側(cè)三張圖中的橢圓，即用戶故事）。這就解決了傳統(tǒng)敏捷開發(fā)中存在的以下問題：1. 最初的產(chǎn)品愿景與割裂的用戶故事之間缺少必然聯(lián)系2. 大量用戶故事之間缺少清晰的結(jié)構(gòu)3. 用戶故事顆粒度大小不一此外，這種體系下建立起來的“用戶故事樹”（需求樹）還能：1. 直接分配到開發(fā)任務中2. 直接生成代碼結(jié)構(gòu)3. 直接用于結(jié)構(gòu)化管理變更、增強、重構(gòu)、缺陷等4. 直接與測試用例匹配而為一人年的工作量進行這種需求分析，只需要1小時左右。1.1 第一步：業(yè)務愿景利用“角色-業(yè)務圖”來支撐產(chǎn)品愿景愿景（Vision）是用戶對產(chǎn)品的核心期望。培訓中使用“角色-業(yè)務圖”（簡稱RB圖）來表達和落實愿景。比如在配圖中：“購物子系統(tǒng)”核心愿景是“建立一種有保障的網(wǎng)上購物方式”；圖中使用“確認收貨-轉(zhuǎn)賬”的第三方監(jiān)管業(yè)務實現(xiàn)。這樣軟件開發(fā)人員就能得到確切的技術(shù)方案，而不是面對描述非常虛的愿景；而技術(shù)方案實現(xiàn)后，又能支撐愿景。有了愿景，產(chǎn)品就不會簡單停留在“能用”的狀態(tài)，而是要積極增加可以實現(xiàn)愿景的功能。現(xiàn)場演練與指導：建立角色業(yè)務圖（20分鐘）案例分享：RB圖詳細規(guī)則與最佳實踐1.2 第二步：業(yè)務數(shù)據(jù)利用“實體-關系圖”發(fā)掘業(yè)務數(shù)據(jù)此內(nèi)容將客戶愿景轉(zhuǎn)化為“對某些的業(yè)務數(shù)據(jù)的操作”，從而逐漸進入開發(fā)人員可理解的范疇；同時業(yè)務數(shù)據(jù)還是早期功能點估算的核心元素。具體分析工具是實體-關系圖（簡稱ER圖），而業(yè)務數(shù)據(jù)對應其中的實體（圖中方框）。實體-關系圖（教學過程中進行了簡化）中分析了實體及其依賴關系，通過適當定義，不但可以保障不會遺漏實體，甚至能直接協(xié)助進行早期估算和部分設計工作。重要！在敏捷開發(fā)中，我們將業(yè)務數(shù)據(jù)作為史詩故事進行開發(fā)。比如在配圖中，所有實體（5個矩形）均包含一組“增刪改查”或類似的操作（就是第三步中的用戶故事），由此可知此圖包含人天左右的工作量張數(shù)據(jù)庫主表和張關系表組增刪改查操作頁面?，F(xiàn)場演練與指導：建立實體關系圖（30分鐘）案例分享：ER圖詳細規(guī)則與最佳實踐1.3 第三步：業(yè)務操作利用“用例-流程圖”分析業(yè)務操作借助精益需求建模方法（“用例-流程圖”，一種由User Case和狀態(tài)圖結(jié)合演進產(chǎn)生的新圖形，簡稱UCF圖），找到一個最小的、完備的業(yè)務操作集合，作為一次交付所能發(fā)布的最新功能集合。在精益開發(fā)中，這個集合稱之為MVP， Minimum Viable Product最小可用產(chǎn)品。用例-流程圖的“一致性”非常好，即兩個不同的分析人員針對同一需求的分析結(jié)果，無論用例的數(shù)量、名稱、乃至排列順序都驚人地相似。重要！在敏捷開發(fā)中，我們將業(yè)務操作作為用戶故事。右圖是QUML中的“增查查改刪”模板中，通過將需求分解為增加-查看所有-查看單個-修改-刪除五層，并將不同角色執(zhí)行的操作放在其正下方（共有操作放在中間），需求分析人員可以迅速而無遺漏地獲得所有用戶故事。同時，圖中由業(yè)務邏輯連接的各個業(yè)務操作（即橢圓形區(qū)域）形成一個MVP，多一個操作則是多余的，少一個則不能完整交付。這對于每個迭代能持續(xù)交付至關重要?，F(xiàn)場演練與指導：建立用例流程圖（60分鐘）案例分享：UCF圖詳細規(guī)則與最佳實踐1.4 第四步：需求樹建立結(jié)構(gòu)化的需求傳統(tǒng)用戶故事組織方法均呈現(xiàn)“列表結(jié)構(gòu)”，在用戶故事數(shù)量龐大時（注：每人年大約能完成用戶故事50個，外加子故事50200個），很難看到整個需求的全貌。培訓中，會借助業(yè)務愿景-業(yè)務數(shù)據(jù)-業(yè)務操作的層次，對需求條目進行結(jié)構(gòu)化表達，形成一棵有層次的需求樹。如圖，看似是一個很普通的“增刪改查表”，但圖中的第二至四級目錄實際上來自于之前的業(yè)務愿景-業(yè)務數(shù)據(jù)-業(yè)務操作。這樣就很容易從之前的圖形化需求形成樹形的需求樹，其不同層次對應不同尺度的用戶故事。注：很多業(yè)界的敏捷開發(fā)工具如Jira都引入了層次化用戶故事，但均沒有提供層次定義和可操作的分解方法。本培訓采用Word作為演示工具，也可對應到具體工具中。第二天1.5 第五步：用戶故事面向用戶價值的需求描述方式很多軟件雖然交付了功能，卻不是客戶想要的。比如，微博這類的大型系統(tǒng)的管理員，是否會有一個“查看所有用戶”這樣的功能來管理幾億個用戶？如果沒有，他怎么知道有哪些用戶？如果有，如何避免海量用戶造成的信息爆炸？敏捷開發(fā)引入了一種面向客戶價值而非產(chǎn)品功能的需求描述方式，將功能放在具體的使用環(huán)境中討論，從而能為客戶制作出符合其價值的產(chǎn)品。 現(xiàn)場演練與指導：編寫自己的用戶故事（30分鐘）案例分享：文字游戲還是價值挖掘挖掘1.6 第六步：用戶建模購買決策者/主要使用者“今年過節(jié)不收禮，收禮就收腦白金”。盡管多數(shù)收禮者（主要使用者）并不知道腦白金到底包含何種成分，服用后到底有哪些好處，但是確有無數(shù)的送禮者（購買決策者）選擇購買。本內(nèi)容介紹如何區(qū)分購買決策者和主要使用者，并面向核心用戶編寫用戶故事?，F(xiàn)場演練與指導：建立自己的用戶模型（30分鐘）案例分享：一款年收入12億元的網(wǎng)絡游戲?qū)Α八杏脩簟钡睦斫? 第二階段：版本規(guī)劃與迭代計劃本階段以第一階段生成的各層次用戶故事為輸入，進行宏觀的版本規(guī)劃和微觀的迭代計劃。傳統(tǒng)敏捷開發(fā)缺少版本規(guī)劃的具體實施方法，“按客戶價值優(yōu)先級進行排序”聽起來有道理但卻難以實施。尤其是在初期無法獲得全部用戶故事的情況下，優(yōu)先級排序非常困難。本培訓中的方法可以：1. 在開發(fā)的初期即可提供顆粒度可控的高層需求（史詩故事）進行排序；2. 產(chǎn)品經(jīng)理根據(jù)業(yè)界統(tǒng)計數(shù)據(jù)即可進行版本規(guī)劃；3. 在版本規(guī)劃的同時自動完成工作量規(guī)劃，從而準確安排迭代的數(shù)量；在每個迭代的計劃會上通過“敏捷撲克估算”，借助集體智慧解決個體問題：1. 迅速找到最快的解決辦法；2. 發(fā)現(xiàn)高手與新手的差距，并通過討論彌補差距；3. 以10分鐘代價提前發(fā)現(xiàn)上千行代碼的浪費；2.1 第一步：版本規(guī)劃項目早期的量化分層規(guī)劃方法版本規(guī)劃涉及到立項時的戰(zhàn)略性規(guī)劃、迭代間的發(fā)布規(guī)劃、隨時可能發(fā)生的產(chǎn)品升級規(guī)劃等不同層次。培訓中會建立三級規(guī)劃方法與之對應，分別是業(yè)務愿景規(guī)劃、業(yè)務數(shù)據(jù)規(guī)劃和業(yè)務操作規(guī)劃。由于業(yè)務數(shù)據(jù)的定義兼容FPA（功能點分析）中ILF（內(nèi)部邏輯文件）的定義，因此每個業(yè)務數(shù)據(jù)無需知道細節(jié)即可按業(yè)界數(shù)據(jù)2人月計算（精確數(shù)值為35人天）。配圖中展示了一個電商網(wǎng)站不同階段規(guī)劃的情況。左側(cè)業(yè)務愿景每個對應420人月規(guī)模的需求；中間業(yè)務數(shù)據(jù)級別每個對應2人月規(guī)模的需求；右上角黑體字則是業(yè)務操作，每個對應45人天規(guī)模。2.2 第二步：迭代規(guī)劃若一個版本需要在三個迭代后才能完成，那么每個迭代應該完成哪些功能？本培訓中引入了精益創(chuàng)業(yè)（Lean Start-up）中MVP（最小可用產(chǎn)品）的概念，介紹如何聚焦于最少的工作量完成一個可以供用戶使用并提交反饋的產(chǎn)品。在完成迭代規(guī)劃后，產(chǎn)品經(jīng)理就得到了一個意向性的迭代列表，以及每個迭代中的需求分布情況。接下來在每個迭代開始第一天，需要召開計劃會議對詳細需求進行講解和估算。2.3 第三步：迭代計劃會本階段通過講解計劃會的完整過程及背后的思想，并通過實際練習，對之前需求分析階段獲得的用戶故事進行估算。詳細內(nèi)容包括：豬與雞的故事敏捷計劃會背后的分權(quán)思想如何通過放權(quán)提升開發(fā)人員個體的積極性。產(chǎn)品經(jīng)理如何講解故事如何從大到小、從整體到局部、從背景到功能地分層講解用戶故事；如何在客戶環(huán)境中理解需求。開發(fā)人員撲克估算如何讓團隊成員說出真實的估算值；如何讓高手在估算時就能幫助新手；如何通過估算來澄清需求。講師在從事開發(fā)時，曾將已經(jīng)完成的、多達4000行代碼壓縮為55行代碼。在實施敏捷估算后，在計劃會即可避免這種浪費，而無需等待編碼實際結(jié)束后才發(fā)現(xiàn)。小游戲：世界（保密內(nèi)容）有多高？（演示估算撲克的使用方法，10分鐘）現(xiàn)場演練：我的故事要多少工作量？（使用客戶內(nèi)部開發(fā)需求，15分鐘）第三天3 第三階段：敏捷日常工作本階段的核心內(nèi)容是如何在順利在迭代期內(nèi)跟蹤項目進展。此階段培訓將涉及到傳統(tǒng)的每日立會燃盡圖、故事板等工具，但同時也會介紹多家公司根據(jù)自身情況對敏捷開發(fā)活動的改良；3.1 日常活動第一步：每日立會與敏捷生態(tài)系統(tǒng)無數(shù)敏捷團隊因為每日立會簡單易行而將其作為第一個推廣的敏捷活動；無數(shù)敏捷團隊也在無奈中親自見證了這個簡單易行的會議最后如何變得死氣沉沉，不得不依靠“遲到罰款箱”來維持。培訓中將介紹每日立會乃至所有敏捷開發(fā)活動背后的運行原理：敏捷生態(tài)系統(tǒng)?？此茻o關的敏捷實踐與團隊模型之間其實存在著隱形的聯(lián)系。3.2 日?；顒拥诙剑嚎窗蹇窗迨且粋€通過將所有迭代內(nèi)工作分為“待開發(fā)”“開發(fā)中”“開發(fā)完畢”三個狀態(tài)來進行任務可視化管理的工具。不過，看似簡單的看板和燃盡圖也有很多背后的故事。本階段培訓后，學員會發(fā)現(xiàn)除了簡單地“透明化”之外，看板還能用來確保產(chǎn)品按時發(fā)布、防止任務堆積、風險前移等。啟發(fā)式演練：如何按需改進看板？3.3 日?；顒拥谌剑喝急M圖燃盡圖不僅是項目進度的儀表盤，還是分析項目問題的利器。在這個環(huán)節(jié)，學員們需要動用十八般武器從第一天到最后一天培訓的所有內(nèi)容才能分析并馴服失控的燃盡圖?，F(xiàn)場演練：分析失控的燃盡圖3.4 高級敏捷實踐介紹實際企業(yè)在推廣敏捷時所作的改進。包括：l NEC的預估會與預評審會制度l 金山的漸進式評審與跟進人制度l DSDM方法中的MoSCoW方法l 當前流行的看板開發(fā)l 面向MVP與持續(xù)交付的的可變周期開發(fā)3.5 場景演練：迭代計劃+每日立會+任務分配策略實踐此1小時的練習環(huán)節(jié)模擬一個4輪的迭代，演示：l 迭代計劃，優(yōu)先級排序：“必須完成/盡可能完成的工作”l 每日立會，團隊協(xié)作，燃盡圖：項目進展控制l 變更管理：在發(fā)生意外時如何選擇最佳結(jié)果注：此演練僅限于人數(shù)低于40人、有充足活動空間的公開課或企業(yè)內(nèi)訓。4 第四階段：自組織團隊建設本階段的核心內(nèi)容是如何把一個普通團隊，打造為跨職能、自組織的敏捷團隊，并在建設團隊的同時培養(yǎng)個人。很多團隊在實施敏捷時采取了“極端敏捷主義團隊”，比如團隊個體自行估算和領取任務、任何人不過問其他人的工作（為了充分“放權(quán)”）這種聽起來很“敏捷”的團隊卻存在以下問題：1. 個體能力差異很大，完成任務的工期、質(zhì)量可相差10倍以上；2. 新手得不到指導，長期無法提高（與之前各自為戰(zhàn)的游擊隊沒有區(qū)別）此階段培訓還將涉及以下內(nèi)容：1. 大型敏捷開發(fā)團隊的結(jié)構(gòu)；2. 敏捷開發(fā)績效管理從團隊考核到個人考核；4.1 團隊建設第一步：自組織團隊原理與同行壓力團隊認為10個月才能完成的項目，被領導攔腰砍成5個月。領導剛剛離開會議室，隊員們哈哈大笑：原來他們早就知道進度會被腰斬，所以提前多估了一倍！為了提高生產(chǎn)率，公司加強了績效管理：凡是延期交付的項目全部會被扣獎金！于是，所有團隊都為自己的項目預留了100%的額外時間結(jié)果是：一年后，公司除了生產(chǎn)率下降一半之外，什么都沒有得到。領導壓力似乎總是失效，那么到底是什么在驅(qū)動敏捷團隊呢？本內(nèi)容會介紹神秘的“同行壓力”是如何在計劃會、每日立會上驅(qū)動團隊努力前行的。4.2 團隊建設第二步：項目經(jīng)理轉(zhuǎn)型敏捷開發(fā)來了，項目經(jīng)理該怎么辦？很多公司嘗試廢棄項目經(jīng)理，啟用Scrum Master，這反而令原來的項目經(jīng)理成為推廣敏捷的阻力。培訓中會介紹項目經(jīng)理應該如何升級為PM2.0，從而成為符合敏捷開發(fā)原則的項目領導者。4.3 團隊建設第三步：1-3-9團隊大型團隊的敏捷方案當團隊超過10人時，眾多敏捷開發(fā)中未曾想到的問題就浮出了水面。越來越難以實現(xiàn)眾多人員之間的“跨職能”，甚至在純軟環(huán)境中分工也越來越難以打破；高手總是認為自己很忙，因而提供幫助的應該是別人；計劃會上越來越多的人開始棄權(quán)，因為只有個別人感覺自己是潛在的任務執(zhí)行者1-3-9團隊創(chuàng)造了一種大團隊分組的方法，即通過產(chǎn)品需求樹將團隊分解為多個Feature Team，獨立運行敏捷開發(fā)，從而降低了團隊的規(guī)模。4.4 團隊建設第四步：松結(jié)對編程項目中的頂尖高手應該做什么？各自為戰(zhàn)？安排攻堅？在敏捷開發(fā)“團隊協(xié)作”的語境中如何使用高手？如果他們?yōu)樾率痔峁椭?，如何保證其自身的生產(chǎn)力不會降低？“松結(jié)對編程”提供了一種有別于兩個人同時編程的“結(jié)對編程”。具體實踐包括：高手與新手一起估算任務，在發(fā)現(xiàn)由能力造成的工作量分歧后，約定某個時間點高手協(xié)助新手，以極短的時間解決新手遇到的困難；每天執(zhí)行代碼審查，確保每一行代碼的質(zhì)量。4.5 團隊建設第五步：代碼審查與編碼規(guī)范如何才能做到“只要高手能避免的缺陷，其他人也一樣能避免”？在“松結(jié)對編程”中一個重要工作是代碼審查，目的是令高手每天都有機會協(xié)助新手改善編碼質(zhì)量。高手同時將各種避免缺陷的方法總結(jié)為編碼規(guī)范。這種“避免缺陷”的規(guī)范遠比“編碼整潔”的規(guī)范更受歡迎。本課程的講師為超過1000人的大型研發(fā)企業(yè)編寫過編碼規(guī)范，并總結(jié)出7條代碼審查最佳實踐。5 附：敏捷設計與開發(fā)工程實踐注：本內(nèi)容僅出現(xiàn)在3天課程、敏捷咨詢咨詢、敏捷CMMI咨詢等場景中。本階段旨在依據(jù)之前的需求模型，通過極輕量級的設計，即轉(zhuǎn)化為代碼結(jié)構(gòu)，從而完成從用戶愿景到代碼、測試的完整過程。此環(huán)節(jié)需要結(jié)合 mvc或java struts/spring mvc框架。從實現(xiàn)功能性需求的角度看，設計有兩個主要目的：1. 作為從需求到代碼的橋梁；2. 以更少的代碼完成更多的需求。然而傳統(tǒng)設計過程缺少一個步驟化的、一致性的設計方法。不設計，新手無法完成高質(zhì)量的代碼；設計，在代碼完成之后幾乎沒有人再去看設計文檔。此章介紹如何使用QUML從需求文檔直接產(chǎn)生代碼。第一，從QUML已有的RB圖、ER圖、UCL圖，可以迅速得到MVC架構(gòu)中的Area、Controller和Action，無需任何額外的設計環(huán)節(jié)；第二，配合QUML中的VCMD代碼分層原理，一個Action中的代碼會自動被分解到View、Controller、Model、Data四個層次中，即使是初學者也可以掌握。5.1 第一步：從RB/ER/UCL圖到Area/Controller/Action（1小時）MVC架構(gòu)除了能更好地實現(xiàn)代碼分層外，Controller/Action結(jié)構(gòu)還能很好地與樹狀結(jié)構(gòu)的需求進行分層對應。在同時應用QUML和MVC時有如下對應關系：l 子系統(tǒng)=Areal 業(yè)務數(shù)據(jù)=Controllerl 業(yè)務操作=Action 經(jīng)過這種對應關系之后，只要拿到前文提到的需求樹，MVC中的所有Area/Controller/Action均被唯一地確定下來，其數(shù)量、名稱、順序幾乎不會發(fā)生變化。除了節(jié)省大量設計時間之外，這種做法還使得需求與代碼建立了意義對應關系，為今后的需求變更貫穿打下了基礎。如右圖，從代碼結(jié)構(gòu)中即可看出它實現(xiàn)了“商鋪管理子系統(tǒng)”（Stores）中的業(yè)務數(shù)據(jù)“建店申請”（StoreApplications）的“創(chuàng)建（Create）”到“批準（Approve）”的所有業(yè)務操作。案例分析：電商系統(tǒng)的MVC代碼結(jié)構(gòu)5.2 第二步：VCMD代碼結(jié)構(gòu)（1小時）QUML將MVC的代碼擴展為四層結(jié)構(gòu)：l View，僅包含頁面布局代碼l Controller，僅包含業(yè)務控制代碼（做什么）l Model，僅包含業(yè)務邏輯代碼（怎么做）l Data，僅包含數(shù)據(jù)訪問代碼有了這種四層代碼規(guī)范后，一個方法中的大約200行代碼將被分解到至少四個文件中，平均每個僅包含50行代碼，從而達到分層設計的目的。通過3.1中的Area/Controller/Action切分和3.2中的V