现实世界的敏捷实践和估计

Question

在一个完美的世界中，我们告诉客户端我们遵循一种敏捷的方法，在这种方法中，我们允许范围随着需求的变化而增加/减少，并且我们为每次迭代每小时收费。

实际上，评估需要在项目开始之前交付，而且总是有压力要达到这个估计数，同时要灵活地处理范围更改。

我想知道人们在基于瀑布的计费/估算中应用了什么样的真正的敏捷实践，我们有时会陷入困境。在您获得信任之后，您是否可以“闯入”一个客户端到敏捷中间项目，或者有任何其他技术可以将客户端转换为敏捷。

*附带说明:在我的“真实世界”的情况下，我经营着一家最近成立的开发公司，它没有强迫客户使用我们的方法和流程的奢侈。很多时候，我们不得不弯腰去使用他们的产品，但我认为这是所有企业在创业时都要面对的一个负担。我在想怎么最好地处理这件事。

Answer 1

在现实世界中，我们告诉客户我们遵循敏捷方法。

我们不会“强迫”客户。客户可以要求任何他们想要的方法。我们仍然会以敏捷的方式来做事情。在最坏的情况下，客户需要大量的预先设计。我们耐心地解释说，我们仍然创建一个待办事项，他们仍然必须优先考虑积压。我们也有耐心将团队分解成几个部分，这样我们就有了多个重叠的sprint，这样客户就会“感觉到”我们在前面做了很多设计。实际上，我们正在为第一个版本构建代码，同时设计第二个版本。大家都很开心。

我们不允许随着需求的变化而增加/减少范围。

随着需求的变化，我们调整交付品的顺序、时间和优先级。

评估需要在项目开始之前交付，而且总是有压力要达到这个估计数，同时灵活处理优先次序和交付顺序。

范围的变化是不可避免的。每个人都知道它们的发生，会计们喜欢看到一个记录范围变化的“变更顺序”。

一个范围的改变是罕见的，不同于普通的，普通的重新排序，重新排序和重新思考积压。

如果您不断地重新考虑优先级和交付的价值，您就不必更改预算或日程安排。

在许多情况下，原来的计划是垃圾，经过一点点的开发工作，更好的计划表面，可以比原来的计划更便宜和更有效。

敏捷并不意味着随机范围的变化。

敏捷意味着通过协作来思考优先事项，以尽快创造更多的价值。

Answer 2

我认为最好的敏捷实践是您自然开发的。建立一个特定的方法是很好的，但是我相信你是在为其他人准备一个很好的方法(他们记录了这一点)。读一读scrum等等，但是随着时间的推移，你会发现模式会随着特定的客户而出现，如果你保持警觉，你就会对他们形成一种自然的感觉。你是一个服务行业，所以你必须回应你的客户想要什么，他们都想要一些不同的东西。

一定要让你的客户知道，估计只是估计，根据他们倾向于改变主意的程度，他们容易受到不同程度的精确性的影响:)

Answer 3

每次迭代的范围、截止日期和成本是固定的。

在迭代之间，一切都是可协商的。