關(guān)于我

加入ThoughtWorks之前，筆者曾有幸參與了幾家大型企業(yè)IT部門項(xiàng)目管理和組織級敏捷轉(zhuǎn)型咨詢。作為一個(gè)曾經(jīng)的PMO咨詢顧問和敏捷教練，我深知敏捷轉(zhuǎn)型在企業(yè)中落地的艱難。其難度不僅在傳統(tǒng)工程實(shí)踐的習(xí)慣的轉(zhuǎn)變，更由于組織結(jié)構(gòu)以及業(yè)務(wù)流程帶來的挑戰(zhàn)。在加入 ThoughtWorks之后，我在以 BA（業(yè)務(wù)分析師）的身份工作的同時(shí)，對敏捷實(shí)踐的落地以及敏捷轉(zhuǎn)型的實(shí)際問題也有了更深的理解。

在作為BA支持了幾個(gè)項(xiàng)目的交付落地以后，我發(fā)現(xiàn)由于組織結(jié)構(gòu)或經(jīng)費(fèi)等等原因，大多數(shù)軟件交付的團(tuán)隊(duì)是沒有專門的敏捷教練的。而BA作為團(tuán)隊(duì)中重要的組織協(xié)調(diào)者，在幫助項(xiàng)目梳理需求，跟進(jìn)需求落地的同時(shí)，還需要幫助團(tuán)隊(duì)進(jìn)行敏捷成熟度的提升，以確保交付更順利地進(jìn)行。無論BA是在客戶方的團(tuán)隊(duì)還是Thoughtworks內(nèi)部的團(tuán)隊(duì)里工作，都是如此。

故事背景

2017年6月，我參與了某大型房地產(chǎn)互聯(lián)網(wǎng)企業(yè)在東南亞地區(qū)的收購項(xiàng)目。該房地產(chǎn)互聯(lián)網(wǎng)公司和ThoughtWorks合作多年，在敏捷工程實(shí)踐上已經(jīng)有了很深的積累。但剛被該公司收購的不久的亞洲各個(gè)互聯(lián)網(wǎng)公司的敏捷轉(zhuǎn)型剛剛起步，成熟度還比較低。在加入目標(biāo)公司團(tuán)隊(duì)以后，我發(fā)現(xiàn)團(tuán)隊(duì)即使在用JIRA作為Kanban工具來管理日常工作，但對于敏捷實(shí)踐、理念的理解卻不清晰或者存在許多誤區(qū)，變成了“形式上的敏捷”。例如：

?1. 團(tuán)隊(duì)沒有故事卡 kick-off 和desk-check，開發(fā)工程師直接把故事卡拿到自己的名下開始工作。在開發(fā)完成后沒有desk-check，直接合并代碼，導(dǎo)致質(zhì)量問題。

2. 比如團(tuán)隊(duì)對迭代目標(biāo)以及需求的優(yōu)先級不清楚，出現(xiàn)高優(yōu)先級或高依賴的故事卡無人認(rèn)領(lǐng)，低優(yōu)先級的故事卡在開發(fā)中的情況。這導(dǎo)致下游對我們有依賴的團(tuán)隊(duì)工作被堵塞，無法進(jìn)行。

3. 而由于團(tuán)隊(duì)成員分布在5個(gè)不同的國家或地區(qū)，且前后端完全分離，給項(xiàng)目內(nèi)的溝通帶來了天然的屏障。出現(xiàn)團(tuán)隊(duì)之間溝通不透明，工作進(jìn)展不明確，干系人之間互相抱怨的情況。

而由于網(wǎng)站的上線日期近在咫尺，若想保障交付的順利進(jìn)行，作為BA僅僅著眼于需求的梳理是不夠的，必須要扮演一部分敏捷教練的角色協(xié)助團(tuán)隊(duì)進(jìn)行一些改進(jìn)。否則，“持續(xù)交付功能”就變成了“持續(xù)交付 Bug”。

BA在促進(jìn)團(tuán)隊(duì)的敏捷轉(zhuǎn)型中能做什么呢？

BA不是專職的敏捷教練，在項(xiàng)目交付中主要的精力還是需要投入到本職工作中。但從敏捷轉(zhuǎn)型的角度，BA能做的是從業(yè)務(wù)和需求出發(fā)對團(tuán)隊(duì)成員加以引導(dǎo)，幫助植入敏捷概念，引導(dǎo)敏捷實(shí)踐在團(tuán)隊(duì)的落地。當(dāng)然各個(gè)項(xiàng)目的背景和問題不盡相同，BA需要根據(jù)項(xiàng)目的實(shí)際情況去識別項(xiàng)目敏捷管理方面的問題，找到解決方案，并在實(shí)踐中不斷調(diào)整。在上文提到的互聯(lián)網(wǎng)房地產(chǎn)網(wǎng)站的項(xiàng)目案例中，我從BA的角度出發(fā)，基于已發(fā)現(xiàn)的問題，在促進(jìn)團(tuán)隊(duì)改進(jìn)以及敏捷轉(zhuǎn)型中識別了一些關(guān)鍵活動：

