敏捷开发—用户故事

 

1.1. 敏捷开发的目的

质量风险前移

适应需求变化

及时总结、思考和促进团队成长。

 

 

2.      User story和需求列表的不同

需求栈通常如下：

序号	功能	详细描述
1	功能1	…………………………………………
2	功能2	………………………………………….

 

为完成以上功能，我们通常会将任务按重要性，和依赖性对其的优先级排序，排在前的优先做。这是在开发过程中惯用的手法。

可是每个功能开发该估计多少工作量呢？这个数据确实千差万别，同时按功能实现还有一个缺点，有些功能只有接口，没有界面。如后台功能。这导致测试没办法正常介入。只有当后继的支持功能和界面完成以后，测试才能介入。同时后继开发也面临着问题，包括上次迭代不完整引起的重构问题，上次迭代遗留的BUG可能很多。

 

出现这些问题的实质原因在区分清楚user story和需求列表的区别，特别是在敏捷开发中的区别。

敏捷开发，崇拜的价值交付，每一个迭代的交付都是有价值的。传统开发模式下任务是横向切的。

横向切的意思就是先做数据存储，再做数据访问，再做业务，再做界面。你可以看见当界面没有成型时测试是没有办法有效介入的。

而敏捷是竖直切的。

没一个迭代都有完成的数据存储，数据访问，业务和界面的实现。通过每一步迭代完成一套功能。

l  概括起来，敏捷的userstory有如下的特点：

l  已工作场景为单位描述

l  每个user story相对独立

l  可讨论的，能够支持开发，需求，客户三者，基于场景沟通。（一个功能是无法承担这样任务的）。

l  有独立的价值。客户可以付钱来卖的。

l  可估计，可预算的。包括了技术上是能实现的，方案和业务逻辑是可实施的，时间上是可估计的。

l  小到一个迭代内可完成的。

l  可测试的。

 

在实际的开发过程中，也会对userstory排序，排序是更具user story对用户的价值为准则，价值高的先开发。