用了Scrum越來越累？這三點幫你走出困境
摘要：你有沒有一種感覺，團隊用了Scrum之後，工作任務越來越多，加班越來越嚴重？有？好兄弟，這篇文章正好能幫你~
本文分享自華為雲社區《用了Scrum越來越累？這三點幫你走出困境》，作者： 敏捷小智 。
你有沒有一種感覺，團隊用了Scrum之後，工作任務越來越多，加班越來越嚴重？有？好兄弟，這篇文章正好能幫你~
「用了Scrum之後，團隊越來越累」，這應該怪Scrum么？其實，這個鍋Scrum還真不背。《2020-Scrum-Guide（簡體中文）》有如下描述：「Scrum基於經驗主義和精益思維。 經驗主義主張知識源自實際經驗以及根據當前觀察到的事物作出的判斷所獲得。精益思維減少浪費，專註於根本。」，也就是說Scrum可以幫助團隊減少浪費，讓團隊開發出最具核心價值的產品，但並沒有說使用了Scrum，工作量會變多或是變少，那問題出在哪呢？我們來分析一下。
問題分析
本文列舉了三個比較具有代表性的原因。
1. 需求沒有得到很好的澄清
從計劃會議開始，團隊就一直處於混沌的狀態：部分業務場景相對複雜， PO僅靠計劃會議不足以向團隊澄清所有重要的業務需求；計劃會議結束，很多需求的細節甚至主要功能，都沒有被開發人員理解，開發人員帶著滿腦子問號進入編碼階段，最終結果可想而知——開發人員在迭代中不斷地和PO對齊，不斷的整改編寫完成的程式碼，測試人員也一直忙於功能測試、回歸測試——整個團隊忙的飛起，做出的產品卻沒有起飛。
2. 估算不準確
這裡包含兩方面估算錯誤，一方面是對團隊速率估算錯誤，另一方面是對於需求工作量估算錯誤。
團隊速率估算錯誤比如：團隊一個迭代使使勁勉強可以做40個故事點的需求，結果團隊高估了自己的能力，以為輕輕鬆鬆就可以做50個故事點的需求，最終造成團隊疲於交付。需求工作量估算錯誤和速率錯誤同理。
3. 團隊內卷
IT行業內卷已經成為常態，以前沒用Scrum大家都寫周報，發給領導彙報工作，誰也不知道彼此幹了啥；現在天天開早會，早會上一聽說，嗯？這兄弟昨天幹了這麼多？那我要做的比你更多（比你更好）——這種內卷氛圍在團隊里蔓延起來，整個團隊就會很累。
解決方法
1. 添加需求梳理會，提前了解需求
Scrum框架中預置的5個活動並不包含需求梳理會，所以很多團隊對「需求梳理會」（以下簡稱梳理會）這個詞感到非常陌生，那什麼是梳理會？
梳理會是PO向團隊成員澄清未來迭代要做哪些需求的活動，開完梳理會再開計劃會議，團隊成員會對需求有更好的理解。梳理會雖然不是Scrum標準活動，但實際生產中，很多Scrum團隊都會在迭代中插入梳理會，幫助團隊對需求達成共識，確保下一個Sprint順利進行。
梳理會什麼時候開，開多久？
梳理會通常在迭代的中後期進行，和Scrum標準事件一樣，梳理會的時間也應該是固定的，且適用於時間盒。梳理會持續時長通常不超過迭代總時長的5%，比如兩周一迭代，團隊可以選擇第二周周三的下午開展需求梳理會。
梳理會怎麼開？
首先聲明一點，需求梳理會不是計劃會議的提前演練，梳理會相對於計劃會議，更像是一種輔助關係，梳理會目的是對Product Backlog進行梳理、細化、排序；計劃會議更多的是對Sprint Backlog里的需求進行拆分、認領。
梳理會首先需要PO說明下迭代哪些需求需要進行開發，同時PO負責向團隊澄清這些需求。如果某個需求太大，PO和團隊一起對需求進行拆分。梳理會上的需求拆分目的是弄清楚下迭代底要做什麼，這個過程不涉及團隊分工，所以需求拆分至Story級別即可，將Story拆分至Task的操作可以放到計劃會議去做。
需求拆分完成後，團隊和PO一起，對新的Product Backlog Item（PBI）進行優先順序排列，並對近期要開發的需求進行工作量估算。所以梳理會給計劃會議打了一個很好的基礎，同時團隊也有更多的時間去深入了解需求，避免需求沒有得到很好的澄清。
2. 合理估算團隊速率和工作量
如果團隊成員對需求理解到位，可每個迭代還是被一大堆工作壓著，那就有可能是計劃會議上活領多了，這就需要團隊對團隊速率以及每個需求的工作量有一個很好的估量。
單個需求的工作量可以以小時為單位，高端點的話，可以用故事點做計量單位。工作量估算的過程，最好是整個團隊都參與進來——人多力量大，一方面能將需求考慮的更全面，另一方面可以縮小估算偏差。更多估算知識可以參考《【DevCloud · 敏捷智庫】估算四篇合集》 。
團隊速率通常不等於一個迭代100%的時間，因為團隊還需要開會、研討等。
團隊速率是以故事點為單位，也就是正常情況下，一個迭代中，團隊能夠交付多少故事點的需求。如果團隊沒有嘗試過使用故事點來估算團隊速率，使用工時來估算也可以。這裡推薦以迭代80%的時間作為可工作時間的上限，也就是說，團隊認領的工作總量不要超過迭代時間*團隊人數的80%。比如團隊7個人，迭代時長為兩周（每天工作八小時，每周工作五天），8*5*2*7*80% = 448h，也就是說這個團隊每個迭代認領的總工作量應該在448h附近（故事點為單位同理）。
如果團隊覺得448h時間還比較緊迫（不考慮團隊磨洋工的情況）或者有很多閑置時間，那麼後續迭代可根據實際情況，重新對團隊速率做估算。
3. Scrum Master遵從敏捷原則，讓團隊遠離內卷
團隊成員之間稍微卷一點，可能會起到一定的積極影響；可是卷的嚴重了，比如996甚至007，整個團隊就很累，這對於團隊發展是不利的。
Scrum本身提倡精益思想，既然團隊迭代初期認領的需求工作量是符合團隊速率的，那麼團隊加班在做什麼呢？是否是過度開發，後面是否會造成浪費？Scrum Master和整個團隊都要反思。
而且敏捷十二原則有一條：「敏捷過程倡導可持續開發，責任人、開發人員和用戶要能夠共同維持其步調穩定延續」，如果團隊按照內卷的節奏，能持續並且高效的發展下去，倒也能接受，可是團隊往往很難堅持，這與敏捷的原則是違背的，作為Scrum Master應該注意到這點，並引導團隊作出調整。
整個大環境都在內卷，如果Scrum Master改變不了團隊內卷的情況，那就為團隊成員準備下《頸椎護理指南》《21天弄明白腰間盤》等養生書籍吧。
總結
以上三點分別從不同的角度講述了用了Scrum之後，團隊越來越累的原因和解決方法，希望對你有幫助。
此文由DevSecOps專家服務團隊出品，前往 專家服務 ，獲取更多DevSecOps工程方法、工具平台、最佳實踐等乾貨。
