Jira“消失”的24小時
寫在前面
故事墻作為交付項目中習以為常的工具，突然的“消失”，才讓我們意識到承載了工作中的很多東西。
沒有預想中的手忙腳亂，團隊的工作卻也沒有想象中的停滯不前。但一些意料之外的阻礙，帶給了我一些對于故事墻價值的思考。
以下是正文：
早上 8:34
睡眼惺忪的我打開手機，便看到群里已經(jīng)熱鬧起來
“又有線上問題了”
“服務器連不上去了”
......
我心里雖然有些波瀾，但卻并沒有很擔心。
8:45
客戶在微信群里反映，“登不上故事卡墻了 , 沒法測uat了”。
我想，“客戶太勤奮了吧，還要在9點會議前爭分奪秒測試。”
“Jira之前也有這種暫時登錄不了的情況，您別著急，稍等一會兒。”
在群里安撫完客戶之后，我打開電腦，連虛擬專用網(wǎng)，輸入驗證碼，一系列熟練的操作后，刷新之前打開的Jira板子，果然也遇到了和客戶一樣的404報錯的現(xiàn)象。為了多試幾次，我還細(shou) 心(can)的把之前我所有已經(jīng)緩存的頁面都刷新試試，結(jié)果當然是一片報錯。
此時的我，還天真的以為，這次只是像之前多次類似系統(tǒng)不穩(wěn)定一樣的暫時現(xiàn)象，也從沒想過Jira板子的消失和早晨的線上問題是同源。
圖源自：https://www.atlassian.com/blog/jira-software/the-new-jira-begins-now
9:30
機智的同組小伙伴，沒有像我一樣手殘的刷新板子。站會依舊可以有條不紊的進行。
直到站會結(jié)束，Jira依舊打不開，此時的我才意識到，可能不是暫時的系統(tǒng)問題。從群里得知，起碼今天前恢復沒有期望的結(jié)果之后，我突然有些手足無措。
| “沒有了板子，我們還能正常開卡和Desk Check嗎?QA同學的測試會不會受到影響啊?我在進行的業(yè)務沉淀還能順利繼續(xù)嗎?” |
仿佛是本來信心滿滿的開卷考試，突然被沒收了小抄。連本身早應爛熟于心的“知識點”，都有些不確定。
9:45
在又抱著僥幸刷新了幾次無果之后，我定了定神，想到了幾條不幸中的萬幸：
1. 對于Dev & QA同學來說：
團隊在項目開始之初，除了Jira 外，還建立了內(nèi)部共同維護test case的Trello板子。這樣做可以使得Jira只保留面向客戶的核心業(yè)務邏輯、故事卡&項目進度的信息，而更加細節(jié)類的“kickoff 清單”、工序信息和接口文檔等就維護在Trello板子上。整個流程需要dev同學在卡開前先擬寫case，再在開卡和測試期間，由BA和QA同學一起補充。Trello上的case往往不僅會比Jira上的AC更全，同時還有TL拆的工序，開卡結(jié)卡注意事項等重要信息。所以，對于QA和已經(jīng)開卡的dev小伙伴來說，Trello其實已經(jīng)作為他們工作期間的主要工具，Jira的消失影響不大。
2. 對于BA來說：
首先，關于需求溝通和澄清的工作。慶幸的是，項目已經(jīng)接近尾聲，大部分和客戶需要確認的內(nèi)容已經(jīng)完成。
其次，關于項目迭代規(guī)劃的工作。得益于剛上項目時，受到Senior BA的啟發(fā)，除Jira卡墻外，我自己還維護了一個比較完整的迭代計劃。雖然只有卡號和卡的標題，但上面還記錄了簽卡進度，開發(fā)進度，開發(fā)周期和估點等詳細信息，可以隨時拿出來當臨時的卡墻。
最為感恩的是，測試系統(tǒng)的大部分功能并未受到影響，可以通過系統(tǒng)操作，喚起大部分的記憶。
3. 對于客戶來說：
雖然現(xiàn)在即將到了UAT測試比較密集的階段，但還好我們的項目不是by迭代上線。距離最后真正上線還有一定的時間。即使勤奮的客戶被迫需要“休息”兩天，Jira的臨時罷工，不會嚴重影響到上線前客戶uat測試的進度。
綜合以上幾點，我有些煩躁的心，慢慢放松下來。
到了下午的時候，我發(fā)現(xiàn)，工作群里也少有因為Jira的問題而產(chǎn)生的抱怨，大家的工作都在有條不紊地進行。本以為可能最會受到影響的開卡、Desk Check和測試的工作并沒有太多受到阻礙，反而是其他一些相比較為“邊緣”的工作受到了一些意料之外的影響：
- 歷史需求細節(jié)難以回憶：由于正處于項目尾聲，我還在對負責的模塊進行業(yè)務沉淀的工作。主要的流程已經(jīng)有很多成熟的文檔，但缺乏一些比較細節(jié)和tricky的邏輯的總結(jié)，以便幫助后人避坑。然而，由于我一直拖延，很多在2月/3月聊的需求的細節(jié)場景單憑記憶很難回憶起來......
- 原有系統(tǒng)邏輯細節(jié)模糊：由于項目是屬于遺留系統(tǒng)改造，除了增加新的功能外，保證原有系統(tǒng)邏輯不受影響也是項目成功的重要標準之一。但部分原有功能背后計算邏輯復雜，頁面信息較少，且屬于早期確認的需求;導致記憶比較模糊，有些細節(jié)我不能完全確認。
- 測試工作成本增加：對于QA測試，即使我們有Trello神器，但遇到需要參考流程圖，計算案例，導入文件樣例，跨squad卡的鏈接等需求時，只有干巴巴簡單文字的Trello就顯得有些愛莫能助。增加了QA小伙伴再去重新找這些資料的時間成本。
總結(jié)下來，我發(fā)現(xiàn)，在本項目特殊的背景下，對一個已經(jīng)非常熟悉敏捷開發(fā)流程的團隊來說，Jira 本期望主要承載【可視化流程管理】的作用，仿佛沒有想象中那么重要。而之前并未太關注的【歷史業(yè)務資源庫】的角色，在“板子消失事件”中凸顯出來。
首先，無論借用我們團隊自己維護的Trello，QA同學自己的用例庫，還是我建的野生計劃板，在較短的時間內(nèi)群策群力快速建立一個新卡墻并非難事。其次，憑借著系統(tǒng)操作，會議記錄，流程圖等文檔，卡中大部分的AC也能基本補全，只是時間長短的問題。
然而，對于這個承載了多年積累，近百個項目，多個供應商，上萬張故事卡、無數(shù)業(yè)務文檔和“幾代人”心血的“故事墻”來說，它已經(jīng)不僅僅是一塊簡單的團隊協(xié)作的“板子”，而是快成為了公司的第二大腦，作為每次需求更新，軟件改造重要的知識來源。尤其是在本次遺留系統(tǒng)改造的項目中，該隱藏價值發(fā)揮的淋漓盡致。
當然，如此龐雜，且管理并不太規(guī)范的“資料庫”, 也會存在諸多問題：
- 故事卡管理比較混亂，經(jīng)常會出現(xiàn)一個功能點的故事卡(feature)橫跨多個史詩級別的故事卡(epic)，或者很多錯誤狀態(tài)的故事卡。即使依靠關鍵詞搜索也會占用大量的時間去查找、核對，是不是真實開發(fā)了的功能/是否是最新的邏輯。
- 故事卡分散在各處，沒有比較完整故事線串聯(lián)，且需求更新眾多，可能需要花費大量的時間去翻閱是否還有隱藏/遺漏的場景。
- 缺少業(yè)務背景。故事卡還是更多的關注系統(tǒng)功能的實現(xiàn)，對于”WHY“的問題沒能做更好的闡述。只有憑一句比較模糊的”so that…”的闡述，常常讓后面參考的同學摸不著頭腦。如果之后做需求更新時遇到了新PO，客戶可能也很難揣測當時設計時的想法，從而留下一些隱患……
根據(jù)5個月左右的項目體驗，對于有類似持續(xù)有需求更新，且強依賴于故事墻做業(yè)務沉淀的項目，我總結(jié)可以從以下一些日常小事入手改進：
- 明確故事卡的管理規(guī)則：對于故事卡的名字，狀態(tài)，和不同級別的故事卡之間的關系，盡量做到準確、清晰易讀。如果是針對做需求更新的卡，可以嘗試鏈接之前有很強業(yè)務相關聯(lián)的老卡，方便追蹤。同時，善用comments，增加附件等功能，盡可能讓卡中的信息做到全而不漏。
- 場景化業(yè)務需求：在進行業(yè)務沉淀的時候，在以文檔/Keynote的方式進行文字說明/截圖時，也可以插入 user journey + 對應故事卡鏈接。不僅可以幫助客戶在UAT期間建立更好的場景概念，還可以讓其他有需要的同學在了解high level的流程的基礎上，再看卡了解細節(jié)。建立宏觀和細節(jié)的連接。
- 適當補充必要的需求背景：在寫卡和做業(yè)務沉淀的過程中，如果允許的情況下，可以更多的增加對于業(yè)務場景的分析、實例化需求、用戶使用習慣、和功能設計初衷等描述。因為很可能，你從客戶處了解到的獨家業(yè)務信息會成為之后需求更新方案的關鍵。
- 一定要及時整理業(yè)務知識/ test case：重要的流程圖，會議紀要，場景分析的文檔也要及時在過程中歸類整理，有助于之后迅速定位，也方便后人參考。其實，即使沒有這次的事件，今年1、2月份那些更多涉及到實際業(yè)務場景等偏“WHY”的知識也有些淡忘，如果當時及時總結(jié)，也可以很好地避免我再去和客戶請教時，卻被反問 “你是要準備出書?”的尷尬場面。
當然，冰凍三尺，非一日之寒, 何況是在如此復雜和時間跨度大的背景之下。但從我做起，從小事做起，期望可以將Jira 原本【歷史資料庫】的角色更好的發(fā)揚光大。
第二天早上8:45
那位勤奮的客戶依舊因為測不了UAT在群里的”哀嚎”：
"Early birds have no feed."
如今，時間也早已過去了24小時，心心念念的板子還沒恢復。雖然這只是一次偶發(fā)事件，但通過這次小意外，我想我們都有了一些收獲。
最后，祝福Jira早日康復。
【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】
