【正文】 你們的持續(xù)集成服務(wù)器能夠在回歸測試出現(xiàn)錯誤的一個小時（或者一分鐘）內(nèi)自動發(fā)出警報嗎？如果你還沒有發(fā)現(xiàn)你能夠做的事情的話，嘗試聆聽Product Owner，團(tuán)隊還有團(tuán)隊以外的公司成員的想法?！巴瓿伞钡亩x當(dāng)產(chǎn)品代辦事項(xiàng)列表?xiàng)l目或者增量被描述為“完成”的時候,每個人都必須理解“完 成”意味著什么。每日站會一定要站著開，每個人要精神集中，不能有懶散的表現(xiàn)。每日站會每日站會的目的在介紹如何開每日站會前， 讓我們先了解一下召開每天的站會的目的和意義是什么？敏捷宣言強(qiáng)調(diào)個體交互重于過程和工具，敏捷原則闡述了面對面的溝通和自組織的團(tuán)隊這些敏捷的核心思想。 開發(fā)團(tuán)隊的組成集中優(yōu)勢兵力各個擊破在Sprint執(zhí)行的過程中，團(tuán)隊要避免一個蘿卜一個坑的工作方式，團(tuán)隊要協(xié)作，并且要集中優(yōu)勢兵力各個擊破。3. 記錄每個Sprint的團(tuán)隊速度團(tuán)隊速率是一個Scrum團(tuán)隊在一個Sprint中實(shí)際完成的故事點(diǎn)數(shù)，通過團(tuán)隊速率可以知道團(tuán)隊做的有多快。 產(chǎn)品負(fù)責(zé)人或者一名團(tuán)隊成員扮演閱讀者的角色，他負(fù)責(zé)閱讀需要估算產(chǎn)品Backlog的條目，并且詢問大家是否有疑問。但是讓開發(fā)者難以估計故事的問題來自：對于領(lǐng)域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。用戶故事的六個特性 INVESTINVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable一個好的用戶故事應(yīng)該遵循INVEST原則。 比較容易在一個Sprint中交付可用的產(chǎn)品增量打造自組織團(tuán)隊，首先要讓團(tuán)隊需要完全自主； 其次，有了自主，管理者需要引導(dǎo)團(tuán)隊持續(xù)改進(jìn)，幫助團(tuán)隊持續(xù)地挑戰(zhàn)更高的目標(biāo)；第三，給團(tuán)隊提供環(huán)境和支持，引導(dǎo)團(tuán)隊往正確地方向邁進(jìn)。 團(tuán)隊決定如何做，如何實(shí)現(xiàn)目標(biāo)，即團(tuán)隊做技術(shù)決策 持續(xù)改進(jìn)SCRUM團(tuán)隊在傳統(tǒng)的工作方式下，開發(fā)團(tuán)隊會有很多不同的角色，比如項(xiàng)目經(jīng)理、產(chǎn)品經(jīng)理、架構(gòu)師、設(shè)計師、用戶體驗(yàn)設(shè)計師，程序員，測試人員，DBA等等。Scrum活動:Sprint回顧會議在每個Sprint結(jié)束后,Scrum團(tuán)隊會聚在一起開Sprint回顧會議,目的是回顧一下團(tuán)隊在流程人際關(guān)系以及工具方面做得如何。每日Scrum是Scrum的一個關(guān)鍵組成部分,它可以帶來透明性,信任和更好的績效。開發(fā)團(tuán)隊預(yù)測并共同承諾他們要完成的工作量。這就是產(chǎn)品待辦事項(xiàng)列表梳理十分重要的原因。 增加或提升涌現(xiàn)出來的或變得更重要的事項(xiàng)開發(fā)團(tuán)隊每天追蹤剩余總和并預(yù)測 達(dá)成 Sprint 目標(biāo)的可能性。SPRINT BACKLOGSprint 代辦事項(xiàng)列表是一組為當(dāng)前 Sprint 選出的產(chǎn)品代辦事項(xiàng)列表?xiàng)l目,外加交付 產(chǎn)品增量和實(shí)現(xiàn) Sprint 目標(biāo)的計劃。通常,開發(fā) 團(tuán)隊有自行優(yōu)化的領(lǐng)域知識。排序越高的產(chǎn)品待辦事項(xiàng)列表?xiàng)l目比排序低的更清晰、更具體。 幫助員工及干系人理解并實(shí)施 Scrum 和經(jīng)驗(yàn)性產(chǎn)品開發(fā)Scrum Master 幫助 Scrum 團(tuán)隊外的人員了解他們?nèi)绾闻c Scrum 團(tuán)隊交互是有益的。 開發(fā)團(tuán)隊是跨職能的,團(tuán)隊作為一個整體擁有創(chuàng)造產(chǎn)品增量所需要的全部技能。 確保開發(fā)團(tuán)隊所執(zhí)行工作的價值第三：適應(yīng)（Adaptation）如果檢驗(yàn)人員檢驗(yàn)的時候發(fā)現(xiàn)過程中的一個或多個方面不滿足驗(yàn)收標(biāo)準(zhǔn)，并且最終產(chǎn)品是不合格的，那么便需要對過程或是材料進(jìn)行調(diào)整。 預(yù)定義過程的缺點(diǎn)在于一旦過程定義出現(xiàn)錯誤，或產(chǎn)品設(shè)計上存在瑕疵，會造成比較大的損失。Game文章首次提到將Scrum應(yīng)用與產(chǎn)品開發(fā)，他們指出：傳統(tǒng)的“接力式”的開發(fā)模式已經(jīng)不能滿足快速靈活的市場需求，而整體或“橄欖球式”的方法——團(tuán)隊作為一個整體前進(jìn)，在團(tuán)隊的內(nèi)部傳球并保持前進(jìn)，這也許可以更好的滿足當(dāng)前激烈的市場競爭。管理生產(chǎn)成果的人不僅要能夠看到過程的這些方面，而且必須理解他們看到的內(nèi)容。在Scrum中，使用產(chǎn)品Backlog來管理產(chǎn)品的需求，產(chǎn)品backlog是一個按照商業(yè)價值排序的需求列表，列表?xiàng)l目的體現(xiàn)形式通常為用戶故事。幸運(yùn)的是，軟件開發(fā)并不會出現(xiàn)這種情況。2001年 敏捷宣言及原則發(fā)布、敏捷聯(lián)盟成立，Scrum是其中一種敏捷方法。如果過程復(fù)雜程度超出預(yù)定義方式的能力范圍，便應(yīng)用經(jīng)驗(yàn)性方式。 —— and 《過程動態(tài)學(xué)、建模與控制》軟件產(chǎn)品的研發(fā)通常存在多很多的不確定性，并且生產(chǎn)的過程非常的復(fù)雜，所以更適合使用經(jīng)驗(yàn)性過程來管理。自組織團(tuán)隊決定如何最好地完成他們的工作,而不是由團(tuán)隊外的其他人來指揮他 們。產(chǎn)品負(fù)責(zé)人可能會在產(chǎn)品代辦事項(xiàng)列表中 體現(xiàn)一個委員會的需求,但要想改變某條目的優(yōu)先級必須先說服產(chǎn)品負(fù)責(zé)人。 開發(fā)團(tuán)隊中的每個成員可以有特長和專注領(lǐng)域,但是責(zé)任歸屬于整個開發(fā)團(tuán)隊 教導(dǎo)開發(fā)團(tuán)隊創(chuàng)建清晰簡明的產(chǎn)品代表事項(xiàng)列表?xiàng)l目產(chǎn)品負(fù)責(zé)人負(fù)責(zé)產(chǎn)品待辦事項(xiàng)列表的內(nèi)容、可用性和優(yōu)先級。隨著產(chǎn)品的使用、價值的獲取以及市場的反饋,產(chǎn)品待辦事項(xiàng)列表變成了更大、更詳 盡的列表。但是,最后的估算是由執(zhí)行工作的人來決定的。開發(fā)團(tuán)隊在整個 Sprint 中都會修改 Sprint 代辦事項(xiàng)列表,Sprint 代辦事項(xiàng)列表也 會在 Sprint 的進(jìn)程中慢慢顯現(xiàn),比如開發(fā)團(tuán)隊按照計劃工作并對完成 Sprint 目標(biāo)所需的 工作有更多的了解。 圖中Y軸代表的是剩余工作量，X軸代表的是Sprint的工作日。需要考慮不少因素,這包括但不限于以下的內(nèi)容:理想情況下,下一個Sprint的備選事項(xiàng)都應(yīng)該提升“商業(yè)價值”。產(chǎn)品負(fù)責(zé)人或任何其它人,都不能給開發(fā) 團(tuán)隊強(qiáng)加更多的工作量。 這個會議每天在同樣的時間和同樣的地點(diǎn)召開。所有Scrum會議都是限定時?長 的,Sprint評審會議的推薦時?長是Sprint中的每一周對應(yīng)一個小時(譯者注:?比如,一個Sprint 包含2個星期,則Sprint評審會議時?長為2個小時)。迭代的長度是固定的，如果我們選擇了1周的迭代，那么保持它的長度不要發(fā)生變化，在整個產(chǎn)品開發(fā)周期內(nèi)每個迭代都是1周的長度。Scrum中的團(tuán)隊，對應(yīng)到龍舟賽的劃槳團(tuán)隊，團(tuán)隊必須協(xié)調(diào)一致，作為一個整體前進(jìn)，在這樣的環(huán)境下單打獨(dú)斗，各自為政沒有任何勝算。 按照可持續(xù)的節(jié)奏工作 確定團(tuán)隊上下文，組織結(jié)構(gòu)、團(tuán)隊結(jié)構(gòu)、團(tuán)隊組成組件團(tuán)隊看起來像這個樣子：按照Scrum和敏捷的交付模式，組件團(tuán)隊有如下一些限制：第一：按照組件來組織團(tuán)隊，很難避免團(tuán)隊之間的依賴，跨團(tuán)隊的協(xié)調(diào)和依賴管理更加復(fù)雜，不利于跨組件或者各個層之間的溝通。2. 活動：需要完成什么樣的功能。 可測試性（Testable）—一個用戶故事要是可以測試的，以便于確認(rèn)它是可以完成的。一個Sprint是指一個1周－4周的迭代，它是一個時間盒。如果某個 Sprint 的目標(biāo)過時了,那么就需要取消該 Sprint。 團(tuán)隊溝通狀態(tài)，了解現(xiàn)狀，發(fā)現(xiàn)障礙 4. ScrumMaster不會逐個的問每個人問題，如果是，那么這個會議已經(jīng)淪為了報告會。4.開發(fā)團(tuán)隊在每個 Sprint 交付產(chǎn)品功能增量。） Product Owner有根據(jù)上次Sprint評審會議來調(diào)整發(fā)布計劃嗎？通常Product Owner應(yīng)該至少在個Sprint之后調(diào)整發(fā)布計劃，一般來說會把一些工作放到后面的版本中，原因是發(fā)現(xiàn)了一些更重要的工作要做。 團(tuán)隊成員都能夠自己領(lǐng)取任務(wù)嗎？測試覆蓋率的漏洞和推遲的重構(gòu)被稱作技術(shù)債務(wù)。 你能夠幫助公司成為一個學(xué)習(xí)型企業(yè)嗎？所以，比較推薦的做法是和團(tuán)隊成員先討論以選擇在一周內(nèi)大家愿意嘗試使用結(jié)對編程的時間，而不是從一開始就強(qiáng)迫團(tuán)隊使用結(jié)對編程。 團(tuán)隊成員之間會以高標(biāo)準(zhǔn)要求對方嗎？會互相挑戰(zhàn)來促進(jìn)成長嗎？ 需求（特別是在產(chǎn)品待辦事列表最頂端的需求）能夠以獨(dú)立的、有價值的、可協(xié)商的、可估計的、可測試的小粒度用戶展現(xiàn)出來嗎？如果你愿意把你的角色限制在組織會議，控制時間盒以及處理團(tuán)隊成員提出的障礙的話，你可以將這個角色當(dāng)作成兼職來對待。 站會結(jié)束后，ScrumMaster知道哪些問題需要幫助團(tuán)隊成員解決。 任何團(tuán)隊之外的人不得發(fā)言或干擾會議。每日站會是Scrum團(tuán)隊每天的第一件事情，這樣可以讓每個人在每天一開始就清楚的了解他一天的安排。所有未完成的條目就都要 放回到產(chǎn)品待辦事項(xiàng)列表中,并重新估算。Scrum采用迭代增量的方式，是因?yàn)樾枨笫怯楷F(xiàn)的，我們對產(chǎn)品和需求的理解是漸進(jìn)式的，Sprint長度越長，我們需要預(yù)測的越多，復(fù)雜度會提升、風(fēng)險也會增加，所以Sprint的長度最多不超過4周。關(guān)注Scrum中文網(wǎng)微信公眾號可以獲得微信版估算撲克。使用估算撲克來做工作量估算是最有效，也是非常有趣的一種估算方式。 有價值（Valuable）— 每個故事必須對客戶具有價值（無論是用戶還是購買方）?？ㄆ峡赡軙懮瞎适碌暮喍堂枋?，工作量估算等。 以客戶為中心的特性驅(qū)動 誤解3：團(tuán)隊自己設(shè)計團(tuán)隊結(jié)構(gòu)； 糾正：管理層決定團(tuán)隊上下文自組織團(tuán)隊和經(jīng)理領(lǐng)導(dǎo)的團(tuán)隊的區(qū)別對于經(jīng)理領(lǐng)導(dǎo)的團(tuán)隊來說，團(tuán)隊成員被分配任務(wù)，團(tuán)隊成員只有執(zhí)行任務(wù)的權(quán)利。 每天跟進(jìn)工作進(jìn)展，并對他們的工作做檢查和調(diào)整自組織團(tuán)隊Scrum團(tuán)隊是一個自組織的團(tuán)隊，傳統(tǒng)的命令與控制式的團(tuán)隊只有執(zhí)行任務(wù)的權(quán)利，而自組織團(tuán)隊有權(quán)進(jìn)行設(shè)計、計劃和執(zhí)行任務(wù)，自組織團(tuán)隊還需要自己監(jiān)督和管理他們的工程過程和進(jìn)度，自組織團(tuán)隊自己決定團(tuán)隊內(nèi)如何開展工作，決定誰來做什么，即分工協(xié)作的方式。團(tuán)隊會找到他們自己的方式來開Sprint評審會議。每日Scrum既不是向管理層匯報,也不是向產(chǎn)品負(fù)責(zé)?人或者ScrumMaster匯報。之后要完成的工作可以稍?大些,以后再對它 們進(jìn)?行分解。整個團(tuán)隊都要參加Sprint計劃會議。X軸代表的項(xiàng)目周期，以Sprint為單位， Y軸代表的是剩余工作量，通常以用戶故事點(diǎn)、理想人天或者teamdays為單位。Product Backlog 功能點(diǎn)被放到Sprint的固定周期中，Sprint Backlog 會因?yàn)槿缦略虬l(fā)生變化:1. 隨著時間的變化，開發(fā)團(tuán)隊對于需求有了更好的理解，有可能發(fā)現(xiàn)需要增加一些新的任務(wù)到Sprint Backlog中。我們只關(guān)心剩余工作和日期這兩個變量。通過產(chǎn)品Backlog地梳理來增添細(xì)節(jié)、估算和排序。產(chǎn)品待辦事項(xiàng)列表?xiàng)l目包含描述、次序和估算的特征。 移除開發(fā)團(tuán)隊進(jìn)展過程中的障礙大型團(tuán)隊會產(chǎn)生太多復(fù)雜性,不便于經(jīng)驗(yàn)過程管理。開發(fā)團(tuán)隊由組織構(gòu)建并授權(quán),來組織和管理他們的工作。實(shí)現(xiàn)這一點(diǎn)的方式會隨著組 織、Scrum 團(tuán)隊以及單個團(tuán)隊成員的不同而不同。第二：檢驗(yàn)（Inspection）開發(fā)過程中的各方面必須做到足夠頻繁地檢驗(yàn)，確保能夠及時發(fā)現(xiàn)過程中的重大偏差。 過程控制通常有兩種方式，第一種方式是預(yù)定義的過程，第二種方式是經(jīng)驗(yàn)性過程。發(fā)布燃盡圖，產(chǎn)品負(fù)責(zé)人做發(fā)布進(jìn)展跟蹤Sprint Planning Meeting: Sprint計劃會議Daily Scrum Meeting：每日站會Sprint Review Meeting：Sprint評審會議Sprint Retrospective Meeting: Sprint回顧會議Product Backlog Refinement: 產(chǎn)品待辦列表梳理Product Backlog Item: 產(chǎn)品待辦清單條目，簡稱PBIUser Story: 用戶故事，指一條需求Story Point：衡量用戶故事的工作量大小的計量單位Velocity: 團(tuán)隊速度Sprint Task: 實(shí)現(xiàn)一條需求需要做的一個技術(shù)任務(wù)Definition of Done: DoD，完成的定義Stakeholders： 干系人Backlog： 待辦列表Artifact ：工件Estimation ：估算Collaboration： 協(xié)作Scaling Scrum：大規(guī)模ScrumSCRUM起源Scrum的原始含義Scrum原始含義是指英式橄欖球次要犯規(guī)時在犯規(guī)地點(diǎn)對陣爭球。Scrum流程如下圖：SCRUM框架包括3個角色、3個工件、5個活動、5個價值3個角色1. 產(chǎn)品負(fù)