返回目錄 下一章·Scrum 中的基本角色和職責(zé)

我們發(fā)現(xiàn)映砖，許多項(xiàng)目成員對(duì)敏捷開發(fā)中的一些基本名詞概念模糊睬关，造成了項(xiàng)目管理過程和內(nèi)部交流上的一些困難澎语。在此對(duì)一些容易混淆的基本概念做解釋肩祥。

1.1 Agile——敏捷

在軟件工業(yè)界坞嘀，敏捷開發(fā)已成為眾多高效開發(fā)團(tuán)隊(duì)的制勝之道郁油。它不僅被許多中小公司青睞本股，在全球一百?gòu)?qiáng)的企業(yè)中，敏捷開發(fā)也已大行其道桐腌，受到許多資深項(xiàng)目管理者和開發(fā)人員的推崇拄显。例如，騰訊內(nèi)部幾乎所有的開發(fā)團(tuán)隊(duì)都在實(shí)施敏捷案站。
????敏捷不是指某一種具體的方法論躬审、過程或框架，而是一組價(jià)值觀和原則。符合敏捷價(jià)值觀和原則的開發(fā)方法包括：極限編程（XP）承边，Scrum遭殉，精益軟件開發(fā)（Lean Software Development），動(dòng)態(tài)系統(tǒng)開發(fā)方法（DSDM）博助，特征驅(qū)動(dòng)開發(fā)（Feature Driver Development）恩沽，水晶開發(fā)（Crystal Clear）等等。所有這些方法都具有以下共同特征：

1. 迭代式開發(fā)翔始。即整個(gè)開發(fā)過程被分為幾個(gè)迭代周期罗心，每個(gè)迭代周期是一個(gè)定長(zhǎng)或不定長(zhǎng)的時(shí)間塊，持續(xù)的時(shí)間較短城瞎，通常為一到四周渤闷。
2. 增量交付。產(chǎn)品是在每個(gè)迭代周期結(jié)束時(shí)被逐步交付使用脖镀，而不是在整個(gè)開發(fā)過程結(jié)束的時(shí)候一次性交付使用飒箭。每次交付的都是可以被部署到用戶應(yīng)用環(huán)境中被用戶使用的、能給用戶帶來即時(shí)效益和價(jià)值的產(chǎn)品蜒灰。
3. 開發(fā)團(tuán)隊(duì)和用戶反饋推動(dòng)產(chǎn)品開發(fā)弦蹂。敏捷開發(fā)方法主張用戶能夠全程參與到整個(gè)開發(fā)過程中。這使需求變化和用戶反饋能被動(dòng)態(tài)管理并及時(shí)集成到產(chǎn)品中强窖。同時(shí)凸椿，團(tuán)隊(duì)對(duì)于用戶的需求也能及時(shí)提供反饋意見。
4. 持續(xù)集成翅溺。新的功能或需求變化總是盡可能頻繁地被整合到產(chǎn)品中脑漫。一些項(xiàng)目是在每個(gè)迭代周期結(jié)束的時(shí)候集成， 有些項(xiàng)目則每天都在這么做咙崎。
5. 開發(fā)團(tuán)隊(duì)自我管理优幸。擁有一個(gè)積極的、自我管理的褪猛、具備自由交流風(fēng)格的開發(fā)團(tuán)隊(duì)网杆，是每個(gè)敏捷項(xiàng)目必不可少的條件。人是敏捷開發(fā)的核心伊滋。敏捷開發(fā)總是以人為中心建立開發(fā)的過程和機(jī)制碳却，而非把過程和機(jī)制強(qiáng)加給人。

1.2 Scrum——橄欖球式開發(fā)模式

