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

恩，你说的都是对的。这些是原则，是目标，或者是判断标准。但是更关键在于怎么做，怎么达到这些目标。比如你说把需求分解成彼此独立的小块。让每个需求可以被讨论，被估计，被跟踪甚至被抛弃等等。那怎么进行需求分析或分解呢？用什么方法呢？

我们一般要不采用目前比较好的方法，如用例，用户故事等来进行需求分析或分解。要不自己创造一套方法。你是怎么做的呢？

我个人认为，关键是什么样的项目和项目的大小了。
按照流程分，按照技术模块或系统架构分，按照客户系统功能分，等等。
关键的可以模块化，序列化，便于管理和控制就可以了。

所以我觉得你说的是两个方面。一个项目的需求明确程度，然后又应该选择什么样的开发过程，这个我不太清楚，个人还没有研究到那个领域，我们公司目前只采用一种，就是瀑布模型，在现在每个项目的需求都是半明确的状况下，确实很碍事。一般的项目呢就边设计边编码边确认，CMMI睁只眼闭只眼，只要在检查时文档是齐全的就OK，项目都要发布了客户需求都还没签字（幸好是内部的，没有纷争的可能性），过程很敏捷，但设计和代码就不敢说敏捷了，一个变更就如同雷轰（跟程序员的水平也有关系，他们的鼻子还不太适应太香的代码）。大的重点的项目有CMMI盯得很严，强制监控流程的里程碑，确定需求的人手忙脚乱，设计和编码的人又闲得没事干。
如果是关于需求怎么做的问题，我有一些建议：
1.在需求过来的时候就马上让整个团队参与，召开讨论会，收集设计、实现、测试人员的所有疑问。如果是维护型项目，需要让设计和实现人员马上审核相关的代码，确认在新增/重构/编码中会引起哪些问题，和现有系统有无冲突，在此可行性分析的基础上，再开始需求分析工作。

2.用户事故：弄清楚客户需求的整个来龙去脉，了解事情的原因和动机，就像一个侦探了解案情。在这方面你可以看一下《软件观念革命》中目标导向设计中的章节和《领域驱动设计》的一些案例对话，相信你会有所启发。与客户面对面交谈，让他们从最初的动机说起。我有一个例子：
在转售货物时，我们公司有自己的货物编号，而销售货物的供应商又有自己的货物编号。我们软件中有一个小功能是把供应商ItemCode和我们的ItemCode对应起来方便管理，我们最早的操作方式是输入一些供应商查询条件，查出一批他们的Codes，然后输一个我们的ItemCode，查询出来，mapping之，然后再……mapping之。才上线没两三个月，客户先是要求把所有mapping的数据导出来，后来又要求使用Excel表格一次导入所有的已填写好的数据（需求就是这一句话，外加了一句，只要能一次操作就好）。当时我们很奇怪，在软件上你就点点鼠标就行了，为什么还要制造这么大批数据来导入呢？我就问题了这个客户几个问题：



这个客户给我打了电话，说：



这时我才知道制作一份Excel表格的工作量是软件界面的操作工作量的真子集……马上我就问：



客户说：是啊。这时就基本确认了以前的功能设计比较白痴了。随后我就给他提出对Excel中所有数据我们在导入中需要做数据检查，因为不可避免有人工输入的误差（客户居然有点不能接受人工输入有误差，呵呵），不过最后还是同意了。我们就设计为把所有检查通过的数据导入，检查不通过的数据，新建一份Excel文件保存，以方便客户的下一次修正。

接着我随口问了一个问题：



客户说：



汗，居然这个都差点漏了。我就问：



客户说不是：



由于我们的系统在权限设计上比较丑陋，是跟窗体绑定的，所以我建议做一个新的窗体，客户又同意了。
到这里，这个“故事”基本上就完结了，书面确认后，就定了，我也几乎可以保证按这个方式进行的用户故事，发生需求变更的可能性小于1%。为什么？因为你真正解决了客户所面临的问题，而不是单纯地去实现客户基于自身软件使用知识所提出的改进想法。

3.用例分析。我认为用例的分解是以用户完成一个任务为粒度，任务中所有操作的连贯性和相关性进行的，就是一个上下文技巧。这时需要测试人员参与，请注意在这里不是分解需求，讨论需求，甚至还要抛弃需求，而是分解达成需求所需要的操作即任务，让我们讨论哪些操作是可以被抛弃的，即实现这个目标，哪些任务是可以不让用户做的。在这一步的准则是：完美就是不能再少。

我觉得在整个过程中没有一套必须的框框，有两点是最重要的，谈话中的沟通能力，以及让团队尽可能早和广地参与需求讨论。因为哪怕你一个需求分析员或项目经理在这个阶段做得再细致深入，但项目要经由设计、实现和测试这些阶段才能有产出，那里面的问题是需求人员所无法预知和估算的，需求分析不光是为客户服务，是为整个项目的完成服务的，应当在这个阶段解答每个阶段预计的所有问题。

目前好像既不用用例，也没用故事，只要能弄清楚用户想干啥,为啥要这样干，就行了。
"驱动"这个词，我现在看起来并不是很贴切，好像是在赶着人走似的，"拉动”就要好得多。

恩，我想你的意思主要有3点：
1、沟通的重要性。需求需要充分的沟通，不但的挖掘才能得到真正的需求。用户往往是说不清自己的真实需求的。
2、以用户的视角看待需求。只有代入用户的角色，你才能真正深入的理解用户需求，为用户解决实际的问题。
3、如何有效传递信息。在用户与项目组之间，项目组成员与成员之间。怎么有效并准确的传递信息。每个人的知识体系是不一样的。比如用户熟悉业务领域。项目组熟悉技术领域。需求，设计，编码，测试等等每个角色的人的知识体系都不一样。这就必然造成沟通上的障碍。导致信息传递效率低下甚至产生严重偏差。

对此我深以为然。

看来大家的状况都差不多。很多事情依然主要靠经验及直觉。我还是从火星赶紧回来。老老实实的从小的实践入手吧。

我倒觉得驱动听起来更顺耳，拉动比较别扭。驱动不是对人而是对事。呵呵。

第3点我表达的不是沟通而是参与，就是让大家基于自己的知识体系和角色任务把自己的想法和预计问题提出来，再一一解决，相当于项目开始前，整个团队先谋略一番，而不是个别人拍脑袋决定。

恩，却如你所说，团队成员的充分参与很重要。除了可以整合资源外，还能增强整个团队的归属感，成就感以及凝聚力。一个项目是属于整个团队的，而不是属于某个人的。也不仅仅是属于公司的。

我曾经参与的一个项目中，人员调动十分频繁，有些人今天在这个项目组，明天就去那个项目组了。更别提充分的参与了。屁股都还没坐热呢。这就使得这些人感觉始终处于游离状态。这是我们在管理中应当尽量避免的。

我们一直在用，确切地说我一直在用。因为在不同的公司我都推广需求用用例描述。关键是用例的级别（风筝、鱼、蛤蜊 :-)）要掌握好，关键不是用什么技术或表述方式，而是让客户明白我们大家要做成什么样。

   我刚参与开发完一个系统，总体感觉不是很好，好多业务给本就不了解，在最终测试时问题很多，项目开发人员之间的协调也不好，像些用例、用户故事根本就没见，只有一个以前客户使用的系统，不清楚的就参考以前系统的设计。
   对企业开发项目的流程很怀疑?