JB的測試之旅-項目流程規範

事前藥

本文閱讀時長約10-30分鐘，建議先瀏覽下總綱，不少細節不必定是通用的，主要仍是想引導你們爲何這麼作，而不是套模板，靈活比什麼都重要，這個是初衷；

內容是全體測試同窗及老大共同參與整 理，並獲得了公司各職能的承認，目前已經在對某些團隊宣講及試點，並會不停優化整個流程，指望能造成一個好的團隊合做模式；

從內容而言，算是一個大而全的輸出，建議不一樣同窗靈活運用，根據不一樣團隊制定合適的流程和規範；

前言

隨着互聯網的飛速發展，企業爲了爭奪市場而快速迭代，隨之而來的，就是敏捷、免測、自動化等一系列規範化的誕生，爲的就是確保項目在高速迭代時依然能保持好的質量及團隊配合；

而測試是處於整個迭代的最下游，一旦上游出現delay，項目在不延期的狀況下，就會壓縮測試時間，從而產生上午寫bug，下午發佈的狀況，而這狀況愈來愈廣泛；

在這種環境下，測試人員壓力很大，甚至喘不過氣，並且bug發佈後，一旦有線上問題，就歸根到測試沒有發現問題等，致使人員內心愈來愈疲憊，說句話說，員工感受不到幸福感；

而這種狀況，每每在小公司裏會更明顯，由於流程不清晰，各類不規範，產品亂插需求等等，很不巧，jb也遇到，正如上面說的，亂排優先級、delay屢見不鮮，老闆一看，什麼，又要delay？怎麼搞的啊！ 不用測試啦，快速迭代，而後出問題又怪到 測試這，怎麼那麼多問題等；

正如彈簧通常，被壓久了，就失去彈力，習慣了是個很可怕詞語，一旦習慣了，就麻木了，人就漸漸失去激情了；

爲了改變這種現狀，測試團隊及老大（技術負責人）也想改變這種狀況，所以就有了下文的內容，主要是制定一系列的項目流程規範，跟各職能達成共識，嚴格循序；

作什麼？

既然老大都支持作這個事，那就思考下要作什麼吧？

常見的項目流程應該是這樣的：

• 需求文檔；
• 評審；
• 工做量評估；
• 制定項目計劃，立項；
• 開發；
• 提測；
• 測試；
• 延期&需求變動；
• 驗收；
• 上線；
• 結項；
• 線上問題跟進；

好像，大概，流程就是這樣啦，沒啥毛病；

可是，夠了嗎？但是要站在項目的角度想這個事情呢；

通過一輪腦暴，發現是還有不少細節，如：

• 職責；
• 開會效率；
• 郵件；
• 請假；
• 團隊意識；
• 辦公室命名；

還有嗎？確定還有的，只是沒想到而已，但畢竟不是專業的項目經理，那先把想到的搞定先吧；

按照上面說的，會分幾塊：

項目迭代流程、職責分工（針對項目跟產品）、團隊意識、開會、郵件、請假、 通信工具（如某釘、某信）；

總綱

項目迭代流程

1.產品經理創建confluence版本目錄;
新項目就先建新空間;
全部文檔按照文檔組織規範來存放；
2.產品經理收集各方（運營、客服等）需求後撰寫需求總表，包含需求概述（一到兩句話）和優先級;
3.需求文檔：按照需求總表的順序出，每一個需求的細緻程度和優先級一致;
寫需求期間設計師同步作設計初稿;
4.負責人評審：由研發、測試的主管評審可行性和資源可用性（人力、服務器等）;
簡單的需求不必定須要開會;
5.設計師初稿：有客戶端或前端參與的需求，初稿要在全體評審前要作出來。
期間設計師有機會先提出產品文檔缺陷;
6.全體評審：全部實際參與項目的同窗參加。儘量提早發現缺陷;
7.工做量評估：各職能給出時間長度和依賴關係，彙總給項目經理排期;
8.排期，立項：項目經理髮出郵件，包含全部的信息;
設計師標註切圖;
9.開發設計評審（通常小於10個工做日的需求不須要，具體由研發主管判斷）;
10.測試用例評審（通常小於10個工做日的需求不須要，具體由測試主管判斷）;
11.開發，提測;
12.測試：先準備好冒煙測試案例給開發。每輪測試撰寫測試報告;
全部人均可以去報bug;
13.延期和需求變動;
14.加班;
15.驗收、上線：發佈後運營和測試再作一輪冒煙測試或持續監控，達到放量的標準才叫完成上線;
16.結項：數據分析、覆盤，項目經理彙總後發郵件;
17.線上故障;

專項版本流程

專項版本的特色是獨立版本項目，不跟隨版本迭代的需求； 在項目空間的根目錄建一個文件夾存放項目相關的內容； 肯定搭車哪一個版本上線後，能夠把全部文檔轉移到那個版本的目錄下；

具體流程規範儘可能和版本迭代流程保持一致。

職責分工

產品經理對結果負責，項目經理對信息傳遞負責，各職能主管對流程負責。

項目經理的核心做用是信息樞紐，主要職責：

• 制定和優化項目流程規範；
• 收集工做量評估，排期，確認里程碑時間，若有必要可召開立項會議，最終發出立項郵件；
• 結項會議主持；
• 解決團隊資源衝突，肯定項目的優先級，協調人力資源；
• 發現團隊合做中能夠提高工做效率的地方，並推進解決。例如建設產品的axure預覽空間；
• 發週報郵件；
• 對團隊的問題作監督、總結、給解決方案；

產品經理：

• 確保需求經過評審，獲得各方確認，並宣佈立項；
• 收集來自運營、商務、客服的需求，作成需求文檔安排到版本迭代中；
• 接收客服的反饋，bug就轉交給測試跟進，產品建議則統一回復，若是須要處理及插入到各版本迭代計劃裏；
• 版本發佈的最終決定人，即時有問題，只有產品贊成，均可以發佈；

團隊意識

