寫在前面

故事墻作為交付項目中習以為常的工具，突然的“消失”，才讓我們意識到承載了工作中的很多東西。

沒有預想中的手忙腳亂，團隊的工作卻也沒有想象中的停滯不前。但一些意料之外的阻礙，帶給了我一些對于故事墻價值的思考。

以下是正文：

早上 8:34

睡眼惺忪的我打開手機，便看到群里已經熱鬧起來

“又有線上問題了”

“服務器連不上去了”

......

我心里雖然有些波瀾，但卻并沒有很擔心。

8:45

客戶在微信群里反映，“登不上故事卡墻了 , 沒法測uat了”。

我想，“客戶太勤奮了吧，還要在9點會議前爭分奪秒測試。”

“Jira之前也有這種暫時登錄不了的情況，您別著急，稍等一會兒。”

在群里安撫完客戶之后，我打開電腦，連虛擬專用網，輸入驗證碼，一系列熟練的操作后，刷新之前打開的Jira板子，果然也遇到了和客戶一樣的404報錯的現象。為了多試幾次，我還細(shou) 心(can)的把之前我所有已經緩存的頁面都刷新試試，結果當然是一片報錯。

此時的我，還天真的以為，這次只是像之前多次類似系統(tǒng)不穩(wěn)定一樣的暫時現象，也從沒想過Jira板子的消失和早晨的線上問題是同源。

[[441380]]

圖源自：https://www.atlassian.com/blog/jira-software/the-new-jira-begins-now

9:30

機智的同組小伙伴，沒有像我一樣手殘的刷新板子。站會依舊可以有條不紊的進行。

直到站會結束，Jira依舊打不開，此時的我才意識到，可能不是暫時的系統(tǒng)問題。從群里得知，起碼今天前恢復沒有期望的結果之后，我突然有些手足無措。

“沒有了板子，我們還能正常開卡和Desk Check嗎?QA同學的測試會不會受到影響啊?我在進行的業(yè)務沉淀還能順利繼續(xù)嗎?”

仿佛是本來信心滿滿的開卷考試，突然被沒收了小抄。連本身早應爛熟于心的“知識點”，都有些不確定。

9:45

在又抱著僥幸刷新了幾次無果之后，我定了定神，想到了幾條不幸中的萬幸：

1. 對于Dev & QA同學來說：

團隊在項目開始之初，除了Jira 外，還建立了內部共同維護test case的Trello板子。這樣做可以使得Jira只保留面向客戶的核心業(yè)務邏輯、故事卡&項目進度的信息，而更加細節(jié)類的“kickoff 清單”、工序信息和接口文檔等就維護在Trello板子上。整個流程需要dev同學在卡開前先擬寫case，再在開卡和測試期間，由BA和QA同學一起補充。Trello上的case往往不僅會比Jira上的AC更全，同時還有TL拆的工序，開卡結卡注意事項等重要信息。所以，對于QA和已經開卡的dev小伙伴來說，Trello其實已經作為他們工作期間的主要工具，Jira的消失影響不大。

2. 對于BA來說：

首先，關于需求溝通和澄清的工作。慶幸的是，項目已經接近尾聲，大部分和客戶需要確認的內容已經完成。

其次，關于項目迭代規(guī)劃的工作。得益于剛上項目時，受到Senior BA的啟發(fā)，除Jira卡墻外，我自己還維護了一個比較完整的迭代計劃。雖然只有卡號和卡的標題，但上面還記錄了簽卡進度，開發(fā)進度，開發(fā)周期和估點等詳細信息，可以隨時拿出來當臨時的卡墻。

最為感恩的是，測試系統(tǒng)的大部分功能并未受到影響，可以通過系統(tǒng)操作，喚起大部分的記憶。

3. 對于客戶來說：

雖然現在即將到了UAT測試比較密集的階段，但還好我們的項目不是by迭代上線。距離最后真正上線還有一定的時間。即使勤奮的客戶被迫需要“休息”兩天，Jira的臨時罷工，不會嚴重影響到上線前客戶uat測試的進度。

綜合以上幾點，我有些煩躁的心，慢慢放松下來。

到了下午的時候，我發(fā)現，工作群里也少有因為Jira的問題而產生的抱怨，大家的工作都在有條不紊地進行。本以為可能最會受到影響的開卡、Desk Check和測試的工作并沒有太多受到阻礙，反而是其他一些相比較為“邊緣”的工作受到了一些意料之外的影響：

• 歷史需求細節(jié)難以回憶：由于正處于項目尾聲，我還在對負責的模塊進行業(yè)務沉淀的工作。主要的流程已經有很多成熟的文檔，但缺乏一些比較細節(jié)和tricky的邏輯的總結，以便幫助后人避坑。然而，由于我一直拖延，很多在2月/3月聊的需求的細節(jié)場景單憑記憶很難回憶起來......

• 原有系統(tǒng)邏輯細節(jié)模糊：由于項目是屬于遺留系統(tǒng)改造，除了增加新的功能外，保證原有系統(tǒng)邏輯不受影響也是項目成功的重要標準之一。但部分原有功能背后計算邏輯復雜，頁面信息較少，且屬于早期確認的需求;導致記憶比較模糊，有些細節(jié)我不能完全確認。

