目录
1：PDF上传链接
当你能够度量你所说的，并且能够用数字去表达它时，就表示你了解它；若你不能度量它，不能用数字去表达它，那么说明你的知识就是匮乏的、不能令人满意的。
--凯尔文勋爵（英国物理学家）1883
3.1：初始探索
在项目开始时，开发人员和客户会尽量确定出所有真正重要的用户素材。
开发人员共同对素材进行估算，估算是相对的，不是绝对的。
探究、分解和速度
过大或者过小的素材都是难以估算的，开发人员往往会低估那些大的素材而高估那些小的素材，任何过大的素材应该被分解成小一点的部分，任何过小的素材都应该和其他小的素材进行合并。
例如。考虑下面这个用户素材：“用户能够安全的进行存款、取款、转账活动”。这是个大的素材，对它进行估算会有困难，有可能还不准确，然而我们可以把它分解成一下更容易估算的素材
(1)：用户可以登录
(2)：用户可以退出
(3)：用户可以向其账户存款
(4)：用户可以从其账号取款
(5)：用户可以从其账号向其他账号转账
随着项目的进行，我们对其时间进行估算，估算的时间越来越准，这样的过程称为探究（spike）。
3.2：发布计划
如果知道了开发速度，客户就能够对每个素材的成本有所了解。他们也知道每个素材的商业价值跟优先级。他们就会选择自己最想完成的素材，此类选择属于商务（business）决策范畴。
开发人员和客户对项目的首次发布时间达成一致，通常也就是2-4个月后的事情。客户挑选在改发布中他们想要实现的素材。当开发速度更加准确之后，可以动态的对发布计划进行调整。
3.3：迭代计划
开发人员和客户决定迭代规模，一般需要两周。同样地，客户选择他们想要的首次迭代中实现的素材。不能选择与当前开发速度不符的素材。
开发的顺序由开发人员自行决定。
一旦开发开始，客户就不可以随意的修改素材的内容。
及时没有完成所有的用户素材，也要值指定的日期进行发布，当前的开发速度可以作为后续开发速度的参考。比如，当前迭代开发完成了31个素材点，那么下次机会迭代的时候也要完成31个素材点。
这样的速度反馈有助于保持计划跟团队实际状况相同步。如果团队在专业知识和工作技能方面有所提高，那么开发速度也很得到相应的提高。如果有人离开团队，开发速度就会降低，如果系统构架朝有利的方向演化，那么开发速度就会提高。
3.4：任务计划
迭代开始，需要对素材进行拆解成一个个小的任务，每个小的任务开发时间大概是4-16个小时。开发人员与客户一起对素材进行详细的拆解，尽可能列出所有的任务。
可以在活动挂图、白板和其他方便的媒介上列出任务，然后开发人员可自行选择他们想要选择的任务进行开发，然后会以随意的任务点数对任务进行估算。
开发可以任意接受不同的任务，精通数据库的可以接受GUI的任务，这样看起来好像是无法人尽其能，但是这样也有好处，开发人员对整个项目了解越多那么团队就会越健康，越有知识。我们希望项目的知识能够传播给每一个团队成员，即是这种知识是和他们的专业无关。
迭代的中点
在迭代进行到一半的时候，团队会召开一次会议。 在这个时间点上，本次迭代中安排的素材应该完成一半完成，如果没有完成，那么团队会设法重新分配没有完成的任务和职责，以保证迭代结束能完成所有的素材。如果不能完成，应该告知客户，让客户去除一些任务，至少客户可以指出那些最低优先级的任务和素材，这样开发人员可以避免在其他上花费时间。
3.5：迭代
每两周，本次迭代结束，下次迭代开始。在每次迭代结束时，会给客户演示当前可运行的程序，要求客户对项目程序的外观、感觉和性能进行评价。
客户可以经常看到项目的进展，他们可以度量开发速度，他们可以预测团队工作的快慢。并且可以早期安排实现高优先级的素材。
3.6：结论
通过一次次的迭代和发布，项目进入了一种可以预测的、舒适的开发节奏。每个人都知道将要做什么，以及何时去做。
开发人员看到的是基于自己估算并且度量开发速度控制的合理计划，他们选择他们感觉舒适的任务，并保持高的工作质量。
使用敏捷开发并不意味着涉众就可以提到他们想要的，它只不过意味着他们将能够控制着团队以最小的代价获得最大的商业价值。
529
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
