實錄丨不以敏捷開發爲基礎的DevOps都是耍流氓，你怎麼看?

6月10日，數人云聯合優維科技在北京舉辦了《DevOps&SRE超越傳統運維之道》的線下沙龍活動，活動中了哥（邱戈川）以Scrum模式的角度切入本次主題，最後得出「不以敏捷開發爲基礎的DevOps都是耍流氓！」讓咱們來看看了哥都分享了哪些內容吧。

前言

Scrum模式開發經驗分享

Scrum出來已經好久了，不少原理性問題就不講了。今天和你們主要分享一下Scrum實施過程當中的一些經驗和對其的一些感覺。

主要有四塊內容——敏捷Scrum模式概貌、人員的分工、平常活動的細節、以及一些可能用到的簡單工具。

現行開發模式及開發過程當中痛點

敏捷模式概貌

Scrum已經用了好久，但爲何始終沒有用到極致或者很火？

你們都在作大型系統，Scrum模式難度稍大，鏈條過長。須要開不少協調會議，溝通成本高。

微服務和容器化讓團隊規模發生轉變，從之前幾十人的大團隊轉變成如今六七人的小團隊。

客戶及運營的需求產生變化，從數月至半年的交付時間轉變到幾周至一月的交付時間，使得業務更傾向於快速迭代、快速交付和快速變動。

什麼是Scrum

敏捷模式概貌

上面這本書詳細地介紹了敏捷，這裏就再也不贅述。先提幾個問題：

需求主導：一般需求都脫離於團隊以外，上司或老闆忽然下達一個指令並規定出時間，而自身的事情還沒有完成，因此在開發上需求到底由誰來主導？

流程主導：不少公司都有一套流程來規範每一個團隊所作的事情，應該團隊來主導流程仍是公司主導流程？

顛覆仍是改進：敏捷是否是須要把之前的東西推翻？

什麼是Scrum？SRE、Scrum、DevOps之間的關聯是什麼？

這裏簡單畫了一個圖。DevOps首先訂製一個流程，用敏捷開發基礎去作DevOps。並不是必定要用敏捷開發，能夠嘗試以快速迭代、快速交付的方式。

我的理解SRE更偏向於運維，涉及一些開放性的DevOps工具或開發工具，它離總體的軟件開發交付還有必定距離。

困境

敏捷模式概貌

不少時候，你們以爲敏捷開發、DevOps的模式及理念很好，但很難落地實踐，歸根究竟是須要作的事情太多。其實這個時候，不管是團隊仍是管理者，都須要停下來，作一些思考。

自運營/服務模式

敏捷模式概貌

N多業務團隊並行，由產品或商務提出需求，但一般只有一句話。也會有一些業務分析師，把業務作好澄清後導入給團隊，每個團隊產品體系裏都要拆出本身理解的PRD，而後再自主規劃版本，最後實施完成推送上線。

須要強調的是，敏捷在運維模式下很難作許多個產品統一的測試聯調。一些大公司爲了某個功能，將全部的產品功能對齊，等所有功能出來後再聯調、測試、最後才推到市場，這是很值得「敬畏」的事。因團隊和內容數量龐大繁雜，由於團隊的數量，涉及的內容已經很難這樣去作了。

受團隊數量和涉及內容的限制，最好的方式是誰最後上線，誰最後作總體測試，以此爲約束。

團隊構成

敏捷模式概貌

上圖即1-1-3-2模式，這是簡單的實踐作法。

關鍵性角色包括：

產品、架構師、開發、測試。

找到合適的產品和架構是最重要的，開發和測試從哪來（如外包）其實並無太大的關係。

溝通鏈條：

之前是產品→技術負責人→開發→測試，這樣的順序鏈條。但如今因團隊人數的關係，全部的需求範圍應該由產品直接對全部人進行溝通，以節省成本。