一、幫助團(tuán)隊(duì)建立敏捷的交付流程

我所加入的客戶團(tuán)隊(duì)原先是沒有QA和BA的，也沒有完善的流程來管理一張故事卡片的生命周期。在 ThoughtWorks的BA和QA加入后，我們發(fā)現(xiàn)由于沒有卡片的kick-off, 開發(fā)對于卡片的理解和卡片原本需要達(dá)到的目標(biāo)容易不一致，導(dǎo)致返工; QA在測卡時(shí)不了解卡片內(nèi)容和上下文，測試時(shí)也不知道如何開始。而沒有desk-check, 開發(fā)做完卡直接挪到 in QA, QA發(fā)現(xiàn)問題需退回去重新開發(fā)，導(dǎo)致反復(fù)返工，影響交付效率。

我和QA小伙伴一起，提議在團(tuán)隊(duì)里執(zhí)行完整的 “Kick-off to desk-check”流程。并且組織了一次會議和團(tuán)隊(duì)分享了一張故事卡的完整生命周期，以及各個(gè)角色在不同環(huán)節(jié)應(yīng)該如何參與，并和團(tuán)隊(duì)就工作流程達(dá)成一致。如下圖所示：

1. 我們將使用Backlog來管理還未進(jìn)入當(dāng)前迭代, 并且未開始分析的需求。

2. BA正在分析中的卡片會放在“In Analysis” 列。

3. 而已經(jīng)分析清楚的卡片會放進(jìn)“Ready for Dev”，按照優(yōu)先級的高低從上至下的排列，開發(fā)在拿取卡片時(shí)也需要從上至下，先拿優(yōu)先級高的卡片。

4. 在開發(fā)領(lǐng)卡以后，會由開發(fā)，BA， QA一起對卡片做kick-off, 保證大家對卡片內(nèi)容和上下文的理解一致。

5. 在完成開發(fā)以后，開發(fā)人員需要發(fā)起desk-check，由QA, BA（我們團(tuán)隊(duì)是純后端團(tuán)隊(duì)，所以沒有UX，而對于前端或者端到端的團(tuán)隊(duì)來說，kick-off 和desk-check都是需要UX 參與的）一起檢查結(jié)果是否符合驗(yàn)收標(biāo)準(zhǔn)，不符合標(biāo)準(zhǔn)的卡片將由開發(fā)人員繼續(xù)修改，直到通過desk-check為止。

6. 卡片進(jìn)入測試環(huán)節(jié)以后發(fā)現(xiàn)的問題，將由QA建Bug卡來跟蹤，由引發(fā)bug的開發(fā)人員來修復(fù)。

7. 測試通過的卡片需要及時(shí)推送到beta環(huán)境，供依賴我們成果的web前端團(tuán)隊(duì)使用。（不同的團(tuán)隊(duì)和項(xiàng)目的在環(huán)境配置上的情況不同）

這一套流程的明確相當(dāng)于給了團(tuán)隊(duì)一個(gè)工作協(xié)議，每個(gè)團(tuán)隊(duì)成員都按協(xié)議領(lǐng)取故事卡，并參與到卡片生命周期的不同環(huán)節(jié)中，最大限度的保障卡片交付的順暢和質(zhì)量。

二、推廣正確的敏捷實(shí)踐

除了梳理和確立流程，BA在一個(gè)團(tuán)隊(duì)的敏捷實(shí)踐的引導(dǎo)上也起著至關(guān)重要的作用。BA經(jīng)常需要作為引導(dǎo)者帶領(lǐng)團(tuán)隊(duì)進(jìn)行每迭代一次的迭代計(jì)劃會議，或是對于史詩故事（ Epic Story）或者用戶故事（User Story）的工作量估算，等等。當(dāng)然團(tuán)隊(duì)里還存在很多技術(shù)上的敏捷實(shí)踐，比如結(jié)對編程，持續(xù)集成等，這些都由團(tuán)隊(duì)的技術(shù)負(fù)責(zé)人（通常稱tech lead）來主導(dǎo)，在此不多做贅述。

在加入了該項(xiàng)目以后，我發(fā)現(xiàn)團(tuán)隊(duì)沒有迭代計(jì)劃會議，導(dǎo)致團(tuán)隊(duì)對于接下來要做的工作的優(yōu)先級不清楚，而只有部分成員清楚接下來工作需求和技術(shù)方案。為了向團(tuán)隊(duì)澄清接下來工作的優(yōu)先級和具體需求，以下幾件事情勢在必行：

