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

现实工作中似乎很少看到使用用例来分析及表达需求的。也很少看到采用UP过程规范进行开发的。

在我经历的项目中几乎都是采用传统的需求，概设，详设等国标/ISO规范来编制文档。鲜有使用UP等文档规范的。相对应的也没有采用迭代方法。基本上都是瀑布（大部分采用分期模式，比如一期，二期，三期啥的）。不知大家情况如何。

在最近的一个内部项目中，尝试了运用用例方法分析及表达需求，采用UP方法进行了小规模的尝试。

在开始我们采用了完整用例格式，发现不是那么的得心应手：
1、项目组需要大量时间精力来编制需求文档（开发周期较短，进度紧）。
2、用户需要投入大量时间进行用例阅读及确认（用户不能集中投入大量时间及精力）。
3、由于用例表达的复杂性，用例的可阅读性，可理解性相对比较低（完整格式有太多细节）。
4、用例跟踪比较麻烦，需求同步很费劲（资源不够）。

所以我们改为使用非正式用例格式。效果就好多了。正如《编写有效用例》中描述的5种典型项目类型。我们的项目是那种周期相对较短，强度较高的项目。不是很适合采用完整用例格式来分析及表达需求。反而比较适合采用非正式用例格式。其实这倒有点类似于敏捷方法中的用户故事了。

采用非正式用例格式有一点需要特别注意的是：在开发期间需要和用户继续频繁的沟通需求细节。这就需要客户的高度参与。这和敏捷方法倒是不谋而合了。不知大家有什么用例分析方面的实际经验？

对用户故事我了解的不是很多，也没见到有项目采用。大家有什么经验呢？

敏捷方法（如XP）采用什么文档规范？还是自己制定文档规范呢？

经验不多，疑惑不少。大家来帮忙解解惑。

我个人认为，在需求方面首先应该确认用户的目标是什么？即：项目完成后会给用户带来什么？
其次，不同的行业有不同的流程标准。要根据不同的行业进行case的定制。所以，每个项目的文档都会不同。如果强度较高，就简单举例子好了。不过在设计的时候要注意能够便于修改（低耦合）。
一点建议，仅供参考。

多谢捧场。

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

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

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

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

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

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

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

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

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

不知道楼主究竟是在讲项目过程控制还是用例、用户故事呢？感觉是两回事哟。

UP，XP是方法论，用例，用户故事是需求分析及表达方式。你可以看着两回事，但他们本来就是密切相关的。

主题写的比较杂乱一点而已。抱歉。

为什么？

我的理解是这样的，UP、用例通常搭配使用（UP不是用例驱动的？）。XP、用户故事一般搭配使用（在XP中如果你不用用户故事那用什么手段？）。当然也不一定非的要搭配使用。

从实际的角度来讲，可以逐步引入其各种好的实践。比如首先可以引入迭代，重构，持续集成之类的实践。然后一个一个往上加。这样更容易出效果，也更容易操作。你的意思是说面不宜铺的太大吧。

另外是否可以帮我解答开始的那些疑惑呢？国内目前是个啥状况呢？你是做咨询的，应该了解的信息很丰富吧。

XP和类似的方法对于客户主要是节约时间和成本。但是对于国内的大多数企业和行政单位，做项目主要是为了有额外的项目经费。考虑一下实际情况，我认为XP适用于一些私人的小型企业和个人兴趣。

很多项目确实如你所说，就怕系统不复杂，系统怎么复杂怎么弄。怎么耗时怎么弄。只要能收到钱就OK了。这样的项目我也见过好些了。都说避免浪费。但很多项目确刻意的浪费。呵呵。

实际上我根本无所谓，随便用什么手段都可以管理需求
所谓“管理需求”，实际上你的目标就是要让每个需求可以被讨论、被估计、被跟踪甚至被抛弃

所以你要把需求分解成彼此独立的小块，这样你才能弄清每个需求的价值，再拿着一个需求去讨论先做后做或者不要做，然后你可以估计每个需求的工作量，最后你有办法验收每个需求。

所以我说的就是INVEST。符合这个标准的就是好的需求，不符合就是不好的需求。当你把需求分好块以后，剩下的问题就是在有效传递信息和避免浪费之间找到一个平衡点。至于究竟是一张卡片还是十页纸的文档，那不是问题的关键，只要它是符合当前情况需要的就行。