Scrum 是一個(gè)用于開發(fā)和維持復(fù)雜產(chǎn)品的框架新啼，是一個(gè)增量的追城、迭代的開發(fā)過程，是敏捷開發(fā)的一種實(shí)現(xiàn)機(jī)制燥撞。Scrum以經(jīng)驗(yàn)性過程控制理論（經(jīng)驗(yàn)主義）為理論基礎(chǔ)座柱，主張知識(shí)源于經(jīng)驗(yàn), 以及基于已知的東西做決定迷帜。Scrum 采用迭代、增量的方法來優(yōu)化可預(yù)見性并控制風(fēng)險(xiǎn)色洞。在這個(gè)框架中戏锹，整個(gè)開發(fā)過程由若干個(gè)短的迭代周期組成，一個(gè)短的迭代周期稱為一個(gè)沖刺（Sprint）火诸。
????在Scrum中锦针，使用產(chǎn)品Backlog來管理產(chǎn)品需求和開發(fā)任務(wù)。產(chǎn)品backlog是一個(gè)按照商業(yè)價(jià)值（或?qū)崿F(xiàn)優(yōu)先級(jí)）排序的事項(xiàng)列表置蜀，列表?xiàng)l目的體現(xiàn)形式通常為用戶故事奈搜。在規(guī)劃Sprint時(shí)，Scrum團(tuán)隊(duì)從產(chǎn)品Backlog中挑選最高優(yōu)先級(jí)的需求盯荤，在Sprint計(jì)劃會(huì)議上經(jīng)過討論馋吗、分析和估算得到相應(yīng)的任務(wù)，并分配給具體的成員去實(shí)現(xiàn)秋秤。
????當(dāng)前Sprint需要完成的任務(wù)會(huì)展現(xiàn)在特別設(shè)計(jì)的面板上宏粤，清晰地展示每個(gè)任務(wù)的負(fù)責(zé)人灼卢、當(dāng)前狀態(tài)绍哎、實(shí)現(xiàn)過程中的問題和變更等等信息。項(xiàng)目團(tuán)隊(duì)和各利益攸關(guān)方能清晰地把握每個(gè)任務(wù)的開發(fā)進(jìn)度和遇到的問題鞋真，并以此分析崇堰、控制項(xiàng)目的進(jìn)度、成本和風(fēng)險(xiǎn)灿巧。
????Scrum以站立會(huì)作為項(xiàng)目規(guī)劃赶袄、過程控制和資源分配的內(nèi)部交流協(xié)商機(jī)制。
????在每個(gè)迭代結(jié)束時(shí)抠藕，Scrum團(tuán)隊(duì)將遞交潛在可交付的產(chǎn)品增量。

????作為敏捷開發(fā)的實(shí)現(xiàn)機(jī)制蒋困，Scrum擁有以下重要特征：

1. 迭代開發(fā)盾似。在Scrum的開發(fā)模式下，我們將開發(fā)周期分成多個(gè)1-4周的迭代雪标，每個(gè)迭代都交付一些增量的可工作的功能零院。迭代的長(zhǎng)度是固定的，如果我們選擇了1周的迭代村刨，那么保持它的長(zhǎng)度不要發(fā)生變化告抄，在整個(gè)產(chǎn)品開發(fā)周期內(nèi)每個(gè)迭代都是1周的長(zhǎng)度。這里需要強(qiáng)調(diào)的是在每個(gè)迭代必須產(chǎn)出可工作的增量功能嵌牺，而不是第一個(gè)迭代做需求打洼、第二個(gè)迭代做設(shè)計(jì)龄糊、第三個(gè)迭代做代碼。
2. 增量交付募疮。增量是一個(gè) Sprint 及以前所有 Sprint 中完成的所有產(chǎn)品待辦事項(xiàng)列表?xiàng)l目的總和炫惩。在 Sprint 的結(jié)尾，新的增量必須“完成”阿浓，這意味著它必須可用并且達(dá)到了 Scrum 團(tuán)隊(duì) “完成”的定義的標(biāo)準(zhǔn)他嚷。無論產(chǎn)品負(fù)責(zé)人是否決定真正發(fā)布它，增量必須可用芭毙。增量是從用戶的角度來描述的筋蓖，它意味著從用戶的角度可工作。
3. 自組織團(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é)作的方式。
4. 高優(yōu)先級(jí)的需求驅(qū)動(dòng)网梢。在Scrum中震缭，我們使用Product Backlog來管理需求，Product Backlog是一個(gè)需求的清單战虏，其中的需求是漸進(jìn)明細(xì)的拣宰、經(jīng)過優(yōu)先級(jí)排序的。Scrum團(tuán)隊(duì)從Backlog最上層的高優(yōu)先級(jí)的需求開始開發(fā)烦感。在Scrum中巡社，只要有足夠1-2個(gè)Sprint開發(fā)的細(xì)化了的高優(yōu)先級(jí)需求就可以啟動(dòng)Sprint了，而不必等到所有的需求都細(xì)化之后手趣。我們可以在開發(fā)期間通過Backlog的梳理來逐步的細(xì)化需求晌该。

