项目进度的计划

在敏捷开发过程中，关于项目进度、迭代周期的确定，下面是本人的一些理解和实践：
1.项目开始阶段根据需求功能的初始优先级估计工期，初步的安排迭代计划，估计出项目的总体进度计划；
2.在项目进行过程中，根据需求优先级的调整以及项目进展，不断的更改迭代内容、周期，进而更改项目的总体进度计划；

上面是我目前采用的方法，在项目的进行过程中，迭代、总体进度调整的比较频繁。往往最终的项目进度和开始的估计相差很大，导致最初的进度计划很不准确，参考性不强。这可能是由于我对项目组人员的开发速度总结的不够准确。
另外一种考虑是项目开始不进行整个进度的计划，只是安排首次迭代，每次迭代完成前安排下次迭代的内容，这也是xp里面的方法，但这样无法估计项目的总体计划，而很多时候是需要在项目开始的时候就估计出总体进度计划的。

不知道大家的方法如何？

实际上我觉得你这种情况，更可能是对用户的需求理解存在误差值比较大，随着项目的深入，而逐步深入掌握。
实际上做项目最忌讳的是，以为客户知道他们想要什么，一切都听客户的。往往最初的计划和部署都是以这个为标准的。而随着项目的进行，客户也在成长，他们的想法也在变化。所以最初的设想就越来越不满足他们的要求，而计划就越来越需要调整。

貌似有原型的情况下，更容易和用户沟通和确定需求，在每个里程碑的时候如果可以的话和用户再谈谈确认一下。

不可控的因素太多， 人，新技术、新团队，需求不明确，需求变更，客户不合作。每项都有可能转变为项目计划的杀手。

这要看签订合同的方式。如果是固定期限，固定价格的合同，那就要限制需求变更，不能完全采用XP的方法，特别是XP的项目计划方法。

要么就是照XP的建议，签开口合同，开发费用根据实际工作量计算，也就是承认最初的计划（工期，成本）都是可以变化的。

如果是固定期限，固定价格的合同，而完全采用XP的项目计划方法，那基本是找死。

这句话太经典了。
我相信很多人在这上面吃过亏，我就是其中之一。
个人觉得影响项目的因素很多，有效的沟通是关键（包括与客户、项目组成员、高层领导等）。