1.目標導向，不是爲了任務而作任務；
2.全部規則都不是死的，哪些要哪些不要，要具體地判斷，按時高質量完成是最基本的目標；
3.全部事務都有優先級順序，若是不清楚的話就詢問上司，直至boss；
4.及時反饋，並通知到應該知悉的人；
5.團隊互助：別人作得60分，若是你抱怨着等別人完善，你也是60分；
6.項目安排一旦定下來就是個承諾，可否兌現是職業素養的體現；

開會

1.主持人要作好時間控制，儘可能一小時內討論完；
2.開會要說明會議目標和議程；
3.按需寫紀要：討論內容與結論，須要跟進的問題和責任人；
4.按時參會，有事不能來或遲到應該告知主持人請假；
5.在提早2小時有通知並說明了遲到要發紅包的前提下，會議主持人能夠要求遲到未請假者發紅包，總額按參會人人均X元；

郵件

1.何時要發：須要跟進和後續查閱的事項；
2.推薦使用foxmail爲客戶端，也可直接使用釘釘；
3.郵件標題，簡明扼要，若是緊急，寫上【緊急】、【項目週報】、【測試周報】，以此類推；
4.稱呼：寫清楚是對誰說的，對全體就是「Dear All」；
5.要有簽名欄，至少有本身的名字；
6.抄送：本身的上司、涉及人員的上司（至部門一級）；

釘釘

1.每一個項目組建一個羣，拉上全部實際參與的人和各級主管；
2.項目事情不容許創建小羣來討論，只要是說正事就不要怕打擾人。
只有討論非工做事宜的才能建，例以下午茶羣。

請假

務必保證上司知悉。
若是本身身上有重要任務，必須讓項目組也知悉。

晨會

在項目迭代較快的時候，都要求進行晨會，目的是快速同步信息，瞭解進度，若是有遇到問題，也及時提出，讓對應負責人推進，避免一切延期的風險；

在晨會反饋時，須要技巧，不能這樣：XX功能進度正常，按照原計劃執行；

應該是須要反饋作了什麼事情，這個事情的進度，大概何時完成，這個事情不是一個項目，而是拆分出最小的一個功能，好比：

昨天作升級功能，界面及接口聯調已經完成，進度60%，今天會進行防劫持功能開發及自測,今天內開發完畢；
複製代碼

小結

看到這裏，是否是以爲很繁瑣？這種雞毛蒜皮的事都要管？
沒錯，看上去越是雞毛蒜皮的事，每每倒是最重要的，互聯網時代，什麼都要高效、注重用戶體驗，這些事情都不例外；

那接下來，就針對項目迭代流程裏的每一個小點進行說明吧；

文檔組織規範

總則

全部文檔以Confluence（下文簡稱cf）爲中心作管理，cf不方便存放的東西才放到svn。

項目組的釘釘公告欄只放置版本頁的cf連接和當前版本的提測記錄。

CF規範

每一個項目由產品經理或項目經理建一個空間。

目錄規範以下：

• 主頁
• • 通用文檔，包括第三方文檔、全局術語表、全局信息（測試服務器地址、svn地址）等，跟具體版本無關聯;
• • 專項文檔，跨版本的需求統籌、跟版本無關聯的運營活動需求;
• • x.x.x（版本號，按具體版本劃分）
• • • 需求總表；
• • • 立項。能夠不獨立成文檔，只存在於郵件或釘釘公告欄裏便可，或在需求總表文檔上回復；
• • • 各個需求文檔，以需求名稱命名文檔名。若是用axure，在這裏填寫svn地址，還能夠包括預覽空間的url地址；
• • • 測試文檔，以做用命名文檔名，主要是用例，可放svn。測試報告只存在於郵件中，若是不嫌煩能夠在需求總表的文檔那裏作回覆；
• • • 結項。這個必需要，不能只在郵件裏；
• • 垃圾桶（廢棄的需求、再也不使用的第三方文檔等移動到這裏）

SVN規範

目錄規範以下：

• 根目錄

• • 小程序(按產品形態或者具體業務來分，任君選擇)
• • • A項目
• • • • 設計文檔
• • • • 接口文檔
• • • • 測試工具
• • • • x.x.x（版本號）
• • • • • 需求文檔（axure源文件和導出的html文件夾、各個需求的word，以需求名字命名）；
• • • • • 設計文檔
• • • • • • ps源文件，設計稿、標註、切圖
• • • • • 測試文檔
• • • • • • xmind、excel用例整理
• • • B項目 ...

需求總表

表格格式

需求名稱	優先級	產品	UI	前端	後端	測試	運維
A需求	核心	JXX、BXX	JAX	BAX	JBAX	JXX	BXX
B需求	高	AXX、CXX	EAX	DAX	FAX	EXX	IXX
A需求	核心	JXX、BXX		BAX	JBAX	免測	BXX

列填寫

• 「需求名稱」和「優先級」由產品填寫。
• 需求名稱：只能是1句話。 若是這都作不到，這個需求確定不清晰;
• 以優先級排序。 優先級說明： 核心：必作，先作，不能砍，不作完就不發佈新版本。可單獨造成一輪提測。 高：必作。條件不容許的話能夠下降爲中優先級。可單獨造成一輪提測。若是存在多個高優先級，則產品繼續細分； 中：若是時間容許，會作； 低：能夠不作； 優先級還能夠用分數來表達，如核心100，高是99-90，從而充分體現各高優先級裏更高優先級的需求；
• 各職能人員名單，由對應主管決定，誰填寫均可以。 若是人很少，直接寫在表格外更好；

執行說明

• 產品應該先寫總表再寫需求文檔，需求文檔的完善程度與總表的優先級是一致的，優先級低的需求還能夠在覈心需求開發過程當中再完善;
• 怎樣算是一個需求？（成爲表格裏的一行）
• • 跟其它需求無關聯；
• • 能夠和其它需求並行開發的，多人合做不會產生交叉；
• • 優先級相同且屬同一個模塊，容許合併；
• • 重要的bug能夠做爲需求列上來；
• • 運維的工做獨立算成需求；
• 整個項目組都按優先級作。 核心和高優先級的能夠作完一個提測一個；

