本文主要涵蓋的內容如下：

• 敏捷Scrum模式概貌
• Scrum Team的組成與角色分工
• 團隊的日常活動

敏捷Scrum模式概貌

開發管理的痛點

• 開發過程的各個環節的明確邊際，造成信息傳遞鏈條過長，溝通成本以及問題反饋效率低。現行的多數團隊，其溝通方式多數是鏈式傳遞的，從產品->架構->開發->測試這樣一個過程。然后就是每個人都希望做完自己規定的職責后可以當甩手掌柜，最后結果是下游環節在出現問題的時候把責任習慣性推給上游環節。測試不管大局，拼命找開發的所謂的“漏洞”，而開發則去說架構沒有設計好，架構則找產品茬說產品啥YY需求。這樣最明顯的特征就是測試似乎績效很好，但是產品質量依然一塌糊涂。這里引出一個公司管理的一個很現實的問題，在小團隊規模開發模式下，以個人還是以團隊的方式考核KPI和事?
• 新技術的引入(微服務、容器化)，不再適應大軍團作戰，而是需要匹配的靈活的端到端團隊。在一個分層比較多的組織里面，最難做到的是管理水平化，往往在團隊外增加“保姆式”的組織或監控流程。這樣團隊除了日常的工作，還要疲于應付那些水平管理所帶來的溝通、會議等。這樣整個團隊都在疲于加班，但是事情依然無法按時完成。
• 客戶的需求變化已經不再局限于整體產品購買，而是傾向于業務快速迭代，大軍團作戰已經難以快速交付、快速變更。如何配合客戶的業務變更成為傳統大型產品銷售型企業最大的挑戰。因為一個客戶的產品已經難以復制性再交付給下一個客戶了。在這樣的市場條件下，如何將系統更大程度的拆解與靈活組裝考驗架構設計能力，也同樣考驗開發組織形式的變更能力。

敏捷開發不是個新鮮事物，但是隨著微服務、容器化等新技術理念的推出，敏捷開發找到了更合適的切合點而已。

什么是Scrum敏捷開發

幾個值得思考的問題：

• 團隊對于需求范圍是否有自主性?
• 開發范圍是否是根據時間倒排?
• 是流程管控開發人員，還是人主導流程?

在有市場交付壓力的團隊中，最容易遇到的問題就是倒排時間。因為交付內容與交付日期已經先確定了，然后當遇到開發瓶頸的時候，第一個想到的就是給團隊增加人手。但是別忘了一個經典的說法，一個女人生一個孩子需要9個月，那么9個女人是否可以一個就生出一個孩子呢?答案是顯而易見的。另外一個說法就是，如果所有的需求都是高優先級的，那么所有的需求都是低優先級的。

具體什么是Scrum敏捷開發，大家可以參考一下這本書：<<Successding with Agile Software Development with Scrum>>

不過還是跟大家強調一點，流程是死的，人是活動，需要根據團隊情況進行變通。

區別

現在已經不流行敏捷開發，而是流程DevOps了。其實可以這樣說，不以敏捷開發為基礎的DevOps都是耍流氓。

Scrum不是等同DevOps，也不等同與現在更流行的SRE的概念。(具體SRE是什么，大家可以搜索一下)。DevOps和SRE將運維管理引入到開發團隊中，將運維情況與開發形成一個閉環，是開發更能有效的考慮實際使用情況。個人理解，其三者的關系如下圖：

"scrum vs devops vs sre"

困境

雖然很多時候，大家都覺得敏捷開發， DevOps等理念都很好，但是就是很難去實行，最大的借口就是原來需要做的事情太多。但是這個時候，無論是團隊還是管理者，需要停下腳步，做下思考，因為你遇到的情況很可能與下面這個圖類似(來自互聯網)：

"hard work"

公司形態與Scrum模式

不同的公司業務形態是否Scrum的方式都一樣呢?我的理解是核心是相通的，方式是靈活適配的。主要分為兩種主要形態：

• 自運營或服務形式提供
• B2B模式的產品開發

自運營/服務模式Scrum流程概貌

參考下圖：

"operation mode"

在自運營的場景下，市場人員和產品的策略管理者(SPM)來探討大的產品方向，然后業務分析師(BSA)做相應的規劃，然后各個子產品Owner，俗稱Product Owner(PO)根據這些輸入制定各自產品的Backlog，然后規劃各自產品的迭代。這里引出一個問題，怎么將抽象的需求或者業務需求拆解到各個子產品中呢?一般的做法是頂層有對應的架構師(俗稱首席架構師)，他來規劃產品的邊界，與大的需求的拆分。但是這樣的人比較難找，因為他既要懂得業務，還要設計整體體系的架構，還要能分解需求邊界等等。如果你遇到這樣的人，千萬不錯過。

