迭代开发过程实现

引言

在本文中，我们将介绍迭代开发流程的实现以及我的一些经验。如果您是迭代开发的新手，本文档可以指导您了解在整个过程中所需的事实。

完成本文后，您将学到以下内容

• 迭代开发方法论的概念.
• 如何在每次迭代中划分内容.
• 如何在并行迭代中保持进度.
• 如何在团队内部分配和跟踪任务.
• 如何处理团队会议.
• 如何管理风险和过度承诺.
• 如何发布您的迭代.

祝您好运，一路顺风！

迭代开发的概念

在批准的截止日期前发布整个项目，往往会导致紧张的开发环境。在许多情况下，人们发现由于交付时间表很紧，最终产品可能无法满足客户的期望。

无论开发团队有多少时间，客户绝对不会接受应用程序中的任何缺陷。

除了提高交付日期，项目经理还必须构思自己的计划，以在批准的日期前交付。

一种经过验证的方法是使用敏捷开发方法论进行迭代开发。使用这种方法时，我们将整个项目的复杂性划分为小的时间块。

还有进一步的两个划分

• 将项目的所有功能划分为客户期望的优先级，称为客户驱动的迭代开发。
• 将功能划分为风险因素，称为风险驱动的迭代开发

选择以上任何一种技术，并发布已完成功能的预期完成日期。让您的客户有机会查看每个可交付成果并提供反馈。市面上有很多开源的Issue tracker或Bug tracker。

预期最终产品将通过新功能的迭代逐年增长。这种方法可以最大限度地降低项目失败的风险，并最大限度地提高风险处理能力，从而显着提高项目的成功率。

如何在迭代中划分内容

我之前提到过，可以通过使用风险驱动或客户驱动其中一种方法来决定迭代内容。如果您无法决定哪种方法最适合您的项目，请考虑以下图表

状态	风险驱动	客户驱动
客户满意度	低	高
团队满意度	高	低
如果截止日期推迟，客户的感知	低	高
风险管理	低	高

无论您选择哪种方法，请始终将迭代视为一个独立的、小型的项目。

客户驱动

这是最受赞赏的方法，因为客户将推动进度并查看已开发的功能。客户优先考虑功能，协调员 accordingly将它们划分到不同的时间块中。

功能之间可能存在一些依赖关系，因此在将功能分配到迭代时要小心。绝不能完全依赖客户来划分迭代。团队也必须仔细审视划分。

有些客户不想参与该过程，并希望在最后看到整个产品运行。请尽量避免这种情况，因为它可能导致不令人满意的结局。据观察，最受欢迎的项目是客户与开发团队密切互动的项目。

当客户看到迭代的进展，并意识到产品正在逐步成形时，他会更加信任团队。如果您的项目截止日期推迟，这也有帮助。

风险驱动

在这种方法中，功能是根据其风险因素划分的，通常最风险的功能首先处理。团队负责人与团队坐在一起，将所有功能都放在桌面上。他们将功能划分为时间块，并发布每个迭代的发布日期。

我相信我团队以前没有做过或不知道如何做的事情都是风险。为了快速检查，您也可以考虑以下几点。

1. 您对该功能没有足够的技术专业知识。
2. 您没有资源，例如某些硬件。
3. 您的团队理解该功能，但不确定如何实现。
4. 您的团队无法理解该功能，或者需求模糊不清。
5. 您的客户无法表达他们的需求，而且需要更多的会议，但客户希望尽快开始开发。

当您划分功能时，我同意将最具挑战性的放在最前面，这样您就有更多时间来研究和解决它们。但是，切勿将所有团队成员都分配给解决风险。至少将 35% 的资源用于其他功能。

始终将每次迭代视为一个独立的、小型的项目，它从

• 理解前方任务的需求。
• 设计开发策略。
• 确定与任务相关的风险。
• 识别前几次迭代中完成的任务的副作用。
• 编程和可重用性设计。
• 设计测试用例并将其分配给合适的候选人。

有时，对团队成员隐藏迭代的实际最终日期，可以让您在开发过程中听到惊喜时更加从容。

如何在并行迭代中保持进度

您的团队可能不是唯一一个忙于迭代的团队；可能还有其他并行迭代正在进行，但每个团队的最终目标都是迭代发布。发布必须是一个稳定、可集成且经过测试的系统。团队负责人还负责与其他迭代发布的集成。

在并行迭代过程中，团队负责人之间的正式会议通常可以减少最终的集成问题。它还有助于探索团队之间的新设计技术和编码实践。

此外，不仅仅是为了完成迭代。团队负责人必须在开发过程中考虑集成限制。发布不应花费太长时间才能与其他并行发布集成。

如何在团队内部分配和跟踪任务

您的团队成员是您的工具；让我们假设您得到了一个工具箱来打开摩托车发动机。如果您不熟悉每个工具的技能，您最终会一团糟。

在与团队成员见面之前，了解每个成员的技能，然后准备好会议材料

1. 每项任务将消耗的估计时间。
2. 每项任务的开始日期和结束日期。
3. 根据技能划分任务。
4. 在每项任务结束时添加少量的时间缓冲。
5. 为测试每项任务添加时间缓冲。
6. 为发布文档添加少量时间缓冲。

在会议中展示上述 2、3、4 和 5，并询问每个成员的估计任务时间，如果他们的估计时间少于或等于您的估计时间，则表示赞赏，如果超出您的估计时间，则告诉他们重新计算，因为我们没有太多时间。让您的团队成员接受任务的划分和估计。

