关于用例、UP，用户故事、XP的疑惑

多谢捧场。

其实我最大的疑问就是目前国内UP，用例分析的运用情况不知怎么样。XP，用户故事等又运用的如何。

不会是论坛上热火朝天，但现实中确鲜有采纳吧（我的经历及眼界似乎看到的就是这样）。

我接触的几乎所有项目都与什么UP，XP，用例，用户故事什么的完全无关。身边也没有多少运用这些方法的商业项目。当然其中的某些实践还是有用到的，比如重构，持续集成什么的。

在很多项目中，客户事先就明显已经选定了方法模型，常见的就如瀑布模型（他们采用这样的模型进行监控）。文档规范也选定了国标/ISO的规范。你说要用UP，XP，用例，用户故事什么的，人家根本就不是那么的接受。

我觉得客户的接受度是一个大问题。当然，这可以通过加强对客户的培训什么的得到改善。不过目前很多客户根本就不给你培训的机会呢。

也有人会提出折衷的方法，比如，我们自己搞一套（UP），对客户搞另一套（瀑布），但这两种方法是很不适配的，对客户搞的那套形式纯粹是浪费资源，也容易把一些事情复杂化。

另外除了现实中客户方面的阻力外，大部分公司内部也阻力重重。我遇到的很多公司，内部管理层仍然对UP，XP，用例，用户故事啥的一点都不感冒，你想推动都推不动啊。

所以我的结论是：普遍来讲，国内目前开发方法似乎仍然以瀑布为主流，文档及过程规范仍然采用国标/ISO为主流，CMM也有一些。但UP，XP等敏捷方法仍然处于一个比较尴尬的现实地位。似乎只有极少的公司采用这些方法为主流（只听说传闻）。大部分公司要不根本不采用，要不仅仅停留在个别团队自己对某些实践的小规模尝试而已。根本不成气候。不知我这样说是否正确呢。

现实中，我有点感觉完全是孤军奋斗，郁闷啊。很期待听到不同的声音。

对用例实践了几次，也有些疑惑，搜到了这篇文章。

我一般用例是使用两种的，区别就是一种是有步骤的，一种是自然语言的。

我发现其实带步骤的用例很少用到，而且很难理解，有时强迫写用例的人做设计的倾向。

现在看来我更倾向于使用自然语言的方式，可以使用简单的界面设计进行补充。

其实需求对客户和开发人员讲，可理解性是最重要的。

我认为最好的形式：自然语言+泳道图+界面原型（最好可交互）

原则：离用户对软件的真实体验越近的方式，就是越好的方式。

静态页面原型是客户比较容易接受的，因为其容易理解，可操作，可反馈，这个也是
符合认知心理学的。

从这个原则引申开去，就是小版本发布，因为用户可以频繁的获得真实体验，已经可以工作的软件肯定是最好的获得体验的方式。