需求文檔

前置說明

文檔的標題是1句話，跟需求總表裏的一致。

• 需求描述的基本要求：條理清晰，邏輯嚴謹，用詞專業，格式規範，易於閱讀，重點詞句標紅；
• 全體評審時，需求文檔上應該是設計稿，而不是原型圖，避免實際開發/測試時大量出現設計稿跟原型圖不相符的狀況；
• 若是是基於舊需求的補充完善，把舊需求複製到新版本，加上修訂記錄並標記修改的部分。

寫做思路和本模板的設計原理

請參考 www.woshipm.com/pmd/1579154…
本文是公司大佬在人人都是產品經理髮表的文章，也獲得的產品經理的承認；

實際的示例，能夠參考 www.woshipm.com/evaluating/…
但請注意要靈活運用，本文是來自於人人都是產品經理的文章，算是比較全面的文章；

修訂歷史

版本	日期	修訂人	修訂內容
V1.0	18.9.27	jb	第一版
V1.2	18.9.29	jb	需求評審，修改XX功能
V1.3	18.10.28	jb	需求變動，緣由是原來功能沒法實現
V1.4	18.11.01	jb	1.增長XX功能，2.修改XX文案

目標

包括但不限於如下內容：

• 解決什麼問題、痛點；
• 此需求自己達到多少使用率、轉化率；
• 此需求能提高多少PV、UV、交易額等。（須要脫敏寫百分比，不須要就寫絕對值）；

主要是防止無腦、拍腦殼需求，凡事要用數據推進，有理有據，讓團隊都知道作這個事的目的，同時也避免浪費資源卻沒有好的結果；

術語表

術語	說明
自動還款	...

哪些東西須要在術語表裏列出？

• 沒有標題的頁面、區域，內部怎麼統一叫法；
• 新功能的名稱；
• 特殊的叫法、代號；
• 一些流程的簡稱；

以前在負責seo項目的時候就出現過，同一個功能，產品、前端、測試、UI各有各叫法，致使溝通形成成本；

參考資料

（這裏放關聯需求和第三方文檔資料，沒有就不須要這部分）

產品結構圖

暫定新項目必定須要此章節，緣由是梳理產品結構圖須要時間，在產品迭代如此快速的狀況下，功能可能每一個版本都在變化，考慮到人力成本，讓產品每一個版本去維護也不可能，由於先要求新項目必定須要，迭代中的項目，酌情處理，能有是最好的；

原型和說明

• 若是用axure作，不要把axure的截圖貼過來，這裏直接放導出網頁的svn路徑，還可放上http空間的連接，方便你們在線閱讀，省得處處找文檔，其它工具畫的圖才截圖;
• 若是整個需求能用簡單圖文說清楚的，就不要用Axure，直接用cf簡短寫;
• 不強制要畫流程圖、狀態表，只要能表達清楚完整，什麼形式均可以；
• 前端和客戶端混合的需求，應標記一下是哪一個端的實現；

非功能性需求

• 性能
• 統計
• 安全
• 兼容性：系統(iOS8，Android4.4)、分辨率&尺寸(4.7寸、長寬比>19：7的屏幕)、瀏覽器（Chrome、ie、火狐）

需求評審和工做量評估

兩輪評審

流程：

• 預審：產品提早2小時發出通知和初稿（不須要完善細節，能夠只是原型），召集主管或負責人預審; 未必須要開會，只要每一個人能確認需求沒大問題就好;
• 全體評審：產品提早1天發出通知和需求連接（設計師已出完初步設計圖），全體人員參加； 應該在會前審完大部分問題，而不是會後；會上只是查漏補缺；
• 跟運營有關的需求，應該在全體評審前由運營先審覈完畢；
• 產品經理根據問題修改完畢後，逐個找負責人確認。
• 都經過後，發出通知通知；
• 項目經理收集工做量評估進行排期，並在各方確認後發出立項郵件；

要求：

• 全體評審不能在上個版本未上線的時候進行，要給參會人足夠的時間精力作好評審；
• 若是問題太多，應該再舉行一次需求評審；

預審

核心做用就是向開發打招呼，知道要作什麼，好安排人力資源。 因此產品文檔不須要很完善，但必定要交代清楚目標和核心的功能點。

召集開發測試的主管或負責人簡單過一遍便可，主要是評審可行性。

不須要預審（免測）的條件：

• 開發工做量小於5個工做日；
• 改UI爲主，沒有難度；

評審要評些什麼？

全部人都要評的：

• 目標是否清晰；針對目標，需求的設計是否合理；
• 針對需求：不完善的地方、影響範圍、用戶體驗； 儘可能在寫代碼前發現需求問題；
• 具體工做量；
• 時間安排：限時上線的就砍需求，不限時就由你們來決定發佈時間；
• 風險點：全部致使評估不許和項目延期的可能性；

特別注意地：

• 技術要評估可行性，影響開發時長的難點，是否須要預研；
• 測試要評估測試資源的充足性（例如測試設備）、自動化測試可行性；
• 運維要評估服務器資源的充足性；

工做量評估

按照每一個需求來評，各個職能都評。

以0.5人天爲最小單位。

一個關於戰鬥力的評估法：

列出參與這個項目的全部人員。爲了便於描述，咱們把其中能力最強或工做效率最高的人稱爲A。A一天（除去加班、
小憩時間）能完成的工做量定義爲1人天，同時把A的戰鬥力定爲1.0。這個需求按照A的標準要幾天才能完成，
則它的工做量可量化爲多少人天。

再對其餘人員逐一跟A比較作評估，若是B一天能完成的工做量是A的70%，則把B的戰鬥力定爲0.7。

假如還有C的戰鬥力0.5，則這個團隊的總戰鬥力爲1.0+0.7+0.5=2.2。若是某個需求的工做量是11人天，則最理
想的狀況下，這個團隊須要用11÷2.2=5天來完成。