1.3 Sprint——沖刺

組成整個(gè)開發(fā)過程的一個(gè)短的迭代周期成為一次沖刺。一個(gè)Sprint是指一個(gè)1周－4周的绿渣、有明確生產(chǎn)計(jì)劃和產(chǎn)出的迭代周期朝群，由Sprint 計(jì)劃會(huì)議、每日站會(huì)中符、開發(fā)工作姜胖、Sprint 評(píng)審會(huì)議和 Sprint 回顧會(huì)議構(gòu)成，并產(chǎn)出可交付的產(chǎn)品增量淀散。也就是說右莱，每個(gè)Sprint結(jié)束即可向需求方提交一次版本更新蚜锨。
????Scrum采用迭代增量的方式，是因?yàn)樾枨笫怯楷F(xiàn)的隧出，我們對(duì)產(chǎn)品和需求的理解是漸進(jìn)式的踏志，Sprint長(zhǎng)度越長(zhǎng)，我們需要預(yù)測(cè)的越多胀瞪，復(fù)雜度會(huì)提升针余、風(fēng)險(xiǎn)也會(huì)增加，所以Sprint的長(zhǎng)度最多不超過4周凄诞。越來越多的團(tuán)隊(duì)使用2周的Sprint圆雁，很多市場(chǎng)變化快、競(jìng)爭(zhēng)激烈的領(lǐng)域帆谍，比如互聯(lián)網(wǎng)和移動(dòng)互聯(lián)網(wǎng)產(chǎn)品開發(fā)團(tuán)隊(duì)也會(huì)使用1周的迭代伪朽。
????每次沖刺可在超前完成工作計(jì)劃時(shí)提前結(jié)束，但必須在到期時(shí)結(jié)束汛蝙。關(guān)閉沖刺時(shí)烈涮，已完成的任務(wù)需要評(píng)審以確定是否真的完成，未完成的任務(wù)則須退回到待辦事項(xiàng)列表中窖剑。

1.4 Backlog——待辦事項(xiàng)列表

Scrum軟件開發(fā)是一個(gè)循序漸進(jìn)的過程坚洽，而用戶需求和技術(shù)實(shí)現(xiàn)通常具有相當(dāng)?shù)牟淮_定性。項(xiàng)目團(tuán)隊(duì)通常需要反復(fù)對(duì)需求進(jìn)行識(shí)別分析西土，創(chuàng)建工作分解結(jié)構(gòu)讶舰，估算工作量，并及時(shí)響應(yīng)需求和技術(shù)的不確定性需了。Scrum利用Backlog來管理用戶需求和任務(wù)跳昼，并通過及時(shí)梳理來響應(yīng)需求變更。
????Scrum的產(chǎn)品Backlog是一個(gè)按照商業(yè)價(jià)值（或?qū)崿F(xiàn)優(yōu)先級(jí)）排序的事項(xiàng)（需求）列表肋乍，記錄經(jīng)過識(shí)別鹅颊、分解和估算的用戶需求和任務(wù)。Jira系統(tǒng)提供的Backlog如下圖所示住拭。

1.5 Issue——事項(xiàng)

在Scrum中挪略，經(jīng)過識(shí)別解析得到的用戶故事、開發(fā)任務(wù)滔岳、測(cè)試得到的BUG等等統(tǒng)稱為事項(xiàng)（Issue）。

2.5.1 Story——用戶故事

用戶故事是從用戶的角度來描述用戶渴望得到的功能挽牢。一個(gè)好的用戶故事包括三個(gè)要素：

1. 角色：誰要使用這個(gè)功能谱煤。
2. 活動(dòng)：需要完成什么樣的功能。
3. 商業(yè)價(jià)值：為什么需要這個(gè)功能禽拔，這個(gè)功能帶來什么樣的價(jià)值刘离。