• 測試工作成本增加：對于QA測試，即使我們有Trello神器，但遇到需要參考流程圖，計算案例，導入文件樣例，跨squad卡的鏈接等需求時，只有干巴巴簡單文字的Trello就顯得有些愛莫能助。增加了QA小伙伴再去重新找這些資料的時間成本。

總結下來，我發(fā)現，在本項目特殊的背景下，對一個已經非常熟悉敏捷開發(fā)流程的團隊來說，Jira 本期望主要承載【可視化流程管理】的作用，仿佛沒有想象中那么重要。而之前并未太關注的【歷史業(yè)務資源庫】的角色，在“板子消失事件”中凸顯出來。

首先，無論借用我們團隊自己維護的Trello，QA同學自己的用例庫，還是我建的野生計劃板，在較短的時間內群策群力快速建立一個新卡墻并非難事。其次，憑借著系統(tǒng)操作，會議記錄，流程圖等文檔，卡中大部分的AC也能基本補全，只是時間長短的問題。

然而，對于這個承載了多年積累，近百個項目，多個供應商，上萬張故事卡、無數業(yè)務文檔和“幾代人”心血的“故事墻”來說，它已經不僅僅是一塊簡單的團隊協(xié)作的“板子”，而是快成為了公司的第二大腦，作為每次需求更新，軟件改造重要的知識來源。尤其是在本次遺留系統(tǒng)改造的項目中，該隱藏價值發(fā)揮的淋漓盡致。

當然，如此龐雜，且管理并不太規(guī)范的“資料庫”, 也會存在諸多問題：

• 故事卡管理比較混亂，經常會出現一個功能點的故事卡(feature)橫跨多個史詩級別的故事卡(epic)，或者很多錯誤狀態(tài)的故事卡。即使依靠關鍵詞搜索也會占用大量的時間去查找、核對，是不是真實開發(fā)了的功能/是否是最新的邏輯。

• 故事卡分散在各處，沒有比較完整故事線串聯，且需求更新眾多，可能需要花費大量的時間去翻閱是否還有隱藏/遺漏的場景。

• 缺少業(yè)務背景。故事卡還是更多的關注系統(tǒng)功能的實現，對于”WHY“的問題沒能做更好的闡述。只有憑一句比較模糊的”so that…”的闡述，常常讓后面參考的同學摸不著頭腦。如果之后做需求更新時遇到了新PO，客戶可能也很難揣測當時設計時的想法，從而留下一些隱患……

根據5個月左右的項目體驗，對于有類似持續(xù)有需求更新，且強依賴于故事墻做業(yè)務沉淀的項目，我總結可以從以下一些日常小事入手改進：

• 明確故事卡的管理規(guī)則：對于故事卡的名字，狀態(tài)，和不同級別的故事卡之間的關系，盡量做到準確、清晰易讀。如果是針對做需求更新的卡，可以嘗試鏈接之前有很強業(yè)務相關聯的老卡，方便追蹤。同時，善用comments，增加附件等功能，盡可能讓卡中的信息做到全而不漏。

• 場景化業(yè)務需求：在進行業(yè)務沉淀的時候，在以文檔/Keynote的方式進行文字說明/截圖時，也可以插入 user journey + 對應故事卡鏈接。不僅可以幫助客戶在UAT期間建立更好的場景概念，還可以讓其他有需要的同學在了解high level的流程的基礎上，再看卡了解細節(jié)。建立宏觀和細節(jié)的連接。

• 適當補充必要的需求背景：在寫卡和做業(yè)務沉淀的過程中，如果允許的情況下，可以更多的增加對于業(yè)務場景的分析、實例化需求、用戶使用習慣、和功能設計初衷等描述。因為很可能，你從客戶處了解到的獨家業(yè)務信息會成為之后需求更新方案的關鍵。

• 一定要及時整理業(yè)務知識/ test case：重要的流程圖，會議紀要，場景分析的文檔也要及時在過程中歸類整理，有助于之后迅速定位，也方便后人參考。其實，即使沒有這次的事件，今年1、2月份那些更多涉及到實際業(yè)務場景等偏“WHY”的知識也有些淡忘，如果當時及時總結，也可以很好地避免我再去和客戶請教時，卻被反問 “你是要準備出書?”的尷尬場面。

當然，冰凍三尺，非一日之寒, 何況是在如此復雜和時間跨度大的背景之下。但從我做起，從小事做起，期望可以將Jira 原本【歷史資料庫】的角色更好的發(fā)揚光大。

第二天早上8:45

那位勤奮的客戶依舊因為測不了UAT在群里的”哀嚎”：

"Early birds have no feed."

如今，時間也早已過去了24小時，心心念念的板子還沒恢復。雖然這只是一次偶發(fā)事件，但通過這次小意外，我想我們都有了一些收獲。

最后，祝福Jira早日康復。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉載請聯系原作者】

戳這里，看該作者更多好文