無論作為產品用戶還是管理諮詢顧問，都非常非常喜歡微信。自認感情比較剋制屬於“高冷”掛，但從很多方面都太佩服太崇拜張小龍了（新書裡微信也會是最喜歡的案例之一，真的不只是一個產品而已，很多方面都太牛了）。不知道大家是否有注意到，在疫情爆發後，微信的響應大概最快速也相對最到位的了，看一看立馬有了“疫情專區”（不知道官方名稱是什麼，以下暫以此代稱），對於瞭解疫情整體數據和最新動態都很有幫助，真是覺得太棒了。
之前瞭解到微信也是使用敏捷開發，最近也在籌備ASM實戰課程和Scrum諮詢服務產品，奇葩開個腦洞用Scrum YY一下看一看“疫情專區”開發過程，也通過這種方式簡單科普一下敏捷開發基本理念與價值以及Scrum的流程實踐吧。
本文包括4部分：
- 敏捷開發基本理念與價值
- 敏捷開發實踐方法
- Scrum的3個角色與5個活動
- 如何通過Scrum實現微信看一看“疫情專區”
敏捷開發基本理念與價值
敏捷開發根源於適應性項目管理和精益開發，相較於傳統基於“預測+規劃+控制”的瀑布式開發方式，能夠適應需求變化的風險，及時理解與響應客戶需求，通過週期迭代交付可工作的增量產品的方式，增強項目管理靈活性與可預測性，並基於團隊責任制的工作理念運行，借鑑精益管理理念與優秀實踐，流程效能高，能夠顯著優化開發成本，提升產品質量與競爭力、客戶滿意度、團隊及干係人滿意度。
就像微信看一看的“疫情專區”，這肯定不是在原來的開發計劃之內的。當外部發生變化，敏捷團隊不會還按原來的計劃生硬刻板執行，而是及時識別需求，並且能夠快速在產品層面實現，從而應對變化，就是敏捷對優秀產品競爭力的賦能。
敏捷開發實踐方法
Scrum是敏捷開發的具體實踐方法之一，優點在於覆蓋開發環節廣，具體方法的執行意見最全並且可實施性最強，定義了非常詳細的團隊角色職責與實施流程步驟，量級輕很容易理解上手，不過想要精通會有難度。
Scrum可以概括為“3355”，也就是“3個角色、3個工件、5個活動和5大價值觀”。下面就用Scrum模擬一下微信看一看的“疫情專區”可能是怎麼實現的。
Scrum的3個角色與5個活動
先簡要同步一下Scrum的3個角色與5個活動。
Scrum的3個角色包括SM(Scrum Master), PO(Product Owner)和Dev Team(Development Team)，職責如圖所示。
Scrum的5個活動包括Plan Meeting, Sprint, Daily, Review和Retro，簡介如圖所示。
如何通過Scrum實現微信看一看“疫情專區”
回到微信看一看“疫情專區”，用Scrum來模擬一下，包括Product Backlog, Plan Meeting&Sprint Backlog, Sprint&Daily, Reveiw&Increment和Retro5個環節。從軟件開發整體過程來看，首先是規劃。
4.1 | Product Backlog
這裡涉及到Scrum的2個工件，就是Product Backlog和Sprint Backlog。Product Backlog需要PO定義產品願景，再根據產品路線圖和版本發佈規劃（決定項目範圍、日程和資源）規劃Sprint Backlog。
Product Backlog根據需求的層級和顆粒度可以分為史詩、特性和用戶故事。
比如微信這個產品可能是一個開發項目集，“看一看”有可能只是其中的項目之一，“朋友在看”可能是一個“史詩”需求，“疫情專區”是一個特性，在這之下再創建顆粒度更細的用戶故事。
用戶故事（User Story）是從需要該新功能的用戶角度對需求進行短小簡單的描述。標準格式是：As a <role>, I want <activity>, so that <user>（作為一個， 我想要, 以便於）/<user>/<activity>/<role>
比如大家點擊看一看頂部的這個數據儀表盤，可能是這樣的一個用戶故事。
相較於傳統的文檔而言，用戶故事的優點在於把需求編寫和責任劃分轉移到溝通與理解。Product Backlog是一個動態管理的過程，不需要一下把所有的需求都寫完，而且需求的內容和優先級等可能隨時會變化，PO保證一定數量的用戶故事比較詳細可以用於接下來Spirnt Backlog的規劃即可，過程中對Product Backlog進行動態的持續梳理維護。
4.2 | Plan Meeting&Sprint Backlog
下面Scrum的第一個活動可以開展了，就是Plan Meeting。假定一個迭代兩週，這個迭代的目標就是“上線‘疫情專區’幫助微信用戶快速瞭解疫情相關信息”（敏捷開發靈活響應變化的優勢很明顯不是嗎？）。
Plan Meeting在確定Sprint目標後，需要理解和估算User Story確定Sprint Backlog。
比如現在，我們就會根據優先級把待規劃的需求一個一個討論，PO需要回答Dev Team提出的問題，確保Dev Team對用戶故事都充分理解，從而更好地規劃之後的工作。比如針對剛才這個用戶故事，Dev Team可能就會開始討論：要不要通過手機定位優先推送本地信息？要不要加入新增數據？累計治癒是綠色的，其它的是白色還是忘了選顏色？PO會根據這些問題逐步細化需求，最終打開團隊共識。
在充分溝通理解用戶故事之後，Dev Team對用戶故事進行effort估算。估算可以採取故事點（Story Points）或理想小時/天數（Ideal Hours/Days）。
Product Backlog中的用戶故事就這樣從右邊進入左邊的Sprint Backlog。至於放入多少合適呢？
根據過去的數據統計，我們的團隊速率（Velocity，即每個Sprint完成的用戶故事故事點均值）是18.58個故事點，現在已進入Sprint Backlog的用戶故事故事點已經18了，那麼我們就先放入這麼多的用戶故事，不再添加了。
接下來Dev Team會規劃用戶故事下的具體工作，不是被動地執行被分配好的工作，而是看哪些工作需要進行才能夠很好地實現用戶故事。成員自主領取工作任務後，我們就正式愉快地開始Sprint啦。
4.3 | Sprint&Daily
Sprint期間每天要開Daily（每日站會），同步接下來一天的工作。Dev Team成員直接對著任務板輪流回答三個重要的問題（不是“你是誰”、“從哪兒來”和“到哪兒去”，雖然本質類似）：
- 前一天做了什麼幫助達成Sprint Goal；
- 今天計劃做什麼；
- 遇到的問題和困難，或者看到了哪些問題可能會導致Goal無法達成，但不就問題的解決展開討論。
過程中跟蹤進度常使用的工具包括任務板、燃盡圖、停車場圖和甘特圖等。
4.4 | Review&Increment
Sprint工作完成後通過Review驗收Scrum的第三個工件-增量（Increment），即可工作的軟件。之前看到一個團隊竟然Review的時候是一堆程序猿面紅耳赤地評審代碼？嗯？這操作就有點兒迷了。正確的姿勢是Dev Team直接進行產品演示，確保交付增量是可工作的軟件。比如對於“疫情專區”，Review可能是工程師們手機投屏直接演示功能是可用的。
4.5 | Retro
Review之後是Retro，回顧哪些方面執行比較好應該堅持做、哪裡需要改善以及具體如何改善，可以在Review直接連在一起開。
然後的然後就是我們打開微信看一看，就有這麼一個非常棒的“疫情專區”了。當然，以上內容只是通過Scrum基本流程簡單模擬一下，中間還有很多內容和細節沒有展開。就像前文提到的，
Scrum量級輕容易實踐，然而想要做得很好其實是非常難的，可產生的效益以及對效能提升的幫助，卻也正在於實踐的深度。像去年接觸研發團隊格外多，發現絕大部分團隊說是敏捷轉型幾年了，實際都不到文化層面，實踐層面還有很多非常不敏捷的地方，剛才的“代碼評審式Review”就是一個例子。大部分團隊的“敏捷”只是“短週期瀑布式開發”，開發模式完全沒變，只是把週期縮短為半個月或一個月，其實跟敏捷毫無關係，所以轉型幾年依然沒有產生任何效益。
敏捷開發的優勢已無需證明，關鍵在於從價值的認知到行動去踐行、享受價值。Worktile的新使命也是“智簡研發”，產品和諮詢服務都會在助力研發效能提升方面持續發力。從諮詢服務方面而言，除了適用於企業整體運營管理的OKR，在疫情平穩後，會上線全新的敏捷諮詢服務，首期服務就是基於EXIN ASM課程體系的實戰Scrum課程與諮詢服務。
這一服務產品還是秉承WMC團隊一貫的實戰風格，不是講講空洞的理念和基本的方法做些遊戲就可以了，而是融入了團隊幾位微軟MVP與業內資深敏捷專家近十年的實踐經驗總結，設計實用性極高的內容、教材與實踐手冊等，通過對Scrum體系的全方位深入實踐講解、應用模擬、實戰問題全面識別解析以及變革全流程管理，幫助企業真正做到“We do Scrum”，更是實現“We are Scrum”的進階。放一個課件的部分preview，整個產品正在反覆打磨，期待春暖上線，給更多研發團隊敏捷轉型提供到一些實在的幫助。
最後從產品角度作為迷妹再次表白兩個人，一位當然是張小龍，還有一位是Worktile CTO-Terry。微信在我看來不僅僅是一款產品那麼簡單，而是一個強大的生態，是很多優秀管理實踐的最佳化身，之後也會針對微信做更深入的案例剖析。
另外表白的就是Terry~本文中演示Scrum流程使用的產品截圖就是去年Worktile六週歲時發佈的全新研發系列產品之一：Agile-敏捷開發，也是國內唯一一款標準的即開即用專業Scrum管理平臺。除了Agile，目前正式發佈的還有Testhub-測試管理，還有更多重磅產品真心值得期待。Terry是Worktile產品的靈魂工程師，包括之前Teams這個產品，真的是在極致專業之下才能打造出這麼強大流暢好用的產品，細節之處尤見用心（話說Terry迷妹迷弟也是多到也排不上號sigh······）。對於管理實踐落地與固化，尤其是研發場景，產品的價值尤為顯著。也希望Agile、Testhub和接下來的諮詢服務，能夠一起幫助更多研發團隊更好地實現敏捷轉型，以更高效也更愉悅的工作體驗解放研發生產力，創造出更多驚豔的優秀產品。
產品角度之外還要表白一下我們Worktile首席科學家徐子巖老師~徐老師是前微軟高級項目經理，連續六年獲微軟MVP，研發管理實戰經驗非常豐富，在研發管理諮詢服務產品開發過程中提供了莫大的寶貴支持，也是我的Scrum最佳第一老師，希望之後的服務產品能夠把徐老師的一線獨到經驗更好地傳播到更多敏捷團隊~還要特別感謝男神對本文的專業支持，手動筆芯~
閱讀更多 Worktile 的文章
