问我应该听我的雇主的话并使用案例工具吗？

EN

这种情况需要对这一决定采取分析性的办法。底线是“CASE工具是否为业务提供了价值？”通常，管理层希望开发人员采用一种方法或工具，因为他们已经听到了关于它的好消息，不管它与组织的当前流程和文化有多好的契合。

如果你的雇主要求你研究案例工具，就像ChrisF指出的那样，你应该去做(这是工作场所的问题，而不是编程)。影响采用案例工具的一些因素包括：

• 您的流程中有哪些可用的CASE工具，
• 估计采用这个新工具需要多少个小时(S)，
• 随着新工具(S)的采用，这一过程将如何改变，
• 或者采用新工具会产生什么样的积极(或负面)影响(S)

将此视为升级您的开发环境和流程的机会。也许您当前的流程与您的组织文化是完美匹配的，但您有责任对您的雇主和团队进行适当的研究。

是的，你应该开始研究案例工具。

1. 因为你需要证据来支持你的断言，他们不会帮你。你永远不会知道，你可能会发现他们会帮上忙。
2. 因为你的雇主让你这么做的。

我不会重复大卫·卡钦斯基( David )在他的极好的回答中提出的观点，因为它们正是你应该遵循的步骤。

这似乎是一个从敏捷到面向案例/MDA的代码生成开发的巨大范式转变。不一定是从项目管理的角度来看(案例方法不会与迭代、用户故事、快速反馈或持续改进的概念相冲突)，但从“软件工艺”的角度来看，这无疑意味着减少对生成的代码的控制，生成的代码可能是不可读的、僵化的、更难测试的、经常需要与模型同步等等。

根据你的描述，你的雇主需要什么是很容易理解的：

• 更好的文档，以避免知识损失，如果一个开发人员要离开团队。
• 更快的开发过程。

作为一名软件专业人员，你绝对可以(而且应该)告诉他你对案例方法是否符合这些期望的能力的怀疑。如果他要求的话，你也有责任开始研究案例工具。仅仅尝试其中的一个并不意味着结果会令人满意(我尤其在考虑潜在的巨大代码生成开销，这种开销与开发速度的需要相冲突)和2/您无法找到折衷方案，即在保留现有敏捷上下文的同时使用案例工具的一些特性(图表、文档生成)。

这里有一篇有趣的文章，介绍敏捷环境中的案例工具及其可能的优缺点：http://www.agilemodeling.com/essays/simpleTools.htm