团队正在开始他们的第一个资本项目-敏捷项目，该项目似乎将与方法学保持一致（即，我们可能只是拿起一本敏捷书，并像食谱一样遵循它），但会有些混乱：
该项目涉及团队中没有人经验的三件事：与Foo Payroll System集成，能够处理XYZ89文件类型（其中“ XYZ89” =您从未听说过的某些文件类型），并进行转换其他文件，以便可以由Frobnobdicator处理。
据我了解，标准的敏捷实践是为每个事件安排峰值时间，然后我们可以确定它们将需要多长时间（我不确定客户是否有很大的机会会决定不这样做它们，因为它们是项目的基本要求）
所以我的问题是：
我们是否在第一次迭代中预先进行了所有峰值处理，以更好地估计执行峰值处理和/或使“行走骨骼”开始运行所需的时间？
如果不是这样，总项目进度表是否会受这些尖峰之一的支配，而返回的数据表明这个特定故事所花费的时间比我们制定的时间更长？
当多个峰值基本上是项目的不可协商需求时，最佳实践是什么？
Answers:
我以前在项目计划中处理这些可疑未知问题的方法是，尝试为开发团队准备时间来事先准备未知功能的原型。这样做的好处是可以清楚地知道完成专门任务所需的条件，证明这些任务在技术上是可行的，并且可以向团队的其他成员介绍可能的陷阱，从而避免在积极开发开始时就可以避免。
这就是为什么许多敏捷项目通常以a开头的原因，我喜欢称之为Sprint 0。
可以将其想象为系鞋带，伸展运动并在刚开始马拉松之前将创可贴放在乳头上。这段时间可用于进行初始项目规划和用户故事创建，设计和体系结构的首次展示，软件框架的创建，并且开发人员可以处理任何原型和概念证明，以应对将使用户故事成为现实的任何新技术或未知技术挑战估算容易得多。
您应该按照产品所有者（或客户）设置的优先级顺序进行操作。杀了一个真的很不错的东西是没有意义的。这样做的想法是，如果您用完了时间而又没有完成某件事，那么它应该是优先级最低的项目。
如果他们不优先考虑他们想要的东西，那么您将陷入困境。
如果事情是相对平等的，那么就不要从最困难的事情开始，而要从轻松获胜开始，这将使团队有机会习惯使用新方法进行合作，并使客户充满信心，他们可以以此方式交付东西。一旦确定，就解决一些困难。用您刚刚完成的简单项目的复杂性来衡量困难项目的复杂性，您将开始了解完成该过程可能需要多长时间。
复杂的项目并不是真正的“尖峰”。它们只是需要付出更多努力才能弄清楚的事情。尽可能将它们分解为更简单的任务。