写在前面
故事墙作为交付项目中习以为常的工具，突然的“消失”，才让我们意识到承载了工作中的很多东西。
没有预想中的手忙脚乱，团队的工作却也没有想象中的停滞不前。但一些意料之外的阻碍，带给了我一些对于故事墙价值的思考。
以下是正文：
早上 8:34
睡眼惺忪的我打开手机，便看到群里已经热闹起来
“又有线上问题了”
“服务器连不上去了”
......
我心里虽然有些波澜，但却并没有很担心。
8:45
客户在微信群里反映，“登不上故事卡墙了 , 没法测uat了”。
我想，“客户太勤奋了吧，还要在9点会议前争分夺秒测试。”
“Jira之前也有这种暂时登录不了的情况，您别着急，稍等一会儿。”
在群里安抚完客户之后，我打开电脑，连虚拟专用网，输入验证码，一系列熟练的操作后，刷新之前打开的Jira板子，果然也遇到了和客户一样的404报错的现象。为了多试几次，我还细(shou) 心(can)的把之前我所有已经缓存的页面都刷新试试，结果当然是一片报错。
此时的我，还天真的以为，这次只是像之前多次类似系统不稳定一样的暂时现象，也从没想过Jira板子的消失和早晨的线上问题是同源。
图源自：https://www.atlassian.com/blog/jira-software/the-new-jira-begins-now
9:30
机智的同组小伙伴，没有像我一样手残的刷新板子。站会依旧可以有条不紊的进行。
直到站会结束，Jira依旧打不开，此时的我才意识到，可能不是暂时的系统问题。从群里得知，起码今天前恢复没有期望的结果之后，我突然有些手足无措。
| “没有了板子，我们还能正常开卡和Desk Check吗?QA同学的测试会不会受到影响啊?我在进行的业务沉淀还能顺利继续吗?” |
仿佛是本来信心满满的开卷考试，突然被没收了小抄。连本身早应烂熟于心的“知识点”，都有些不确定。
9:45
在又抱着侥幸刷新了几次无果之后，我定了定神，想到了几条不幸中的万幸：
1. 对于Dev & QA同学来说：
团队在项目开始之初，除了Jira 外，还建立了内部共同维护test case的Trello板子。这样做可以使得Jira只保留面向客户的核心业务逻辑、故事卡&项目进度的信息，而更加细节类的“kickoff 清单”、工序信息和接口文档等就维护在Trello板子上。整个流程需要dev同学在卡开前先拟写case，再在开卡和测试期间，由BA和QA同学一起补充。Trello上的case往往不仅会比Jira上的AC更全，同时还有TL拆的工序，开卡结卡注意事项等重要信息。所以，对于QA和已经开卡的dev小伙伴来说，Trello其实已经作为他们工作期间的主要工具，Jira的消失影响不大。
2. 对于BA来说：
首先，关于需求沟通和澄清的工作。庆幸的是，项目已经接近尾声，大部分和客户需要确认的内容已经完成。
其次，关于项目迭代规划的工作。得益于刚上项目时，受到Senior BA的启发，除Jira卡墙外，我自己还维护了一个比较完整的迭代计划。虽然只有卡号和卡的标题，但上面还记录了签卡进度，开发进度，开发周期和估点等详细信息，可以随时拿出来当临时的卡墙。
最为感恩的是，测试系统的大部分功能并未受到影响，可以通过系统操作，唤起大部分的记忆。
3. 对于客户来说：
虽然现在即将到了UAT测试比较密集的阶段，但还好我们的项目不是by迭代上线。距离最后真正上线还有一定的时间。即使勤奋的客户被迫需要“休息”两天，Jira的临时罢工，不会严重影响到上线前客户uat测试的进度。
综合以上几点，我有些烦躁的心，慢慢放松下来。
到了下午的时候，我发现，工作群里也少有因为Jira的问题而产生的抱怨，大家的工作都在有条不紊地进行。本以为可能最会受到影响的开卡、Desk Check和测试的工作并没有太多受到阻碍，反而是其他一些相比较为“边缘”的工作受到了一些意料之外的影响：
- 历史需求细节难以回忆：由于正处于项目尾声，我还在对负责的模块进行业务沉淀的工作。主要的流程已经有很多成熟的文档，但缺乏一些比较细节和tricky的逻辑的总结，以便帮助后人避坑。然而，由于我一直拖延，很多在2月/3月聊的需求的细节场景单凭记忆很难回忆起来......
- 原有系统逻辑细节模糊：由于项目是属于遗留系统改造，除了增加新的功能外，保证原有系统逻辑不受影响也是项目成功的重要标准之一。但部分原有功能背后计算逻辑复杂，页面信息较少，且属于早期确认的需求;导致记忆比较模糊，有些细节我不能完全确认。
- 测试工作成本增加：对于QA测试，即使我们有Trello神器，但遇到需要参考流程图，计算案例，导入文件样例，跨squad卡的链接等需求时，只有干巴巴简单文字的Trello就显得有些爱莫能助。增加了QA小伙伴再去重新找这些资料的时间成本。
总结下来，我发现，在本项目特殊的背景下，对一个已经非常熟悉敏捷开发流程的团队来说，Jira 本期望主要承载【可视化流程管理】的作用，仿佛没有想象中那么重要。而之前并未太关注的【历史业务资源库】的角色，在“板子消失事件”中凸显出来。
首先，无论借用我们团队自己维护的Trello，QA同学自己的用例库，还是我建的野生计划板，在较短的时间内群策群力快速建立一个新卡墙并非难事。其次，凭借着系统操作，会议记录，流程图等文档，卡中大部分的AC也能基本补全，只是时间长短的问题。
然而，对于这个承载了多年积累，近百个项目，多个供应商，上万张故事卡、无数业务文档和“几代人”心血的“故事墙”来说，它已经不仅仅是一块简单的团队协作的“板子”，而是快成为了公司的第二大脑，作为每次需求更新，软件改造重要的知识来源。尤其是在本次遗留系统改造的项目中，该隐藏价值发挥的淋漓尽致。
当然，如此庞杂，且管理并不太规范的“资料库”, 也会存在诸多问题：
- 故事卡管理比较混乱，经常会出现一个功能点的故事卡(feature)横跨多个史诗级别的故事卡(epic)，或者很多错误状态的故事卡。即使依靠关键词搜索也会占用大量的时间去查找、核对，是不是真实开发了的功能/是否是最新的逻辑。
- 故事卡分散在各处，没有比较完整故事线串联，且需求更新众多，可能需要花费大量的时间去翻阅是否还有隐藏/遗漏的场景。
- 缺少业务背景。故事卡还是更多的关注系统功能的实现，对于”WHY“的问题没能做更好的阐述。只有凭一句比较模糊的”so that…”的阐述，常常让后面参考的同学摸不着头脑。如果之后做需求更新时遇到了新PO，客户可能也很难揣测当时设计时的想法，从而留下一些隐患……
根据5个月左右的项目体验，对于有类似持续有需求更新，且强依赖于故事墙做业务沉淀的项目，我总结可以从以下一些日常小事入手改进：
- 明确故事卡的管理规则：对于故事卡的名字，状态，和不同级别的故事卡之间的关系，尽量做到准确、清晰易读。如果是针对做需求更新的卡，可以尝试链接之前有很强业务相关联的老卡，方便追踪。同时，善用comments，增加附件等功能，尽可能让卡中的信息做到全而不漏。
- 场景化业务需求：在进行业务沉淀的时候，在以文档/Keynote的方式进行文字说明/截图时，也可以插入 user journey + 对应故事卡链接。不仅可以帮助客户在UAT期间建立更好的场景概念，还可以让其他有需要的同学在了解high level的流程的基础上，再看卡了解细节。建立宏观和细节的连接。
- 适当补充必要的需求背景：在写卡和做业务沉淀的过程中，如果允许的情况下，可以更多的增加对于业务场景的分析、实例化需求、用户使用习惯、和功能设计初衷等描述。因为很可能，你从客户处了解到的独家业务信息会成为之后需求更新方案的关键。
- 一定要及时整理业务知识/ test case：重要的流程图，会议纪要，场景分析的文档也要及时在过程中归类整理，有助于之后迅速定位，也方便后人参考。其实，即使没有这次的事件，今年1、2月份那些更多涉及到实际业务场景等偏“WHY”的知识也有些淡忘，如果当时及时总结，也可以很好地避免我再去和客户请教时，却被反问 “你是要准备出书?”的尴尬场面。
当然，冰冻三尺，非一日之寒, 何况是在如此复杂和时间跨度大的背景之下。但从我做起，从小事做起，期望可以将Jira 原本【历史资料库】的角色更好的发扬光大。
第二天早上8:45
那位勤奋的客户依旧因为测不了UAT在群里的”哀嚎”：
"Early birds have no feed."
如今，时间也早已过去了24小时，心心念念的板子还没恢复。虽然这只是一次偶发事件，但通过这次小意外，我想我们都有了一些收获。
最后，祝福Jira早日康复。
【本文是51CTO专栏作者“ThoughtWorks”的原创稿件，微信公众号：思特沃克，转载请联系原作者】
