用户故事

敏捷过程中，用户故事取代了传统软件需求表述，定义为作为一名<User>可以<dowhat>收到哪些<value>，采用这种形式使用户故事可以综合来自问题域（交付的业务价值）、用户角色和解决方案域（用户通过系统从事的活动）的要素。用户故事是使用索引卡片采集功能的简短语句，详细的系统行为不出现在这种简单语句中，而是通过团队与产品负责人之间对话和验收标准逐渐形成。角色支持对产品功能的细分，而且它经常引出其它角色的需要以及相关活动的环境；活动表述相关角色所需的“系统需求”；价值传达为什么要进行活动，可以为团队提供价值导向引领。

用户故事与需求说明书有着实质的差异：故事不是系统应该完成的事而是需要完成哪类的事；故事简短容易阅读，团队各类人都能理解；代表有价值功能的小型增量，可以在一定周期内开发；故事相对而言更容易估算；对故事很少或没有维护；用户故事以及随后的代码都是增量发展。

什么是好的用户故事？用户故事要具有独立性、可协商性、有价值、可估算、小型和可测试。

关于如何分割用户我会单独用一篇文章进行阐述，也会更透彻分析用户故事。

故事穿刺：用于消除在用户故事或其它项目方面的风险和不确定性，故事穿刺的指导原则是可估算可演示而且可验收，在不同的迭代中分别实现故事穿刺和作为其结果的故事。

干系人、用户表征和用户体验

系统干系人：直接使用系统的人->利用系统使用者成果的人->系统的部署与影响运营影响的人，一般包括用户和操作人员、用户方的经理、采购人员、管理员、技服人员和安装维护人员等，系统干系人将成为系统需求工作的主要驱动力。

项目干系人：受预算和日程直接影响的人；受产品/系统/解决方案的开发方式直接影响的人；将参与系统的推广、销售、安装或维护人员。

理解系统干系人的需求：可以分为一个列表通过干系人的角色，系统特征和系统活动进行描述

用户表征：主要表征代表有特定需求的用户，并且其需求智能通过专门为其设计的用户界面满足；次要表征也是系统用户，它们可以使用针对主要表征设计的界面。开发一组用户故事可以帮助我们识别角色，进而可以帮会组识别用户表征，分析案例研究中用户故事与用户角色的示例将为我们给出关于用户表征的一些线索，用户表征提供了针对用户及其需求的更细粒度鉴别，不需要话费太大的力气试图理解它们，最后在识别了每个用户表征之后，首先尝试理解它们对系统有什么期待以及它们要利用系统做什么，在其之后就已经为接下来编写故事和任何附加的需求发现工作做好准备了。

用户体验：如果把用户体验开发完全分散到各个团队，虽然从敏捷团队的授权与速率角度更有吸引力，但是在实践中可能会有许多问题。UX集中开发有很多相互依赖，但这种集中开发活动可以提升UX领域的核心能力并防止不可避免的设计变更对关对产生重大影响，为了解决更多依赖关系一般会采用分布式、有治理的用户界面开发模型。

敏捷估算与速率

敏捷项目随时知道它的确切位置，因为这是基于可工作代码的主观评估，甚至不用估计；利用有效的敏捷估算，团队就有了对接下来几周工作内容想到那个可靠的预报器。估算可以确定成本、建立优先级排列和安排日程与承诺。

从范围估算到团队速率：根据某团队在给定领域中已知的历史速率，就可以预计她们呢完成任意工作量要用多少时间。这也是一种有价值的校准，可以帮助他们在下一轮故事中更准确地叫牌。

从速率到进度和成本

进度估算：首先团队对将要排程的待变事项故事进行估算；其次，把估值累加；然后，由于迭代市场也是已知的，使用以下简单方程式估算完成任意待变事项将用多少天：完成工作的天数 = 每次迭代的天数 × （待办事项大小的估值/速率）。

成本估算：用团队的平均负担成本除以他们的速率，就是该团队每个故事点的成本。然后，在估算任何待变事项时，只要以该团队每个故事点的成本乘以待变事项的故事点总估值即可。

迭代、代办事项、吞吐量和看板

迭代长度：大多数团队以两周为时间与三点有点，一是这个时间足以创建有意义的增量价值，二是鉴于制定计划的事务成本和其他开销，团队认为这是它们可以承受的最快反馈周期，三是短迭代将故事分为一些小块，使定义/构建/测试必须同时进行，避免使迭代“瀑布化”的倾向。

迭代模式：第一阶段是简短的计划会议，期间评审待变事项并排列优先级进行估算，然后团队承诺在接下来迭代中的一定工作量；第二阶段是执行，期间通过编码和测试，实现迭代的待办事项条目；最后阶段包括对ixnxitong增量的评审与评估，以及接下来对迭代过程和结果的回顾。团队待办事项条目应该聚焦于用户功能性，而更为详尽的需求和验收准则通常在实现相关故事的迭代之前或在这期间才会详细制定。

迭代计划：提炼待变事项中的故事，准备迭代计划会议

迭代承诺：基于速率的承诺、基于目标的承诺、基于任务的承诺用SMART（具体、可度量、可完成、相关的和有时间限制的）描述任务

最后执行迭代，通过周期重复进行直到完成队列中所有的待办事项条目，可以采用燃尽图追踪迭代的整体状态。

追踪与调整：利用看板和敏捷项目管理工具追踪

评审与回顾：分为两个部分产品演示和评审；迭代回顾

待变事项、精益与吞吐量

需求发现工具箱