在自運營或者以服務的形式向客戶提供支持的場景下，每個子產品的PO自行規劃迭代范圍，自行規劃上線時間。不是所有的特性都要完成才能上線。對于跑的快的團隊，其實可以將某個需要別的子產品配合的特性的提前上線的，盡管這個特性還沒有真正能使用。對于產品關聯依賴的特性，則可以通過PO間的Scrum2Scrum協調解決。(后面講)

B2B的Scrum流程概貌

參考下圖：

"b2b mode"

在B2B的產品銷售模式下，很難做到各自獨立的子產品對客戶發布，因為客戶需要的是一個Turn Key的交鑰匙模式。在這種模式下是否就不可以做到敏捷開發呢?其實也不然。

和前面的自運營模式不同的是，各個子產品不會發布到生產環境中，但是各個子產品依然可以根據自己的節奏做發布。只是需要在特定的時間，將各個子產品的組合起來做一次基線測試和聯調，出一個整個產品的基線版本就好。這里需要主要的是，不用拉齊各個產品的版本節奏，而是根據時間點對不同的子產品做版本選擇就好。另外集成測試團隊只是在需要的時候臨時組建，而不是固定的團隊。切記，平時這些集成測試的人員應該在各個子產品的團隊中。各個子產品間的集成測試應該在功能特性完成時就獨立去做了。這個基線測試更像是集成的回歸測試。

Scrum 2 Scrum

對于產品比較龐大的系統而言，一個業務流程很可能涉及多個子產品，這樣就需要不同的團隊的PO/SA一起做協調與溝通了。

"scrum 2 scrum"

通常是Chieft SA召集(平臺類產品)或者Businss System Analyst(業務類分析師)召集。Strategy Product Manager和Release Project Manager也會參與進來。這個需要注意的是，要避免團隊與團隊間的人員交叉協調與溝通，因為這樣會導致團隊效率極其低下。團隊間的溝通最好由PO/SA統一在這個會議上協調。

另外就是，對于阻礙別的團隊進展的需求，應該優先解決(不一定是完成整個特性，如提供對應的接口也是一種形式)，避免團隊間等待的情況發生。

這個會議更多的是對于需求范圍的確定，以及團隊間的協調，不討論具體的方案細節。原理上不同的團隊都是接口間的依賴，方案可以由各自團隊的SA負責。

對于是否需要對每個團隊的方案進行評審和把控，取決與團隊情況。因為比較難有幾個都對整體系統的每個模塊的方案細節都清楚的。當然如果有，則可以成立Change Control Board(CCB)來做專門的架構評審。

Scrum Team的組成與角色分工

對于Scrum團隊的組成，一直沒有一個很好的定義，人數的多少總是爭議的焦點。另外就是當遇到變化的時候，到底是給團隊增加人手還是有別的好的方式呢?從實踐看，對于一個團隊的事情變化，負荷變重后，最好的方式重新成立一個Scrum團隊接管新的任務遠遠比給團隊增加人手的方式容易的多。畢竟新人的加入在一段時間并不能給團隊產生正向的價值，因為需要溝通融合。保持Scrum團隊的穩定性是首要原則。那么什么樣的規模的團隊比較合適呢?或許和7這個數字比較有緣吧(我家的車牌就有777 -:))，團隊的規模在7個人左右的規模比較容易操作，一來溝通的成本比較低，二來無需安排特定的人員做管理類的工作。這樣整個團隊都會聚焦在具體的事情上。

團隊的組成方式：1-1-3-2，如下圖：

 

"scrum team"

這里需要注意的是，在這樣的規模團隊溝通不再是鏈式的溝通方式，而是有PO和整個團隊傳遞需求，SA和整個團隊傳遞技術。這里沒有真正意義的管理者，團隊是自管理，高度自治。

PO的職責

• 根據MRD(平臺類產品可選)來分析和定義PRD并設計解決方案
• 競品分析、外部數據收集，自我提出制定產品提升需求
• 并規劃產品的Roadmap，制定版本計劃
• 選定每個迭代的Scope，對團隊內澄清需求
• 組織planning game, 組織產品開發中特性的Demo，組織驗收每個版本的交付。組織回顧會議，總結和提升團隊能力。
• (平臺類)收集業務產品反饋，推動業務對于新特新的使用
• (平臺類)運營產品，收集產品運行數據，支撐業務日常使用的方案支持等
• 與架構師配合，規劃產品的技術改進

