敏捷需求分析

（本文发表于程序员杂志2006年第4期）

在很多人的印象中，敏捷软件开发是种类似黑客行为的过程，是程序员最爱的勾当。不写文档，不作需求分析，没有项目经理，做什么东西完全是程序员自己的行为。所以他们认为这样的过程无法满足真正大型项目和复杂项目的需要，因此在经过考虑后，放弃了敏捷方法。

真的是这样吗？敏捷过程到底是如何做需求分析？用户故事和用例有什么区别？敏捷过程如何去管理需求的？这些是一些想要实践敏捷的人一直在困惑的事情。

我们常常看到书中讲，程序员拿到一个用户故事后，怎么计划，怎么分解，怎么写单元测试，怎么小步前进，怎么持续集成。这是典型的程序员视角。事实上，敏捷方法分为三部分，敏捷项目管理，敏捷需求分析，敏捷软件开发。上述书中提到的完全是敏捷开发中的实践，很多人了解到的敏捷，只是敏捷的三分之一。

在敏捷的团队中，作一个敏捷程序员确实是非常舒服的事情。从程序员的角度来看，只需要选择一张他感兴趣的故事卡片，了解清楚该卡片的需求，开始从功能测试写代码，等通过了所有测试就完工。基本上不需要考虑太多的事情，非常轻松愉快。但程序员向谁去问清楚需求？故事卡片是怎样写出来的呢？让我们来关注开发前发生的事情。

了解敏捷过程的人都知道，Kent Beck在XP过程中提到了现场客户，如果一个敏捷团队能够有现场客户，这当然是最棒的事情。但多数情况下，客户都是很忙碌的，很难全力投入到软件开发过程中。这时候，我们就需要商务分析师这个角色，来充当客户的角色。

我在ThoughtWorks的团队中担任的就是商务分析师这个角色。商务分析师最重要的职责就是与客户交谈，了解和分析需求，将其制作成用户故事并将需求转述给程序员。同时，商务分析师也要代替客户负责功能验收测试。

敏捷思想的核心是人与交流。需求问题实际上是一个交流问题。商务分析师要和客户交流，搞清楚客户到底需要什么，到底为什么需要这些东西。商业价值是商务分析师关注的最终目标。有了目标的指向，就可以不迷失方向。和客户进行交流，最终目的就是挖掘出客户的商业目标。可能大家会经常有这样的经验，客户说，我要这个功能，我想要怎么怎么样。这时候要特别注意，他说的这些东西并不是真正的需求。商务分析师需要详细的问客户为什么，挖掘出他真正的目标。

在这个目标下，商务分析师开始进行需求的分析：我们到底是否真的需要这个需求？有没有更好的解决方案？有没有简单并且低廉的方式？换一种形式是不是也能达到这样的需求？这个需求有多少地方涉及到以前的软件变更？

搞清楚这些事情后，就可以写出用户故事。用户故事的书写遵循一定的原则，一般包括三部分："作为（系统的一个涉众），我想要（做一件事），从而（达到一个商业价值）"。在书写的时候格式比较随意，可以在故事卡背面写上注释或疑问，甚至画上界面原形图。

举一个最常见的用户故事例子，"作为一个普通用户，我希望能够用用户名和密码登录，以便我能享受到个性化的服务"。其中，用户是系统涉众，登录是他想要做的事情，而他的目标是获得个性化的服务。

从这个例子我们可以想象到，这个页面可能存在两个文本框，用于输入用户名和密码，有一个按钮来登录，并且不登录就不能看到个人资料，另外，如果用户输入错误需要提示"登录失败请重试"。这就是可见性，也可以称为可测试性。我们可以根据这样的可见性写出功能测试，从而驱动这个用户故事的开发，这被称为 Acceptance Driven Development。

用户故事的作用有两个，一个是作为进度跟踪的依据，一个是作为与人交谈的备忘录。用户故事卡片并不是很精确的需求，因此不需要把事情描述的非常清楚。将需求的详细分析推迟到实现前夕来完成，这是敏捷需求分析的精华所在。任何提前做好的东西都会导致浪费，敏捷过程提倡足够就好，避免浪费。

不少人对用户故事和用例的区别感到疑惑。用户故事的作用是备忘功能，而不是文档。而用例需要详细的描述其操作步骤，以及每个异常路径，因而起到了文档的作用。用户故事是可见的商业价值，而不是功能描述。每个用户故事的粒度和工作量都相差不多，这和用例有很大的区别。用户故事是小粒度的，可测试的，可见的，并且是有价值的。[注:此处存有争议，请读者辨证阅读，勿断章取义]

