上个月我曾写过一篇关于非常规的敏捷方法如何对制造执行系统(MES)或制造运营管理(MOM)项目的成功至关重要的文章。我没有预料到人们对这个问题表现出的所有兴趣。许多人在LinkedIn上发表评论，要求解释和见解，特别是:“如何用这种方法估计项目?”和“如何管理在各种sprint期间可能发生的范围变化?”
在本月的专栏中，我将回答第一个问题;下个月我将处理另一个问题。显然，我并不认为我知道所有的答案，但我从我使用Autoware的经验中提供了思考和讨论的食物。
对软件项目进行评估总是一项复杂的任务。已经发展了许多理论，试图将估计活动引入定量算法方法。然而，由于软件开发过程基本上是创造性的，在我看来，实际上没有一种方法被证明能够产生足够正确的评估，比经验更有效。在开发项目的情况下尤其如此，项目之间发生的变化可能非常大。
选择用敏捷方法管理项目会进一步增加复杂性，因为敏捷方法提供的高灵活性对应于要获得的最终结果的不确定性。然后，我如何对实现没有很好地定义和指定的东西所需的资源进行估计?
当我们需要定义开发新项目所必需的承诺时，我们通过以下步骤来解决问题:
- 与客户一起定义其需求的大致边界，并将宏观请求映射到我们经验中尽可能多的宏观领域。这有助于我们识别(至少是粗略地)问题，并了解从哪组经验中获取信息，从而尝试将请求带回已知的东西。
- 考虑到项目的复杂性，开发一个技术解决方案的宏观体系结构作为参考。此体系结构提供了一个已定义的公共元素，以便在以后与客户机的任何交互中引用。
- 确定有多少需求集与标准特性或已经为其他项目开发的组件相似，有多少不同或超出了公司的经验范围。
此活动考虑到由客户的用户需求规范(如果可用)提供的文档。最重要的是，这个过程通过与客户的直接互动进行，帮助我们更好地理解客户的目标和期望，而不是任何文件所能描述的。同样重要的是了解客户的中期和长期愿景，以便能够立即从达到最终目标所需的方向接近项目-至少可以在此分析时定义。
将宏需求与宏功能联系起来，允许您将问题分割成更小的问题或模块，通过这些问题，您可以更好地利用在评估和实现中获得的经验。这大大降低了定义必要资源的过程的风险，并允许您更清楚地定义每个模块的风险系数，以用于纠正估计。
在定义了模块、可以借鉴的经验和风险因素之后，你会得到两件事:
- 项目预算价值的定义，其唯一目的是允许客户确定它是否与他们的期望、估计或预算一致。
- 对探索所暴露的主题所需的承诺价值进行准确估计，对分析进行细化，以便将每个文档(可能由客户单方面生成)纳入客户-集成商团队制定并共享的文档。
如果客户决定继续项目，则开始对项目范围进行深入分析的阶段，从而起草通用规范文件或修改和分享客户制定的内容。
这一步对于创建一个可以为所有相关参与者提供支持和安全的公共基础至关重要。这个通用规范文档在这个阶段尽可能地协调了团队的期望，澄清了目的，并定义了正式项目的轮廓。本文件的目的是在项目过程中进行编辑和修订，但在每种情况下都用作指导未来活动的指导方针。
只有在这项活动完成之后，才有可能重新估算预算并提供所涉及的工作量估算。所获得的价值将只受一种变化的影响——在项目期间讨论和同意的范围的变化——这将在下个月详细讨论。
Luigi De Bernardini是Autoware, a认证控制系统集成商协会意大利维琴察的成员。有关Autoware的更多信息，请访问Autoware网站或浏览公司简介工业自动化交易所。
