敏捷測試(6) 基於story的敏捷基礎知識

2021-06-20 05:41:20 字數 2599 閱讀 2870

站會的目的有三個:

(1)周知進度

從使用者故事和任務的層面周知進度,任務進度只有兩種狀態:完成未完成(完成百分比)。

(2)周知計畫

你將會在下次會議之前做哪些工作?

(3)丟擲問題

哪些東西阻礙你的進度?(「沒有問題」,意味著你能夠交付自己當前的任務,而且符合估算的時間範圍)如果遇到需要解決的問題,可以在每日立會之後處理。

實現一項目的必要前提:

1.站2.敏捷專案必須提供能夠「安全失敗」的環境,團隊成員不會因為沒有達成任務承諾遭受懲罰。

大家要能夠安全說出任務狀態的真實情況,並且了解專案環境的現實情況。有時,我們的估算可能很糟糕(只是估算而已,又不是承諾),又或者某些事情的發生讓某些成員無法完成任務,整體環境必須讓他們能夠說出真實情況,這樣團隊成員就能調整他們的日程表,將任務排序,並調整適應專案的現實。

站會的主要內容:

最後主持人總結一下,然後根據實際遇到的問題,少數人進行線下溝通、跟進、解決。

站會的時間盡量控制在十分鐘左右。

開站會的一些技巧

(a)輪流主持

輪流主持能提高團隊成員的參與度,且如果主持人臨時有事,也不會因此無法開展,通常每次站會結束時指定下次站會的主持人。

(b)解決問題不放在會議中

(c)早上舉行

可以讓所有人按時來,按時工作。

可以讓每個人更清楚今天自己該幹什麼。

晚上每個人進度不一,作息時間不一樣,早上說昨天幹了什麼更準確。

有了迭代的總體計畫,還需要細化到對每個story進行管理,除了之前的估點外,我們使用卡片牆對其進行管理。

卡片牆如下圖所示:

需求池:所有新建的story(一般為未經過估點的)卡片貼在此處。

待開發:所有待開發的story卡片貼在此處。

需求池->待開發:講解溝通完需求、估完點、補充完驗收標準後,移動

開發中:所有正在開發的story卡片貼在此處

待開發->開發中:rd將story拆分完task,並給qa講解task實現思路,qa同意後,移動。

待測試:所有開發完成,等待qa測試的story卡片貼在此處。

開發中->待測試:rd開發完成story,且完成單測、整合測試編寫,和經過仔細的自測後,移動。

測試中:所有qa正在測試的story卡片貼在此處。

qa singn off:所有經過qa測試,qa認為可以上線的story卡片貼在此處。

測試中->qa singn off:qa經過仔細測試,bug都被修復驗證,認為story符合上線標準時,移動。

已驗證:所有經過pm驗收,可上線的story卡片貼在此處。

qa singn off->已驗證:pm在驗收環境中驗收,認為符合需求後,移動。

加速區:所有需要加速解決的story卡片貼在此處。如卡片中有block測試的bug急需修復,等。

block區:所有被一些問題block的story卡片放在此處。

卡片:story卡、task卡(story編號、估點數、使用者故事)。

角色卡fe、rd、qa的名字,以不同顏色區分,分別寫上人名,用於貼在story上。誰在做什麼,誰忙誰閒,有多少剩餘人力,一目了然。

上線時間:略。

使用燃燒圖,計畫及其變化,以及每天進度一目了然。

燃燒圖如下

1、x軸為時間,一般是迭代週期的每一天;

2、y軸為工作量,根據專案情況,可以用已完成估點或已完成story點數來表示;

3、最開始,計算出本次迭代要完成的所有工作量(作為y軸刻度,迭代天數作為x軸刻度),然後,每天站立會議時,了解前一天已經完成的工作量,並計算出迄 今為止完成的工作總量。把其畫在y軸上,以此類推(並把y點連線成線)。如果計畫比較(理想)準確,燃燒圖的最後一天」燃燒「折線將和總工作量折線相交;

以上五項,簡單易實現,用很低的時間成本就能做出「計畫」,並保證計畫的落實,且能快速適應變化!

敏捷測試(7) 基於story的敏捷基礎知識

除需求講解意外,需要所有團隊成員參加的會議僅有兩個,分別是 迭代啟動會 和 迭代回顧會 在迭代開始之前,需要召開迭代啟動會,目的有以下兩個 明確迭代週期,即上線時間 明確迭代目標,即以什麼樣的優先順序,交付哪些story。在明確了迭代週期和上線時間後,按照前面提到的 迭代規劃 來開迭代啟動會即可,在...

敏捷開發 敏捷測試

敏捷測試的定義 首先敏捷測試是敏捷的一種,原有測試定義中通過執行被測系統發現問題,通過測試這種活動能夠提供對被測系統提供度量等概念還是適用的。在傳統的測試定義上,還需要新增 敏捷測試是遵循敏捷宣言的一種測試實踐 強調從客戶的角度,即使用系統的使用者的角度,來測試系統 重點關注持續迭代的測試新開發的功...

敏捷開發與敏捷測試

敏捷開發 1.敏捷型方法是 適配性 而非 預設性 重型方法試圖對乙個軟體開發專案在很長的時間跨度內作出詳細的計畫,然後依計畫進行開發。這類方法在計畫制定完成後拒絕變化。而敏捷型方法則歡迎變化。其實,它們的目的就是成為適應變化的過程,甚至能允許改變自身來適應變化。2.敏捷型方法是 面向人 的 peop...