ThoughtWorks有个项目组作的是一个网游物品交易平台。该平台是典型的互联网项目，在开工的时候客户对功能需求还不明确，但需要快速推出抢占市场，正是最适合敏捷过程的项目。

在项目伊始，商务分析师和客户做了深入的谈话，了解他的商业构想，他的盈利模式，搞清楚宏观的结构，然后思考并整理获得的结果，花1-2天时间将客户需求大略整理为几十个用户故事。这些用户故事并不完善，不足以做好整个系统。但对于我们开始项目的前一阵，已经足够了。我们可以从这里开始项目。

敏捷方法希望快速交付可用的软件。实现软件的快速交付是通过迭代来完成。在迭代开始前，由一组有经验的开发人员大致评估一下用户故事，标记出不同的难度和风险，并提出问题供商务分析师来获得更详细的信息，商务分析师会和相关涉众去讨论。然后商务分析师将推荐优先级最高的一组用户故事给客户来挑选，客户可以选择这些用户故事，或者指出从他的视角看到的优先级更高的用户故事。这些将成为下一个迭代的内容。

客户看到每个迭代交付的可运行的软件后或者得到用户反馈后，常常会有新的想法冒出来。有些想法是好的，有些想法就属于看到别家网站有这个功能，不假思索的提出的功能。这些不同的需求都需要经过认真的分析，找出哪些是值得我们立即考虑的，哪些是不用急迫的去实现的。

有一次和客户谈话时，他说到希望增加拍卖功能。那么，我们为什么需要拍卖呢？客户说希望让用户拍卖物品以获得最高价格。经过考虑，我们发现，网游物品的实时性和唯一性决定了系统不适合使用拍卖机制。拍卖的时效性无法满足实时交易的要求，因此，用户最终放弃了这个特性。

另一次，客服人员提出增加一个查询用户交易的功能，而此时我们有其他更加重要的功能需要先去考虑，查询用户交易功能可以由技术人员临时通过数据库直接代为查询，因为项目运营初期交易不是很多，暂时还不需要专门的后台功能来支持客服的工作。所以把这个需求卡片一直贴在墙壁上，始终没有排到最高的优先级。

客户一开始也不是很能够接受敏捷需求中强调商业价值和优先级的做法。但经过几个月的磨合，客户也逐渐适应了许多敏捷思想，甚至我在和客户讨论时，偶然提起了后期的某种可能的情况，他们还能够帮我纠正应当考虑目前的情况，为近期的情况作计划。

用户故事的跟踪和管理是由项目经理来进行。每个迭代跟踪卡片的进展，是否已经开始实现？是否已经完成代码开发？是否已经开始功能测试？不同的卡片在迭代前都会评估为不同的大小。我们一般分为大中小三级。等实践过几个迭代后，团队的开发速度基本保持恒定，我们就可以很容易的知道每个迭代能做多少个用户故事，这样就可以安排下一迭代的开发。

每个迭代内分析好恰好足够下一个迭代开发的需求，就是商务分析师每个迭代的主要工作内容。商务分析师的需求分析工作在上一个迭代完成，包括需求的了解，分析，评估和排列优先级。

在每个迭代开始的时候，由商务分析师主持召开迭代计划会议，在会议上向所有的程序员解释这个迭代要完成的用户故事，然后由程序员自由提问，知道他们能够获得足够开始实现该功能的信息。

在程序员完成一个用户故事后，商务分析师还要来代表客户做功能验收测试，查看是否完成了预计的功能，是否有程序员还没有想到的异常情况。如果存在问题需要退回给程序员继续完成。这在一定程度上保证了系统完成的需求不偏离客户的要求。当然，更多的测试还需要QA来完成。

我们的实践充分表明了，敏捷过程并不是没有需求分析，而是把需求分析过程分散到整个开发的过程中，让开发和需求分析并行进行。这就是ThoughtWorks敏捷方法实施成功的秘诀之一。而商务分析师在这个过程中，起到了纽带和桥梁的作用，是一个团队不可缺少的角色。

评论

22 楼 gigix 2007-05-23  

wainwen 写道

冰云能够分享1~2个User Story吗，就算改头换面，对大家的帮助也很大

AS A build monkey
I WOULD LIKE TO see my project turns to red in CruiseControl dashboard
SO THAT I CAN know the latest build status of my project

21 楼 wainwen 2007-05-23  