用戶故事以故事點(diǎn)（Story point）作為其相對(duì)大小的衡量單位室叉。故事點(diǎn)一般是指相對(duì)于某個(gè)標(biāo)準(zhǔn)故事而言，當(dāng)前故事所需付出的努力硫惕。由于故事點(diǎn)往往由相對(duì)比較法估算得出茧痕，因此其大小只有比較意義沒有絕對(duì)意義，也并不對(duì)應(yīng)具體工時(shí)恼除。

1.5.2 Epic——史詩(shī)

在Scrum項(xiàng)目中踪旷，Epic是指從用戶需求中識(shí)別出來的在一定程度上相互獨(dú)立、而內(nèi)部則相對(duì)聯(lián)系的需求集合豁辉，例如系統(tǒng)管理模塊令野、用戶認(rèn)證模塊等等。
????也就是說徽级，一篇史詩(shī)是由一系列用戶故事組成的故事集气破。通常用Epic大致描述系統(tǒng)模塊的功能概要或需求范圍，但不應(yīng)描述細(xì)節(jié)餐抢。

1.5.3 Task——任務(wù)

Task是明確定義了輸入輸出现使、技術(shù)指標(biāo)和其他具體要求的任務(wù)說明。對(duì)于從Story中具現(xiàn)的任務(wù)旷痕，一般直接從Story中開出Sub-task碳锈。如果Story足夠小，則不必再開出Sub-task苦蒿，可直接將Story作為任務(wù)交給具體人員去完成殴胧。

1.5.4 Improvement——改進(jìn)

Improvement指改善性的微小需求變更，是對(duì)已完成的用戶故事的細(xì)微優(yōu)化調(diào)整佩迟。這些調(diào)整一般不涉及具體功能的變更团滥，而是基于用戶體驗(yàn)的細(xì)節(jié)優(yōu)化，不足以形成新的用戶故事报强。

1.5.5 New feature——新特性

新增的用戶需求灸姊。并非對(duì)已有用戶故事的細(xì)化或者完善，而是指新的用戶故事秉溉。盡量杜絕在一次沖刺中間插入新特性力惯，應(yīng)當(dāng)把他作為用戶故事規(guī)劃到Backlog里，再根據(jù)其優(yōu)先級(jí)安排到以后的沖刺中召嘶。所以在JIRA中父晶，盡量不要?jiǎng)?chuàng)建New feature。

1.5.6 Bug——缺陷

測(cè)試人員在項(xiàng)目測(cè)試過程中發(fā)現(xiàn)的任何缺陷弄跌，都需要在JIRA系統(tǒng)中開設(shè)BUG甲喝，詳細(xì)說明缺陷細(xì)節(jié)，確定其優(yōu)先級(jí)和負(fù)責(zé)人铛只。由于公司的JIRA與測(cè)試管理系統(tǒng)TestLink相關(guān)聯(lián)埠胖，測(cè)試人員可以利用TestLink自動(dòng)創(chuàng)建Bug并生成缺陷說明糠溜。

2.6 Priority——事項(xiàng)優(yōu)先級(jí)

事項(xiàng)優(yōu)先級(jí)定義事項(xiàng)基于用戶需求、技術(shù)實(shí)現(xiàn)或其他利益攸關(guān)方的要求所確定的實(shí)現(xiàn)先后順序直撤。包括：

1. Blocker：最優(yōu)先實(shí)現(xiàn)非竿。在Bug中指阻礙開發(fā)或測(cè)試工作，無法繼續(xù)運(yùn)行谋竖，需要立即修復(fù)并且部署红柱。
2. Critical：重要。在Bug中指崩潰圈盔、數(shù)據(jù)丟失豹芯、嚴(yán)重的內(nèi)存泄漏。
3. Major：主要驱敲。在Bug中指主要的功能喪失铁蹈。
4. Minor：次要。在Bug中次要功能喪失众眨，或其他問題握牧，即存在簡(jiǎn)單問題。
5. Trivial：不重要娩梨。在Bug中指如單詞拼寫錯(cuò)誤或文字對(duì)齊美觀問題等沿腰。

1.7 Burn-down Chart——燃盡圖

燃盡圖（burn down chart）是在項(xiàng)目完成之前，對(duì)需要完成的工作的一種可視化表示狈定，向項(xiàng)目組成員和相關(guān)方提供工作進(jìn)展的一個(gè)公共視圖颂龙。

1.7.1 沖刺燃盡圖

