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

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

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

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

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

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

四、每日站會(huì)時(shí)重點(diǎn)關(guān)注被阻塞的工作

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

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

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

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

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

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

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

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

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

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

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

六、使用自動(dòng)化代替人工

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

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

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

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

總結(jié)

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

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