冰云能够分享1~2个User Story吗，就算改头换面，对大家的帮助也很大
个人感觉，冰云描述的商务分析师，非常关键。懂技术，同时善于理解并提炼用户的真正需求。国内的软件开发，最缺的就是这类人。
商务分析师，又身兼了目前常说的产品经理和项目经理的部分职责
和真正的客户相比，他离信息系统更近
和技术经理相比，他离业务系统更近
在架构设计师、需求分析师、项目经理、技术经理、产品经理等等头衔外，新增一个商务分析师，似乎很有道理

20 楼 nbsp 2007-05-17  

冰云 写道

（本文发表于程序员杂志2006年第4期）

我们的实践充分表明了，敏捷过程并不是没有需求分析，而是把需求分析过程分散到整个开发的过程中，让开发和需求分析并行进行。

弱弱地问一下：敏捷开发是否可以看成是原型法的迭代过程？

19 楼 balaschen 2007-05-15  

另外还有一个疑问是QA测试的依据是什么,用户故事还是其他？仅靠用户故事足够完成验收测试吗

18 楼 balaschen 2007-05-15  

敏捷方法希望快速交付可用的软件。实现软件的快速交付是通过迭代来完成。在迭代开始前，由一组有经验的开发人员大致评估一下用户故事，标记出不同的难度和风险，[b]并提出问题供商务分析师来获得更详细的信息，商务分析师会和相关涉众去讨论[/b]。然后商务分析师将推荐优先级最高的一组用户故事给客户来挑选，客户可以选择这些用户故事，或者指出从他的视角看到的优先级更高的用户故事。这些将成为下一个迭代的内容。

这里有两个疑问，请实践过敏捷的帮忙解惑：
1、“开发人员提出问题供商务分析师来获得更详细的信息，商务分析师会和相关涉众去讨论”，BA和客户进一步讨论沟通后的结果是不是需要以类似需求文档的形式写下来？不可能还是以用户故事的形式书写吧？

2、某一次迭代涉及的多个用户故事要实现的功能，也许需要以某种关系进行协作以完成功能，类似于高层的设计，由谁来完成？总不能程序员挑选完用户故事后，自行协商各个类之间消息接口吧？敏捷设计是如何进行，一直是我实践中比较大的困惑。

17 楼 agile_boy 2006-12-22  

正常逻辑来说，敏捷开发，对基于项目的好像是很自然的事情，不知道大家对于开发一个可扩展的产品级别，有什么好意见没有。
我的感觉，做产品和做项目在好多地方的定位都是有根本差别的

16 楼 lausunyu 2006-12-04  

只不过是在给ThoughtWorks做广告罢了

15 楼 flybart 2006-12-04  

真是精彩文章，思路清晰描述到位。不过我特别对用户故事的构建感兴趣。
XP的书本上说得很多，但实践中应该有很多“想不到”。
是否能举几个例子，说说最佳实践，说说“想不到”的地方。

14 楼 yangzheng 2006-11-21  

写的不错，很有感受。很多理念可以融入到我们的项目管理中。

不过楼主所说的很多东西和我们实际项目操作中有些差别。

1、项目需求的不明确，导致后面很多东西无法确认，比如开发的时间，测试的时间。我们做项目时需要申请资源，包括测试人员、demo设计人员，开发人员等，这些人员不光是我们项目的参与人员，也是其他项目的参与人员，我们在项目开始的时候需要向他们的经理申请他们的资源。所以我们尽量在前期把需求确认的充分些，幸好我们是有一批专职的人员来收集需求，提炼需求，类似于产品经理的角色。我比较认同这句话：“需求分析过程是分散到整个开发的过程中”，实际操作中也是这样的，有些需求只有到了真正做的时候才能发现问题。


我想，还是一句话，适合的就是最好，别人的优点可以借鉴。

13 楼 冰云 2006-11-20  

xiaoyu 写道

xiaoyu 写道

但这个东西好不好估计你的项目大概完成时间? 因为需求一开始并没有清楚. 对于公司要后期调整人员变动, 或者新项目等不明确.

希望在这方面说一下. 谢谢

还有就是如何计算成本问题(大概), 钱怎么样算?

PS> 华丽地转页 ^0^

daquan198163 写道

国内大多数项目都是客户告诉你他有一笔xx万的预算，打算做个东西，然后让你出个方案，这个方案肯定要包括主要功能和工期
这种情况是不容你一点点把软件作出来，然后告诉他这就是我的方案的
不知道TW如何应对这种客户，签的又是什么样的合同？

啊哈，钱如果能按照时间算是最理想的。如果不行，就只好估算一个大概工作量了。谈一个scope不确定但是时间人数确定的合同。

12 楼 冰云 2006-11-20  

robbin 写道

yes，很棒的总结！