Sprint燃盡圖用于展示沖刺周期內(nèi)故事點(diǎn)的變動(dòng)情況，理想情況下纽什，該圖表是一個(gè)向下的曲線措嵌，隨著剩余工作的完成，Sprint故事點(diǎn)“燒盡”至零芦缰。然而實(shí)際上企巢，每個(gè)迭代都有很多待開發(fā)的Story，在敏捷開發(fā)中让蕾，工作量的評(píng)估是以Story為單位的浪规，一個(gè)迭代Story的數(shù)量會(huì)影響到燃盡圖的Y軸。如果Story的數(shù)量過少探孝，繪制出來的燃盡圖就會(huì)呈明顯的折線形狀笋婿，也會(huì)對(duì)速度和風(fēng)險(xiǎn)的判斷帶來影響。所以顿颅，曲線未必能真的代表剩余的工作數(shù)量萌抵，也不能完美地作為管理層進(jìn)行項(xiàng)目可視化管理和績(jī)效管理的工具。但它可以反映出項(xiàng)目沖刺規(guī)劃元镀、管理和進(jìn)度控制上的一些問題绍填。
????以下是某項(xiàng)目某個(gè)沖刺周期的燃盡圖：

1.png

????圖中曲線在第二周時(shí)有三個(gè)時(shí)間段比較集中地下降，說明團(tuán)隊(duì)在這三個(gè)時(shí)間段比較集中地確認(rèn)任務(wù)已完成栖疑；圖中沒有比較大的向上的突起讨永，說明沖刺策劃工作還算不錯(cuò)，Scrum Master對(duì)沖刺有較強(qiáng)的控制力遇革，沒有在沖刺周期內(nèi)引入過多的新特性卿闹；最終曲線沒有到達(dá)零點(diǎn)，說明沖刺周期內(nèi)有任務(wù)未完成萝快，需要反思是否存在一個(gè)沖刺內(nèi)工作量過多還是锻霎、引入了新特性還是存在別的工作效率或團(tuán)隊(duì)協(xié)作的問題。
????而下面這張圖反映了項(xiàng)目團(tuán)隊(duì)對(duì)沖刺的策劃和控制可能存在更多的問題：

1.7.2 交付燃盡圖

對(duì)于PMO而言揪漩，交付燃盡圖可能比沖刺燃盡圖更具有實(shí)際意義旋恼。
????沖刺燃盡圖反映了一個(gè)Sprint內(nèi)工作的“燃盡”情況，而交付燃盡圖則展示了在更長(zhǎng)的奄容、可能跨越很多個(gè)Sprint周期的情況下冰更，軟件是否能如期交付某個(gè)版本或某個(gè)模塊。以下是某項(xiàng)目的某個(gè)版本的交付燃盡圖昂勒。

交付燃盡圖中蜀细，淺綠色的柱狀代表這個(gè)Sprint完成了的故事點(diǎn)數(shù)，所以前面加了個(gè)減號(hào)戈盈；
????淺藍(lán)色的柱狀代表奠衔，在這個(gè)Sprint開啟之前就存在的故事點(diǎn)數(shù)，在這個(gè)Sprint結(jié)束時(shí)還剩下多少塘娶；
????深藍(lán)色的柱狀代表归斤，在這個(gè)Sprint開啟后到下個(gè)Sprint開啟前這段時(shí)間，版本中增加了多少故事點(diǎn)數(shù)血柳，所以用加號(hào)官册。
以下通過2個(gè)圖例說明如何解讀交付燃盡圖。

1. 較正常的交付燃盡圖难捌，可以預(yù)測(cè)這個(gè)版本可以在什么時(shí)候交付

   
   
   
   

   兩條預(yù)測(cè)線膝宁，上面那條的由來是，淺藍(lán)色柱狀的頂部中點(diǎn)根吁，用最小二乘法計(jì)算的擬合直線员淫；下面那條則是深藍(lán)色柱狀的底部中點(diǎn)郑原，用最小二乘法計(jì)算的擬合直線暮的。兩條線斜率的意義是，每個(gè)Sprint故事點(diǎn)數(shù)完成的速率和故事點(diǎn)數(shù)新增的速率蒋伦。兩條預(yù)測(cè)線的交點(diǎn)對(duì)應(yīng)的橫坐標(biāo)代表這個(gè)版本預(yù)計(jì)會(huì)在哪個(gè)沖刺內(nèi)完成。