1. 確定接下來的上線計(jì)劃，梳理團(tuán)隊(duì)工作的優(yōu)先級

團(tuán)隊(duì)工作的優(yōu)先級是和整個(gè)項(xiàng)目的優(yōu)先級緊密聯(lián)系的。而該項(xiàng)目是一個(gè)截止時(shí)間驅(qū)動型（Deadline Driven）的項(xiàng)目，因此項(xiàng)目的優(yōu)先級就需要參考上線計(jì)劃。我從交付負(fù)責(zé)人處拿到了各個(gè)站點(diǎn)的上線計(jì)劃。從上線計(jì)劃（從下圖）則可以輕易的識別出，在當(dāng)時(shí)的時(shí)間點(diǎn)（2017年7月），團(tuán)隊(duì)的第一優(yōu)先級就是支持香港站點(diǎn)上線了。

但在團(tuán)隊(duì)的一份已有的需求列表上，優(yōu)先級卻是按如下的方式排列的：

這個(gè)列表會使人困惑。按照各站點(diǎn)上線的時(shí)間表，香港站的開發(fā)時(shí)間只剩不到一個(gè)月了，雖然各個(gè)站點(diǎn)在功能模塊上大同小異，但目前顯然沒有那么多時(shí)間讓我們一蹴而就的完成所有站點(diǎn)的工作量。而且由于我所在的團(tuán)隊(duì)負(fù)責(zé)的是中間API層的工作，網(wǎng)頁前端的開發(fā)對我們的成果是強(qiáng)依賴關(guān)系，API層的工作不完成，將直接影響網(wǎng)頁前端的開發(fā)甚至站點(diǎn)的按時(shí)上線。這個(gè)時(shí)候團(tuán)隊(duì)要做的是聚焦在香港站上線的支持上，其他工作都需要往后排。

在得到客戶方交付負(fù)責(zé)人的同意后，我開始根據(jù)各個(gè)站點(diǎn)的上線時(shí)間表重新整理優(yōu)先級。整理后的需求列表如下：

團(tuán)隊(duì)在香港站上線前需要支持的工作放在第一優(yōu)先級。其他功能根據(jù)各個(gè)站點(diǎn)的上線時(shí)間一一往后排，放進(jìn)backlog，暫時(shí)不用關(guān)注。

2. 定期召開迭代計(jì)劃會議，向團(tuán)隊(duì)澄清迭代目標(biāo)和需求

在理清楚團(tuán)隊(duì)接下里的工作內(nèi)容和優(yōu)先級以后，就需要向整個(gè)團(tuán)隊(duì)澄清傳達(dá)了，保證整個(gè)團(tuán)隊(duì)對于目標(biāo)和需求的理解一致。因此，迭代會議是敏捷交付團(tuán)隊(duì)不可或缺的過程。而由于團(tuán)隊(duì)之前沒有迭代計(jì)劃會議的慣例，BA需要和交付負(fù)責(zé)人以及團(tuán)隊(duì)就開會的原因和目標(biāo)達(dá)成一致并設(shè)定會議時(shí)間，環(huán)節(jié)。

此外，由于團(tuán)隊(duì)不熟悉工作量估算的方法，在迭代會議中，BA還需要協(xié)助團(tuán)隊(duì)快速選擇一種合適的估算方法，找到工作量估算的基線（如確定某個(gè)故事卡為1個(gè)故事點(diǎn)，或者一個(gè)標(biāo)準(zhǔn)人天等），并通過工作量相對大小的對比來進(jìn)行工作量估算。這樣做的目的是通過幾個(gè)迭代的積累，了解團(tuán)隊(duì)的工作速率，為以后的迭代計(jì)劃設(shè)立參照。

三、促進(jìn)信息的可視化，加強(qiáng)各團(tuán)隊(duì)之間以及和重要干系人的溝通

面對面的單點(diǎn)溝通往往是最順暢的，而在同一個(gè)地點(diǎn)工作的小團(tuán)隊(duì)（如，5-8人）的溝通也往往不成問題。但由于客戶組織結(jié)構(gòu)的特殊性，項(xiàng)目是由分布在5個(gè)不同的國家和地區(qū)的團(tuán)隊(duì)組成的，如墨爾本，馬來西亞，中國西安，印尼和香港；而且前后端完全分離（前端團(tuán)隊(duì)，中間層API團(tuán)隊(duì)，以及后端團(tuán)隊(duì)完全分開）。除了語言和文化會造成一定的障礙以外，團(tuán)隊(duì)成員的對敏捷工作流程的差異給項(xiàng)目的溝通增加了更多的難度。

