一、识别干系人
识别干系人并分析和记录他们的相关信息，可以帮助敏捷项目经理建立对各个干系人或者干系人群体的适度关注。在项目或者阶段的早期，识别干系人，并分析他们的利益层次、个人期望、重要性和影响力，对项目成功非常重要。识别干系人的工具，主要包括：任务、线框图和用户故事
二、人物
人物是用细节描述详细阐释用户信息，提供客户的背景；部分人物带有名称、地址、年龄、收入、洗好、厌恶和其他概念性细节。任务是快速识别项目干系人和他们兴趣点的一个工具。软件项目通常创建即将使用这个系统的不同类型的任务。人物可以基于某个真实的人或者多个用户的复合原型。使用时，需要注意：
- 提供一个用户的原型描述
- 立足于现实
- 目标导向的
- 有形的和可操作的
- 聚焦
人物角色并非是对需求的代替，而是为了增加需求。人物帮助团队排序优先级，聚焦于用户，洞察真正的用户，帮助团队站在用户的角度了解产品和方案，聚焦交付一些有价值的功能，有利于项目做决策，缩短项目的讨论，通常，为了防止一些场景的用户故事被遗漏，可以通过设立极端人物方法，去识别可能被遗漏的用户故事。
2、线框图
线框图是创建产品模型的一种常用方法。例如，在软件研发中，线框图可以描述出不同的屏幕以及这些屏幕之间的流动关系。这个图可以确保每个人对这个产品理解一致。如果理解有差异，线框图可以为干系人提供一种视觉话的方式去帮助他们达成一致。如果理解有差异，线框图可以为干系人提供一种视觉化的方式帮助他们达成一致。线框图是"低保真度原型"的一种展示形式，可以很快度并且低成本地区获取反馈。
线框图1.png
线框图2.png
敏捷团队可以用诸如Viso、PPT或者徒手在白板、白纸上画出线框图，去定义或者改变工作流，目的就是帮助弄清什么是"完成"，去验证团队正在构建的产品增量的方法是否正确。
三、用户故事
用户故事是大小适中的，是可以被理解的商业功能模块。敏捷团队通常依赖用户故事和用户故事待办事项(通常可以等价为产品待办事项)进行商业需求优先级的排序。敏捷中的(theme)是指一组有关的用户故事。用户故事示例如下：
用户故事1.png
用户故事2.png
用户故事3.png
1 用户故事三要素
一个用户故事包含三个基本要素：角色、目标及可以达到的商业价值，通常形式是：
作为一名<角色>，我想要<功能>，这样就可以实现<商业价值/益处>。
例如：作为<旅客>，我想<注册成为XXX旅店会员>，是为了<使用网上预订房间的服务>。
2 用户故事的3C
- Card：
故事写在物理卡片上，起到交流提示的作用。卡片是载体，非需求本身，只充当需求的"占位符"。物理卡片不建议用电子卡片等替代，目的是为了保证面对面的沟通和交流。- Conversation：
故事包含的诸多细节需要和用户协商确定，可以一方写，一方看，双方交互，延迟决策，后续确定细节相关事宜，这样可以减少浪费。这一点提现了敏捷宣言的第一条：“个体和交互胜过流程和工具”，同时也是INVEST属性中的"可协商"属性相匹配。- Confirmation：
故事包含验收标准和环节，以确保被正确实现。故事范围体现在验收条件中，用户的期望被验收测试的方式记录、传递和呈现。验收标准通常在发布计划和用户故事定义中被确定，但是验收标准也可以在故事被选入迭代后在迭代计划中确定。一个不变的准则就是，验收标准必须在开发前确定。验收标准的确定是不断改变的，所以要经常与产品负责人交流。
3 用户故事的INVEST属性
INVEST分别是以下几个单词的首字母组合：I——independent(独立的)、N——negoitable(可协商的)、Valuable(有价值的)、E——estimable(可估算的)、S——small(小的)、T——testable(可测试的)。INVEST属性。如下图
image.png
下面我们就依次来看下：
- 独立的(independent)：
每个故事都是独立的，可以用任何一种方法进行用户故事排序和使其实现。独立的用户故事便于开发团队根据个人能力进行选择，依赖会影响客户对优先级的区分；确保每个用户故事都是独立的，可以避免让一个故事的实现以另一个为基础，避免让故事的工作量和难度与实现的次序相关。- 可协商的(negotiable)：
团队可以和商业代表一起讨论用户故事并且基于某些属性做一些权衡。用户故事的可协商性可以挖局客户的真实需求。3C原则的中的"conversation"也体现了这一点。故事不是合同、方案、需求规则说明书，而是可以协商的。- 有价值的(valuable)：
价值是故事的生命，如果不能定义一个需求的价值，那么久可以不需要实现，用户故事要包括这个需求的价值或者益处。鉴于待办事项是根据价值排序的，所以缺乏清晰定义商业价值的用户故事将很难对它进行排序。不同的用户和客户，价值关注点也不同，必须挖局并凸显其核心价值。- 可估算的(estimable)：
尽管"可估算"不是一个准确的词语，在敏捷中也不提倡准确的估算，但是估算可以显示需要在这个用户故事上付出的努力。如果很难估算着用户故事，那么我们就不能依据成本效益分析进行排序，估算是为了更好的计划。通常，故事难以估算的原因及处理方法如下：
- 颗度太大，史诗故事——这样的故事需要拆分
- 缺乏领域知识——需要与客户讨论
- 缺乏技术能力——进行穿刺
- 缺乏封闭性——拆分故事
- 小的(small)：
相对于大的用户故事来说，小的故事更容易被估算。因为工作单元越大，估算这些工作的可靠性就降低。每个用户故事要小到可以在一个迭代中完成，工作量在2~5天。但是，并非"故事越小越好"，一个非常小的用户故事，比如花费1个小时或者更少的时间，这些故事应该被禁止，因为将会在创建故事、跟踪这些故事中花费很多的简介成本，这也是一种浪费。可以通过把大的用户故事分解为小的更易于处理的故事。故当开发者注意到用户故事或任务用时比时间框显示的长时，应该提醒团队并采取措施，包括把任务分解为更小的用户故事。- 可测试的(testable)：
对于过程监控来说，用户故事的可测试性很重要，我们需要根据被验收的用户故事数量来度量过程。3C原则中的“confirmation”体现了故事的可测试性属性。验收条件体现故事范围，需要在故事编译的时候就识别验收标准。同时，对于这些测试要能够从界面或者接口进行，能够被自动化测试。
4 用户故事待办事项
一旦用户故事被写好，他们就应该放在一个待办事项中。这个用户故事的待办事项是一个可视化的待完成的工作列表。用户故事待办事项可以知道我们在团队内部进行优先级排序，也可以作为版本管理和迭代管理的一个计划工具，知道团队在范围讨论时可以聚焦于管理变更。此外，还可以帮助协调项目并让团队成员对任务达成共识。随着信息的不断涌现，还可以对故事待办事项进行更新。
5 用户故事的粒度
一个大的项目从整体上来说是一个复杂的系统，有大量的工作，并且不能进行整体的规划估算。所以，我们需要把项目分解为更小的单元，直到我们可以进行实际的估算。这一点也体现了敏捷计划的适应性。尽管用户故事是用的最多的一种计划工具，但是并不是敏捷项目中用的唯一的工具。在一个项目的需求结构中，用户故事一般处在中间级别。
故事是可以分层次的，就像计划可以分层次一样，Epic、Feature、User Story是用于区分需求颗粒度的标签。一些项目团队把史诗放在了用户故事的上一层级。一个史诗也可以在上面或者下方替换一个功能节点。这说明在需求结构中，史诗位置被定义的不同方式。
用户故事层次.png
网友评论