用户故事与敏捷方法

接触了解用户故事到现在,近十个月了,一直没用这种方法进行完整的实践,趁着这两天休假,将前期了解的知识整理一下。

敏捷与极限编程

对于敏捷的粗浅了解仅有一些概念性的东西和最近一段时间的实践。敏捷强调递增与迭代,在迭代中完善细节。

敏捷宣言

个人和交流重于过程和工具

正在运行的软件本身重于复杂的文档

与客户的沟通和交流重于使用合同约束客户

对变化的快速响应重于跟随计划

极限编程

12个实践

短交付周期:2周左右,通常1-3周,不超过4周

计划游戏:发布计划和迭代计划。

重构:不断关注重构。

测试:测试驱动开发,测试-编码-测试-编码。

结对编程

持续一致的速度

团队代码所有权

编码标准

简单设计

隐喻

持续集成

现场客户:产品、测试、开发团队及时沟通。

极限编程价值

沟通:面对面沟通

简单:最简单可行的方式

反馈:重视反馈,越快越好

勇气:重视勇气

关键原则

快速反馈

假设简单

增量变化

拥抱变化

高品质质量

用户故事

概览

用户故事包括:描述、对话和注释。必须是:独立的、有价值的、可讨论的、可估计的、可测试的、规模合理的(小的)。史诗故事包括复合故事和复杂故事,根据具体情况对用户故事进行分割和合并。

描述是对用户故事的简单书面描述,它是主动的。

对话用来提醒客户团队和开发亟待讨论的问题,不需要记录太多细节。

注释主要包括验收测试用例。测试用例在开发前已经由产品和测试完成。

故事需要所有团队成员经过多轮的讨论,才不断完善。

优秀用户故事准则

考虑每一个用户角色,从目标故事(高层次故事)开始衍生

切蛋糕原则:每个故事具有某种程度的完整性

编写封闭的故事,有明确的范围边界

卡片约束

根据时间来确定故事规模和精确度

不要过早涉及用户界面

有些需求并不是故事,可以使用其他的形式表达某些需求

故事里包括用户角色

一个用户故事只为一个角色编写

以主动语态编写

由客户编写

不需要编号,增加无谓的流程

有序号,表示优先顺序

故事卡用来提醒客户和开发的对话讨论,要简洁,尽量只有切人点提醒,不加入太多的细节

角色建模

列出角色(角色卡)

整理角色

提炼角色

角色特征(角色卡)

构造虚拟人物

简单分析极端人物

搜集故事

故事作坊:头脑风暴(记录而不评价故事,重在数量而非质量);简单原型(类似简单页面结构和功能的结合体),及时抛弃简单原型。

用户访谈:了解怎么使用开放式和背景无关的提问。

观察用户

问卷调查

验收测试

开发之前写测试用例:客户定义测试,开发会定义一些其他测试。测试用例编写的时机包括:讨论需要记录明确的细节时;写代码之前作为一项任务;开发过程中或之后发现新的测试时。

产品和测试共同编写详细的测试,产品带来目标,测试带来怀疑的心态

开发团队会为很多详细的用例写单元测试,客户不负责定义所有可能的测试,应该更专注于那些向开发团队说明故事意图的测试

测试类型

集成测试

交互测试

可用性测试

性能测试

压力测试

注意:测试的是缺陷,而不是覆盖率;高度合作的团队心态:不应该推卸责任,而应该是我们共同负责;理清测试重点。

故事点估算

开发和客户团队参与,以团队估算

每个开发人员估算,经过多轮估算得出估算值

三角测量:比较故事的故事点;列出所有故事的故事点,按故事点排列比较

使用故事点:史诗故事不需要与拆分后的故事点数值相同

制定发布计划

莫斯科原则MoSCoW

必须有的(基本功能)

应该有的(重要但短期内有替代解决方案的功能)

可以有的(没时间就不考虑的)

这次不会有(客户期望拥有但同时承认需要在后续发布中实现的功能)

方法

根据用户的广泛性和重要性、故事之间的关系、时间等制定优先级

制定优先级前应该先估算故事点

价值优先or风险优先

根据架构需要安排优先级

确定迭代周期时间长度

从故事点到预计工期

初始速率:历史速率or进行一轮迭代试试or猜猜猜

开发人员帮助排列优先级,提供信息,在基础性需求、架构需求与其他需求之间取得权衡

产品故事有顺序编号


制定迭代计划

讨论故事:开发人员没有必要理解故事所有的细节;客户克制,不要改变优先级

从故事中分解任务

某些任务不需要在每个版本的故事中都列出(以前的迭代中了解或全局的规范)

开发人员承担每个任务的职责

接受任务后,开发人员单独估计任务

测量并监控速率

根据已完成的故事测量速率,不急于调整,在多轮迭代有稳定速率后调整发布计划

几个图

计划速率和实际速率(故事点-迭代次数)

计划故事点和实际故事点(累计故事点-迭代次数)

迭代燃尽图(剩余故事点数-迭代次数)

每日燃尽图(剩余小时数-天)反应剩余工作量:开发人员剩余工作时间可调整,但应该在开始尽可能合理评估;可以增加新的必须的任务

用户故事不良征兆

故事太小

故事互相依赖

开发人员镀金

故事中包含太多细节

故事中太早出现用户界面

想得太远

故事划分太过频繁(故事太大,一轮迭代难以完成;故事包括高优先级和低优先级的子故事)

很难为故事排优先级(故事太大;不具有直接商业价值的用户故事)

用户故事与用户界面 (敏捷版以使用为中心的设计)

用户角色建模

捕捞高层次的用户故事

排列故事优先级

精炼高优先级和中等优先级的故事

对故事整理分组

建立书面的原型

精炼该原型

开发

客户团队

用户故事与敏捷方法_第1张图片


开发团队

用户故事与敏捷方法_第2张图片



你可能感兴趣的:(用户故事与敏捷方法)