Scrum 使用絮叨

關於Scrum 的一些絮叨
Scrum 的推行的基礎在於全員參與,全員協做，包含Dev, QA(quality assurance) ,BA(Business analyst)以及Supporter team等等。

---

初衷
這篇文章的寫做前提是由於咱們團隊在推新的release cycle的時候，有產品的同窗不能理解這樣作的目的，或者說很難接受咱們去延長需求發佈時間（實際並無延遲上線時間，第一感官錯誤……）

現狀

1，線上問題層出不窮
2，預計上線時間和實際上線時間不符
3，上線計劃混亂，週期混亂（雖然以前定的有，可是基本沒有遵循，有需求就會時不時上線）
4，開發轉敏捷開發後，Sprint中任務計劃頻繁被打亂
5，在release以後，不能及時驗證所有需求，一旦有問題，版本回歸會有問題
6，……

---

目標

1，爲了更加規範產品發佈流程
2，保證線上產品的質量
3，提高整個團隊的效能。

---

流程
關於Scrum的流程，我簡單描述下以前咱們的主要環節。

BA
需求收集
需求整理，過濾，篩選(很重要)
需求分類（任務，可用性問題（bug），性能問題，概念想法（暫時不能實現也須要收集））
評估優先級
詳細設計
驗收條件
驗收方式：（Sprint demo全員參與，在sprint結束以後，又各責任人演示當前sprint實現了哪些需求，是否達到驗收標準。Mini demo當開發人員的Story完成以後，拉上相關QA&BA，進行小範圍功能驗收，此流程可貫穿在Sprint中。）

---

Dev
1，Planning meeting得到Story
2，理解需求，代碼實現
3，Unit Test編寫（第一輪質量驗證）（已有計劃）
4，提交git(進入Code Review work flow)（正在推動）
5，Code review done/Reject.（正在推動）
6，進入dev環境，由開發來聯調各自功能是否ok（第二輪質量驗證）
7，沒有問題,merge code from Dev branch to QA branch

---

QA
1，後面會添加Automation Testing(第三輪質量保證，保證基本流程或者主要流程每次都不會有問題)
2，Functional testing 驗證QA branch(第四輪質量驗證)
3，Integration testing （第五輪質量驗證）

測試爲了保證系統基礎功能的穩定性，必須編寫一套UAT cases(User acceptance testing), UAT case必須在每次release甚至於每次build都須要自動驗證（須要添加到automation testing 流程中），UAT case須要根據系統功能的變化進行持續升級。

由於咱們目前在現有系統中存在太多的技術債（所謂技術債，指的是在項目前期一味的追求進度而忽視質量形成的欠債），若是總體去修改工做量會過大，咱們的經驗是在每一個Sprint中預留20%-30%的buffer去作修復工做。

這個時候咱們的系統中會有三套環境：

Dev & QA & Live（production）

若是預算充足，咱們是須要一套stage 環境。stage環境從配置和硬件設備基本和Live環境一致，從而使一小部分用戶進行新功能試用，以達到咱們最終的全面上線的目的。
Of course，Dev & QA徹底分離，對於目前咱們來講暫時夠用，前提是絕對的物理分離，從數據庫到業務代碼！（很抱歉，目前咱們沒有此環節，我正在努力推動！）

通過上述五輪的質量保證，咱們就能基本排除線上因開發或者測試的覆蓋率不足形成的問題，環境問題不能絕對避免。

看起來上述的內容似乎和咱們的重點：release cycle沒有關係？
其實否則，週期爲一週的時候，不少需求咱們是在一個sprint中測試不徹底，倉促上線，會形成線上問題。
1，所謂每個Sprint，基本要求就是Sprint中全部需求能夠徹底開發+測試結束而且能夠達到上線要求。（目前不知足）
2，當前一週的任務能夠release出去嗎？從看到的結果，並非這樣，後期這部分會整理出數據來支撐此結論（目前不知足）

按照咱們目前的需求以及上線頻率來看，修改release週期爲2週一次，Sprint 週期也定爲2週一次，能夠徹底cover咱們的現狀。而且能更好的提高工做質量以及的 deliver 更多的工做量。
爲何敢這麼說？使用了Scrum以後，後端團隊的提高體現

1，我的工做目標更加明確
2，在交付環節比過去按時而且質量大幅提高
3，規範的方式，你們的積極性更高，產出更高
4，不會被臨時穿插的需求打亂本身的工做計劃，效率更高，產出更高
5，每一個人目前都感受到節奏感強，工做更充實，更有動力，產出更高
6，慢便是快（對於產品，需求更加明確，清晰，在code的時候節省了大量時間而且避免踩坑）

因此但願每一個同事能去擁抱scrum，它是一個工具，一個讓咱們更加高效的工具，一個加強咱們團隊合做的工做，一個能夠提高你們的積極性，主觀能動性，一個偉大的工具！！