PingCode團(tuán)隊如何通過敏捷開發(fā)應(yīng)對放開后的疫情沖擊

對需求理解保持高度一致，能夠確保在開發(fā)過程中，無論是誰作為用戶故事負(fù)責(zé)人，無論用戶故事內(nèi)子任務(wù)分派給誰，都能在最終驗收時與預(yù)期的功能保持一致。避免由于某位成員臨時請假的情況下，因為其他成員對需求理解偏差導(dǎo)致最終的結(jié)果不達(dá)預(yù)期。

三、盡量不要指定用戶故事負(fù)責(zé)人

雖然最「正統(tǒng)」的 Scrum 規(guī)范要求不能指定用戶故事的負(fù)責(zé)人，但是我們在實際工作中，還是允許 Team Leader / Product Owner 在某些情況下可以提前指定用戶故事的負(fù)責(zé)人。這主要是為了確保一些關(guān)鍵或復(fù)雜的功能由資深的員工完成，或者讓某些成員能夠有機(jī)會去負(fù)責(zé)一些自己想做的業(yè)務(wù)。

但是在當(dāng)前情形下，我們認(rèn)為提前指定負(fù)責(zé)人會帶來更大的不確定性風(fēng)險。因此，會傾向于更加的謹(jǐn)慎。也就是說，除非出現(xiàn)非常必要的情況，我們是不允許團(tuán)隊在計劃會議中直接指定某些用戶故事的負(fù)責(zé)人。因為指定負(fù)責(zé)人或多或少的會降低參與感與熟悉程度。而一旦出現(xiàn)負(fù)責(zé)人請假的情況，其他成員則很難短時間內(nèi)進(jìn)行補(bǔ)充和替代。

對于必須要指定的極特殊情況，我們也要求同時指定一名后備人員（即雙負(fù)責(zé)人制）。他與負(fù)責(zé)人對用戶故事的理解，以及對技術(shù)實現(xiàn)的了解程度基本一致，能夠確保人員出現(xiàn)問題的時候可以快速補(bǔ)充。

四、每日站會時重點關(guān)注被阻塞的工作

我們要求各團(tuán)隊的 Scrum Master，在近期的每日站會中重點關(guān)注那些被阻塞的工作，在必要的時候逐個詢問團(tuán)隊成員開發(fā)進(jìn)度是否有偏差。

工作被阻塞，一方面可能是因為技術(shù)問題，另一方面，在當(dāng)前還可能是其他成員或其他團(tuán)隊無法按時交付功能點。這在 PingCode 這種多團(tuán)隊、分布式項目中顯得尤為突出。而功能點的延遲交付，很有可能是成員投入不足導(dǎo)致的。

有的時候，成員的投入比例很難在計劃會議中明確預(yù)測。可能在迭代過程中，有的員工本人身體不適，或者家庭原因等等，導(dǎo)致不同程度的投入度不足。而我們不同于歐美企業(yè)，在遇到個人問題和困難時多半會自己解決，而并不會向團(tuán)隊同步。也就是經(jīng)常說的「輕傷不下火線」。雖然這種做法可以理解，但是在客觀上往往會導(dǎo)致工作進(jìn)度和完成質(zhì)量出現(xiàn)了不同程度的下降。而且往往很難被立即發(fā)現(xiàn)。

對于一個 Scrum 團(tuán)隊，我們希望看到真實的狀況，遇到問題和困難大家一起解決。同時 PingCode 團(tuán)隊也不鼓勵所謂的「帶病工作」。因此，關(guān)注阻塞情況能夠幫助我們更快發(fā)現(xiàn)潛在的問題，立即進(jìn)行調(diào)整。這小調(diào)整包括更換負(fù)責(zé)人、調(diào)整迭代目標(biāo)和優(yōu)先級等。確保迭代結(jié)束時，交付的內(nèi)容都是完整的且有質(zhì)量保證的。

五、在群組、需求詳情和評論以及協(xié)作空間討論模塊中進(jìn)行溝通

開發(fā)過程中，團(tuán)隊成員、產(chǎn)品經(jīng)理、設(shè)計師以及運維同事，甚至營銷線同事之間都會有頻繁的溝通。其中涉及需求、技術(shù)、實現(xiàn)等等諸多方面。此前我們推薦大家在可能的情況下面對面溝通。因為這樣效率最高，而且能夠確保大家都明確各自的訴求和最終的結(jié)論。