團隊的人越多，花在溝通上的時間也會增多。再加上可能有評估不許、部門會議、臨時請假的狀況，在估算整
體所需時間時，應乘以一個係數，例如1.2，來做爲最終時間。即上例中，應爲5×1.2=6天。相似地，若是要996，則可乘
以一個小於1的係數，能夠是0.85。

在實際狀況下，並不是全部團隊成員都全天參與此項目，同時參加多個項目的狀況很常見。若是A對本項目只投入一半
的時間，則團隊的總戰鬥力應算成1.0×0.5+0.7+0.5=1.7。
複製代碼

設計師流程規範

前置說明

• 這裏只關注影響合做的規範，跟「好很差看」有關的標準是設計師內部的專業規範，這裏不涉及。
• 程序員指望的設計師能力，可參考https://www.zcool.com.cn/article/ZODIyODM2.html

設計圖規範

預審的目標是讓負責人評估可行性，設計稿着重表達出樣式的位置、形狀和交互便可，是原型仍是設計稿都不要緊。

全體評審的目標是讓開發準確評估工做量。對工做量影響極小的東西能夠不是終稿，例如顏色值、字體大小、間距。

終稿可在各需求實際寫代碼前肯定，容許在驗收階段再進行不須要測試迴歸的微調，當面調試的須要記獲得同步回設計稿。

切圖規範

• 設計師自身維護全部的圖片，每次都是給開發全部的切圖（包括新增和剔除廢棄），且同一張圖或有小改動但放在原位的圖文件名不變，自身知道哪些圖片在這個版本不須要了；
• 全部源件不是拆分版本上傳svn，每一個版本下都是保存當前用到的全部東西；
• 切圖文件按規範命名，全小寫英文，下劃線鏈接；
• 寬高應是偶數；

對某些組件是否在切圖中應用透明邊距和對應作標註，應統一風格。

標註規範

• 最好能有全局規範；
• web項目字號不能低於12px，app項目不能低於10px；
• 全部大小均爲偶數；
• 標註很差說明的，應使用文字說明；

命名規範

UI文件的命名規範，可參考下方：

排期和立項

術語解釋

• 里程碑（時間）：重要的時間節點，例如提測、發佈，來自英文milestone。 風險點：任何可能形成項目延期的事項 立項：通過核心和高優先級的全體需求評審後，由項目經理收集各職能的工做量、風險、所需資源評估，協商得出里程碑時間，發出郵件。
• 每輪提測叫t一、t二、t3，t = test；
• 每輪提測內提交的修改，叫patch；
• 合起來看：第2輪提測打的第3個tag，叫t2p3；
• 全功能提測：全部在本版本要上線的需求都作完了，也可讓UI提早驗收；

關於提測，不少大型公司叫rc1，全稱是Release Candidate的縮寫，意思是發佈倒計時，這個階段大多數用於集成測試後的版本；

通常的不一樣流程的命名以下：

beta、rc、trial、release、patch、hotfix
複製代碼

項目排期

排期目標：

• 每一個需求的職能依賴關係以及時間表，好比前端依賴ui和後端，被依賴者何時作完；
• 分幾輪提測，每輪的時間點，提測內容，「核心」和「高」優先級的需求，均可造成一輪提測；
• 發佈時間；
• 風險點；

里程碑時間安排示例：

• t1：11.2，需求A、B。UI在11.1前給出，後端接口在11.1前準備完畢；
• t2（全功能）：11.5；
• t3：11.7；
• 發佈：11.8；

可能的風險點：

• 參與人員業務不熟；
• 長假的先後，工做效率低；
• 人員請假；
• 第三方服務或政策因素；

版本管理

版本號格式：x.x.x，說明：

• 有新需求，第2位+1，第3位置0
• 大改版，第1位+1，第二、第3位置0
• 小bug改動，第3位+1

立項郵件

收件人：項目組釘釘羣

標題：【立項通知】xxx（項目）y.y.y（版本），例如 【立項通知】XXXX產品3.2.4

正文：

Dear All，

本期項目共有5個核心和高優先級需求，3箇中低優先級需求。有12我的參與實際工做。具體請看需求總表【url】；

項目週期：10月4日-10月18日，共10個工做日

里程碑：

1. t1：10月12日（週三）。提測需求A、B。UI在10.10前給出，後端接口在10.11前準備完畢
2. t2：10月13日（週四）
3. t3（全功能）：10月18日（週二）
4. 發佈：10月20日（週四）

風險點：
1.新同窗加入實現需求A，業務不熟，可能會延長解bug時間
2.需求B須要技術預研，預留時間未必準確。請 @xxx 隨時彙報進度
第三方合做商xxx在月中要進行數據遷移，影響咱們對接
複製代碼

如何作版本規劃

需求池，關聯度梳理，拆解，優先級評估，迭代週期，專項；

版本規劃的目的

在現代社會市場和需求變化快的狀況下，產品經理制定迭代週期短的產品規劃，可根據市場的反饋，及時調整產品下一個迭代的需求功能和產品形態以知足公司的戰略和業務需求；

需求池

產品經理在作產品設計以前，都會建立一個需求池，用來收集各類需求，防止有遺漏的需求和方便對需求的梳理； 由產品經理管理維護，項目相關人員補充內容； 不管需求是否可行，項目相關人員均可以將需求填進需求池中，且無數量的限制； 需求梳理時，產品經理可從需求池中分析和篩選； 製做需求池的方式有兩種：文檔表格和OA系統。表格內可含如下內容：

• 需求名稱（必選）：
• 需求描述（必選），詳細描述需求功能，有如下分類：
• • 用戶需求：用戶想要的功能；
• • 業務需求：賺錢的功能；
• 需求類型（可選），包含如下分類：新增功能、功能優化、Bug修復、體驗優化；
• 來源（可選），包含如下分類：戰略規劃、競品分析、用戶需求、運營市場反饋；

需求梳理

