对于最终用户和系统集成商来说，不那么传统的敏捷方法对于制造执行系统(MES)/制造运营管理(MOM)项目的成功是如何至关重要的，本专栏是第三期(也是最后一期)。正如我所指出的上个月，当我写第一篇文章在这个话题上，我没有想到会引起这么多人的兴趣。一些评论者要求解释和洞察如何创建使用这种方法的项目的成本估算。其他人想知道如何管理在各种sprint中可能发生的不可避免的范围变化。上个月，我谈到了如何进行成本估算的问题。这个月，我将探讨第二个点——项目范围中的变更管理。
项目范围的变更是每个项目经理的噩梦。这是必然会发生的，但很容易导致利润大幅减少或与客户关系受损——这取决于如何管理它们。这两种情况显然都是有害的，并显示了仔细管理项目范围中的任何更改是多么重要。在MES项目中，情况更加复杂，因为项目涉及到不断发展的生产过程的组织。如果你以单一的方式处理这类项目，这意味着你应用了经典瀑布式项目管理，您要么必须在开发过程中管理大量的变量，要么在项目结束时使用一个不再满足用户需求的系统，这都是有风险的。
在这种情况下，使用非典型敏捷方法提供了一个主要的优势，因为开发是以循序渐进的方式进行的——一个冲刺一个冲刺——在初始阶段进行全局分析的上下文中进行，以确保一个一致的框架。
当您以这种方式组织一个项目时，每个sprint的发布都是一个反思和回顾的点。客户获得最初所需的整体功能的一部分，并在其组织结构中立即开始使用它。作为这一过程的自然结果，他随后获得了经验并开发了导致重新考虑项目规范的信息。每个sprint之后都有一段时间对初始规范进行讨论和关键的重新评估。可以根据经验或操作条件的变化对尚未执行的sprint进行确认、修改，或者对已经发布的sprint进行修改。
当变更与已经开发甚至发布的组件相关时，必须从技术和经济的角度使用传统的方法来处理它们。
在为尚未开发的sprint修改需求的情况下，对变更对系统配置、风险和开发所需工作的影响进行评估。范围变更明显地在质量控制方面被跟踪和管理，但通常不需要对经济项目成本进行调整，因为必要的活动只是预期活动的替代。
紧接在这个反思阶段之后，我们继续开发下一个sprint的功能规范，以适应更新的需求。这种灵活性元素使需求始终与最终用户的当前需求保持一致，使项目的技术和财务管理上的变更的影响最小化。
根据我的个人经验，使用这种方法管理的项目与使用传统瀑布法管理的项目在技术/财务结果方面存在着巨大的差异。
用敏捷方法管理的项目倾向于在持续改进的过程中自然地发展。相反地，那些使用整体/瀑布方法管理的人常常在最后面临一段停滞期，客户和系统集成商之间的关系变得紧张，需要重建相互信任。
如我在第一个敏捷的帖子， MES/MOM的主要目的是支持支持运营的业务流程，弥合生产和战略管理之间的差距——每个公司的生产和战略管理是不同的，并且高度可变，这取决于公司自身适应市场演变的需要。
只有确保灵活性以支持客户需求的内在可变性和相关各方的相互经济保护的项目管理方法，才能实际上保证这类项目的成功。我个人认为非传统的敏捷方法是能够为大多数项目做到这一点的唯一方法。
Luigi De Bernardini是Autoware是位于意大利维琴察的认证控制系统集成商协会成员。有关Autoware的更多信息，请访问Autoware概要工业自动化交易所。