我们开发Javaeye2.0的过程也是敏捷需求，我大致相当于商务分析师的角色，jerry和ouspec相当于敏捷开发者的角色，但是我们的流程没有你们那么严格。基本上就是我们三个人用skype随时开会沟通，然后快速制作原型推出，另外调研资深会员的意见，根据反馈情况安排近期计划，然后分解任务用JIRA分配给每个人。

不过刚好今天gigix和我交流到互联网项目的开发，我们都认为，目前的敏捷实践对于互联网项目来说还不够敏捷。

嗯，同感，互联网项目需要更加快的发布速度。这个比较难平衡。项目做了近1年以后，快速发布会变得很难。光发布前的测试就会占用1周的时间。想在1周内发布几乎不可能。

11 楼 daquan198163 2006-11-20  

国内大多数项目都是客户告诉你他有一笔xx万的预算，打算做个东西，然后让你出个方案，这个方案肯定要包括主要功能和工期
这种情况是不容你一点点把软件作出来，然后告诉他这就是我的方案的
不知道TW如何应对这种客户，签的又是什么样的合同？

10 楼 xiaoyu 2006-11-20  

xiaoyu 写道

但这个东西好不好估计你的项目大概完成时间? 因为需求一开始并没有清楚. 对于公司要后期调整人员变动, 或者新项目等不明确.

希望在这方面说一下. 谢谢

还有就是如何计算成本问题(大概), 钱怎么样算?

PS> 华丽地转页 ^0^

9 楼 冰云 2006-11-20  

xiaoyu 写道

但这个东西好不好估计你的项目大概完成时间? 因为需求一开始并没有清楚. 对于公司要后期调整人员变动, 或者新项目等不明确.

希望在这方面说一下. 谢谢

现在的项目，尤其是web需要运营类的，很难定义什么时候是完成。因为项目很快就上线，之后不停的发布新版本。项目一直在不停的做。因此，你不可能估计完成时间，开始时候对后期的需求也不可能完全清楚。可持续的开发才是这类项目的关键。

我们开始的时候计划的整个项目需求大概有50-70个Story，到项目进行了10个月的时候，完成了大约70个Story，但未完成的，或者说新增的需求也是50-70个。从传统项目管理来看，项目才完成一半。。。但项目已经发布了12次，已经开始创造利润。

人员变动，也是很容易的。我们的方法是在项目中到6个月可以交换到别处。developer的roll off比较容易，提前一两周来，和人pair几天就熟悉了，BA的话可能需要1-2个迭代的交接时间。小规模的人员调动基本上不会影响项目的开发速度。新人进来，也会给项目带来新鲜的血液和思路。就像温水煮青蛙，在项目中干的太久了，很容易忽视一些做的不好的地方，新人的新视角对改进过程很有帮助。

8 楼 taowen 2006-11-20  

clamp 写道

一个全职分析师能够对应多少个敏捷程序员而不至于成为瓶颈？

5？8？能到10个吗？

Quantity is not the issue, Quality is the issue. If you have a team of BA who knows nothing about the business, it is useless. We have a part time BA working in the team, but he knows EVERYTHING. We often find him more important than other full time BAs. I have to say most of the time, this BA is and should be provided by the client.

7 楼 冰云 2006-11-20  

clamp 写道

1:16……
到项目后期能脱开吗？如果是延续性项目怎么办呢？

我说的就是在后期。开始的时候还没那么多developers呢，做了近1年半之后是这么多

6 楼 xiaoyu 2006-11-20  

但这个东西好不好估计你的项目大概完成时间? 因为需求一开始并没有清楚. 对于公司要后期调整人员变动, 或者新项目等不明确.

希望在这方面说一下. 谢谢

5 楼 clamp 2006-11-20  

1:16……
到项目后期能脱开吗？如果是延续性项目怎么办呢？

4 楼 冰云 2006-11-19  

clamp 写道

一个全职分析师能够对应多少个敏捷程序员而不至于成为瓶颈？

5？8？能到10个吗？

按说应该可以di，我们上一个项目8个pair我一个BA，基本能应付过来，同时还兼些IM的工作。再多了团队也该分家了。不过我个人比较希望两个BA pair，这样BA才好互相学习。尤其是与客户交流时，如果一个人不太容易在问问题的同时做记录，而且可能存在一时无法立即应付的局面，如果有两个人同时思考就容易了。我们那个项目最多时候3个BA在一个team，相当华丽

3 楼 clamp 2006-11-19  

一个全职分析师能够对应多少个敏捷程序员而不至于成为瓶颈？

5？8？能到10个吗？