產品經理收集完成產品需求以後，對需求池中的需求進行分析，梳理出需求功能結構圖，爲產品迭代提供方向； 需求分析時，可執行如下操做：

• 需求合併：合併同類型需求。
• 需求刪除：篩掉不合理、不符合產品定位的需求。
• 需求關聯：梳理需求之間的依賴關係，
• 需求拆解：將需求拆解成一個個可實現的功能，造成需求功能結構圖，可用腦圖表示；

需求優先級評估

需求優先級的評估就是在有限的資源（時間、人力、硬件），產品經理安排優先作的需求功能，以達到產品的階段性目標，符合公司的價值；

可按如下優先級排序：

• 公司戰略： 公司戰略指定的核心功能/業務需求，能爲公司帶來直接收益；
• 利於日活/拉新： 可以有效的提成用戶活躍度和用戶量；
• 功能優化、Bug修復、體驗優化： 這類主要就是用戶體驗類，提高產品的使用滿意度；
• 提高運營、運維效率：減小成本；

迭代週期規劃

迭代週期就是要一個迭代從開始時間到結束時間的時間窗，完成設計、開發、測試、上線等活動；

固定的迭代週期就是固定的時間窗，有如下好處：

• 創建團隊的節奏感：有預期的節奏，容易讓團隊造成習慣，團隊生產效率更規律；
• 下降協同成本：可以並行的去安排多個迭代的規劃，評審等活動。每一個人都知道這些活動何時進行，減低溝通和協同成本；
• 簡化規劃活動：固定的迭代週期，固定的人力，固定的產出交付，有利於產品規劃的合理性；

短週期：10個工做日（兩週）之內的時間窗； 長週期：10-20個工做日（一個月）的時間窗；

根據需求優先級，團隊的實際狀況，選擇合適迭代週期，通常須要考慮如下因素：

• 項目週期：短週期迭代，快速取得反饋意見並改進；
• 需求數量：需求越少，採用短週期；
• 不肯定的因素：項目組的工做效率、技術門檻等； 不肯定性越多，就應該採用短週期迭代；
• 需求優先級變化：頻繁更改優先級，採用長週期迭代；
• 迭代系統開銷：每次迴歸時間成本很高，採用長週期迭代；

專項

專項是在項目預審或需求評審時，涉及範圍（多部門合做、代碼重構、功能優化）大，時間窗超過長週期的，須要專門設立的項目；

專項是全部項目集中優先級最高，安排專人負責項目，集中當前的人力資源優先解決問題；

專項的特色：

• UI/UX 大幅度修改，耗時10工做日以上；
• 系統代碼重構；
• 時間窗超過20個工做日；

如何作好專項：

• 適當調整其餘項目的優先級，由組長介入分配參與此項目的人力；
• 專項組員當前只負責當前專項工做，確保項目不被其餘項目干擾，定期完成；
• 項目負責人按期去推動；

產品和UI協同規範

產品經理在描述某個需求功能有多個異常狀態時，在產品文檔用不用顏色的文字或者表格來強調突出；

由UI同窗在畫高保真設計稿時，針對不一樣狀態來進行設計；

有助於產品經理在驗收UI設計稿的時候，針對功能點和多種異常狀態的驗收；

運營介入需求

運營提早提早確認產品需求功能和迭代，確保當前迭代是符合產品總體規劃，有利於團隊協同效率；

但過多的流程會致使運營作很差自身的工做，所以簡化以下流程：

• 產品經理制定產品迭代規劃，需告知運營，如運營有異議，可溝通及時調整；
• 產品經理在預審時，需告知此版本迭代需求，如運營有異議，可溝通及時調整；
• 產品經理在需求評審時，提早通知項目組員，包括運營人員，進行產品的文檔修正，如產品文案等；

開發規範（待梳理）

待梳理的緣由是，開發規範目前來講是最內部的，優先級應該是最低的，所以暫時不考慮，大體會涉及到這幾個內容：

代碼風格規範
api規範，數據結構、文檔規範
git 分支和log規範
review制度
對外文檔規範
設計文檔：數據庫結構、系統設計圖
複製代碼

提測流程和免測標準

規則

• 右前端、客戶端、後端參與的需求，由對應開發來提測；

流程

• 開發自測，確保主路徑沒問題，若是測試組有提供冒煙測試，必須冒煙都經過；
• 在釘釘公告欄寫上本次提測的tag和測試重點，每一個版本內累計更新，不要覆蓋上次的內容
• 若是質量不過關，測試能夠打回；

提測通知示例

（術語解釋參考排期和立項）

前端t1 2.3.3/1803031104 已自測，自動XX、UI改版
前端t2 2.3.3/1803041203 未自測，XX
前端t2p1 2.3.3/1803051404 …… 解決一個崩潰，會影響全部須要登陸的界面
iOS t3 2.3.3/1803061203 已自測，全功能提測
後端t1 1803061203 解決xxx問題
複製代碼

patch的提交頻率以天爲單位，不建議解決一個bug就提測一個patch； 若是實在須要，應該開發和測試同窗單對單地驗證完畢，而後發patch時再由測試迴歸多個問題；

前端、後端、小程序、H5這種沒有tag概念的話，就用當前日期處理；

打回

標準：

• 測試環境沒搭好（提供部署環境的代碼時未提供部署文檔）；
• 主路徑跑不通；
• 開發未經過冒煙測試用例；
• 開發未寫明測試重點、修改代碼的影響範圍；
• 開發未提供相關數據庫設計文檔、接口設計文檔；

通知：

• 釘釘羣裏 @全部人 來通告，說明緣由；

免測標準

免測的前提是確認測試已知悉，而後纔是下面的條件：

• 只改UI佈局或文案，沒有改交互和業務；
• 只是改後臺報表統計；

測試報告

撰寫原則

• 最終目標不是故意找茬，而是讓管理者知道哪一個環節有問題，能及時作調整；
• 要能反映質量，不要寫成在描述需求或業務；
• 質量問題要具體到職能或人；不能模棱兩可，看不出誰要爲問題負責；
• 記錄測試手段，爲線上故障的漏測找依據；