我注意到很多时候，团队负责人在讨论用例估计时总是找到很多争论。只有经验丰富的开发人员才能准确估计。但每位团队负责人都必须遵循此实践，在开发人员动手之前获取任务的估计。切勿让开发人员在未确定完成时间的情况下工作。

每天花一些时间与每个团队成员随意交流，先从友好的交谈开始，然后了解工作进度。

开发人员的常见问题是他们是代码迷，如果他们代码中的某些逻辑工作不正常，他们会一次又一次地与之斗争，这很好地体现了他们的奉献精神。始终关注类似情况，开发人员可能会花费所有时间来探索、学习或解决问题，而时钟在滴答作响。您有责任让他们根据您的优先级工作。我有一个类似的经历列在下面

我们在项目启动阶段的最后阶段，当时我问了一位团队成员
我问	“嗨，丹尼斯！你已经按时完成了你的任务，我现在给你一个小任务吧？”
丹尼斯	“我上一个任务有一些需要修复的地方，让我先完成它吧”
所以我允许他回到第一个任务。两天过去了。
我又问	“丹尼斯，进展如何？一切都在正轨上吗？”
丹尼斯	“当然，看来我需要多花点时间”
我回答	“没关系！尽力而为”
又过了两天，他似乎很忙于这项任务，我又问
我问	“今天怎么样，丹尼斯？还有问题吗？”
丹尼斯	“是的，还没解决，我解决好会通知你的”
我问	“让我看看！也许我可以学到新东西”
丹尼斯	“好的，实际上我正在尝试在持久层之前创建一个抽象层”
我问	“你为什么要这样做？”
丹尼斯	“因为，如果将来持久性供应商发生变化，那么客户在代码中进行更改的难度就会减小。”
我感到惊讶	“但是客户永远不会更换供应商，未来 20 年内也不会，这也不在规格中”
丹尼斯	“但这将是一个很好的功能，可以减少兼容性问题”
我坚持	“但是，如果这个好的功能永远不需要也不使用呢？”
丹尼斯	“但是你应该和客户谈谈，告诉他这件事，他会很高兴的”
我冷冷地回答	“不，你早就应该和我谈过这件事了，我已经和客户讨论过了，他永远不会更换供应商，因为这不是一个开源项目，客户已经在这个项目中花费了数千美元购买了许可证。此外，规范中还有其他任务。请关闭这项研究，到我的办公室来，我还有其他更重要的任务给你。”

考虑以上经验，有一种开发人员会花费大量时间在类似的任务上。他们不会根据团队负责人或项目经理的意见行事。你需要快速识别他们，以节省宝贵的时间。

如何处理团队会议

在迭代过程中应进行多次开发人员会议。团队负责人必须确保人员充分理解任务。有时强迫某人重复他们对任务的理解会很有用，相信我，他们不会喜欢这样。

大多数时候，会议最终会产生大量澄清需求和开发人员的问题。由团队负责人快速协调客户并澄清需求是完全可以的。

如果客户不在，并且需要一些时间来回复您的问题，那么您需要利用这段时间。时钟在滴答作响，团队成员正在等待您的回复。始终列出所有低优先级任务，并在这段时间内使用它们来让那些等待客户澄清的团队保持忙碌。

如何管理风险和过度承诺

几乎所有的迭代都包含至少一项被识别为风险的任务。还有一些任务是从一开始就未被识别出来的，要非常小心，一旦确定就尽快告知客户。

这些风险也应在初步团队会议中讨论，并记录开发人员的评论。进行自己的研究以验证评论。如果困惑持续存在，则开发一份详细的文档，其中解释以下内容

1. 为什么这项任务是风险。
2. 解释风险的关键程度。
3. 可能的解决方案是什么。
4. 您的建议是什么。
5. 您的研究参考文献。

许多时候，客户会减少或更改他们的需求，风险不再是风险。如果无法减少需求，则尝试将风险与迭代中的其他任务隔离开来，以免干扰整体开发进度。分配另一个时间段来单独处理该风险。

过度承诺在经验不足的团队中非常常见。当某些任务未完成时，可能会出现问题，这些任务与集成模块有关，或者被其他迭代团队所期望。

团队负责人必须在交付日期之前识别出预期无法按时完成的任务。这本身就是一项任务，因为

• 大多数开发人员经常低估需求，并始终确信任务将按时完成。只有在最后几个工作日，开发人员才会意识到用例的复杂性。
• 某些编码问题或供应商限制。
• 某些技能的短缺花费的时间比预期的要长。

团队负责人必须在交付日期之前，确保与他的上级或客户协调，了解发布的内容。

为了完成发布中的所有任务而延长交付日期是一个糟糕的主意。

始终按时交付，即使迭代内容不符合客户的期望，也要在发布前与客户协调。显然，这不应该是发布前一晚。让您的客户知道发布可能不包含某些功能。

在发布说明中清楚地写下未完成的功能以及这些功能的预期完成日期。

如何发布您的迭代

一次好的发布应包括以下内容

1. 发布说明，列出了所有已完成的功能和测试状态。
2. 如果某些功能未完成或未经过充分测试，请在文档的单独标题中写下。如果您能写下这些任务的预期完成日期，那将始终受到赞赏。
3. 详细说明任何限制或约束的文档数量。

不要忘记为该迭代使用的所有资源单独创建备份。

您可能不需要源代码控制环境中的备份，但请花点时间考虑那些不在源代码控制中的资源。

摘要

迭代和增量开发过程已被证明是最佳实践。迭代比顺序软件开发提供了戏剧性的反馈增加，从而提供了客户和团队之间更广泛的沟通。

该过程的好处是，惊喜被分散在不同的时间段，这始终为您提供了很好的时间和机会来分别管理和处理风险。