首页 新闻 论坛 群组 Blog 文档 下载 读书 Tag 网摘 搜索 开源 FAQ 第二书店 博文视点 程序员
频道: 研发 数据库 中间件 信息化 视频 .NET Java 游戏 移动 服务: 人才 外包 培训
    图书品种:235680
       
热门搜索: ASP.NET Ajax Spring Hibernate Java

“There’s no sense in being Precise when you don’t even know what you’re talking about.

—— John von Neumann

使用故事点或者理想日进行估计时最常见的问题之一就是:“我们何时进行重估?”要得到答案,至关重要的是记住故事点或者理想日是对要实现的功能的总体规模和复杂度的估计。故事点尤其不是对实现一个功能所需时间的估计,虽然我们常常会掉进把它们当成是对时间的估计这一陷阱。实现一个功能所需的时间是一个关于功能的规模(以故事点或者理想日表示的估计)和小组的进度率(以小组的速度来表示)的函数。

如果我们始终牢记故事点和理想日是对规模的估计,就更容易发现,只需要在我们确信一个用户故事的相对大小发生了变化的时候,才需要重新估计。使用故事点或者理想日的时候,我们不会只由于一个用户故事的实现时间比我们预想的长就进行重估。最好通过一些例子来看一下。

7.1  SwimStats Web站点

在本章的其他部分和接下来的几章中,我们会用到SwimStats,一个假想的针对游泳运动员和游泳教练的Web站点。SwimStats将被作为一项服务卖给不同年龄组、学校和大学里的竞赛性游泳队。教练可以用它来跟踪他们的运动员花名册、组织测验,以及为比赛做准备;运动员可以使用这个Web站点来查看比赛结果、检查他们的个人记录,以及追踪他们的成绩随时间的提高。游泳比赛中的官员可以把比赛结果输入到系统中。图7-1中显示了SwimStats的一个屏幕中显示内容的例子。

图7-1  SwimStats Web站点的一屏内容

查看所有评论(0)条】

最近评论



正在载入评论列表...
热点评论