需求敏捷化

Kanban及Scrum的敏捷开发方法论无法解决需求敏捷化；但是「用户故事」能很好地解决

用户故事是一种轻量级的敏捷分析方法

• 对用户有价值的功能点进行简单描述
• 用户故事不能使用技术语言来描述，要使用用户可以理解的业务语言来描述

一个好的用户故事包括三个要素：

1. 角色 Who
2. 活动 What
3. 商业价值 Why

用户故事的5C特性

「Card 卡片」用户故事通常写在故事贴/卡片上；可能写上故事的简短描述/工作量估算等

「Conversation 交谈」用户故事的细节来源于与客户或者产品负责人的交流沟通

「Confirmation 确认」通过验收测试用例，验收「用户故事」被确认完成

「Construction构建」团队通过技术手段实现这个用户故事的功能或要求

「Consequence 后果」交付给用户真正使用，获得反馈

用户故事的优点

1. 「用户故事」强调面对面的直接沟通，而不是文档的交流;因为文档很难应对用户需求的频繁变化；导致最后没人去阅读那些文档
2. 「用户故事」易于开发人员与客户/用户的共同理解（没有用技术用语，而是采用用户的语言来简单描述需求）
3. 「用户故事」可以分割成颗粒度比较小的用户故事，非常适合迭代开发
4. 「用户故事」鼓励推迟考虑细节；可以很快地写出独立的用户故事，非常适合时间有限的项目

使用故事点进行工作量评估

Sprint计划会议里，有一个很重要的技术环节「故事点的估计」：对要开发的用户故事进行一个粗量级的估算，对用户故事的复杂度有一个具体的了解

• 传统软件团队通常用工时估算工作量：工时是一种绝对估算的方式；它的估算方法，通常依赖于历史经验信息；对流程较为固定，需求较为稳定的团队来说，工时估算方法是适合，但是工时估算难以应对客户需求的频繁变更，
• 敏捷估算方法是相对估算的概念，没有绝对的估算天数和小时数；故事点是敏捷开发过程中，常用的一种相对估值方式：针对不同需求，可以估算一个需求比另一个需求更大，大多少倍；但是不确定每个需求的准确工作量；一旦对某个故事点的相对规模达成共识，就可以快速分配，而无需太多辩论故事点让团队基于难度而非时间来解决问题，这使得团队成员更关注于创造价值；而不是专注于花了多少时间
• 故事点估算软件规模可以使用近似斐波那契数列: 「0，1?2，2，3，5，8，13」 或 T-恤尺码： 「XS，S，M，L，XKL 」来估算；帮助团队围绕工作规模，做出更好的决策

【Tips：实际工作中，工时或故事点规模估算没有优劣之分；只有适不适合；总而言之，良好的估算实践 1??有助于团队掌握项目的成本和盈利能力 2??还有助于团队对于要交付的需求规模，优先级，价值达成共识；从而更好的做出业务决策」

用户故事分析的典型步骤

• 用户角色：不仅是人的岗位，角色，还包括周边系统
• 业务流程：用户与被实现系统之间的交互流程；但不包括系统内部各部件之间的交互流程（各系统之间的交互还有数据库等，在用户故事里面是感知不了的；在实现用户故事时，如果有涉及到系统之间的交互，也要想好要什么样的旅程「用户故事地图」：点击跳转新的，还是直接打开页面。而且作为产品，有时候有监控数据需求时，还需要明确哪些信息怎么存，或者存不存）
• 提取用户故事：根据用户故事可以感知的层次，从交互步骤中提取出一个个的用户故事
• 整理用户故事：如果用户故事太大，则需要进一步分割；如果用户故事太小，则可以跟其他用户故事合并

优秀用户故事的六个特征（INVEST原则）

• 「Independent 独立性」一个用户故事尽可能独立于另一个用户故事；用户故事之间的依赖性使得确定计划，确定优先级，工作量估算变得很困难；通常会通过组合用户故事或者分解用户故事，减少用户故事得依赖性
• 「Negotiable 可协商」一个用户故事得内容，要是可协商得；用户故事不是合同，只是对需求的一个简短描述；不包括太多细节；具体的细节在沟通阶段产出，如果一个用户故事带有太多的细节；实际上它限制了和用户的沟通
• 「Valuable 有价值的」 每一个用户故事必须对客户有价值；一个让用户故事有价值的好方法是让客户写下它们；让用户意识到这是一个用户故事，而不是一个契约；而且在可以协商的时候，他们是乐于写下用户故事的
• 「Estimable 可估算的」 开发团队需要去估算，以便确定优先级，工作量，和安排计划
• 「Small 短小」 一个好的用户故事，尽量短小，最好不要超过10个人日的工作量；至少要确保能在一个Sprint里完成；因为用户故事越大，安排计划工作量的风险也就越大
• 「Testable 可测试性」一个用户故事要是可测试的，以便于确认是可以被完成的；如果不能被测试，那就无法知道它什么时候可以完成【Tips： 用户故事也是测试/验收驱动开发的实践』