【正文】 工件、5個(gè)活動(dòng)、5個(gè)價(jià)值3個(gè)角色1. 產(chǎn)品負(fù)責(zé)人（Product Owner）2. Scrum Master3. Scrum團(tuán)隊(duì)3個(gè)工件1. 產(chǎn)品Backlog（Product Backlog）2. SprintBacklog3. 燃盡圖（Burndown Chart)5個(gè)活動(dòng)1. Sprint計(jì)劃會(huì)議（Sprint Planning Meeting）2. 每日站會(huì)（Daily Scrum Meeting）3. Sprint評審會(huì)議（Sprint Review Meeting）4. Sprint回顧會(huì)議（Sprint Retrospective Meeting）5. 產(chǎn)品Backlog梳理會(huì)議（ Product Backlog Refinement）5個(gè)價(jià)值1. 承諾 – 愿意對目標(biāo)做出承諾2. 專注– 把你的心思和能力都用到你承諾的工作上去3. 開放– Scrum 把項(xiàng)目中的一切開放給每個(gè)人看4. 尊重– 每個(gè)人都有他獨(dú)特的背景和經(jīng)驗(yàn)5. 勇氣– 有勇氣做出承諾，履行承諾，接受別人的尊重SCRUM理論基礎(chǔ)Scrum以經(jīng)驗(yàn)性過程控制理論（經(jīng)驗(yàn)主義）做為理論基礎(chǔ)的過程。在確定檢驗(yàn)頻率時(shí)，需要考慮到檢驗(yàn)會(huì)引起所有過程發(fā)生變化。發(fā)布燃盡圖，產(chǎn)品負(fù)責(zé)人做發(fā)布進(jìn)展跟蹤Sprint Planning Meeting: Sprint計(jì)劃會(huì)議Daily Scrum Meeting：每日站會(huì)Sprint Review Meeting：Sprint評審會(huì)議Sprint Retrospective Meeting: Sprint回顧會(huì)議Product Backlog Refinement: 產(chǎn)品待辦列表梳理Product Backlog Item: 產(chǎn)品待辦清單條目，簡稱PBIUser Story: 用戶故事，指一條需求Story Point：衡量用戶故事的工作量大小的計(jì)量單位Velocity: 團(tuán)隊(duì)速度Sprint Task: 實(shí)現(xiàn)一條需求需要做的一個(gè)技術(shù)任務(wù)Definition of Done: DoD，完成的定義Stakeholders： 干系人Backlog： 待辦列表Artifact ：工件Estimation ：估算Collaboration： 協(xié)作Scaling Scrum：大規(guī)模ScrumSCRUM起源Scrum的原始含義Scrum原始含義是指英式橄欖球次要犯規(guī)時(shí)在犯規(guī)地點(diǎn)對陣爭球。受到以上思想的影響，以及對世界范圍內(nèi)軟件項(xiàng)目的研究，Jeff Sutherland在 1993年首次在Easel公司定義了用于了軟件開發(fā)行業(yè)的Scrum流程，并開始實(shí)施。過程控制通常有兩種方式，第一種方式是預(yù)定義的過程，第二種方式是經(jīng)驗(yàn)性過程。比如研究一項(xiàng)新技術(shù)，下一盤棋，踢一場球賽，在過程運(yùn)行當(dāng)中，我們需要通過不斷的獲得真實(shí)的反饋，然后進(jìn)行適應(yīng)和調(diào)整，使得過程能夠產(chǎn)出我們需要的結(jié)果。 第二：檢驗(yàn)（Inspection）開發(fā)過程中的各方面必須做到足夠頻繁地檢驗(yàn)，確保能夠及時(shí)發(fā)現(xiàn)過程中的重大偏差。SCRUM團(tuán)隊(duì)的三個(gè)角色Scrum團(tuán)隊(duì)中包括三個(gè)角色，他們分別是產(chǎn)品負(fù)責(zé)人、開發(fā)團(tuán)隊(duì)和 Scrum Master。實(shí)現(xiàn)這一點(diǎn)的方式會(huì)隨著組 織、Scrum 團(tuán)隊(duì)以及單個(gè)團(tuán)隊(duì)成員的不同而不同。然而,產(chǎn)品負(fù)責(zé)人是 負(fù)責(zé)任者。開發(fā)團(tuán)隊(duì)由組織構(gòu)建并授權(quán),來組織和管理他們的工作。此規(guī)則無一例外。大型團(tuán)隊(duì)會(huì)產(chǎn)生太多復(fù)雜性,不便于經(jīng)驗(yàn)過程管理。 找到有效管理產(chǎn)品代辦事項(xiàng)列表的技巧 移除開發(fā)團(tuán)隊(duì)進(jìn)展過程中的障礙Scrum 中所定義的工件能最大化關(guān)鍵信息的透明性,來保證 Scrum 團(tuán)隊(duì)成功地交付完成的增量。產(chǎn)品待辦事項(xiàng)列表?xiàng)l目包含描述、次序和估算的特征。開發(fā)團(tuán)隊(duì)在接下來的 Sprint 中將要進(jìn)行開發(fā)的產(chǎn)品待辦事項(xiàng)列表?xiàng)l目是細(xì)粒度的,已經(jīng)被分解過,因此,任何 一個(gè)條目在 Sprint 的時(shí)間盒內(nèi)都可以被“完成”。通過產(chǎn)品Backlog地梳理來增添細(xì)節(jié)、估算和排序。開發(fā)團(tuán)隊(duì)負(fù)責(zé)所有的估算工作。我們只關(guān)心剩余工作和日期這兩個(gè)變量。Sprint 代辦事項(xiàng)列表使開發(fā)團(tuán)隊(duì)確定的、達(dá)到 Sprint 目標(biāo)所需的工 作清晰可見。Product Backlog 功能點(diǎn)被放到Sprint的固定周期中，Sprint Backlog 會(huì)因?yàn)槿缦略虬l(fā)生變化:1. 隨著時(shí)間的變化，開發(fā)團(tuán)隊(duì)對于需求有了更好的理解，有可能發(fā)現(xiàn)需要增加一些新的任務(wù)到Sprint Backlog中。我們只關(guān)心剩余工作和日期這兩個(gè)變量。X軸代表的項(xiàng)目周期，以Sprint為單位， Y軸代表的是剩余工作量，通常以用戶故事點(diǎn)、理想人天或者teamdays為單位。 對事項(xiàng)進(jìn)行估算產(chǎn)品待辦事項(xiàng)列表梳理的一個(gè)最大好處是為即將到來的幾個(gè)Sprint做準(zhǔn)備。整個(gè)團(tuán)隊(duì)都要參加Sprint計(jì)劃會(huì)議。為了決定做多少,開發(fā)團(tuán)隊(duì)需要考慮當(dāng)前產(chǎn)品增量的狀態(tài),團(tuán)隊(duì)過去的工作情況,團(tuán)隊(duì)當(dāng)前的生產(chǎn)能力,以及排好序的產(chǎn)品待辦事項(xiàng)列表。之后要完成的工作可以稍?大些,以后再對它 們進(jìn)?行分解。Scrum活動(dòng):每日Scrum會(huì)議開發(fā)團(tuán)隊(duì)是自組織的。每日Scrum既不是向管理層匯報(bào),也不是向產(chǎn)品負(fù)責(zé)?人或者ScrumMaster匯報(bào)。每日Scrum通 常不超過15分鐘。團(tuán)隊(duì)會(huì)找到他們自己的方式來開Sprint評審會(huì)議。Scrum團(tuán)隊(duì)總是在Scrum的框架內(nèi),改進(jìn)他們自己的流程。自組織團(tuán)隊(duì)Scrum團(tuán)隊(duì)是一個(gè)自組織的團(tuán)隊(duì)，傳統(tǒng)的命令與控制式的團(tuán)隊(duì)只有執(zhí)行任務(wù)的權(quán)利，而自組織團(tuán)隊(duì)有權(quán)進(jìn)行設(shè)計(jì)、計(jì)劃和執(zhí)行任務(wù)，自組織團(tuán)隊(duì)還需要自己監(jiān)督和管理他們的工程過程和進(jìn)度，自組織團(tuán)隊(duì)自己決定團(tuán)隊(duì)內(nèi)如何開展工作，決定誰來做什么，即分工協(xié)作的方式。Scrum中的PO就是舵手的角色，他對產(chǎn)品的方向負(fù)責(zé)，對產(chǎn)品的Why和What負(fù)責(zé)，對產(chǎn)品的愿景，產(chǎn)品包括哪些主要的特性負(fù)責(zé)。 每天跟進(jìn)工作進(jìn)展，并對他們的工作做檢查和調(diào)整 2個(gè)披薩的團(tuán)隊(duì)大小（59人）自組織團(tuán)隊(duì)和經(jīng)理領(lǐng)導(dǎo)的團(tuán)隊(duì)的區(qū)別對于經(jīng)理領(lǐng)導(dǎo)的團(tuán)隊(duì)來說，團(tuán)隊(duì)成員被分配任務(wù)，團(tuán)隊(duì)成員只有執(zhí)行任務(wù)的權(quán)利。 團(tuán)隊(duì)監(jiān)督和管理他們的過程和進(jìn)度在自組織團(tuán)隊(duì)的環(huán)境下，管理層關(guān)注在如下幾個(gè)方面： 誤解3：團(tuán)隊(duì)自己設(shè)計(jì)團(tuán)隊(duì)結(jié)構(gòu)； 糾正：管理層決定團(tuán)隊(duì)上下文在一個(gè)大的開發(fā)組織中，Scrum會(huì)把大的開發(fā)團(tuán)隊(duì)劃分成多個(gè)59人的小團(tuán)隊(duì)，那么我們應(yīng)該按照什么方式來劃分呢？在傳統(tǒng)的開發(fā)模式下，我們習(xí)慣于按照系統(tǒng)的架構(gòu)模塊，或者系統(tǒng)分層組織團(tuán)隊(duì)，也有的團(tuán)隊(duì)按照系統(tǒng)需求、開發(fā)、測試結(jié)合系統(tǒng)架構(gòu)混合組織的方式。 以客戶為中心的特性驅(qū)動(dòng) 個(gè)人學(xué)習(xí)和團(tuán)隊(duì)學(xué)習(xí)的機(jī)會(huì)用戶故事什么是用戶故事？用戶故事是從用戶的角度來描述用戶渴望得到的功能?？ㄆ峡赡軙?huì)寫上故事的簡短描述，工作量估算等。用戶故事之間的依賴使得制定計(jì)劃，確定優(yōu)先級，工作量估算都變得很困難。 有價(jià)值（Valuable）— 每個(gè)故事必須對客戶具有價(jià)值（無論是用戶還是購買方）。用戶故事越大，在安排計(jì)劃，工作量估算等方面的風(fēng)險(xiǎn)就會(huì)越大。使用估算撲克來做工作量估算是最有效，也是非常有趣的一種估算方式。關(guān)注Scrum中文網(wǎng)微信公眾號可以獲得微信版估算撲克。我們估算了產(chǎn)品Backlog的故事點(diǎn)總數(shù)，然后又知道了每個(gè)Sprint團(tuán)隊(duì)的平均速度，那么我們就可以推算我們大概需要多少個(gè)Sprint可以做完，這樣我們就得到了周期。Scrum采用迭代增量的方式，是因?yàn)樾枨笫怯楷F(xiàn)的，我們對產(chǎn)品和需求的理解是漸進(jìn)式的，Sprint長度越長，我們需要預(yù)測的越多，復(fù)雜度會(huì)提升、風(fēng)險(xiǎn)也會(huì)增加，所以Sprint的長度最多不超過4周。取消一個(gè) SprintSprint 可以在 Sprint 時(shí)間盒結(jié)束之前取消。所有未完成的條目就都要 放回到產(chǎn)品待辦事項(xiàng)列表中,并重新估算。每日站會(huì)是團(tuán)隊(duì)自己的會(huì)每日站會(huì)是Scrum團(tuán)隊(duì)每天的第一件事情，這樣可以讓每個(gè)人在每天一開始就清楚的了解他一天的安排。為什么每日站會(huì)沒有效果？每日站會(huì)和傳統(tǒng)的項(xiàng)目會(huì)議有如下幾點(diǎn)不同：1. 任何團(tuán)隊(duì)之外的人不得發(fā)言或干擾會(huì)議。 每日站會(huì)都會(huì)在15分鐘以內(nèi)完成。 站會(huì)結(jié)束后，ScrumMaster知道哪些問題需要幫助團(tuán)隊(duì)成員解決。這個(gè)定義也同時(shí)被用來指導(dǎo)開發(fā)團(tuán)隊(duì)了解在 Sprint 計(jì)劃會(huì)議的時(shí)候他們能選擇多少 產(chǎn)品代辦事項(xiàng)列表?xiàng)l目。如果你愿意把你的角色限制在組織會(huì)議，控制時(shí)間盒以及處理團(tuán)隊(duì)成員提出的障礙的話，你可以將這個(gè)角色當(dāng)作成兼職來對待。 你可以通過幫助Product Owner維護(hù)產(chǎn)品待辦事列表和發(fā)布計(jì)劃來提高他的效率。 需求（特別是在產(chǎn)品待辦事列表最頂端的需求）能夠以獨(dú)立的、有價(jià)值的、可協(xié)商的、可估計(jì)的、可測試的小粒度用戶展現(xiàn)出來嗎？ 你有曾經(jīng)幫助過Product Owner整理待辦事列表項(xiàng)目，然后分配到不同的版本中去嗎？ 團(tuán)隊(duì)成員之間會(huì)以高標(biāo)準(zhǔn)要求對方嗎？會(huì)互相挑戰(zhàn)來促進(jìn)成長嗎？ 團(tuán)隊(duì)有保持更新任務(wù)版嗎？重構(gòu)需要在每個(gè)小時(shí)內(nèi)進(jìn)行多次，每當(dāng)有重復(fù)代碼，復(fù)雜的條件邏輯（通常表現(xiàn)為過量的縮進(jìn)和冗長的方法），糟糕的命名，對象間的過度耦合，一個(gè)對象的職責(zé)過多等等問題出現(xiàn)的時(shí)候就需要進(jìn)行重構(gòu)。所以，比較推薦的做法是和團(tuán)隊(duì)成員先討論以選擇在一周內(nèi)大家愿意嘗試使用結(jié)對編程的時(shí)間，而不是從一開始就強(qiáng)迫團(tuán)隊(duì)使用結(jié)對編程。 你的公司的職業(yè)發(fā)展道路和你的團(tuán)隊(duì)的集體目標(biāo)相符嗎？如果以測試、自動(dòng)化測試或者開發(fā)文檔為代價(jià)來鼓勵(lì)編程或者設(shè)計(jì)架構(gòu)，那么答案就是否定的。 你能夠幫助公司成為一個(gè)學(xué)習(xí)型企業(yè)嗎？整個(gè)公司的做得怎么樣？測試覆蓋率的漏洞和推遲的重構(gòu)被稱作技術(shù)債務(wù)。 團(tuán)隊(duì)在開發(fā)系統(tǒng)功能測試和單元測試的時(shí)候使用的是同一種語言嗎（而不是使用團(tuán)隊(duì)里只有部分成員懂的腳本語言）？這個(gè)是可能的。 團(tuán)隊(duì)成員都能夠自己領(lǐng)取任務(wù)嗎？ Product Owner有根據(jù)上次Sprint評審會(huì)議來調(diào)整發(fā)布計(jì)劃嗎？通常Product Owner應(yīng)該至少在個(gè)Sprint之后調(diào)整發(fā)布計(jì)劃，一般來說會(huì)把一些工作放到后面的版本中，原因是發(fā)現(xiàn)了一些更重要的工作要做。）但是如果你展望團(tuán)隊(duì)能夠做到你之前無法想象的事情的時(shí)候，你就成為了一位出色的ScrumMaster。開發(fā)團(tuán)隊(duì)在每個(gè) Sprint 交付產(chǎn)品功能增量。午飯之后會(huì)有另外一個(gè)階段的活躍討論，當(dāng)下班前慢慢的安靜下來。4.3. ScrumMaster不會(huì)逐個(gè)的問每個(gè)人問題，如果是，那么這個(gè)會(huì)議已經(jīng)淪為了報(bào)告會(huì)。如果每日站會(huì)沒有效果，檢查一下這些規(guī)則：你是不是每天在認(rèn)真開每日站會(huì)？如果不是為什么？如果你改變了Scrum的一些基本的規(guī)則，你可能會(huì)面臨一些風(fēng)險(xiǎn)，因?yàn)檫@些規(guī)則都是經(jīng)過錘煉和項(xiàng)目考驗(yàn)的一些通用規(guī)則。4. 團(tuán)隊(duì)成員不是向ScrumMaster匯報(bào)情況，每日站會(huì)是團(tuán)隊(duì)自己的會(huì)。 每日站會(huì)的紀(jì)律會(huì)議時(shí)間最多不超過15分鐘。 團(tuán)隊(duì)溝通狀態(tài)，了解現(xiàn)狀，發(fā)現(xiàn)障礙取消 Sprint 會(huì)消耗資源,因?yàn)槊總€(gè)人都需要在新召開的 Sprint 計(jì)劃會(huì)議中重新開始 另一個(gè) Sprint。如果某個(gè) Sprint 的目標(biāo)過時(shí)了,那么就需要取消該 Sprint。在Sprint進(jìn)行過程中，如下內(nèi)容不能發(fā)生變化：一個(gè)Sprint是指一個(gè)1周－4周的迭代，它是一個(gè)時(shí)間盒。如果我們要估算從家到公司的絕對距離時(shí)多少公里，您可能不一定知道，但是如果您時(shí)做地鐵上班，從家里到公司有多少站，你一定很容易知道，當(dāng)我們知道有多少站之后，我們就可以大概清楚路上需要花多長時(shí)間了。估算撲克的使用方法： 可測試性（Testable）—一個(gè)用戶故事要是可以測試的，以便于確認(rèn)它是可以完成的。一旦一個(gè)客戶意識到這是一個(gè)用戶故事并不是一個(gè)契約而且可以進(jìn)行協(xié)商的時(shí)候，他們將非常樂意寫下故事。 交談（Conversation） 用戶故事背后的細(xì)節(jié)來源于和客戶或者產(chǎn)品負(fù)責(zé)人的交流溝通。2. 活動(dòng)：需要完成什么樣的功能。 共享代碼庫，統(tǒng)一的持續(xù)集成組件團(tuán)隊(duì)看起來像這個(gè)樣子：按照Scrum和敏捷的交付模式，組件團(tuán)隊(duì)有如下一些限制：第一：按照組件來組織團(tuán)隊(duì)，很難避免團(tuán)隊(duì)之間的依賴，跨團(tuán)隊(duì)的協(xié)調(diào)和依賴管理更加復(fù)雜，