需求澄清要由產品來作，實現指導、實現方式則由架構師來作。產品決定作什麼，架構決定怎麼作，這是很是重要的一點。從而營造一種氛圍：外部提出的只是需求，不是技術方案或實現，技術方案和實現要由團隊的架構師去把握。

在團隊中，可能有一個測試，四個開發，或根本沒有測試，取決於團隊自身狀況。

公司規模較大，團隊數量較多時要視狀況而定是否作Scrum to Scrum，不一樣的PO在一塊兒協調和澄清每個產品或大的場景下的分工。注意：開協調會時，要把範圍控制在少數人，而不是全員大會。

角色分工

角色分工以前已提過，但分完工以後，仍是有不少人作了不應作的事情，如老闆去作技術指導。

PO

角色分工

不想作好測試的開發不是好PO，也就是說，一個產品作很差測試，作很差開發，那也就不必去作產品了。幾個比較大的要求點：

• Roadmap：須要作整個產品的Roadmap規劃，至少要給出每一個迭代有什麼，有幾個迭代，每一個版本是什麼樣。

• 迭代範圍：產品要控制迭代範圍，不少公司老闆說什麼就是什麼，致使團隊越作越混亂，因此產品經理要作好澄清，對外承諾的範圍要掌握在手裏。

• 產品生命週期計劃、特性Demo、推廣等等。另外還需跟架構師配合，溝通產品規劃中每一個迭代與技術產品相關的改進點。

架構師

角色分工

架構師須要作好實現架構的設計以及相關成員的指導（如開發、測試），組織相關人員會議，作敏捷不表明不開會，甚至一些小團隊內部之間的會議可能比原來的會議還要多。

開發

角色分工

開發沒有太多的變化，惟一要作的事情就是開發要把東西作出來進行展現，讓代碼儘快可見。

測試

角色分工

測試最大的問題是不少時候被拋離團隊以外，由於測試總以爲本身是最後一環。不少公司以測試Case數量做爲考覈，這是對於測試人員最大的誤區。

理想中測試主要作測試設計，從設計角度來進行測試。測試驅動開發完善產品、彌補思考上的遺漏，同時不少公司的開發把測試當作助手，呼來喚去，是很是不對的。

開發與測試的配合——模式轉變

角色分工

模式上，開發和測試作一些轉變。原來的模式中規劃完成後，開發將產品開發出來，打包交給測試。

而新的模式下，測試從第一天就要參與其中，提早進行測試設計。

開發與測試的配合——思惟轉變

角色分工

開發與測試的溝通，須要整個團隊進行磨合的。前面提到，測試從第一天就進行測試，不須要開發來進行信息傳遞，而開發更加不是測試的上游。

將來，開發和測試邊界會愈來愈模糊，測試也須要把重複性的工做進行自動化。

角色缺失

角色分工

其實這裏把Scrum Master去掉了，由於不少人把Scrum Master變成了打雜。另外若是公司全員作敏捷，建議不要在公司層面定製流程，同一公司的不一樣團隊磨合程度又一，不少團隊是靠人磨合出來的。

Planning Game

平常活動

Planning Game之前的標準作法是給你們一副撲克牌，12358斐波納契數列數字牌。如今我用Gitlab比較多，將Planning Game的全部內容列上便可，而後你們作大致迭代評估，而不是精細評估。

有幾點經驗分享一下：

• 第一點，要負責好對應的範圍，不要在一個版本里面，將全部的大功能都選擇上。當把一個版本里面的大功能選擇完了以後實際上等於沒有選擇，由於範圍越大，失控也越高。 選擇一些小功能或不重要的功能，做爲風險緩衝。

• 第二點，須要預留出技術改進的空間，何時作重構，何時作改進等等。

• 第三點，迭代的週期，兩個迭代出一個版本，最好是兩週完成一個迭代。以版本而不是迭代作發佈，預留出一週的時間作發佈緩衝，並對下一個迭代進行規劃。

Standup Meeting

平常活動

