在軟件測試中有關敏捷項目基本步驟的介紹

一、根據發布目標分析需求，把需求分析成獨立的故事，初步的分析可以是粗略的，隨著需求的不斷深入刻意對故事進行整合或者切割。

        要注意的是分析出來的需求盡量在發布目標的范圍之內，超出發布目標的需求應該盡量避免過深分析。

        所謂的發布目標是確定了這個版本可以讓用戶滿意的條件。

        故事模式：做為（用戶角色），我可以（做什么），以便（業務價值）。后面的業務價值在比較簡單或者大家都比較明確的時候刻意不需要注明。

        當前團隊實踐推行方法：

        第一階段，這個分析工作開始由PM進行收集、整理和分析。

        第二階段，當大家都為用戶故事的方式接受以后，采用需求討論的方式來明確和分析用戶故事。

二、對分析的故事進行相對估計，估計出來的故事點是對用戶故事和復雜度的無單位估計值，使用的數值大小本身沒有絕對意義，只有相對于其他故事規模的相對意義。

        比如，用戶登錄這個用戶故事的估計值是2，那么做為同等開發規模的用戶推出，這個用戶故事的估計只也應該是2。

        當前團隊實踐推行方法：

        第一階段，這個估計的工作暫時由PM來負責完成，但是由于一個人的估計肯定會有偏差，所以在估計完成之后需要進行調查來進行修正。

        第二階段，用估計撲克會議來統一的對用戶故事進行估計，當主持人拿出一個新的用戶故事之后，大家給出自己對這個故事使用撲克打分，然后取出平均值，對差異較大的估計值要給出解釋，來消除對用戶故事的錯誤理解。估計撲克會議的實踐不超過１個小時。

三、準備產品調查，對用戶故事進行功能存在，和功能缺失性的產品調查，然后根據調查結果對用戶故事進行劃分，劃分成3類：基本需求，線性需求，非線性需求。

        此外還有反對的需求、存在疑問的需求、無所謂的需求3種類型的需求，這些需求將根據進一步的發展進行確認。

        當前團隊的實踐推行辦法：

        第一階段，由PM發出調查問卷在參與到項目的開發團隊、測試團隊、技術支持團隊來進行調查，然后匯總答案根據存在問題和缺失問題的答案，對用戶故事進行定性。

        第二階段，由PM發出調查問卷擴展到相關的用戶群體中進行調查，然后匯總答案根據存在問題和缺失問題的答案，對用戶故事進行定性。

        四、確定發布規劃，首先要確定的是迭代周期的長度，以周為單位，然后估計出每個迭代周期團隊的速度。然后可以從用戶故事池中選擇出合適的用戶故事來填充到第一次和第二次的迭代周期中。其余的暫時可以先不用填充，隨著每次迭代周期的完成來對發布計劃進行更新。最后根據估計的速度和需要開發的故事來確定需要幾個迭代周期，并最終有幾個迭代周期來確定需要開發的時間周期。發布計劃可以以功能來驅動進行，也可以以日期來驅動進行。 

        發布規劃的特點，以月做為時間范圍，規劃對象是用戶故事，估計的單位是故事點。

        當前團隊的實踐推行辦法：

        第一階段，使用1周做為迭代周期，開始時軟件測試團隊速度使用估計的方式做出簡單估計，根據每個周期結束后的團隊速度再進行發布計劃的調成。迭代周期內用戶故事的完成暫時以開發完成做為標準。

        第二階段，使用2周做為迭代周期，可以使用原有的歷史速度做為團隊速度，多出的一周時間做為測試修復時間，迭代周期內用戶故事的完成以測試完成，完整的功能提交做為標準，并在開發過程中熟練使用單元測試來進行確保功能的完整完成。

        五、確定迭代規劃，根據填充到迭代周期內的用戶故事來分解成工作任務，工作任務包括設計工作，不同層次的開發工作，調試工作和測試工作等等具體的任務，然后對任務進行估計，這時候估計的單位以理想工作小時做為單位。比如，設計需要兩個人小時，開發持久層需要1個人小時，調試持久層需要半個人小時，開發業務層需要2個人小時，調試中間層需要1個小時等。

        然后根據每個故事的人小時和這個迭代周期內參與的人數，以及每個人所能參與的實際有效時間（注意有效時間約為每天6小時，需要考慮到會議，討論，頭腦休息等非理想工作時間）來判斷這個迭代周期的填充是否足夠，如果不夠則再加入一個用戶故事，如果超出則移出一個用戶故事到下一個迭代周期中。

        迭代規劃的特點，以周做為時間范圍，規劃對象是工作任務，估計的單位是理想小時。

        當前團隊的實踐推行辦法：

        第一階段，使用速度驅動的方法來進行迭代規劃，即確定了本次迭代的速度，然后選擇用戶故事擴展成任務，對任務進行估計。

        第二階段，使用承諾驅動的方法來進行迭代規劃，即提出一個故事，把故事擴展成任務，對任務進行估計，讓小組承諾是否可以完成這個故事，如果可以在迭代周期內完成則加入這個故事，如果不能完成則推遲到下一個迭代走起。

        六、迭代開始，在迭代開始時召開迭代啟動會，分配迭代周期內的用戶故事和工作任務到個人，每個工作任務必須精確到個人，同一個用戶故事的不同工作任務可以根據情況適當分配給不同的人來完成。

當前團隊的實踐推行辦法：

        第一階段，任務分配給個人，通常一個故事的任務分配給同一個人。

        第二階段，任務分配給結對，通常一個故事的任務分配給同一個結對。 

        七、迭代進行，每日早對昨日完成的工作任務和問題進行匯報，并且同時計劃今天需要完成的工作任務，對于迭代過程中的進度和問題進行及時的觀察和調整，要求每個人完成某個任務之后要及時的告知整個小組知道（qq群的方式最為快捷）。

        當前團隊的實踐推行辦法：

        第一階段，由PM及時地對當日工作進行詢問。并負責把遇到的問題跑出來進行解決。

        第二階段，小組成員主動地對已經完成的任務進行匯報，并及時把自己遇到的問題拋出來。

        八、迭代結束，確認本次迭代完成的用戶故事，對于完成一部分的用戶故事計算到下一次迭代中。并對本次迭代的過程資產進行總結，形成FAQ方式的文檔進行規整。

        同時根據新的需求情況，資源情況，已完成功能的回饋，以及開發中遭遇的不確定性問題，對發布規劃和迭代規劃作出調整。

        當前團隊的實踐推行辦法：

        第一階段，使用學習網站，或者博客等方式對經驗進行記錄。

        第二階段，使用完善的skills對經驗進行記錄，可以方便的組織成培訓文檔，并方便的進行搜索，查找。

        九、迭代測試，為了保證用戶功能完整的提交，每個用戶故事開發完成之后都要對該用戶故事進行測試，然后在針對開發中出現的問題進行修復，以便完整的完成一個用戶故事。

        第一階段：測試迭代周期和開發迭代周期分開。

        每次迭代開始階段由PM告知開發組需要開發的和修復的的用戶故事，同時告知測試組本次迭代需要測試的故事，需要準備的故事，需要復測的故事。

        并在分配任務時，把修復故事的工作規劃到本次迭代中來。

        每次開發完成的用戶故事點算作本次迭代的速度。

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: 軟件測試 項目