用户故事与敏捷方法

用户故事与敏捷方法.png

第1部分 起步
识别、编写、测试用户故事

第1章 概览
帮助开发人员和客户团队双方协作，任何一方都不能占绝对主导地位，保证资源的合理分配。
不要妄想在项目一开始就做出包罗万象的决策，注重反馈，将各个决策分散到项目过程中。
客户团队活跃于软件开发的全过程，编写用户故事、确定优先级，客户团队包括确保软件符合潜在用户需求的人，可以包括测试人员、产品经理、实际用户和交互设计师
用户故事_{工作量大小，迭代长度}每个版本的计划工作时间，迭代速率~用户故事/迭代长度
一个发布由一个或多轮迭代组成，发布的要求是项目时间表和预期功能集合之间达到平衡
每个故事用故事点来估计，故事点表明一个故事相对于其他故事的大小和复杂度
验收测试用来验证实现的用户故事是否符合客户团队的期望，测试应尽早在迭代中编写，将假设和预期更早的与开发人员沟通
用户故事强调对话交流而非书面沟通，代表用户在单一环境中可能做的事情；用户故事需要避免使用技术术语，保证客户团队和开发团队都能理解；用户故事可以促进考虑细节，且能更新；客户团队进行故事的优先级排列， 同时也要考虑开发团队的意见和成本

第2章 编写故事
独立的：故事之间相互依赖
将相互依赖的故事合并成一个大的、独立的故事；用一个不同的方式去分割故事
可讨论的：关于细节的处理
故事卡包含一两句短语，提醒开发人员和客户进行对话；故事卡包含一些注释，表明在对话中亟待解决的问题；将细节变成测试
对purchasers或users有价值的：避免过度关注技术和实现细节
让客户编写用户故事
可估计的：估算工作量
开发人员缺少领域知识；开发人员缺少技术知识；故事太大
小的：有助于制定计划
合适的故事大小取决于团队、容量以及使用的技术
按照创建、编辑、删除这些动作来分解故事，或者根据数据边界来分解故事
可测试的：量化的测试效果

第3章 用户角色建模
用户角色user role：一组属性的集合，刻画了一群人的特征以及这群人与系统可能的交互
角色建模的步骤：头脑风暴，列出能想到的用户角色——整理用户集合——整合角色——提炼角色
两个额外的技术：虚拟人物（假想的用户角色代表，用户强化用户角色在团队成员心中的印象）+极端人物（帮助考虑原本遗漏的故事，也可能产生新的用户故事）

第4章 搜集故事
拖网 trawling 将收集需求比作捕鱼
用户访谈：通过提出开放式的/与背景无关的问题获取用户的本质需求
问卷调查：可以用于确定故事优先级，但不适合捕获新的用户故事
观察：明确需求
故事编写工作坊：编写大量用户故事，确定工作流

第5章 与用户代理合作
用户代理user proxy，在项目中代表用户
谁适合做用户代理？
用户经理：并非软件使用者，尽可能接触终端用户，不能得罪
开发经理：避免让开发经理担任用户代理
销售人员：通过销售人员认识客户
领域专家：水平较高，围绕他们开发出来的产品可能对其他人不友好
市场营销团队：更关注产品特性的数量而非质量
以前的客户：考虑其动机和目标是否与实际用户一致
客户purchaser：考虑用户与客户在需求上的差异
培训师和技术支持：与实际用户的差异
业务分析师或系统分析师：适合作为用户代理，既懂技术，又熟悉软件相关的领域知识
与用户代理合作时，做些什么？
能接触到用户但访问受限时，启动用户顾问团队user task force提出意见和建议，用户代理做决策
实在不能接触到用户时，可以使用多个用户代理模拟用户，避免开发出的系统仅仅满足一个人的需求，并且确保多个代理来自不同的类型
设立客户团队的步骤：邀请真实用户加入——确定项目负责人——确定项目成功必须的关键因素

第6章 用户故事验收测试
记录客户和开发团队所讨论过的细节，在写代码之前写测试可以为开发人员提供有价值的信息，测试应当是软件开发过程中的一部分
集成验收测试工具FIT：每次迭代都会破坏一些已完成验收测试的代码，所以迭代后的测试应包含以往所有的测试，FIT通过明确输入输出，验证程序得到输入后是否能正确输出
测试类型：功能测试/用户交互测试/可用性测试/性能测试/压力测试，测试的是缺陷，而非覆盖率

第7章 优秀用户故事准则
考虑从每个用户角色使用目的
每个故事提供一个完整的端到端end to end的功能（每个功能有输入有输出）
权衡相互冲突的需求，编写封闭故事
基于大故事实现的时间跨度，编写小故事
在故事中包括用户角色
故事的可读性在只为一个用户编写时，是最强的
以主动语态编写
由客户编写
不要过早涉及用户页面

第2部分 估算和计划
项目计划，为最高优先级的故事创建高层次的发布计划

