语言 Chinese, Simplified

SEO Title

agilemodeling：Just Barely Good Enough Models and Documents: An Agile Core Practice

敏捷建模中一个比较有争议的概念是，敏捷模型和敏捷文档对于手头的任务来说已经足够了，或者就像我喜欢说的那样，它们还不够好(JBGE)。在本文中，我提出了以下关于模型或文档(工件)不够好的关键点:

这实际上是最有效的
它是情景
这并不意味着低质量
它会随着时间变化
它来得比你想象的要快

1. 仅仅足够好实际上是最有效的

出于某种原因，人们认为JBGE暗示了工件不是很好，而实际上没有什么比这更偏离事实的了。当您停下来思考它时，如果一个工件是JBGE，那么根据定义，它可能处于最有效的位置。图1是一个收益递减图，它总结了一个勉强足够好的工件的价值曲线。价值是指工件的净收益，它将被计算为收益-成本。虚线位于工件为JBGE的位置:线左边的任何地方都暗示您还有工作要做，右边的任何地方都暗示您已经做了太多的工作。当您在做某件事情时，它还不够，那么您仍然可以在它上面投入更多的精力，并从中获得好处(当然，假设您确实做了使工件更接近其预期目的的工作)。然而，如果工件已经是JBGE(或者更好)，那么对它进行更多的工作显然是一种浪费:一旦工件实现了预期的目的，那么对它的任何更多的投资都只是繁忙的工作。这个图有点天真，因为很明显，在工件变得不够好之前，值很可能是负数，尽管为了便于讨论，我将假设您从一开始就做得很好。

图1所示。成本分析刚刚好。

理想情况下，您的所有工件都应该是JBGE，如图所示。不幸的是，这并不是一个理想的世界。您经常会在一个工件上投入太多的精力，在您处理它时无意中超出了目标。例如，我真的需要图1中值曲线最右边的箭头吗?如果没有，那么这个图表就已经足够好了。敏捷建模者只是人，他们并不总是能把工作做得完美无缺，所以实际上，一些构件将远远不够好。秘诀是学会如何检测你什么时候达到了刚刚好到可以停止工作的程度。说起来容易做起来难。

2. 仅仅足够好是环境形成的

JBGE的基本挑战是情境性的。例如，我经常在白板上绘制UML序列图来探索复杂的逻辑，然后在完成之后丢弃它。在这种情况下，白板图很好，因为它帮助我解决了我正在思考的问题，无论我和谁一起工作。但是，如果我们以后需要更新这个逻辑，并且希望通过关系图而不是源代码来实现，又该怎么办呢?显然，在这种情况下，手绘草图还不够好，我们将使用复杂的case工具创建详细的图表。我们仍然会创建一个敏捷模型，尽管它比草图复杂得多，因为JBGE反映了情况的需求(记住，敏捷建模者建模是有目的的)。

要确定一个工件是否是JBGE，您必须积极地与该工件的直接受众一起工作。对于系统概述文档，它是维护程序员;对于用户手册，它是最终用户;对于草图序列图，它是实现相应代码的程序员。如果不知道用户想要什么，您就不能实际地创建JBGE，从而使您处于这样一种情况，即您有动机在工件上投入比需要多得多的精力。这常常被证明是浪费精力，因为很有可能工件会成为他们不打算读它(TAGRI)原则的牺牲品。为了确保您知道工件的受众想要什么，您需要确保与他们良好的沟通，并且更好地争取积极的涉众参与。

3.仅仅足够好并不意味着低质量

有些人似乎认为JBGE的工件质量很低。事实是，他们的素质足以胜任手头的工作。这并不是做一个低质量工作的借口，因为质量在观察者的眼中:工件的受众决定它是否足够，而不是它的创造者。如果您的涉众需要一个优秀的、详细的工件，那么当它达到优秀和详细的程度时，它就是JBGE。

4. 仅仅足够好随时间推移

工件可以在其生命周期的两个方向上沿着这个值曲线移动。您的需求可能会改变，变得更复杂或者更简单，因此您可以选择相应地更新您的工件。如果工件变得不够好，那么您将需要考虑更新它。

如果一个工件已经足够好了，你应该重新制作它吗?除非它损害了你在其他方面的努力。例如，对于图1来说，手绘图表已经足够了，尽管在我绘制它的时候，我没有方便地访问任何书写材料(例如纸张或白板)，所以我使用Microsoft Visio。后来，当我有机会接触到这样的材料时，我没有费心去替换图表，因为那也将是无用的繁忙工作。是的，我在创建图表时投入了太多的精力，因为用Visio绘制图表花费了我近15分钟的时间，但我本可以在白板上绘制这个图表，拍下它的照片，然后用软件在不到5分钟的时间内清理干净。但是，再花五分钟来改变图表的格式是没有任何意义的。

对于第二个例子，假设我不喜欢当前沿着X轴的标题，并且相信支出会更好。将启动Visio的努力,是值得阅读的文档,更新它,生成GIF,将图片上传到我的ISP,编辑这个页面的HTML返工文本匹配图,上传HTML,打开浏览器看看本文以确保我做得很对,做任何必要的补丁和随后的上传,然后提交更改版本控制?听起来至少5到10分钟的努力几乎没有任何价值。敏捷建模器只在受到伤害时才进行更新，而当前的X轴标题还不足以保证进行这种投资(实际上，我认为当前标题是有意义的)。事实上，这种更新实际上会降低本文的价值，因为成本大于收益。

5. 它来得比你想象的要快

图2描述了图1中所示的理想图的更现实的版本，具体到建模。它显示了两条数值曲线，虚线表示的是传统/重法建模的理论值，实线我认为是实际的数值曲线。传统主义者似乎认为，随着时间的推移，对建模和相应规范的重大投资将继续增加价值。然而，实践表明，建模的价值来自于改进的沟通和思考问题的能力，并且这种价值会很快达到峰值。例如，对于初始的预先建模，这通常发生在几天或几周之后(对于高风险的项目，您可能需要在初始建模上投入更多的时间)。即使对于企业架构或企业业务建模，您仍然只需要在初始建模上花费几周的时间。对于迭代建模，它甚至更短，通常只有几个小时，对于以分钟为单位的模型风暴来说。

敏捷建模

图2。建模的价值。