作為BA剛加入團(tuán)隊(duì)時(shí)，我偶然會聽到一些其它團(tuán)隊(duì)對我所在團(tuán)隊(duì)的抱怨，大意是前端團(tuán)隊(duì)完全不知道我所在的API團(tuán)隊(duì)在做什么，Jira看板也看不懂，進(jìn)度也不明確。經(jīng)過分析：我發(fā)現(xiàn)原因主要有兩個(gè)。

1. 前端，API，后端三個(gè)團(tuán)隊(duì)的依賴太強(qiáng)，但各個(gè)團(tuán)隊(duì)的進(jìn)度未充分可視化。

2. 未及時(shí)和各干系人做好同步。

由于組織架構(gòu)的關(guān)系，項(xiàng)目里各團(tuán)隊(duì)之間的依賴關(guān)系是特別強(qiáng)的，如下圖所示：

一旦后端團(tuán)隊(duì)的工作不完成，API 團(tuán)隊(duì)就無法開始工作，因此前端的需求也無法開始開發(fā)。如果多邊通信結(jié)構(gòu)中信息傳遞一旦出現(xiàn)障礙，還會引發(fā)其它的狀況。例如曾經(jīng)出現(xiàn)過后端或者 API 團(tuán)隊(duì)的工作已經(jīng)完成了，而前端團(tuán)隊(duì)并不知情的情況。

作為BA，在這種場景下需要做兩件事情：

1. 建立端到端的史詩故事看板（Epic kanban），向其他團(tuán)隊(duì)可視化進(jìn)度。由于API團(tuán)隊(duì)的故事卡并不是嚴(yán)格意義上的用戶故事，而是技術(shù)任務(wù)卡。因此當(dāng)其他團(tuán)隊(duì)或干系人想要了解進(jìn)展時(shí)，是很難直接從卡片的層面上識別某功能是否已經(jīng)支持了。為了更好的統(tǒng)籌需求，可視化進(jìn)展，一個(gè)端到端的史詩看板就非常必要了。有了這個(gè)看板并及時(shí)更新，前端團(tuán)隊(duì)就可以快速了解又有哪些需求的后端被解鎖，前端可以開始開發(fā)了。

2. 在每天的項(xiàng)目級站立會上及時(shí)更新團(tuán)隊(duì)進(jìn)展。項(xiàng)目級站會又稱 Scrum of Scrums，項(xiàng)目的PO，交付負(fù)責(zé)人，BA等重要干系人參加。項(xiàng)目上決定的傳達(dá)，各團(tuán)隊(duì)之間的信息交換都會在這個(gè)會議上發(fā)生，所以這是一個(gè)溝通進(jìn)展和風(fēng)險(xiǎn)的最佳場合。除了利用看板可視化進(jìn)度以外，再在這個(gè)會議上需要同步進(jìn)度和風(fēng)險(xiǎn)。在這樣的雙重措施之下，所有的集成事務(wù)一目了然，提升了總體進(jìn)度的透明度。

寫在最后

從業(yè)務(wù)層面，BA是需求的開發(fā)者和橋梁；從團(tuán)隊(duì)運(yùn)轉(zhuǎn)的層面，BA是重要的組織協(xié)調(diào)者。在團(tuán)隊(duì)沒有專職敏捷教練的情況下，BA在做好需求梳理的同時(shí)，適當(dāng)?shù)倪M(jìn)行敏捷實(shí)踐的引導(dǎo)以及敏捷理念的傳達(dá)，必定能幫助更順利的交付，給團(tuán)隊(duì)敏捷成熟度的發(fā)展助力。

該房地產(chǎn)網(wǎng)站公司的案例只是我作為BA在單一的項(xiàng)目實(shí)踐中的體會總結(jié)。根據(jù)不同的項(xiàng)目狀況，BA在促進(jìn)團(tuán)隊(duì)發(fā)展，以及敏捷轉(zhuǎn)型中還可以做更多。當(dāng)然實(shí)施起來可能并沒有那么容易，我們需要更多的時(shí)間，更多的引導(dǎo)和實(shí)踐來逐漸培養(yǎng)團(tuán)隊(duì)的敏捷意識。小團(tuán)隊(duì)的敏捷轉(zhuǎn)型本質(zhì)上是一種自下而上推進(jìn)組織級敏捷轉(zhuǎn)型的方式，如果團(tuán)隊(duì)內(nèi)的各個(gè)角色都一起努力，所有團(tuán)隊(duì)一起來做，組織級敏捷轉(zhuǎn)型的實(shí)現(xiàn)也就不遠(yuǎn)了。