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

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

　　我们常常看到书中讲员拿到个用户故事后如何计划如何分解如何写单元测试如何小步前进如何持续集成这是典型员视角事实上敏捷思路方法分为 3部分敏捷项目管理(project management)敏捷需求分析敏捷软件Software开发上述书中提到完全是敏捷开发中实战很多人了解到敏捷只是敏捷 3分的

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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