這里需要再此強調的是，PO需要能夠控制團隊的開發節奏，屏蔽外界對于團隊的干擾，同時還要展現團隊的核心價值。千萬不要做成傳聲筒的角色。

SA的職責

• 產品的技術實現架構的設計
• 指導開發成員的開發
• 指導測試成員的測試設計
• 驅動測試自動化
• 組織Design Review、Code Review、Test Design Review等
• 與PO配合，規劃產品的技術改進
• (平臺類)指導業務團隊架構師對于產品使用的技術支持

SA是這個團隊的技術的代表，需要能代表團隊對外做技術的PK的功底。所以和PO的配合很重要，一個代表需求放，一個代表實現方。沒有哪方比哪方重要，關鍵是如何用技術的方式體現業務的更高價值。SA對于開發的技術能力的提升富有不可代替的責任。

Develper的職責

• 產品的技術實現
• 負責子模塊的詳細設計
• 負責自動化單元測試以及集成測試的開發
• 對產品的技術持續提升提供建議
• 對測試澄清技術細節、協助測試完善測試設計
• 確保代碼即時“可見”：Portal展示/Test Case Pass

最為開發，除了完成開發任務外，還需要對于業界的技術特別是開源的技術的敏感度。加入某些開源的項目，提供一些自己的代碼將是十分有意義的。如果能有自己的想法，自己創建出自己的開源例子那更加完美。不過國內的開源情況，開源還是背靠公司表容易推進。

Tester的職責

• 產品的測試設計完善測試自動化工具與流程
• 驅動開發的完善與補充開發思考上遺漏
• 負責端到端的系統級測試、性能測試、穩定性測試
• 為開發定位問題提供便利
• 產品的發布執行

對于測試，這里需要多說一些。因為有些互聯網公司開始推行無測試的團隊。其實并不代表測試已經不重要了，而是互聯網的快速變化使得對于測試人員的要求與開發一樣高了，而且團隊的運作已經沒有辦法再預留出測試的空檔期了。不過這個還是要看團隊的情況，如果測試能夠從每個迭代就能開始做測試設計，那么測試獨立性還是有必要性的。如果團隊總是以開發主導，變化總是比較隨意(或者叫無法拒絕變化)，或許還是開發自己測試比較合適。

另外就是測試最重要的職責是測試設計，而不是開發的幫手，更不是給開發打雜。測試最重要的價值體現是找到架構、開發上的思維漏洞而不是bug的數量。如果還是用KPI的方式考核測試對于開發的bug的數量，除了助長開發與測試的矛盾，別無益處。

開發與測試的磨合

• 溝通、溝通還是溝通。
• 開發和測試的信息來源將都來自于產品需求，而不是開發是測試的上游
• 測試的定位的轉化。
• 在Scrum模式下，開發與測試的工作邊界將更加模糊。
• 測試有個最主要的功能是測試點的設計而不是通過復雜的重復性工作來體現測試的價值。
• 測試應該更好的思考如何提供便利的工具。讓定位問題和更加方便
• 開發則應該配合測試一起詳細review測試點的設計，并從而思考開發中潛在的問題。

團隊的日常活動

Planning Game

Planning Game的目的是向團隊傳遞這個迭代的范圍，確保團隊每個人都有一致的目標。在一個或者兩個迭代后要以發布一個版本為結果。那么每個版本都可以用一句話的方式總結出來。如果每個迭代沒有一個核心的思想，則迭代范圍將比較混亂，團隊的工作也容易無序。定出來的范圍，需要預先拆解成每個任務項，并且把任務放到gitlab issue中管理，讓每次代碼提交都能關聯起來，便于后續的代碼的審核。同時將任務寫到字條上貼在自己團隊的看板中。看板現在有很多電子版的管理工具，但是不用糾結這個，其實一個真實的看板更管用。(后面會講我們和電子類的看板的不同)

"planning game"

Planning Game的經驗：

• 不要一次性選擇多個大的feature在一個版本中
• 選擇一些小功能或改進性功能作為風險控制的緩沖
• 預留技術改進的工作項
• 以版本維度作為計劃
• 一個版本中以2個開發迭代(4周)為好
• 需要做發布到生產的，預留一周做發布緩存

看板與站會

目前已經有不少電子類的工具提供看板的功能，但是實踐中，使用一個真實的看板反而比較容易操作。看板雖然并不復雜，但是也有相應的書，可以參考<<Kanban in Action >>，如下圖：

