中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

團(tuán)隊(duì)引入Scrum的初期，會(huì)有一個(gè)常見(jiàn)的現(xiàn)象，就是成員們發(fā)現(xiàn)開(kāi)的會(huì)變多了，自己安靜開(kāi)發(fā)寫(xiě)代碼的時(shí)間變少了。在這篇文章中，我嘗試基于自己曾經(jīng)參與和指導(dǎo)過(guò)的Scrum團(tuán)隊(duì)闡述一下這些會(huì)議的意義，以及如何規(guī)劃并且讓團(tuán)隊(duì)更好地執(zhí)行Scrum會(huì)議。

Scrum的會(huì)議及其意義

標(biāo)準(zhǔn)的Scrum流程包含了四個(gè)類(lèi)型的會(huì)議，即Sprint Plan、Daily Scrum、Sprint Review和Sprint Retrospective。首先我們要知道，Scrum是敏捷開(kāi)發(fā)的一種實(shí)踐，它自然也遵循敏捷開(kāi)發(fā)原則。它的目標(biāo)是交付可使用的軟件，所以上面提到的這些會(huì)議都對(duì)這個(gè)目標(biāo)有著直接的幫助。

Sprint Plan會(huì)議主要是計(jì)劃當(dāng)前迭代的工作內(nèi)容做計(jì)劃。和傳統(tǒng)開(kāi)發(fā)流程里面項(xiàng)目例會(huì)或者啟動(dòng)會(huì)不同，Sprint Plan著重于Product Owner 和Dev Team的交流和互動(dòng)。通過(guò)Product Owner的講解，Dev Team的理解和提問(wèn)，整個(gè)團(tuán)隊(duì)對(duì)于每一個(gè)Work Item最終都會(huì)達(dá)成充分一致，同時(shí)對(duì)于每一個(gè)Work Item的工作難度、涉及范圍、可出現(xiàn)的問(wèn)題和潛在的難點(diǎn)都會(huì)有充分的預(yù)判。最終在這個(gè)基礎(chǔ)上，團(tuán)隊(duì)對(duì)Work Item的工作量（復(fù)雜度）進(jìn)行打分。這些會(huì)上工作看似耗時(shí)，但是它的作用是把開(kāi)發(fā)中可能遇到的問(wèn)題提前暴露。如果以整個(gè)Sprint周期來(lái)衡量，這種充分的溝通能縮短開(kāi)發(fā)時(shí)間，而且最大限度的規(guī)避了開(kāi)發(fā)中出現(xiàn)問(wèn)題的風(fēng)險(xiǎn)。所以Sprint Plan會(huì)議占用的時(shí)間是完全有意義且必要的。

Daily Scrum作為每天都會(huì)進(jìn)行的會(huì)議，主要保證了團(tuán)隊(duì)成員充分的溝通。雖然時(shí)長(zhǎng)較短，但是因?yàn)樗枰總€(gè)成員介紹自己當(dāng)天的工作內(nèi)容、第二天的工作計(jì)劃以及目前的困難，從流程上確保了大家必須提前安排好自己的工作。而且這個(gè)會(huì)議也能督促?zèng)]有工作的成員主動(dòng)領(lǐng)取任務(wù)。

Sprint Review作為團(tuán)隊(duì)工作的驗(yàn)收，要求成員通過(guò)現(xiàn)場(chǎng)演示的方式展示自己的成果。這種驗(yàn)收方式踐行了敏捷宣言中“可工作的軟件高于詳盡的文檔”。Product Owner作為最終用戶(hù)的代表，基于實(shí)際可演示（可工作）的軟件進(jìn)行驗(yàn)收。

Sprint Retrospective作為對(duì)當(dāng)前Sprint的總結(jié)，看似和產(chǎn)品開(kāi)發(fā)無(wú)關(guān)，其實(shí)在某種意義上可以說(shuō)是最重要的會(huì)議。敏捷的原則就是在實(shí)踐中不斷總結(jié)和改進(jìn)。Sprint Retrospective會(huì)議就是專(zhuān)門(mén)為團(tuán)隊(duì)總結(jié)Scrum執(zhí)行過(guò)程的問(wèn)題而設(shè)立的。

