敏捷过程如何做需求分析

申请免费试用、咨询电话：400-8352-114

考试大特别推荐：敏捷过程如何做需求分析
　　在很多人的印象中，敏捷软件开发是种类似黑客行为的过程，是程序员最爱的勾当。不写文档，不作需求分析，没有项目经理，做什么东西完全是程序员自己的行为。所以他们认为这样的过程无法满足真正大型项目和复杂项目的需要，因此在经过考虑后，放弃了敏捷方法。
　　真的是这样吗?敏捷过程到底是如何做需求分析?用户故事和用例有什么区别?敏捷过程如何去管理需求的?这些是一些想要实践敏捷的人一直在困惑的事情。
　　我们常常看到书中讲，程序员拿到一个用户故事后，怎么计划，怎么分解，怎么写单元测试，怎么小步前进，怎么持续集成。这是典型的程序员视角。事实上，敏捷方法分为三部分，敏捷项目管理，敏捷需求分析，敏捷软件开发。上述书中提到的完全是敏捷开发中的实践，很多人了解到的敏捷，只是敏捷的三分之一。
　　在敏捷的团队中，作一个敏捷程序员确实是非常舒服的事情。从程序员的角度来看，只需要选择一张他感兴趣的故事卡片，了解清楚该卡片的需求，开始从功能测试写代码，等通过了所有测试就完工。基本上不需要考虑太多的事情，非常轻松愉快。但程序员向谁去问清楚需求?故事卡片是怎样写出来的呢?让我们来关注开发前发生的事情。
　　了解敏捷过程的人都知道，Kent Beck在XP过程中提到了现场客户，如果一个敏捷团队能够有现场客户，这当然是最棒的事情。但多数情况下，客户都是很忙碌的，很难全力投入到软件开发过程中。这时候，我们就需要商务分析师这个角色，来充当客户的角色。
　　我在ThoughtWorks的团队中担任的就是商务分析师这个角色。商务分析师最重要的职责就是与客户交谈，了解和分析需求，将其制作成用户故事并将需求转述给程序员。同时，商务分析师也要代替客户负责功能验收测试。
　　敏捷思想的核心是人与交流。需求问题实际上是一个交流问题。商务分析师要和客户交流，搞清楚客户到底需要什么，到底为什么需要这些东西。商业价值是商务分析师关注的最终目标。有了目标的指向，就可以不迷失方向。和客户进行交流，最终目的就是挖掘出客户的商业目标。可能大家会经常有这样的经验，客户说，我要这个功能，我想要怎么怎么样。这时候要特别注意，他说的这些东西并不是真正的需求。商务分析师需要详细的问客户为什么，挖掘出他真正的目标。
　　在这个目标下，商务分析师开始进行需求的分析：我们到底是否真的需要这个需求?有没有更好的解决方案?有没有简单并且低廉的方式?换一种形式是不是也能达到这样的需求?这个需求有多少地方涉及到以前的软件变更?
　　搞清楚这些事情后，就可以写出用户故事。用户故事的书写遵循一定的原则，一般包括三部分："作为(系统的一个涉众)，我想要(做一件事)，从而(达到一个商业价值)"。在书写的时候格式比较随意，可以在故事卡背面写上注释或疑问，甚至画上界面原形图。
　　举一个最常见的用户故事例子，“作为一个普通用户，我希望能够用用户名和密码登录，以便我能享受到个性化的服务”。其中，用户是系统涉众，登录是他想要做的事情，而他的目标是获得个性化的服务。
　　从这个例子我们可以想象到，这个页面可能存在两个文本框，用于输入用户名和密码，有一个按钮来登录，并且不登录就不能看到个人资料，另外，如果用户输入错误需要提示“登录失败请重试”。这就是可见性，也可以称为可测试性。我们可以根据这样的可见性写出功能测试，从而驱动这个用户故事的开发，这被称为 Acceptance Driven Development。
　　用户故事的作用有两个，一个是作为进度跟踪的依据，一个是作为与人交谈的备忘录。用户故事卡片并不是很精确的需求，因此不需要把事情描述的非常清楚。将需求的详细分析推迟到实现前夕来完成，这是敏捷需求分析的精华所在。任何提前做好的东西都会导致浪费，敏捷过程提倡足够就好，避免浪费。
　　不少人对用户故事和用例的区别感到疑惑。用户故事的作用是备忘功能，而不是文档。而用例需要详细的描述其操作步骤，以及每个异常路径，因而起到了文档的作用。用户故事是可见的商业价值，而不是功能描述。每个用户故事的粒度和工作量都相差不多，这和用例有很大的区别。用户故事是小粒度的，可测试的，可见的，并且是有价值的。
　　ThoughtWorks有个项目组作的是一个网游物品交易平台。该平台是典型的互联网项目，在开工的时候客户对功能需求还不明确，但需要快速推出抢占市场，正是最适合敏捷过程的项目。