郵件模板

收件人：項目組的釘釘羣 抄送：測試組的釘釘羣 標題：【測試報告】xxx項目y.y.y（版本）[第z輪|release]，例如 【測試報告】jb項目1.2.1 t1

正文：

Dear All， 1.結果概況

結果：[經過|有條件經過|失敗打回]； [有條件經過的緣由]：產品贊成部分bug不影響發佈，並已知曉問題風險，贊成下次解決；

（一兩句話總結項目質量）例如：開發比上一版本的質量有明顯提高，需求變動數也少了，給你們點個贊！

遺留問題數：x個。

（很少的話下面直接列出來，帶有禪道url的超連接）

2.質量報告

質量指標：

• 需求變動數：10個，增長工做量：20人天；
• 測試案例一次經過率：76%；
• bug總數：108個；
• 性能指標：api接口平均響應時間：400ms；
• 兼容性：測試設備（列表見過程記錄）中沒有發現兼容性問題；
• 每輪提測的patch數；

bug分佈： 一系列的餅圖，數量和百分比。維度：責任人、報bug人、出錯緣由、嚴重程度、解決耗時、異常狀態（打回和從新激活）；

本輪測試後，處於未關閉狀態的bug，責任人分佈：

3.過程記錄

需求與測試人員參考立項文檔：(url)

案例狀況：

• 數量：76個；
• 類型覆蓋：功能測試，接口測試，接口自動化，兼容性測試，性能測試；
• 自動化案例增長3個接口的監控；

測試環境：

手機型號：

系統類型與版本：

瀏覽器類型與版本：

• Windows Chrome Version 69.0.3497.100 (Official Build) (64-bit)
• Mac Safari Version 12.0 (13606.2.11)
• iPhone 7, iOS 11.3.2 Safari
• 小米6A， MIUI 10.2.2 系統瀏覽器，UC瀏覽器 V12.3.3.2342

bug系統使用規範

報告規範

指派：

• 直接指派給你知道的負責人，不然先給測試負責人；

模塊：

• 儘可能選對，不一樣模塊通知到的負責人可能不一樣；
• 不知道的話選其它，由測試負責人再修改；

標題：

• 一句話總結出錯的位置、現象；或者是建議作法；
• 思考一下要搜索出這個bug時會用什麼關鍵字，這個關鍵字應該存在標題裏；
• 標題能夠用[]來存在重要內容，如【小說】小說模塊出現沒法加載問題；

重現步驟：

• 說明問題的現象是什麼，爲何這算是一個bug；
• 能夠補充說明要修復成什麼樣，若是是顯而易見的就不用說了；
• UI展現問題或文字說不清的問題，截圖說明，必要的話作成GIF或錄屏；
• 特定狀況才觸發的問題，要包含測試數據，例如：
• • 帳號密碼；
• • app項目的操做路徑，例如 首頁->資訊廣場->點擊第一條->白屏；
• • web項目的URL；
• • 若是以爲多是兼容性問題，寫上重現條件，例如手機版本、系統版本；
• • 其餘能幫助重現的信息；

嚴重程度劃分標準：（目前禪道對應一、二、三、4）

• 嚴重：崩潰、白屏、404/500錯誤；業務錯誤，流程不通，主要功能缺失，數據計算錯誤，性能；
• 通常：次要功能錯誤、缺失；數據長度；界面樣式影響使用
• 輕微：界面樣式問題但不影響使用
• 優化建議：體驗很差；速度太慢

優先級劃分標準，產品經理對優先級有最高決定權：（目前禪道對應一、二、三、4）

• 當即解決：主路徑問題，不解決沒法繼續作測試；
• 下次提測時解決：默認項；
• 發佈前解決：相對獨立，對其它功能沒影響的問題；
• 下個版本解決：未嚴重影響用戶，但解決起來有難度，可能形成項目延期；

這裏須要注意，通常嚴重問題都是緊急的，可是要考慮到問題出現的機率及影響面，從而會有嚴重不緊急，緊急不嚴重的狀況；

如啓動頁的logo錯了，雖然不嚴重，但會影響到公司聲譽，因此是緊急的；
某個功能出現閃退，可是隻在極端的狀況出現，考慮到修復成本及影響面，可能屬於嚴重不緊急；
複製代碼

使用規範

• 轉給他人時，能夠考慮添加備註；
• 及時解決，產品的bug添加到需求池或其它地方有記錄就算已解決；

注意事項

切勿將需求當Bug報，報Bug以前，須要瞭解Bug和需求之間的區別：

• 需求是描述一件事情，做爲何用戶，但願如何，這樣作的目的或價值何在；
• 需求須要構建用戶角色，描述使用場景，定義用戶問題；
• Bug是程序中隱藏或被發現的功能缺陷或漏洞。簡單說就是使用軟件時，出現的錯誤問題；
• Bug須要描述重現的步驟，環境及其餘因素，以便定位問題；

但並非說需求不能報禪道，只是但願能用更好的方式來區分出來，如標題寫上[需求]、選擇對應模塊和優化建議，指派給產品經理；

延期和需求變動

延期

有延期風險時應及時通知項目經理，並由項目經理組織各負責人確認是否延期；

最終由項目經理髮出郵件，列明延期緣由、修改後的里程碑時間，同步更新cf文檔；

郵件標題：【項目延期】xxx項目延期說明mmdd

Dear all，
    XXX項目 上線時間由11.13 延期到 11.14，延期一天
    延期緣由以下：
    一、處理XX問題，超出計劃時間。
複製代碼

需求變動

通知規則：

• 必須在需求文檔的修訂記錄上有所體現；
• 在釘釘上@全部人 通知。若是增長的工做量超過1人天的，必須發郵件；
• 會致使項目延期的變動，必須產品主管確認；

通知內容：

• 之前是怎麼，要改爲什麼樣；
• 更新文檔在哪；
• 影響的具體工做量；
• 影響後的項目計劃安排；

操做流程