對(duì)于一個(gè)新成立或者剛開(kāi)始實(shí)踐Scrum的團(tuán)隊(duì)，建議在第一次Sprint Plan或者啟動(dòng)會(huì)的時(shí)候?qū)ι鲜鯯crum各種會(huì)議的作用和意義有一個(gè)簡(jiǎn)單介紹，盡量讓團(tuán)隊(duì)成員認(rèn)識(shí)到它們的重要性，從而最大限度的避免對(duì)會(huì)議的抵觸情緒。

當(dāng)然，僅僅了解會(huì)議的重要性還不夠。為了保證會(huì)議高效而有序的進(jìn)行，需要在會(huì)前、會(huì)中以及會(huì)后做很多工作，讓團(tuán)隊(duì)切實(shí)感受到重要性。接下來(lái)我們針對(duì)不同類(lèi)型的會(huì)議簡(jiǎn)單介紹一下如何執(zhí)行的。

Sprint Plan會(huì)議

Sprint Plan會(huì)議最主要的就是討論和評(píng)估Product Backlog里面的Work Item。首先，Product Owner需要在平時(shí)就注意維護(hù)好Product Backlog，即保證Backlog里面的Work Item都反映了最新的需求，內(nèi)容具體明確，優(yōu)先級(jí)合理。

其次，在開(kāi)始Sprint Plan會(huì)議前，Product Owner需要預(yù)先對(duì)需要討論的Work Item在進(jìn)行一次梳理。必要的時(shí)候，可以和團(tuán)隊(duì)的技術(shù)骨干或者主要開(kāi)發(fā)人員事先溝通。這樣的好處是，在Sprint Plan會(huì)議中，團(tuán)隊(duì)針對(duì)每個(gè)Work Item的討論更加高效，避免會(huì)上花大量時(shí)間思考和討論具體的需求細(xì)節(jié)。

另外，Sprint Plan會(huì)議還有一個(gè)可能引起拖延的問(wèn)題就是對(duì)Work Item的打分。在標(biāo)準(zhǔn)的Scrum流程中，團(tuán)隊(duì)成員需要根據(jù)自己對(duì)Work Item的理解，在不被其他成員影響的情況下獨(dú)立打分，然后針對(duì)不同的分?jǐn)?shù)進(jìn)行討論，直到達(dá)成一致為止。但是實(shí)際情況往往是，團(tuán)隊(duì)成員由于各自的專(zhuān)業(yè)技能不同、知識(shí)面不同、能力不同，打出的分?jǐn)?shù)各不相同?；蛘哂捎谝恍┘夹g(shù)細(xì)節(jié)，導(dǎo)致幾名成員討論的時(shí)候各不相讓。最終導(dǎo)致一個(gè)Work Item遲遲無(wú)法確定Effort。雖然充分的討論有助于提前發(fā)現(xiàn)問(wèn)題和規(guī)避風(fēng)險(xiǎn)，但是這種過(guò)于陷入細(xì)節(jié)的爭(zhēng)論卻不利于會(huì)議的進(jìn)程。因此可借鑒的做法是，在對(duì)Work Item打分的時(shí)候，選一個(gè)對(duì)此任務(wù)最為熟悉的成員打一個(gè)基準(zhǔn)分，然后大家針對(duì)這個(gè)基準(zhǔn)分投票。如果有不同意見(jiàn)再討論。

最后，當(dāng)團(tuán)隊(duì)工作量已經(jīng)飽和后，理論上來(lái)說(shuō)Sprint Plan會(huì)議就結(jié)束了。但是為了應(yīng)對(duì)估算誤差導(dǎo)致Sprint后期沒(méi)有任務(wù)可做的情況，可以適當(dāng)多估算幾個(gè)Work Item作為備用。

Daily Scrum會(huì)議

