会员登录
会员注册
客户看到每个迭代交付的可运行的软件后或者得到用户反馈后，常常会有新的想法冒出来。有些想法是好的，有些想法就属于看到别家网站有这个功能，不假思索的提出的功能。这些不同的需求都需要经过认真的分析，找出哪些是值得我们立即考虑的，哪些是不用急迫的去实现的。
有一次和客户谈话时，他说到希望增加拍卖功能。那么，我们为什么需要拍卖呢?客户说希望让用户拍卖物品以获得最高价格。经过考虑，我们发现，网游物品的实时性和唯一性决定了系统不适合使用拍卖机制。拍卖的时效性无法满足实时交易的要求，因此，用户最终放弃了这个特性。
另一次，客服人员提出增加一个查询用户交易的功能，而此时我们有其他更加重要的功能需要先去考虑，查询用户交易功能可以由技术人员临时通过数据库直接代为查询，因为项目运营初期交易不是很多，暂时还不需要专门的后台功能来支持客服的工作。所以把这个需求卡片一直贴在墙壁上，始终没有排到最高的优先级。
客户一开始也不是很能够接受敏捷需求中强调商业价值和优先级的做法。但经过几个月的磨合，客户也逐渐适应了许多敏捷思想，甚至我在和客户讨论时，偶然提起了后期的某种可能的情况，他们还能够帮我纠正应当考虑目前的情况，为近期的情况作计划。
用户故事的跟踪和管理是由项目经理来进行。每个迭代跟踪卡片的进展，是否已经开始实现?是否已经完成代码开发?是否已经开始功能测试?不同的卡片在迭代前都会评估为不同的大小。我们一般分为大中小三级。等实践过几个迭代后，团队的开发速度基本保持恒定，我们就可以很容易的知道每个迭代能做多少个用户故事，这样就可以安排下一迭代的开发。
每个迭代内分析好恰好足够下一个迭代开发的需求，就是商务分析师每个迭代的主要工作内容。商务分析师的需求分析工作在上一个迭代完成，包括需求的了解，分析，评估和排列优先级。
在每个迭代开始的时候，由商务分析师主持召开迭代计划会议，在会议上向所有的程序员解释这个迭代要完成的用户故事，然后由程序员自由提问，知道他们能够获得足够开始实现该功能的信息。
在程序员完成一个用户故事后，商务分析师还要来代表客户做功能验收测试，查看是否完成了预计的功能，是否有程序员还没有想到的异常情况。如果存在问题需要退回给程序员继续完成。这在一定程度上保证了系统完成的需求不偏离客户的要求。当然，更多的测试还需要QA来完成。
我们的实践充分表明了，敏捷过程并不是没有需求分析，而是把需求分析过程分散到整个开发的过程中，让开发和需求分析并行进行。这就是ThoughtWorks敏捷方法实施成功的秘诀之一。而商务分析师在这个过程中，起到了纽带和桥梁的作用，是一个团队不可缺少的角色