提示：本文共有 3316 个字，阅读大概需要 7 分钟。
5.2 在敏捷用户故事中使用线框图
想象一下，您想出了一个允许用户查看客户人口统计信息列表的设计。像这样：
只是将其放入用户故事并说“构建此”是很诱人的。但是，重要的是不要低估您脑海中关于此相对简单的页面应如何运行的信息。
对于将要构建它的开发人员来说，有一些空白需要填补。 但不要低估或过度思考这些空白。 要找到正确的平衡点，可以利用二八法则。
毫无疑问，开发人员需要用户故事中的详细信息。线框图之所以出色，是因为它可以提供交流所需的80％的信息，只需要花费交互性更强或像素完美的工具20％的精力即可。
因此，不要在最后20％的细节上花费80％的精力，只需在用户故事中使用简单的语言进行描述即可（稍后再介绍）。
我们的目标不是拥有一个庞大的、令人印象深刻的规范或原型，我们的目标是发布一个允许用户实现其目标的产品。
第一步: 分解设计
产品经理经常感到惊讶的是开发用户界面需要多长时间。 这种挫折感很大程度上是由于对用户界面实际上是如何构建的缺乏了解。 设计所需的时间和构建所需的时间之间很少有关联。 这就是为什么把设计分成更小的部分是很有用的。
甚至这个简单的设计也可以分解成几个部分。 需要注意的是，部分可以单独交付(只要遵从顺序)。 你不能交付一个不完整的功能，但是你可以交付一个大功能的一小部分。 这是有区别的。例如， 一个按钮，当你点击它不做任何事情时是不完整的。 例如，一个表格可以查看但不能编辑可以独立存在。
下面是如何将这个功能分解为几个部分:
表格及其内容搜索字段编辑和删除功能导出功能请注意，按此顺序，它们可以分批交付，甚至发布。没有搜索的表可能比不上有搜索的有用，但仍在满足原始功能要求。
每个故事都应为客户增加一些价值，无论价值多少。
注意：分解设计可能会打断你的工作流，但你并非必须在设计阶段这样思考。 线框图的价值在于，它能让你轻松地把脑子里想的东西放到页面上。 而且，大多数情况下，你脑子里的东西都是高水平的。 所以，顺其自然，设计你脑子里的东西。 当你设计的时候，不要担心故事的写作。
第二步: 排序，优先排序，估算
有关故事顺序的注意点。将设计分解为多个部分时，重要的是找到基础，其他部分将基于该基础。在这种情况下，合乎逻辑的选择是表格功能。 你可以说基础也应该是最重要的功能。
表格功能应该是你写的第一个故事。 写最重要的故事有助于确保最重要的功能得以实现。 由于发布日期固定和日程安排不断变化，所以永远不要假设所有的东西都会得到实现。 从重要的事情开始，你至少可以最大限度地利用你的时间。
当你在用户故事插入线框图(作为一个嵌入式图片，附件等) ，你不必删除其他无关部分。 你可以做的一件事就是展示你创建的完整线框图，但是隐藏那些不适用于特定故事的部分。 这样的话，故事的目的就很明确了，但是你也要保持对最终目标的关注。
例如，你可以这样做:
这样分解设计的一个好处是，现在您可以得到每个部分的估计值(仅线框图就足以得到预算) ，这不仅更加准确，还可以在冲刺阶段进行划分。假设在预算会议之后，点值最终如下所示：
客户数据表 - 2 points编辑和删除功能 - 4 points查找 - 1 points导出 - 3 points这将允许产品所有者对整个特性集做出更好的成本效益决策。 也许导出功能是某个吵闹的客户一直要求的，但你知道大多数客户不会使用这个功能。 看到这一部分比其他部分相对更“昂贵” ，可能会促使您推迟到下一个版本。 如果你只是对整个设计只有10个点的预算，这部分将不会一次实现。
我们已经在这一点上取得了长足的进步。 但是不要止步于此，还有一步！
第三步: 写下“食谱”
最后一个阶段是使用线框图，帮助您找出开发人员构建它需要知道的细节。 我学会的一个技巧就是想象自己正在使用它。 在你的头脑中，线框图阐明了你正在构建的东西，并允许你描绘它的用途。 这个过程有助于提供开发人员构建它所需要的细节。
创建线框图有点像烹饪。 想想你做最喜欢的菜。 现在，考虑写一份如何烹饪你做的菜的菜谱。 这是一个完全不同的过程。 它已经从创造转变为沟通。 这完全是站在开发人员的立场上考虑问题，不要对他们的理解能力和知识水平做太多的假设。
这里的教训是，创建线框图的过程实际上更适合UI设计师而不是开发人员。 它可以帮助UI设计师确定想要构建什么，这反过来又可以使UI设计师更容易地交流如何构建它(即使完全是非技术性的)。
用户故事的结构通常如下:
摘要、故事讲述线框图验收准则注意: 我喜欢在“故事叙述”部分包括我们正在构建的内容的“原因” ，并解释这个特性提供了什么价值。 信不信由你，开发者关心这个。 这个解释也应该通过他们的“嗅觉测试”。 如果你不能让他们“买账” ，也许你应该重新考虑一下你为什么这么做。
第三部分是验收标准(也称满意条件、验收测试等)。 这个部分是为开发人员和测试人员准备的。 在这里，我认为可以对传统的格式稍作修改。 我喜欢把这一部分看作是食谱的一部分。 在这里，您可以尽您所能，告诉开发人员如何构建它。 如果您一开始对此有困难，不要担心，此过程的好处之一是，它可以帮助您了解开发人员构建事物所需的信息。它为开发过程打开了一个窗口，使所有人受益。
再说一次，我们从一个基础开始。 不要害怕得到最基本的东西。 例如，您可以从“创建一个具有以下列的表: 姓氏、名字、地址、电话”开始。 小块代码使检查工作变得容易，并且通常实际上对应于开发人员必须编写的代码块。
现在您可以看到这个包含客户信息的表格，请使用它绘制图片。 除了您故意拆分为其他故事的功能之外，作为一个用户，您在这里可能看到和做什么？ 你能对列进行分类吗？ 如果是的话，是所有的列，还是只是其中的一部分？ 您提出的一切都很可能是开发人员需要知道的信息。
另外，如果您在某种程度上精通技术，您可能会想到开发人员可能想知道的其他事情。 您可能知道地址数据存储在单独的数据库字段中(例如，省份、城市、街道)。 如果没有指定，开发人员可能会在数据库表中为每个列创建单独的列属性字段，因为这是他们查看“地址”的方式。 但是，您可能知道用户更喜欢查看这些字段的集合(也许这样他们就可以轻松地同时复制和粘贴这些字段)。 因此，把这个添加到您的食谱，地址字段应该包括街道，城市，国家和邮编等。
但也要意识到，用户可能无法按照城市对表进行排序，例如，“ 城市”不是表中的一个独立列，还有省份、邮编等。 产品经理既想要它能够排序，又能够有多个字段。 强迫写进菜谱是不允许的。 这是一种权衡: 您是想要一个更易于阅读的地址字段，还是希望能够按照地址的每个部分进行排序？ 这取决于你，而不是开发者需要处理的问题。
对于这个特殊的故事，您的验收标准可能如下，这里只是给出一些可能的细节，可以加入你自己的想法。
看看一个简单的4列表可以有多少细节? ！ 这里的要点不是构建这个表有多难(如果已经有了表框架，可能只需要30分钟) ，而是在构建它时需要做出多少决定。 而且，如果您没有指定它们，那么这些决定将由开发人员或您正在使用的框架来做出。 在很多情况下，不做决定就是做决定。
此时，您应该向开发团队展示 Story 以进行实际检查，根据他们的反馈进行必要的修改，并将其放入开发队列中。 就是这样！ 然后，继续下一个故事..。
最后的一些建议
有时候你会想在线框图完成后对 Story 做一些小的调整(标签更改等等)。 即使更新线框图很容易，我经常只是更新故事的文本。 我让它知道，如果有一个文字和线框图之间的差异，始终按照文字进行开发。你的语言要随意。 就像你写信给一个在你不在的时候照看你的狗的人一样。 不要害怕写这样的东西: “样式应该看起来像我们的其他表”或者“与平面设计师一起创建一个导出图标”。 只包含必要的细节。 询问开发人员是否有他们不清楚的地方。每个开发人员都是不同的，所以您可能最终会根据您的团队更改细节级别。 有些人只看线框图，有些人直接接受标准。 一些人在缺少细节时即兴发挥，另一些人在得到澄清之前拒绝继续。 试着了解他们的风格和喜好。 最后，试着承担责任，让你的故事清晰易懂。
看到此处说明本文对你还是有帮助的，关于“5.2 在敏捷用户故事中使用线框图”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！
