（多年前的笔记，从ITEYE迁移过来的）
在获取到用户的需求并编写成User Stories，并且通过Playing Poker Game 估算出每一个User Story开发所需的时间后。我们得到了要开发所有的User Stories需要的时间，大多数情况都是客户对新软件的要求都相当的迫切。很少有项目是不受时间的制约的。而成功的软件开发就是在规定的时间，规定的预算开发出来用户需要的软件。所以我们需要根据我们的可用时间来进行软件开发。
计算实际可用的开发时间（以人天为单位）：
每一个项目都会有一个明确的截至时间，客户需要在那个时候得到他们需要的东西。所以我们的理论上可用时间一般是固定的，就是从项目开始到客户规定的截至时间。但是我们的开发时间并没有这么多，其中包括了周末、节假日、员工度假等等，在计算是都要考虑进入，这样每一个月的工作天数就是20。另外我们还要考虑开发人员的工作效率，还有就是员工请假、生病等情况，我们可以用开发速率来代表（其值应该小于一）0.7或0.8是一个不错的起点。等我们进行了一次迭代开发后我们根据实际的工作情况再调整该值。
我们用下边的公式来计算实际可用的开发时间：
实际可用的开发时间 = 可用自然月数 × 20 × 开发人数 × 开发速率
让客户挑选要开发的User Sotries并安排优先级：
在计算出实际可用的开发时间后，我们就可安排我们在可用时间内开发的User Stories了。等等，不是我们而是客户决定要开发哪些User Stories。只有客户才真正知道他们需要什么，不需要什么。通常情况下客户都会要求的比实际需要的多，这时候我们就要帮助用户跳选他们真正需要的，同时我们也能在可用时间内开发的User Stories。
根据优先级和实际可用时间用户挑选出了必须要实现的User Stories并排序，这些User Stories将做为Milestone 1.0中要开发的特性。在这个过程中我们需要告诉客户那些没有被挑出来的User Stories 并不是被舍弃掉，而是推迟到Milestone2.0或Milestone3.0。
Milestone1.0中应该只包含Baseline Functionality,如果少了这些功能软件就无法提供它的功能，这些功能是软件的最小功能集。
将选出的User Stories 分到各个迭代开发中（同样根据优先级）：
在得到Milestone1.0的所有User Stories后，我们需要它们分到几个迭代循环中。迭代循环不宜过长，宜采用较短的迭代。较短的迭代周期有助于发现和应对变化和没有预期的时间，可以及时的调整。同时较短的迭代周期也容易更早的从客户那里得到反馈，更容易调整计划。
但是太短话，又因为频繁的计划、发布反而不利于开发。同时，迭代周期的选择也和开发人员的经验，项目的特点有关。一般情况下，一个自然月即20个工作日作为一个迭代周期是比较合适的。
根据每次迭代可以完成的工作量将Milestone1.0 中的User Stories分到各个迭代周期中。优先级高的User Stories应该最先开发。这样我们就得到了几个迭代开发周期。
使用Big Board监控开发的过程：
在得到第一个迭代开发后，我们就可以进行第一次的迭代开发了。别急，我们还需要一个工具来监控我们的工作效率和实际工作量。这就是Big Board。没有找到的Big Board的图片(会在以后的文章中介绍)。
需要注意的问题：
1.在处理要开发什么，不开发什么，以什么顺序开发，都是由客户决定的。作为开发人员只能辅助客户。
2.开发团队的人员不是越多越好，根据团队成员的情况和项目特点，当人员达到一定数目时再添加人员不但不会提升开发速度反而会降低团队的生产力。这是由于人员越多交流沟通和管理的开销越大。
3.不要加班，加班只会使开发人员感到疲惫并降低生产力，而且影响开发人员的生活（一些极特殊的情况除外，如：产品发布前）。
4.与客户保持良好的沟通，注意沟通方式。最重要的要“Be honest with customer”.