Daily Scrum會(huì)議相對(duì)簡(jiǎn)單，因此只需要注意成員在發(fā)言的時(shí)候避免幾個(gè)人過(guò)多的討論細(xì)節(jié)，導(dǎo)致會(huì)議無(wú)限期延長(zhǎng)的情況。一旦出現(xiàn)這種情況，Scrum Master需要及時(shí)制止。

另外，有的團(tuán)隊(duì)因?yàn)镻roduct Owner參與多個(gè)Scrum團(tuán)隊(duì)，或者Product Owner和Dev Team距離較遠(yuǎn)（地理位置、時(shí)差），導(dǎo)致無(wú)法每次都參與Daily Scrum。為此可以考慮Dev Team的一個(gè)成員作為Product Owner Agent，臨時(shí)代理Product Owner的職責(zé)。對(duì)于相對(duì)簡(jiǎn)單的需求問(wèn)題可以直接決定，而對(duì)于那些不好判斷的問(wèn)題則在會(huì)后單獨(dú)和Product Owner溝通。而這個(gè)Product Owner Agent的人選建議從測(cè)試人員中尋找，因?yàn)樵贒ev Team中測(cè)試人員對(duì)于需求的理解和把握是相對(duì)準(zhǔn)確且中立的。

Sprint Review & Retrospective會(huì)議

Sprint Review一定要保證每一個(gè)Work Item都是以演示的形式進(jìn)行驗(yàn)收。對(duì)于功能性的Work Item，演示起來(lái)相對(duì)比較好實(shí)現(xiàn)。而對(duì)于那些非功能性Work Item，比如架構(gòu)設(shè)計(jì)、技術(shù)調(diào)研、可行性分析等，則看上去很難演示。對(duì)此，一般的做法是，對(duì)于架構(gòu)設(shè)計(jì)，通常在Work Item分解到Task的時(shí)候就包含和設(shè)計(jì)、評(píng)審、更新三個(gè)部分。而在評(píng)審部分，團(tuán)隊(duì)成員和相關(guān)技術(shù)專(zhuān)家已經(jīng)Review過(guò)設(shè)計(jì)，并且在后續(xù)的更新環(huán)節(jié)針對(duì)評(píng)審結(jié)果做了修改。因此在最終的Sprint Review會(huì)議可以直接略過(guò)，或者簡(jiǎn)單介紹一下評(píng)審結(jié)果。對(duì)于技術(shù)調(diào)研和可行性分析，則需要在Sprint Review會(huì)議上演示調(diào)研分析的成果，譬如例子程序、測(cè)試報(bào)告、分析報(bào)告等?？傊?，Sprint Review會(huì)議里面要求的演示并不僅僅指狹義的界面操作，也可以是文檔、例子、報(bào)告等一切能夠展示工作結(jié)果的東西。

Sprint Review的演示不宜過(guò)長(zhǎng)，一般控制在每個(gè)5分鐘之內(nèi)，這就要求每個(gè)Work Item的負(fù)責(zé)人在會(huì)前準(zhǔn)備好自己的演示環(huán)境和步驟。有一個(gè)可行的做法，就是在會(huì)前每個(gè)成員都在自己的測(cè)試環(huán)境準(zhǔn)備好演示要用到的場(chǎng)景，會(huì)議開(kāi)始后輪流接入投影儀演示。對(duì)于一些比較耗時(shí)或者操作等待時(shí)間很長(zhǎng)的演示，也可以實(shí)現(xiàn)通過(guò)屏幕錄像的方式進(jìn)行演示。這么做可以讓成員在演示前細(xì)心準(zhǔn)備，也就是進(jìn)行必要的測(cè)試。而進(jìn)一步的，能夠讓團(tuán)隊(duì)在開(kāi)發(fā)過(guò)程中就對(duì)自己負(fù)責(zé)的Work Item的質(zhì)量進(jìn)行持續(xù)關(guān)注。

