PingCode團隊如何通過敏捷開發應對放開后的疫情沖擊
隨著「第九版」、「二十條」以及最近發布的「新十條」，我們的防疫措施轉向開放和共存，全國各地的企業陸續復工復產。這讓我們仿佛看到了經濟的快速復蘇和生產力的立即回升。
但是，北方的幾個城市相繼出現了大量人員感染的情況。特別是最近，北京的感染人數肉眼可見地快速增加。大家仿佛一夜之間從「因為封控無法上班」變成了「因為發燒無法上班」。突如其來的情況令眾多團隊措手不及：人員因病無法到崗，或者因為需要照料家人無法全身心投入工作，導致項目進度瀕臨失控。
同樣的，作為以北京和西安為研發中心的 PingCode 團隊也面臨著這樣的問題。接下來，本文試圖和大家分享一下我們是如何通過敏捷開發，結合 PingCode 產品本身來盡力解決問題的，希望能夠為您提供一些靈感和思路。
一、更加細致地進行迭代容量估算
在 Scrum 流程中，迭代計劃會議的第一個階段就是要確定團隊的容量，就是確定當前迭代能夠完成的故事點總和。一般來講，這個數字是參考之前已完成的迭代，然后再進行討論，并最終達成共識。
在人員相對穩定的情況下，上述方式不會有什么大問題。但是，因為處在第一波疫情沖擊之下，對于容量估算則要格外謹慎和小心。為此，我們引入了一個簡單的公式進行計算。
首先我們會統計之前（沖擊前）幾個迭代的平均容量。然后再統計當前迭代人員的投入情況（百分比）。主要包括：
-
因為生病，或者需要照料家人等造成的病假或事假。 -
因為恢復期無法以之前100%的能力投入。 -
家人或共居者有陽性，結合目前5-7天的潛伏期，預計可能出現的病假。
這里需要注意的是，我們明確的表示，投入情況并不代表某位成員是否「稱職」，也與績效、工作態度等無關，僅僅是為了團隊能夠盡量合理的預測，保證最終產出物的質量。因為只有這樣，才能讓大家提供最真實客觀的反饋。
最后我們將每位成員的投入情況帶入公式計算，得到一個估算的容量值。再討論確定最終的容量。譬如之前團隊共有5人，平均容量為 50 。本次迭代開始時，兩位同事因病在家休息一周，第二周恢復期只能有50%的工作效率。另一位成員需要照看家人，只有15%的時間能夠參與工作。那么最終的容量值大致是 50 / 5 * (1 + 1 + 0.15 + 0.25 + 0.25) = 26.5 。
二、確保每個人對需求的理解一致
由于人員的不確定性增加，在迭代會議時，大家在討論需求的時候需要更加仔細。在可接受的范圍內，我們建議團隊盡可能地對用戶故事的每一個細節和場景進行充分的討論，確保所有人對需求的理解是一致的。同時，對于討論過程中發掘出的內容進行詳細記錄。
對需求理解保持高度一致，能夠確保在開發過程中，無論是誰作為用戶故事負責人，無論用戶故事內子任務分派給誰，都能在最終驗收時與預期的功能保持一致。避免由于某位成員臨時請假的情況下，因為其他成員對需求理解偏差導致最終的結果不達預期。
三、盡量不要指定用戶故事負責人
雖然最「正統」的 Scrum 規范要求不能指定用戶故事的負責人，但是我們在實際工作中，還是允許 Team Leader / Product Owner 在某些情況下可以提前指定用戶故事的負責人。這主要是為了確保一些關鍵或復雜的功能由資深的員工完成，或者讓某些成員能夠有機會去負責一些自己想做的業務。
但是在當前情形下，我們認為提前指定負責人會帶來更大的不確定性風險。因此，會傾向于更加的謹慎。也就是說，除非出現非常必要的情況，我們是不允許團隊在計劃會議中直接指定某些用戶故事的負責人。因為指定負責人或多或少的會降低參與感與熟悉程度。而一旦出現負責人請假的情況，其他成員則很難短時間內進行補充和替代。
對于必須要指定的極特殊情況，我們也要求同時指定一名后備人員（即雙負責人制）。他與負責人對用戶故事的理解，以及對技術實現的了解程度基本一致，能夠確保人員出現問題的時候可以快速補充。
四、每日站會時重點關注被阻塞的工作
我們要求各團隊的 Scrum Master，在近期的每日站會中重點關注那些被阻塞的工作，在必要的時候逐個詢問團隊成員開發進度是否有偏差。
工作被阻塞，一方面可能是因為技術問題，另一方面，在當前還可能是其他成員或其他團隊無法按時交付功能點。這在 PingCode 這種多團隊、分布式項目中顯得尤為突出。而功能點的延遲交付，很有可能是成員投入不足導致的。
有的時候，成員的投入比例很難在計劃會議中明確預測。可能在迭代過程中，有的員工本人身體不適，或者家庭原因等等，導致不同程度的投入度不足。而我們不同于歐美企業，在遇到個人問題和困難時多半會自己解決，而并不會向團隊同步。也就是經常說的「輕傷不下火線」。雖然這種做法可以理解，但是在客觀上往往會導致工作進度和完成質量出現了不同程度的下降。而且往往很難被立即發現。
對于一個 Scrum 團隊，我們希望看到真實的狀況，遇到問題和困難大家一起解決。同時 PingCode 團隊也不鼓勵所謂的「帶病工作」。因此，關注阻塞情況能夠幫助我們更快發現潛在的問題，立即進行調整。這小調整包括更換負責人、調整迭代目標和優先級等。確保迭代結束時，交付的內容都是完整的且有質量保證的。
五、在群組、需求詳情和評論以及協作空間討論模塊中進行溝通
開發過程中，團隊成員、產品經理、設計師以及運維同事，甚至營銷線同事之間都會有頻繁的溝通。其中涉及需求、技術、實現等等諸多方面。此前我們推薦大家在可能的情況下面對面溝通。因為這樣效率最高，而且能夠確保大家都明確各自的訴求和最終的結論。
但是在人員波動較大的當下，我們轉而推薦大家更多的使用能夠留存數據的在線溝通方式。而且避免使用一對一的私聊。這主要是因為，一對一的溝通雖然效率高，但是溝通的結果僅限于兩個人。一旦后期有人請假，對于接手的其他成員就會出現信息的缺失。即使通過再次溝通能夠彌補這樣的缺失，耗費的時間成本也是一個不能忽略的問題。
因此我們要求團隊成員通過以下三種方式進行溝通：
一是利用Worktile 群組進行溝通：我們為每一個 Scrum 小組創建的對應的 Worktile 聊天群組，對于迭代內的溝通都要求通過群組進行交流。這樣一方面保證了信息能夠留存的檢索，另一方面，如果有需要負責人替換的情況，也可以通過群組信息快速或者需求詳情。
二是要求對所有結論性的東西都落實在對應工作項的描述和評論中。這樣，任何人打開此工作項，都能夠得到完成的需求詳情、技術細節和討論結果。
三是使用協作空間討論偏底層技術，或者需要長期溝通的內容：作為PingCode協作空間中即將推出的一項新功能，目前已經在我們團隊內部試用了一個月左右。對于那些偏底層技術，或者需要長期溝通的內容，我們要求通過討論功能進行。一方面大家可以針對一個問題進行回復，同時也可以針對別人的回復進行評論。通過這種方式能夠讓討論更加深入和有針對性，更容易沉淀出最終的結果。同時，討論的結果連同過程，都能夠被快速的查閱和檢索。
六、使用自動化代替人工
需要注意的一點，我們采用上述的任何措施，只能是在人員出現波動的時候，通過靈活運用敏捷開發流程，盡量的規避風險，將影響降低到可控的范圍內部。那么還有什么辦法，進一步解決成員構成不穩定的問題呢？讓更多的工作從人工操作變為機器自動操作，這不失為一種解決方案，而且是一個根本上的解決方案。
譬如在 PingCode，我們針對 Alpha、Beta 這兩個日常開發用到的環境，都做到了基于代碼倉儲的全自動部署的能力，完全不需要人工的干預。通過在AWS上構建的 Jenkins、Kubernetes、Helm 和 Harbor，開發人員合并代碼后會自動執行代碼掃描、編譯、測試、打包和部署工作。3-5分鐘左右，就能夠在 Alpha 環境看到最新的功能，完全無需研發和運維人員手工操作。
類似的，對于涉及線上的 RC 和 Production 環境，我們設計了完整的部署工單系統。研發人員只要按需提交申請，指定部署環境和待執行的腳本等，待運維同事確認就可以在指定時間自動執行，完成部署和上線。
除了流水線以外，我們還充分利用 PingCode 的自動化能力，解決了很多之前需要大家手動執行的操作。一方面節約了開發的時間，另一方面，也在人員不在崗的時候盡量保持流程的穩定性和消息的及時性。
總結
研發團隊人員的波動是一件很平常的事情，之前也會時有發生。但是由于第一波疫情的沖擊，使得這一現象體現的尤為突出。敏捷開發的原則是擁抱變化，而變化不僅是我們之前關注的需求變化，其實也包含了成員的變化。因此我們認為，通過貫徹和優化敏捷開發流程，能夠很好的解決當下的問題。
上述的一些規則，在我們的團隊已經實施了2周左右。從目前來看取得了較好的效果。雖然各團隊的迭代產出或多或少的還是會收到一些影響，但是產品質量沒有出現大的問題。團隊內和團隊間的配合也相對穩定。因此，我們希望通過這篇文章分享一下經驗，能夠幫助大家一起盡力平穩渡過這段特殊時刻。