當團隊比較小時，沒有必要作的過重，雖然如今已經出了電子白板，我的的經驗是用真實的白板操做性更好，更能體現哪些事情有關聯依賴性，哪些人在作什麼事。

須要強調的是，每一個人作的事情是自主的，但須要架構師掌控好，有限度的作出選擇。對於很是重要的事情，要選對的人去作，而不是隨意去作。選擇的紙條項目要控制在兩個之內，具備難度的要讓架構師去作設計。

Review Meeting

平常活動

敏捷上開會仍是比較多的，但內部要想辦法有效率去開。Review meeting包括設計、代碼、測試 Review等。大功能設計，能夠去作從三分之一到二分之一再到完整的Review，這樣能夠減小返工率。

End to End Demo

平常活動

儘快作emo，越快越好，能跑場景便可。不要讓產品最後纔看到Demo，也不要等全部的東西都作完，同時團隊成員注意現階段不須要挑刺。

DOD meeting

平常活動

DoD Meeting最好以迭代的方式，而不是版本方式。第一個迭代的DOD，要爲下一個迭代作好風險控制。哪些是能作的，哪些是不能作的，哪些是須要本身作的，哪些要新增，都須要做出及時的調整。

Retrospect Meeting

平常活動

按期作回顧，一般的作法是拿便利貼寫三點——對每一個方向提三點。選擇一個輕鬆的環境，每一個人講一些。而回顧會的意義不是批鬥或者拍馬屁，曾經有一次開發把產品經理批鬥的很嚴重，產品經理反過來又把開發罵了一頓，以上作法都不可取。

產品運營

平常活動

整個團隊也要作一些產品運營，不管產品是對內或對外，包括客戶支持、數據分析，以及對內對外的分享。

迭代版本範圍的選擇原則

PO的工具

每一個迭代版本的選擇，對於產品很重要。一句話歸納這個版本的價值和目標最佳。要向團隊成員澄清目標，不然團隊成員可能不知道重點或優先級。

版本細節定義

PO的工具

版本細節定義能夠用魚骨圖表現，標註版本、週期，以及重要事項等。

Backlog/PRD管理

PO的工具

Backlog無需和代碼綁定，在Wiki裏進行管理便可。雖然Backlog不少時候只表現粗略的需求，但其好處容易與相關團隊成員達成優先級別的一致。

小公司作產品時容易忽略Backlog管理，想到哪作到哪。Backlog的定義詳見PPT。

產品功能地圖

PO的工具

產品要作功能地圖，用腦圖的方式概括整理便於你們理解，另外一個好處是便於開發和測試補充遺漏，若是運用好功能地圖，會更好的溝通，以及作功能之間的相關性測試。

任務拆解與管理

PO的工具

任務完成後須要進行分解，用Gitlab的Issue方式去管理，天天站會時彙報工做進度，測試對完成的功能進行測試，細節須要討論的，和測試提的BUG直接寫到Issue上去便可。

版本Release Note

PO的工具

每一個版本出來都要寫上Release Note，很多公司更新迭代多個版本，可是連一個Release Note都沒有。Release Note建議要寫一下產品是否對其餘產品依賴以及依賴的版本是什麼。 以前犯過一個錯誤，出了版本後，因爲產品已經出了多個版本，而以前依賴的下一產品版本是錯誤的，則致使現有產品的版本仍是舊的。

內部版本定義規則

PO的工具

不少時候咱們使用有兩位版本號，有三位的、也有四位的、或者純字母。經驗上三位版本號會比較好理解，第一個是大版本號，不向下兼容；中間是Feature版本號，能夠向下兼容；最後一個是Patch版本。後面「-」的版本是本身內部的測試版本或RC版本。

總結

Scrum模式開發經驗分享

最後，整個Scrum模式但願你們根據團隊狀況，來調整流程和開發模式。人是活的，流程是死的。沒有明文禁止的，均可以改變和調整的。

了哥公衆號：vipdocker