"kanban"

和電子類的看板的區別主要在于：

• 聚焦事與人，而非進度。一般的看板總是將不同的task按照進度進行粘貼，處理人寫在字條上。這樣容易讓人忽略誰正在處理的事情，容易忽略誰的情況是最后交付的風險
• 將事情歸類整理，如某個特性相關的事情都粘貼在一起，這樣日常容易掌控某個特性是否能夠端到端的完成，而不至于同時并行過多的特性開發，導致最后無法端到端完成。這樣也容易處理在迭代末尾需要砍任務的時候比較容易

有了看板，那么日常的站會進行將比較容易，不過有些注意點如下：

• 盡可能簡短(15min內)，每個人只講完成情況和遇到的問題，不具體討論方案
• 需要特意申明需要配合的內容
• 額外增加的內容，需要立即貼出來并由PO判斷是否需要做
• 自主領取新的內容，如果有工作依賴或難度的內容，需要TL協調
• 風險需要立即提出
• 盡可能做完一個任務在領下一個任務
• 如果發現任務時間過長，需要做分析和拆解
• 如果覺得任務有難度，開發應該提出要求SA給出設計

Review Meeting

在團隊的日常活動中，有各類的Review Meeting，主要目的是團隊內信息的有效傳遞以及貢獻團隊的智慧。具體操作經驗如下：

由各個主題的Owner自主組織，包括：Design Review, Code Review, Test Design Review, Retrospect Review

對于比較大或比較復雜的設計可以分階段Review: 1/3->1/2->final

Review一定要有最后的完整輸出

時間長度一定要控制，1個小時為宜，時間過長應該分多次

End to End Demo

團隊PO的要確保對于迭代中交付物的驗收，最好的方式就是組織端到端的功能特性的Demo。培養團隊有意識的在每次提交代碼的時候，都能快速將結果展示出來。

Demo會的一些經驗：

• 目前團隊對于輸出的理解是否一致，是否滿足PO的想法
• 不要局限在一定完整測試完，只要能端到端跑完場景即可
• 不要局限一定在版本交付前，而是每個feature為維度，時間可長可短，越早越好
• 不要局限一定要有界面，跑測試代碼也是一種Demo
• 不是去挑刺，也不是去測試

同時Demo會也可以邀請一些關鍵任務參與，如市場人員，樹立大家對于產品的信息，以及傳達團隊對于產品更深刻的理解。

DoD Meeting

DoD: Definition of one。DoD會議主要目的是團隊對于一個迭代的輸出的總結。團隊這個時候可以找個輕松的環境如咖啡廳進行。

"dod"

DoD的一些經驗：

- 以迭代為維度作為DoD

- 版本中的第一個迭代的DoD要為下一個迭代做好風險控制，及時調整版本范圍

- 不要只關注代碼是否已經完成，要同時關注自動化程度、代碼質量程度(Jenkins狀態， Sonar狀態)，文檔情況(Doc, Wiki)，測試結果，是否已經CodeReview，是否已經做了代碼清理工作(如掃描ToDo)等

Retrospect Meeting

回歸會主要團隊的自我反省以及自我提供，主要是提供機會給團隊成員思考有哪些地方做的好的，哪些需要提高的，哪些地方有遺漏等。

"retrospect"

Retrospect meeting的經驗：

• 需要先回顧上一次回顧會的執行情況
• 每項內容每個成員各寫3個認為是重點的內容，寫在便利貼上
• 不是批斗會也不是拍馬屁會
• 需要總結后制定Action Plan
• 盡可能把氛圍調整在一個輕松的環境如咖啡屋
• 頻率可以是兩個版本一次(8-10周)

總結

"summary"

人是活的，流程是死的;沒有明文禁止的，都是應該可以改變的

大家不要過于拘束學術上的定義，而是真實根據自己團隊的情況進行調整，適應以及高效就是好的流程。也不是說Scrum一定能保證高效，也不是說沒有Scrum就不高效，一切取決于人。就像有些大的互聯網公司的核心平臺團隊，每個人的能力和自主性都很強，沒有比散養更好的管理方式了。

另外，如果管理者愿意看到團隊的自治與效率提升，則切實應該考慮如何更好的去信任團隊，去輔助團隊自治，而不是在去做“保姆式”管理。

【本文是51CTO專欄作者“VIPDOCKER-了哥 ”的原創文章，如需轉載請通過51CTO與作者聯系】

戳這里，看該作者更多好文