第8章 估算用户故事
故事点：一个故事点的工作量可以看作一个理想日的工作
以团队估算：估算故事由整个团队进行
估算：将客户和开发团队集合；第一轮各写各的，而后表达观点；第二轮根据观点重新估算；随着轮数的增加，估算值会越来越统一
三角测量：帮助团队验证他们是否认同各个故事的工作量
使用故事点：每轮迭代能够完成的故事点数要考虑 1、这轮迭代中是否有异常时间，2、估算方法保持不变，3、第一轮迭代的故事必须独立
如果用结对编程呢？：工作量相同，速率值不一样
开发人员给出工作量估算，客户负责回答问题并澄清故事细节

第9章 发布计划
已知每轮迭代的工作量估算，合理预测完成符合用户期望的发布需要多少轮迭代
开发人员和客户商定一个日期范围，而非具体日期
决定在发布中包含哪些功能：DSDM优先级排列方法（must have,should have,could have,won't have this time）
排列故事优先级：考虑风险和相互影响；客户和用户也有自己的考虑，当客户与开发相左时，交由客户决定；估算故事点，成本也会影响客户的优先级排序
混合优先级：客户在确定优先级时，可能会分割故事
高风险故事：以价值优先为导向，开发人员会倾向于先做风险最高的故事，但最终必须由客户决定
选择迭代长度：开发人员和客户共同选择，长度越短进度越透明
初始速率：参考历史值/执行一轮初始迭代获取速率/猜测
创建发布计划：设立初始期望，不断调整期望和监控每轮迭代大的速率
开发人员提供信息辅助客户准确排列优先级

第10章 迭代计划
讨论故事：调整故事优先级
分解任务：分割出某个特别困难的任务/展示给客户帮助客户了解的部分任务/分割能提高效率的任务
承担职责：任务关联团队成员
估算并确认：评估是否承担过度的职责
开发人员认领任务，客户优化故事优先级顺序

第11章 测量并监控速率
测量速率：两三次迭代后才能获得一个长期的、稳定的速率，只考虑通过验收测试的故事，不能将部分完成的故事计算在速率内
计划速率和实际速率：故事点图和累计故事点图
迭代燃尽图（剩余故事点-迭代次数）：以故事点表示的在每轮迭代末剩余的工作量，虽然不能表示团队的开发速度，但能更好的展示项目的整体进展
每日燃尽图（剩余小时数-天）：展示团队在某轮迭代中的进展
公开剩余工作量信息

第3部分 经常讨论的话题
用户故事与其他需求方法的区别

第12章 故事不是什么
常见的需求方法：1.用例use case 2.软件需求指南software requirements specifications IEEE830 3.场景interaction design scenario
故事小于用例
IEEE 830关注解决方案的特征，用户故事关心用户目标
场景大于故事，场景较为具体
预想再全面，也无法得到一个完整的系统，原因是忽略的反馈系统

第13章 用户故事的优势
突出交流，保证沟通顺畅
提供迅速的反馈周期，促成对需求的充分理解
便于迭代开发和制定计划
鼓励细节、随机应变式开发、参与性涉及
缺点：不太适用大型项目（故事多、文档的可回溯性）

第14章 用户故事不良征兆一览
故事太小
故事相互依赖
镀金（开发人员实现了不需要的功能）
细节太多
过度考虑用户界面细节
想得太远
故事划分太过频繁
客户难以为故事安排优先级
客户不愿意写用户故事，不愿意排列优先级
了解不良征兆，找出解决方案

第15章 scrum与用户故事
scrum：一种迭代递增的软件过程（递增过程：团队按功能点开发和发布软件，每个迭代的工作往往不需要返工；迭代过程：通过持续改进来取得进展）
scrum基础：30天1周期的print；4~7人的自组织开发团队；待开发产品功能的backlog列表；计划会议；评审会议；每日简会
在sprint中使用用户故事

第16章 其他话题
非功能性需求（性能、准确性、可维护性等）可以通过创建约束的方式来处理
纸质还是软件？适合项目团队就好
迭代过程中尽量避免用户界面的反复变化
故事完成后，保留故事卡card
记录缺陷报告形成封面故事卡

第4部分 一个完整的实例
编写用户故事-估算故事-做发布计划-为故事编写验收测试

第17章 用户角色
项目：了解项目详情
定义客户：帮助编写用户故事
定义一些角色雏形
整合与提炼
角色建模（使用频率/用户专业程度/用户对电脑的数量程度/用户对团队正在开发的软件的熟练程度/目的/用户体验）
添加虚拟人物
了解项目背景以及目标用户，确定用户画像

第18章 一些用户故事
不按照角色或者虚拟人物的顺序写出故事
先从一个特定的用户角色或者虚拟人物开始写出团队能够想到的所有故事，然后考虑下一个角色或虚拟人物

第19章 估算故事
用故事点代表理想日、复杂度或对团队有意义的其他一些度量值
客户与开发团队通过多次讨论，最终确定每个故事的故事点

第20章 发布计划
确定迭代长度（考虑交付时间）
估算速率
给故事安排优先级
最终的发布计划

第21章 验收测试
在用户故事的基本上，充分考虑细节输出尽可能详细的测试内容