項目執行過程當中，預計項目延期2天之內，與技術人員評估以後，發出延期通知； 超過2天或者延期2天，召開會議，討論解決方案，發出延期會議郵件；

全部的延期說明，都須要給出具體可量化的緣由；

集體加班制度

集體加班的標準

• 及時上線能帶來可觀收入；
• 外力因素（政府政策、第三方故障等）；
• 延期了過久，要把進度趕回來；

集體加班須要由產品和項目共同決定，而且有郵件通知；

不知足條件的，不得隨意要求項目組加班，更不得由產品或項目私下要求加班；

別人過失致使的我的加班，應根據本身意願決定是否加； 不加是合理的，項目延期是符合流程的； 若是選擇加班，那是我的爲項目順利所作的努力，是高績效的有力依據； 加班完了最好有意識地記錄本身的貢獻，在述職時列出這些積極表現；

通知

由項目經理發郵件通知，模板：

標題：【加班通知】xx項目mmdd

正文：
（加班的緣由、人員名單、目標）
複製代碼

補貼

集體加班，可由產品或項目申請經費購買週六下午茶，人均x元左右； 若是領導贊成，可協調成補休，不一樣團隊視實際狀況落地，下午茶補貼是必定要有；

驗收、發佈、上線

驗收者

產品、UI、後臺系統使用者（運營、客服、風控等）；

驗收進入條件

測試流程結束的下一步是驗收； 進入驗收的最理想標準是全部bug都已關閉；

若是時間緊張，能夠放寬到同時知足這兩個條件：

• 優先級爲「下次提測前解決」的bug都已關閉；
• 優先級爲「發佈前解決」的bug不超過人均2個；

測試環境驗收

• 測試向驗收者演示主流程，形式多樣，主要是要溝通清楚；
• 驗收者本身操做，或讓測試演示更多流程；
• UI覈對，主要是顏色值和像素級大小的比對你，肉眼能看出來的差別，應該在測試過程就發現；
• UX體驗反饋；

發佈與線上驗收

• 產品經理宣佈測試環境經過，讓開發發佈到生產環境，各職能核心人員待命應對故障；
• 發佈後，測試和產品再過一遍主流程，後臺系統使用者也應該作些操做來檢驗或持續一段時間觀察相關數據是否異常；
• 線上驗收標準由各驗收者本身決定 儘可能在週二或週四上午發佈，以便出現問題時你們有時間精力當即修復；

上線

生產環境驗收經過後，確承認以開始放量，這個結果視爲「上線」；

由產品經理宣佈，若是沒什麼問題，釘釘羣裏說完便可，若是有風險，應發郵件：

收件人：項目組
標題：【上線通知】xxx項目y.y.y
正文：
...
（風險預估）
（應急預案）
複製代碼

結項

結項會議

時間：上線三天後 主持人：項目經理或助理 參會人員：實際參於項目的全部人員，主管酌情參與 會前準備：把須要投影的東西給主持人，本身準備好發言提綱 會議流程分爲兩部分 第一部分，結果總結，按如下次序發言：

• 項目：簡單回顧總體項目進度，消耗的人力時長，誤差多少與緣由；
• 產品：線上版本相關數據（脫敏）。主要目的是讓你們知道勞動成果的意義；
• 測試：簡要說測試報告的重點，突出質量的部分；

第二部分，過程總結，這部分發言可進行討論：

按如下次序發言：項目->運營->產品->UI->後端->前端->客戶端->測試->運維；

發言內容指引：

• 對事不對人，主要目的是點贊和總結下次如何作得更好；
• 本身或合做方哪裏有改進，上次的問題解決得如何；
• 本身或合做方哪裏作的很差，有什麼解決方案或建議；
• 提高工做效率的心得（溝通方式，工做方式、項目安排、工具使用等）；

結項郵件

發件人：項目經理或助理

收件人：項目組釘釘羣**，可接着項目週報發**

標題：【結項報告】xxx（項目）y.y.y（版本），例如 【結項報告】XX3.2.4

正文：（下劃線表示是示例，真實郵件不要有）
Dear All，
（暫無模板，幾乎就是結項會議的會議紀要）
複製代碼

例子：

Dear all，
XX小程序VX.X 總體概況以下：
1.XX暴雷X.X的項目計劃是X.X -   XX.XX，預計消耗X工做日。實際項目執行是從X.XX -  XX.XX，總共消耗 XX工做日，延期XX工做日。
2.小程序上線以後，使用分享解鎖和動態分享功能的人數不少，後續產品會針對分享功能進一步優化及挖掘用戶，詳情數據請查看附件；
3.整個項目測試反饋的總bug反饋數XX個，有效問題XX個，X個不處理，X個延期處理，X個轉爲需求;

延期緣由：
1.項目人數不足，前端同窗在項目中期纔開發;
2.需求評審事後，沒有進行技術可行性分析，致使項目中後期才發現某些功能實現起來困難;
3.評審需求時，沒有足夠時間仔細閱讀文檔。需求裏面隱藏着好多功能點，致使評審時間不許;
4.產品文檔發生修改的時候，沒有立刻通知項目成員，增長溝通成本;
5.開發時發生UI及需求文檔和後端接口字段串聯不上，增長溝通成本和研發成本;
6.bug數量多，有效Bug 有93個，修復時間長;
7.消息中心功能在項目後期才調通，處理時間久;
8.測試跟前端雙方在bugfix階段的配合存在問題，須要優化;

解決方案：
一、XXX
複製代碼

表格說明

線上故障

##故障定義 發佈生產環境並驗收經過，確認放量後，還發現的bug都算線上故障；

報告標準

什麼狀況的線上故障須要報告？

• 對營業額有大影響，例如沒法打開頁面，沒法買標；
• 對用戶口碑有大影響，例如功能沒法使用；

什麼狀況的不須要報告？

• 簡單的用戶體驗或純UI的問題

處理流程

