摘要/敏捷开发/用户故事

更快的速度,更少的消耗,应对现实世界的快速变化

What 对用户有价值的功能

组成

卡片(Card)                书面描述->计划 提示    

对话(Conversation)    对话->故事细节            

确认(Confirmation)    测试->确定何时完成       

故事不具备契约性质 协议通过测试来记录

故事也是可以迭代的

测试描述的目的是传递故事的额外信息

类型

史诗故事(Epic)

...

成本

故事点(story point)    大小 复杂度

NUT(Nebulous Units of Time)

累计故事点

中央极限定理(Central Limit Theorem)

任一分布的独立样本数量之和符合正态分布

特点

INVEST

独立的 Independent

可讨论的 Negotiable

对用户或客户有价值的 Valuable to Purchasers or Users

可估计的 Estimatable

小的 Small 太小会导致 缺陷报表和用户界面变更

可测试的 Testable

不良症兆

故事太小

故事相互依赖

镀金

故事中包含太多的细节

过早包含用户界面细节

想得太远

故事划分太过频繁

很难为故事安排优先级

客户不愿意写用户故事,为故事安排优先级

分割故事

复合故事 compound story

复杂故事 complex story

处理非功能性需求

性能 performance

准确性 accuracy

可移植性 portability

可重用性 reusability

可维护性 maintainability

互操作性 interoperability

可用性 availability

易用性 usability

安全性 security

容量 capacity

How

敏捷过程

极限编程 XP

探针试验(spike)

最大时间量 时间箱(timebox)

实践

短交付周期 small releases

计划游戏 the planning game

重构 refactoring

测试 testing

结对编程 pair programming

持续一致的速度 sustainable pace

团队代码所有权 team code ownership

编码标准 coding standard

简单设计 simple design

隐喻 metaphor

持续集成 continuous integration

现场客户 on-site customer

价值

沟通 communication

简单 simplicity

反馈 feedback

勇气 courage

关键原则

快速反馈 rapid feedback

假设简单 assuming simplicity

增量变化 incremental change

拥抱变化 embrace change

高品质产品 quality work

敏捷版本的统一过程 Agile Unified Process

Scrum团队

往往采用30天为周期的迭代 Sprint 开始的时候召开Sprint计划会议

所有工作内容放在产品Backlog的排好优先级的列表

Backlog产品是所有待开发产品功能的列表

下一个Sprint要做的任务存放到Sprint Backlog列表中

每日Scrum简会 (Daily Scrum) 审核进度 进行调整

产品负责人(负责管理Product Backlog内容 排列优先级)

ScrumMaster(为Scrum团队服务 排除障碍)

任何时候都可以添加故事 或者重新排列优先级

每个Sprint都要完成一部分可以潜在交付的产品功能增量

加入基于故事的敏捷版以使用为中心的设计

用户角色建模

捕捞高层次的用户故事

排列故事优先级

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

对故事整理分组

建立书面的原型

精炼该原型

开始编程

标准

商业语言 对话交流 避免在故事中出现用户界面和技术方面的定义

鼓励推迟考虑细节 逐步求精

每一个用户故事代表一个独立的功能

迭代

选择迭代长度

速率(veolocity)

开发人员可以再一轮迭代中完成的工作量

计算速率只考虑已完成的故事

完成一个任务或故事所花费的实际小时数对速率没有影响

迭代规划

选择迭代包含的故事

排列故事优先级

放大缩小 zoom in/out

迭代燃尽图 监测实际 计划速率区别

发布

一个发布由一个或者多个迭代组成

发布规则

确定项目时间表和预期功能集合之间达到平衡

调研和实现不放在同一轮迭代中

故事之间的交付顺序应该是无关的

给故事注释最好是便于测试用例

反馈循环

用例一般比单个故事要大,更容易包含关于用户界面的嵌入式假设

用例存在于整个开发过程中 用户故事往往只是暂时的

创建约束卡

系统角色 non-human user rule

频率

总体目标

市场和目标用户群调查

搜集故事

拖网 (trawling)

需求会像鱼一样 会成长 也可能死亡 今天的渔网可能会漏掉一个需求

需求分析人员 requirements trawler

相关性 relevance 变化

占位符 placeholder