Sprint Retrospective會(huì)議是對(duì)Sprint流程的總結(jié)會(huì)，因此需要注意不要成為對(duì)Sprint結(jié)果，或者對(duì)于團(tuán)隊(duì)成員的總結(jié)會(huì)。Retrospective經(jīng)常會(huì)變成成員的批評(píng)與自我批評(píng)會(huì)議，這其實(shí)是不對(duì)的，需要Scrum Master特別注意。Scrum倡導(dǎo)的是團(tuán)隊(duì)而非個(gè)人，因此Retrospective總結(jié)的也是團(tuán)隊(duì)而非個(gè)人。

鑒于東方人大多比較含蓄和內(nèi)斂，Retrospective也有可能變成無(wú)聲靜默會(huì)議。這時(shí)候需要Scrum Master在會(huì)議前就能總結(jié)出一些待改進(jìn)的事項(xiàng)，會(huì)上帶頭提出，引導(dǎo)其他成員參與。或者采取輪流發(fā)言的機(jī)制，強(qiáng)制每個(gè)成員都要參與。但是無(wú)論什么手段，都要確保對(duì)流程不對(duì)結(jié)果，對(duì)事不對(duì)人。

最后，為了防止Retrospective只抱怨不解決，會(huì)議記錄需要明確提出來(lái)的每個(gè)問(wèn)題的提出者、內(nèi)容、解決方案、負(fù)責(zé)人和截止時(shí)間。在下一次Retrospective會(huì)議中，Scrum Master可以先匯報(bào)上次Retrospective會(huì)議的記錄以及解決結(jié)果。這樣做的好處是用實(shí)際行動(dòng)表明成員提出的每一個(gè)改進(jìn)建議都是被重視被落實(shí)的，鼓勵(lì)大家繼續(xù)提出問(wèn)題并改進(jìn)。同時(shí)要指出，對(duì)于解決結(jié)果來(lái)說(shuō)，某個(gè)問(wèn)題最終沒(méi)能解決也是一種可接受結(jié)果。

一些通用原則

準(zhǔn)時(shí)參會(huì)

– 會(huì)議開(kāi)始前5分鐘之前，可以申請(qǐng)遲到。

– 會(huì)議開(kāi)始后5分鐘內(nèi)到場(chǎng)，不算遲到。

– 會(huì)議開(kāi)始后5分鐘之后，算遲到。

– 每一個(gè)遲到的成員需要給團(tuán)隊(duì)發(fā)紅包或請(qǐng)吃零食等。

發(fā)言權(quán)

– 只有對(duì)項(xiàng)目有直接貢獻(xiàn)的成員可以發(fā)言

準(zhǔn)時(shí)結(jié)束

– 絕不拖堂

– 未討論的內(nèi)容另行組織會(huì)議

會(huì)議記錄

– 除Daily Scrum外，所有會(huì)議均保存會(huì)議記錄，使用統(tǒng)一模板

– 會(huì)議記錄包括：時(shí)間、參會(huì)人、議題、決議、負(fù)責(zé)人和截止時(shí)間。

總結(jié)

Scrum流程中，各種會(huì)議是其主要的組成部分，也是推進(jìn)Scrum進(jìn)行的基礎(chǔ)。確保這些會(huì)議有序高效的進(jìn)行是能否成功開(kāi)展Scrum的關(guān)鍵。因此團(tuán)隊(duì)，特別是Scrum Master要對(duì)此給予足夠的重視。

上面提到的一些原則、經(jīng)驗(yàn)和流程僅僅是基于我之前參與過(guò)的Scrum項(xiàng)目總結(jié)而來(lái)的。而實(shí)際上，Scrum團(tuán)隊(duì)各不相同，會(huì)議的內(nèi)容、進(jìn)程和安排也不會(huì)完全一樣。這需要整個(gè)團(tuán)隊(duì)不斷地嘗試、磨合、改進(jìn)。最重要的，確保會(huì)議的討論是有意義的，是得到團(tuán)隊(duì)認(rèn)可的，才能最終達(dá)到目的。

#專(zhuān)欄作家#

袁林，人人都是產(chǎn)品經(jīng)理專(zhuān)欄作家。分享SaaS運(yùn)營(yíng)和企業(yè)管理／協(xié)作／辦公的相關(guān)知識(shí)

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來(lái)自 Pexels ，基于 CC0 協(xié)議