• 不管誰發現的，首先應該反饋給測試同窗；
• 測試確認重現步驟後，報bug給開發解決，並由產品經理決定是否緊急發佈修復；
• 修復後，由測試負責人彙總各職能的報告併發出郵件；
• 產品報告對運營數據的影響；
• 開發報告出錯的緣由、（代碼層面的）影響範圍；
• 測試報告沒測出來的緣由；
• 由測試組織討論如何防範這樣的狀況再出現；

報告郵件

原則：

要找出責任人（或指出是哪一個職能便可）和出錯類型（代碼、需求、溝通之類的），並明確寫到報告中；
對事不對人，注意措辭；
要有解決方案，且有明確的跟進人；
複製代碼

例子：

收件人：項目組釘釘羣

抄送：測試組釘釘羣

標題：【線上故障】xxx項目a月b日yyy問題

正文：（下劃線表示是示例部分，真實郵件不要有）

Dear All,

本次故障的現象：散標詳情頁出現白屏，並一直彈框「數據異常」

持續時間：10月3日14:30上線就存在，在10月3日18:00由後端修復，故障持續3.5小時

發現時間：由客服在10月3日16:00收到用戶反饋而發現
影響：用戶沒法查看和購買散標
緣由：後端……
解決方案：解決代碼錯誤便可

未能更早發現故障的緣由：後端上線前改代碼未通知測試

防範方案：須要開發自覺，開發主管要增強宣導。最佳解決方案是git提交都有監控，但目前可執行性太弱；
複製代碼

項目週報

原則

• 有事起奏無事退朝；
• 項目經理可在週一上午召開站會收集信息，各職能負責人需積極配合；
• 週一下午3點前發出郵件；

郵件模板

收件人：接着立項郵件全體回覆，每週接着上一週發直到結項

標題：【項目週報】xxx（項目）mmdd（月日），例如 徵信通1018

正文：

Dear All，

（1-3句話總結狀況。）

（當前進度，是否存在風險。有就說明異常狀況與緣由，提醒注意，請求協助。）

本週項目進度正常，按計劃進行中，無特別狀況須要彙報。項目計劃參考立項文檔；


本週進度基本可控，可能的風險點：

週三xxx要請假，也許會形成延期
xxx需求還沒出UI稿，設計師在忙別的項目，可能形成前端延期


10月4日週二上線了1.3.2版本，運營數據在持續觀察中。1.3.3的需求正在評審中。

項目肯定延期1天，改成10月28日發佈，緣由：

需求變動，xxx需求未考慮到yyy的狀況，補上後產生新工做量，具體請參考 需求變動文檔/郵件
xxx臨時有事請假
阿里雲服務器故障，狀況未知，@xxx正在處理

10月5日發生了線上故障 xxx，具體請參考 測試 發的郵件，標題爲：yyy

本週運營數據：（由產品經理進行脫敏處理，有圖表更好）

PV變化在5%之內，在合理範圍內
UV降低了20%，應該跟國慶假期有關
買標數據上漲30%，交易總額上漲50%，上線的新功能很是有用！
xxx的運營需求，轉化率爲7.8%，效果不好！
複製代碼

例子

例子1：

hi，all，上週XXX各項目進度以下：
XXXAPP：
VX.X.X版本：
研發側：
1）bugfix中，目前還剩下X個bug，開發進度約XX%；
2）XX功能上週已開發完畢，計劃週二週三跟客戶端聯調，週四提測；
3）對接XX工做，肯定延期，須要等XX上線才能夠對接，初定XX月上旬，產品已知曉；
4）考慮XX可能存在風險，決定把該功能延期到X.X.X版本上，避免因XX功能致使項目延期或承擔風險；

測試側：目前已提測t一、t2，均測試完畢，處於bugfix驗收環節；

VX.X.X版本：
該版本爲小版本，主要是體驗優化（具體優化內容）；

1）產品側：需求已與測試、後端、UI評審，前端因還在忙VX.X.X項目，暫時未參與；
2）研發側：後端，除了版本兼容須要跟前端討論可行性，其餘功能能在本週內開發完成；
3）UI側：已經提供了設計稿；

VX.X.X版本：
該版本爲大版本，主要是新增XX功能；

1）產品側：需求已與測試、後端、UI評審，前端因還在忙VX.X.X項目，暫時未參與；
2）研發側：後端，除了版本兼容須要跟前端討論可行性，其餘功能能在本週內開發完成；


XXX：
1）研發側：上週已提測XX功能，目前開發進度XX%，進度正常，預計下週五所有開發完畢；
2）測試：測試中，測試進度10%，在測試XX模塊中，因頁面內容跳轉還未徹底實現，所以後期存在返工量，後期可能會存在風險；


XXX項目VX.X：上週已上線；
複製代碼

例子2：

Dear All，
上週主要項目進度
 已發佈 ：
 針對線上問題修改預付利息算法
 產品：XXX   開發：XX  測試：XX萱
 進行中 ：
1.輕鬆投部分退出     測試階段
 產品：蔡菁菁   開發：黃振廷，吳鼕鼕（本週增長），蔡曉萍，林博淳   測試：周佩萱
風險：故障較多，主流程仍不通結算失敗，而且問題反覆出現。前期開發（業務）設計存在許多缺陷
    原計劃本週上線
解決方案：協調產品及開發負責人討論，決定增長一名開發。看故障解決狀況明天早會再討論進一步解決方案

2.App優化-XXX功能  測試階段  進度正常
產品：XXX   開發：XXX   測試：XXX

3.XXXX  測試階段  進度正常
產品：XXX  開發：XXX   測試：XXX

4.XXX  開發編碼階段
產品：XXX  開發：XXX   測試：XXX

5.XXX 開發設計階段
產品：XXX 開發：XXX    測試：XXX
複製代碼

小結

上面的內容，是整個團隊的努力，你們一塊兒完成的，完成這麼一件事不容易，雖然花費了不少時間，但真的很值得，由於以前只是在門外，而現在在門內，不親力親爲，真的不知道須要瞭解這麼多內容；

好了，就這樣吧，若是有補充的，歡迎提出，謝謝你們；