被写在了前面的故事墙上，作为交付项目的常用工具。突然的“消失”让我们意识到它承载了我们工作中的很多东西。没有想象中的匆忙，但团队的工作也没有想象中的停滞。但是一些意想不到的障碍让我对故事墙的价值有了一些思考。以下为正文：早上8点34分，我睡眼惺忪地打开手机，看到群里已经很热闹了，“又出现在线问题”，“无法连接服务器”……虽然心里有些动荡，但是却不是很担心。8点45分，客户在微信群反映，“我无法登录故事墙，无法测试UAT”。我想，“客户太辛苦了，还得争分夺秒在9点开会前测试”。“jira之前也出现过这种暂时无法登录的情况，别着急，稍等片刻。”安慰完群里的客户后，我打开电脑，连上虚拟专用网，输入验证码，经过一系列熟练的操作，刷新了之前打开的Jira看板。果然，我也遇到了和客户一样的404报错。为了多试几次，我仔细（shou）仔细（can）刷新了我之前缓存的所有页面，结果当然是报错了。这时候我天真地以为这次和之前类似的系统不稳定一样只是暂时的现象，没想到Jira板子消失和早上上线的问题是同源的。图片来自：https://www.atlassian.com/blog/jira-software/the-new-jira-begins-now9:30同组的机智小伙伴，没有像我这样的刷新板。立会仍能有条不紊地进行。直到站会结束，Jira还是打不开。这时，我意识到这可能不是暂时的系统问题。从群里了解到，至少今天，在没有预期效果的情况下恢复后，我突然不知所措。“没有了板子，我们还能正常开卡和桌检吗？会不会影响QA同学的考试？我的业务沉淀还能顺利进行吗？”备忘单突然被没收了。就连本该熟记于心的“知识点”，都有些摸不着头脑。9:45刷新了几次都没有结果，静下心来，想到几件幸运的事情：1.Dev&QA同学：项目开始的时候，团队除了Jira，还建立了一个Trello看板来内部共同维护测试用例。这样做，Jira只保留面向客户的核心业务逻辑、故事卡和项目进度信息，而更详细的“启动列表”、流程信息和接口文档则保留在Trello看板中。整个过程需要dev同学在开卡前写case，然后BA和QA同学在开卡测试期间补充。Trello上的案例往往不仅比Jira上的AC更完整，还包含了TL的拆解过程、开卡和关卡注意事项等重要信息。因此，对于已经报名的QA和dev小伙伴来说,Trello实际上已经成为他们工作期间的主要工具，Jira的消失影响不大。2.对于BA：首先是沟通，明确需求。幸运的是，项目已接近尾声，需要客户确认的大部分内容已经完成。其次，做好项目迭代规划。得益于刚开始项目时SeniorBA的启发，除了Jira墙外，我还维护了一个比较完整的迭代计划。虽然只有卡号和卡名，但也记录了签卡进度、开发进度、开发周期、评价分等详细信息，可以随时作为临时卡牌墙使用。最值得庆幸的是，测试系统的大部分功能都没有受到影响，大部分记忆都可以通过系统操作恢复。3、对于客户：虽然我们即将进入密集的UAT测试阶段，但幸运的是我们的项目并不是迭代上线的。距离实际发布还有一定的时间。即使勤奋的客户被迫“休息”两天，Jira的临时罢工也不会严重影响客户上线前uat测试的进度。基于以上几点，我有些烦躁了，慢慢的放松了下来。下午发现工作组里关于Jira问题的投诉很少，大家的工作都在有条不紊的进行着。本以为受影响最大的开卡、台检、测试工作并没有受到太大阻碍，但其他相对“边缘化”的工作却受到了一些意想不到的影响：很难回忆起历史需求的细节：因为它处于项目尾声，我还在做自己负责的模块的业务沉淀。主流程已经有很多成熟的文档，但是缺少一些详细的、刁钻的逻辑总结来帮助后人避坑。但是因为一直拖拖拉拉，很难回忆起2/3月份讲的很多需求的详细场景……原系统的逻辑细节比较模糊：由于项目属于legacy除了新的功能，保证原有的系统逻辑不受影响也是项目成功的重要标准之一。但部分原函数背后的计算逻辑复杂，页面信息较少，属于提前确认的需求；导致记忆模糊，有些细节我无法完全确认。测试工作成本增加：对于QA测试，即使我们有Trello神器，当我们需要参考流程图、计算案例、导入文件样本、跨小队卡片链接等时，Trello，它只有枯燥和简单的文本，似乎有点无能为力。这就增加了QA小伙伴重新找这些资料的时间成本。综上所述，我发现在这个项目的特殊背景下，对于一个已经非常熟悉敏捷开发流程的团队来说，Jira原本期望主要承担【可视化流程管理】的作用，似乎并没有想象中那么重要.之前不受重视的【历史业务资源库】的作用，在“董事会失踪事件”中凸显出来。首先，无论是借用我们团队维护的Trello，QA同学的用例库，还是我搭建的野企划板，短时间内快速搭建一个新的卡片墙都不难。其次，在系统操作、会议记录、流程图等文件的帮助下，卡片中的大部分AC都可以基本完成，只是时间问题。然而，对于这堵多年积累的“故事墙”，近百个项目、多个供应商、数万张故事卡、无数的商业文件和“几代人”的心血，并不是简单的，而是，它已经成为公司的第二大脑，作为每次需求更新和软件改造的重要知识来源。尤其是在这个遗留系统改造项目中，这种隐藏的价值被发挥得淋漓尽致。当然，如此庞大且不受监管的“数据库”也会存在很多问题：故事卡的管理比较混乱，经常会出现一张功能点跨越多个史诗级故事卡（epic）的故事卡，或者很多故事卡处于错误的状态。即使是靠关键词搜索，查找和检查是否是真正开发的功能/是否是最新的逻辑，也会花费大量时间。故事卡到处散落，系列中没有比较完整的故事线，需要更新的地方很多，翻看是否有隐藏/遗漏的场景可能会花很多时间。缺少业务上下文。故事卡还是更注重系统功能的实现，未能对“WHY”问题做出更好的阐述。只有一个比较含糊的“所以……”的解释，后面的同学经常会一头雾水。如果后面更新需求的时候遇到新的PO，客户可能很难揣测当时的设计思路，留下一些隐患……根据5个月左右的项目经验，有类似的连续需求更新，依赖性强对于故事墙的业务沉淀项目，我总结可以从以下日常小事入手进行改进：明确故事卡的管理规则：关于故事卡的名称、状态，以及不同关卡的故事卡之间的关系，尽量做到准确，清晰，易读。如果是需要更新的卡片，可以尝试链接到之前业务关系很强的旧卡片，这样便于追踪。同时，利用好评论，增加附件等功能，尽量使名片中的信息尽可能完整。场景化业务需求：沉淀业务时，也可以在文档/Keynote形式的文字描述/截图时插入用户旅程+对应的故事卡片链接。不仅可以帮助客户在UAT时建立更好的场景概念，也可以让其他有需要的同学在了解highlevel流程的基础上读卡了解细节。建立宏观和细节的联系。适当补充必要的需求背景：在写卡片和做业务沉淀的过程中，如果允许，可以增加更多的业务场景分析、实例化需求、用户使用习惯、功能设计初衷等描述。因为很有可能，你从客户那里了解到的独家业务信息，将成为后续需求更新计划的关键。一定要及时整理业务知识/测试用例：过程中重要的流程图、会议纪要、场景分析文档也要及时整理，有利于后期快速定位，也方便后人参考。事实上，即使没有这件事，今年1、2月与实际业务场景相关的“why”知识也已经有些遗忘。如果我及时总结，也可以避免我向客户征求意见。当时有人问他“你打算出书吗？”尴尬的一幕。当然，冰冻三尺不是一蹴而就的，更何况是在如此复杂、时间跨度大的背景下。但从我做起，从小事做起，希望Jira原有的【历史数据库】的作用能够更好的发扬光大。第二天早上8点45分，辛辛苦苦的客户还在群里“哀号”，因为测不出来UAT：“早起的鸟儿没有饭吃”。现在，24小时过去了，他心心念念的板子还没有恢复。虽然这只是一个意外，但是通过这个小小的意外，我想我们大家都有所收获。最后祝吉拉早日康复。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