但是在人員波動較大的當(dāng)下，我們轉(zhuǎn)而推薦大家更多的使用能夠留存數(shù)據(jù)的在線溝通方式。而且避免使用一對一的私聊。這主要是因為，一對一的溝通雖然效率高，但是溝通的結(jié)果僅限于兩個人。一旦后期有人請假，對于接手的其他成員就會出現(xiàn)信息的缺失。即使通過再次溝通能夠彌補(bǔ)這樣的缺失，耗費的時間成本也是一個不能忽略的問題。

因此我們要求團(tuán)隊成員通過以下三種方式進(jìn)行溝通：

一是利用Worktile 群組進(jìn)行溝通：我們?yōu)槊恳粋€ Scrum 小組創(chuàng)建的對應(yīng)的 Worktile 聊天群組，對于迭代內(nèi)的溝通都要求通過群組進(jìn)行交流。這樣一方面保證了信息能夠留存的檢索，另一方面，如果有需要負(fù)責(zé)人替換的情況，也可以通過群組信息快速或者需求詳情。

二是要求對所有結(jié)論性的東西都落實在對應(yīng)工作項的描述和評論中。這樣，任何人打開此工作項，都能夠得到完成的需求詳情、技術(shù)細(xì)節(jié)和討論結(jié)果。

三是使用協(xié)作空間討論偏底層技術(shù)，或者需要長期溝通的內(nèi)容：作為PingCode協(xié)作空間中即將推出的一項新功能，目前已經(jīng)在我們團(tuán)隊內(nèi)部試用了一個月左右。對于那些偏底層技術(shù)，或者需要長期溝通的內(nèi)容，我們要求通過討論功能進(jìn)行。一方面大家可以針對一個問題進(jìn)行回復(fù)，同時也可以針對別人的回復(fù)進(jìn)行評論。通過這種方式能夠讓討論更加深入和有針對性，更容易沉淀出最終的結(jié)果。同時，討論的結(jié)果連同過程，都能夠被快速的查閱和檢索。

六、使用自動化代替人工

需要注意的一點，我們采用上述的任何措施，只能是在人員出現(xiàn)波動的時候，通過靈活運用敏捷開發(fā)流程，盡量的規(guī)避風(fēng)險，將影響降低到可控的范圍內(nèi)部。那么還有什么辦法，進(jìn)一步解決成員構(gòu)成不穩(wěn)定的問題呢？讓更多的工作從人工操作變?yōu)闄C(jī)器自動操作，這不失為一種解決方案，而且是一個根本上的解決方案。

譬如在 PingCode，我們針對 Alpha、Beta 這兩個日常開發(fā)用到的環(huán)境，都做到了基于代碼倉儲的全自動部署的能力，完全不需要人工的干預(yù)。通過在AWS上構(gòu)建的 Jenkins、Kubernetes、Helm 和 Harbor，開發(fā)人員合并代碼后會自動執(zhí)行代碼掃描、編譯、測試、打包和部署工作。3-5分鐘左右，就能夠在 Alpha 環(huán)境看到最新的功能，完全無需研發(fā)和運維人員手工操作。

類似的，對于涉及線上的 RC 和 Production 環(huán)境，我們設(shè)計了完整的部署工單系統(tǒng)。研發(fā)人員只要按需提交申請，指定部署環(huán)境和待執(zhí)行的腳本等，待運維同事確認(rèn)就可以在指定時間自動執(zhí)行，完成部署和上線。

除了流水線以外，我們還充分利用 PingCode 的自動化能力，解決了很多之前需要大家手動執(zhí)行的操作。一方面節(jié)約了開發(fā)的時間，另一方面，也在人員不在崗的時候盡量保持流程的穩(wěn)定性和消息的及時性。

總結(jié)

研發(fā)團(tuán)隊人員的波動是一件很平常的事情，之前也會時有發(fā)生。但是由于第一波疫情的沖擊，使得這一現(xiàn)象體現(xiàn)的尤為突出。敏捷開發(fā)的原則是擁抱變化，而變化不僅是我們之前關(guān)注的需求變化，其實也包含了成員的變化。因此我們認(rèn)為，通過貫徹和優(yōu)化敏捷開發(fā)流程，能夠很好的解決當(dāng)下的問題。

上述的一些規(guī)則，在我們的團(tuán)隊已經(jīng)實施了2周左右。從目前來看取得了較好的效果。雖然各團(tuán)隊的迭代產(chǎn)出或多或少的還是會收到一些影響，但是產(chǎn)品質(zhì)量沒有出現(xiàn)大的問題。團(tuán)隊內(nèi)和團(tuán)隊間的配合也相對穩(wěn)定。因此，我們希望通過這篇文章分享一下經(jīng)驗，能夠幫助大家一起盡力平穩(wěn)渡過這段特殊時刻。