在网上搜索，敏捷贤者认为用例和用户故事是两个不同的东西： Mike Cohn： 用户故事不是用例 Alistair Cockburn： 用户故事之于用例就像瞪羚之于凉亭 Extreme Programming.org： 用户故事与用例的目的相同，但并不相同。 用例驱动方法是需求捕获最热门的技术之一，现在有些人认为它是一种过时的旧式技术，它与许多问题相关联，导致您的团队由于用例问题而不是“敏捷” ： 前期需求——试图定义前期所有方面的细节将导致大量的精力和时间的浪费，因为很多工作都需要重做。 功能分解：用例的功能性质自然导致系统在具体和抽象用例方面的功能分解，这些用例通过扩展关联并包括用例关联。 如果你在网上搜索关键词“用例 vs 用户故事”，你会发现一长串关于用例方法的缺点、问题或陷阱的文章，而与用户故事相关的好处甚至更长。 . 有趣的是，IT ...
继续阅读...

“工欲善其事，必先利其器” 《论语·魏灵公》  “工欲善其事，必有器” 《论语》 软件方法是使用选定的过程技术来提高软件开发工作质量的实践，从而减少缺陷，从而最终提供更短的交付时间和更好的价值。一种软件方法通常被认为比其他任何方法都好，但总是无休止地争论不休。我必须说，没有一种最好的开发方法，不同的方法最适合不同的项目环境。什么是最好的取决于方法是为谁，在什么情况下，为了什么目的，等等；说没有一种方法最适合软件开发人员，也就是说不同的方法最适合不同的团队或不同的项目性质。 Grady Booch 说： “如果你想建造一个狗屋，你几乎可以从一堆木材、一些钉子​​和一些基本工具开始，比如锤子、锯子和卷尺。几个小时后，你很可能最终会得到一个功能齐全的狗屋……如果你想建造一座高层办公楼，你会想要进行广泛的规划……你将只是一个更大的群体的一部分负责开发和部署建筑物，因此团队将需要各种蓝图和模型来相互沟通……” 您会为小型 Web 应用程序和 NASA 太空探测器采用相同的方法吗？可能不会。你会在六人团队中采取与六十人团队相同的方法吗？再一次，可能不会。正如 Scott Amber 所指出的，不同的情况显然需要不同的方法。软件开发没有一刀切的解决方案，事实上，设计人员需要拥有广泛的工具供他们使用，了解每种工具的优缺点，并能够快速决定最合适的工具在给定上下文的理想工作流中应用。 ...
继续阅读...