2. 存在較大的無法按時(shí)交付甚至永遠(yuǎn)無法交付的風(fēng)險(xiǎn)

   
   
   
   

   上圖兩條預(yù)測(cè)線圣蝎，縱坐標(biāo)軸的右側(cè)沒有交點(diǎn)刃宵，代表這個(gè)版本恐怕存在較大的交付風(fēng)險(xiǎn)，需要注意徘公。如果發(fā)現(xiàn)版本無法可能無法交付的時(shí)候可以選擇的策略牲证，一般是增加開發(fā)的速率，或者是減少一些當(dāng)前版本的故事點(diǎn)數(shù)关面，放到下一個(gè)版本中去坦袍。

1.8 Fist-of-five——舉手表決

舉手表決（Fist to five，fist of five）是敏捷軟件開發(fā)團(tuán)隊(duì)用于調(diào)查團(tuán)隊(duì)成員并幫助達(dá)成一致意見的一種技術(shù)等太。使用舉手表決技術(shù)捂齐，Scrum Master或PO重申該團(tuán)隊(duì)也許會(huì)采取的行為，并要求團(tuán)隊(duì)成員展示他們的支持級(jí)別缩抡。每個(gè)團(tuán)隊(duì)成員通過舉起緊握的拳頭或豎起對(duì)應(yīng)支持級(jí)別的手指數(shù)來回應(yīng)奠宜。如果一個(gè)團(tuán)隊(duì)成員舉起的手指少于3，他有機(jī)會(huì)陳述其反對(duì)意見缝其，團(tuán)隊(duì)會(huì)給出回應(yīng)挎塌。Scrum Master或PO繼續(xù)舉手表決過程直到達(dá)成一致意見（每個(gè)人都舉起的手指都不小于3）或同意轉(zhuǎn)移到下一話題。

• 緊握拳頭：不内边，我完全不同意榴都。
• 1根手指：我非常擔(dān)心。
• 2根手指：我想討論一些小問題漠其。
• 3根手指：我不完全同意但我可以接受意見通過而不須進(jìn)一步討論嘴高。
• 4根手指：我認(rèn)為想法不錯(cuò)且愿意為其工作。
• 5根手指：想法棒極了和屎，執(zhí)行時(shí)我愿意帶頭拴驮。

1.9 需求空間、開發(fā)空間和測(cè)試空間

通常柴信，一個(gè)項(xiàng)目的開發(fā)過程套啤，可以通過3個(gè)空間來進(jìn)行表達(dá)：需求空間、開發(fā)空間和QA測(cè)試空間随常。3個(gè)空間相互間應(yīng)當(dāng)是完全整合的潜沦，使得整個(gè)團(tuán)隊(duì)的不同職能能夠相互協(xié)作。其中：

1. 需求空間：存放绪氛、描述項(xiàng)目所有待實(shí)現(xiàn)的需求唆鸡，表現(xiàn)為Product Backlog，由PO主導(dǎo)并管理枣察，所有團(tuán)隊(duì)成員可以參與梳理争占。
2. 開發(fā)空間：包含項(xiàng)目正在開發(fā)實(shí)現(xiàn)的所有事項(xiàng)燃逻，表現(xiàn)為Sprint Backlog和Scrum Board，在Scrum Master 指導(dǎo)下由開發(fā)團(tuán)隊(duì)共同管理臂痕。
3. 測(cè)試空間：管理項(xiàng)目的測(cè)試計(jì)劃和測(cè)試用例伯襟，是項(xiàng)目的一系列質(zhì)量目標(biāo)和驗(yàn)收標(biāo)準(zhǔn)，由QA主導(dǎo)管理刻蟹。當(dāng)Sprint開始后逗旁，QA根據(jù)User Story編寫對(duì)應(yīng)的測(cè)試用例，加入QA空間舆瘪；當(dāng)開發(fā)人員提交到To QA后，QA根據(jù)測(cè)試用例執(zhí)行測(cè)試红伦，反饋測(cè)試結(jié)果英古。此外，還包括其他不同級(jí)別的測(cè)試計(jì)劃和用例昙读。