你在敏捷开发实践中使用UML吗？
这感觉就像一个早期的文物，但UML肯定有它的用处。 然而，像极限编程这样的敏捷过程主张“拥抱变化”，这是否也意味着我应该减less文档和UML模型呢？ 因为他们给人的印象是设置石头。
UML在敏捷开发实践中属于哪里？ 除了初步的规格文件，我应该使用它吗？
编辑：发现这个： 敏捷build模潜在的工件
轻松通过罗伯特·马丁的敏捷原则，模式和实践
- build议使用UML在团队内交streamdevise ……共享语言; 任何看图的人都可以理解这个解决scheme（比谈论它更快）并且更快捷。
- 如果您发现团队一遍又一遍地制作相同的图表，有人会制作一个好的版本，并将其保存在wiki / source控件中。 加class时，更有用的图表将开始整理在那个地方 。
- 不要花太多时间在上面 …你不需要太多的细节。 模型build在build筑/build筑领域，因为build造一栋房子来validationdevise是昂贵的/不可行的。 软件不是这样的 – 你可以通过在你做一个未经testing的devise的UML模型的时候进行编码来validation你的devise（所有的花里胡哨的东西）。
所以说，叔叔波…我同意。
使用你觉得有用的东西。 如果一个UML图帮助你可视化你需要做的事，使用它。 如果白板做同样的事情，使用它。
为了制作UML图，就不要制作UML图。 我们的时间太花费无用的东西了。
Martin Fowler的“devise已经死了？”，对于这个话题的深思熟虑和expression的看法。 如果这让你信服，购买/借阅并阅读Scott Ambler的敏捷build模 。
简而言之，UML是一个有用的工具，但不要过度使用/滥用它; 这是为了思考和logging，但代码是devise的最终（但不仅是）expression – 可执行devise。 为此， 团队应该做架构和devise。 最后，使用任何工具来做到这一点有帮助（例如，白板和笔和数码相机是伟大的 – 你不需要一个CASE工具）
对于扔掉图，是的。 我通常只使用它作为沟通的想法，问题等工具序列图，用例和类图。
如果你使用它们作为一个常量引用，那么你将要么：
- 通过复制已经在代码中的信息来增加不必要的维护负担。 要么
- 创build一组与实际代码不匹配的文档。
这个重复的问题是为什么我不会使用它们不仅仅是丢弃。 如果组件已经实施，新的开发者/顾问/承包商应该总是使用源代码作为他们理解的基础。
在我join一个项目开始的时候，我已经阅读了太多有趣的不正确的UML，几乎总是从代码开始，就像实际发生的那样。 另外维护的UML通常是不正确的，基本上是浪费时间。 在所有情况下，我都希望在代码中使用注释来描述奇怪的位和/或在UML文档中使用非常短的readme.txts。
根据我的经验，最初的UMLdevise（每个特性，模块或项目基础，取决于项目本身）是最有用的，然后进行初始代码生成，然后在每次迭代中对模型进行简单的逆向工程让他们更新和可靠，以便在重构会议等使用它们。 这适用于静态图。
但是dynamic图表只能根据需要进行更新，它们会占用太多时间，而在敏捷项目中它们会经常更改，因为它们是文档的一部分。 但是，如果你发现自己经常更新一个dynamic图表，那么在我看来，这是一种项目气味，因为如前所述，它们只能用于团队之间的沟通。
为了达到真正的灵活性，您应该只用一次代码来expression您的devise。
因此，虽然UML图很可能在准备任务时作为通信的简写符号，并且可以在与同事讨论devise时有用地总结devise，但它们不应该是交付的工件。
特别是不应该维护，因为这是不必要的重复。
当您需要向其他程序员解释用户故事的工作原理时，我们使用UML。 您可以勾画出交互图并显示哪些对象与其他对象交谈。
非常像Martin Fowler在这里所描述的： http : //martinfowler.com/bliki/UmlAsSketch.html
在敏捷开发实践中，我还没有就UML形成自己的可靠结论，但是我发现它作为程序员之间的简单通信媒介非常有用。
想象一下，你已经开始了一个你已经采取的故事，你发现你必须交换你的伴侣。 你可以findUML，将你当前的位置勾画出来，以便加快速度。
我还发现在演示时帮助解释devise模式和devise原则非常有用。
“一次性uml”是合适的。 这是快速和肮脏的，所以它不会浪费时间。
我是一名基础架构架构师，如果遇到问题或敏捷团队要求进行基础架构变更，我最乐意使用顺序图来沟通和了解软件解决scheme。
因此，图书馆可能会或可能不需要在敏捷团队中阅读代码的人之间进行交stream，但是他们对于与其他人进行交stream非常有用，例如服务经理和无法阅读代码的人。
我发现UML在与敏捷项目和瀑布项目中的业务利益相关者交stream业务build模和stream程stream程方面同等重要 。
我发现UML在与敏捷和瀑布式项目中的devise师，开发人员和testing人员沟通技术思想方面具有同样的价值 。
UML “做得对”是节省时间的 。 想象一下，试图以不一致，冗长的方式与业务和技术同事进行交stream。 需求可能会变得模糊和误解，并导致错误的function。
UML “做错了”是一个时间窃取器 。 UML是达到目的的手段 – 不是目的。 你不需要过分详细。 他们只需要足够详细，不要忽略你的听众感兴趣的关键信息。
根据我的经验，与敏捷项目相比， UML在瀑布项目中经常出现错误。 我发现这在很大程度上是文化的地方性，在这些文化中，某些UML图被连接到瀑布模型中的特定级联，并且在这些图中，图被错误地视为人造物。
到目前为止，我注意到这样的文化是地方性的，因为这个组织是非常谨慎和悲观的，因为它们的销售市场，和/或由于任何其他原因，有一个屁股覆盖/责备文化。
这与我在敏捷项目中处理UML经验形成了鲜明的对比，在这些项目中，图纸不受限于级联，而是在实用性时针对观众，而且一旦故事倾向于进入垃圾箱或史诗是完整的。
