如何在极端编程环境中进行建模？

Question

我知道一些方法，比如极限编程( Extreme，XP)，它为开发软件指定了自己的具体实践。但是，与Scrum不同，它更多地关注管理方面，XP指定了需要遵循的软件实践。从阅读这篇文章，这些步骤消除了使用BPMN和UML等工具的显式建模阶段。在马丁·福勒( Martin )的“另一篇文章”中，他进一步解释了这种沮丧。

就我个人而言，我更喜欢模型驱动的方法，我想这取决于公司和人员的喜好。敏捷的目标之一是“将开发人员从文档工作中解放出来”。像XP这样的方法似乎很容易导致文档不足。为了实现这个目标，解决方案是实现该工具，以帮助开发人员减少编写文档的工作量，而不是通过编写更少的文档、从现有图表收集信息并自动生成报告( RTF、PDF、HTML中的Sparx系统的企业级架构师)。

一些软件工程师也抱怨绘制图表耗费了他们的时间。在我看来，解决方案不是绘制图表，而是使用工具。今天的建模工具支持双向工程，您可以在代码和图之间进行同步，从而消除了在代码基发生更改时手动更正图表的额外工作(具体而言，是类图)。

建模是如何融入使用极限编程的团队的？

Answer 1

XP并没有明确要求创建一个模型，但它并没有说永远不应该生成一个模型。如果开发一个模型可以帮助您构建并记录您的系统，则绝对应该这样做。区别在于，在计划驱动的环境中，敏捷建模与系统建模有着不同的关注点。事实上，敏捷建模站点甚至专门针对如何在极端环境中建模。

敏捷环境采用更精益的方法(在精益工程或精益制造的意义上)。一些关键的租户包括减少浪费，决定迟交，以及快速交付。为了消除浪费，只需以适当的粒度交付所需的文档。如果你生产一种工作产品，那么该工作产品最终会给客户增加价值--浪费被认为是任何无助于为其付款的人增加价值的东西。

实际上，您链接到的X编程博客文章支持这一点：

您很可能需要为您的project...If提供一些格式良好的UML，当您真正需要这些东西时，您应该尽一切努力做到这一点。但是在你的团队内部，你很可能不需要他们，因为你所需要的信息将通过更有效的交流媒介进行交流。

你链接到的马丁·福勒文章也支持这一点：

当然，XP在很大程度上不强调图表。尽管官方的立场是“如果有用的话就使用它们”，但是有一个强大的潜台词“真正的XPers不做图表”。

一个敏捷方法的核心思想是“过程和工具上的个人和交互”。。您不为跟踪流程或使用工具而遵循流程或使用工具。如果您正在处理的任务没有增加价值，或者它不能产生对某人(客户或其他工程师)有用的东西，那么您就不去做了。

马丁·福勒接着说：

主要的价值是沟通。有效的沟通意味着选择重要的事物而忽视次要的事物。这种选择性是很好地使用UML的关键。..。图的普遍使用的一个共同问题是人们试图使它们变得全面。

再说一次，同样的想法。任何文件的目的都是沟通。如果你生产的东西并不能帮助你沟通系统，你为什么要这样做？不要专注于每一个细节，而是专注于传达一条信息，提供有用的，增值的信息给别人。

甚至在本文的后面，福勒继续指出，案例工具的问题之一是它们可能不同步。一旦代码和文档不同步，文档就不会添加任何值。我甚至会更进一步，说它增加了负值，因为它为任何试图利用它做出决定的人提供了虚假和误导的信息。如果您有一个维护同步的进程，那很好。但是，如果您没有并且确实让您的文档不同步，这就引出了另一个问题:为什么您有它们？它们显然没有被使用，否则它们就会被维护。

XP不需要模型驱动的其他方法，即使它们不一定会增加任何价值，而是要求将时间和资源花在实际帮助您向客户/客户端交付价值的事情上。如果您能够证明某些模型确实为您的项目增加了价值，那么您应该尽一切努力来生成它们。但是，您不应该生成复制其他信息或不增加价值的模型。