敏捷开发 迭代需求

       迭代需求的整理是敏捷开发的第一步，也是敏捷开发很重要的一步，在这一步中我们需要把客户的业务需求按照优先级的顺序，整理成为一个个的迭代。然后把一个个的迭代拆成一个个可验收的故事卡。

       在此需要说说什么是故事卡，故事卡和业务需求之间的关系。故事卡是一个个独立的，可验收的功能，一个业务需求可以拆分为多个故事卡。比如：我们常见的账号管理需求，需要对账号进行增、删，改、查。因为添加、修改、删除、查询都是一个个可单独验收的场景，我们可以把账号管理需求拆分为四个故事卡。因此把需求拆分为故事卡的原则是：

     1.故事卡是可以独立验收的场景

      2.故事卡包含的点数应该尽量小，一般划分为1、3、5个点，如果超过了应该重新拆分该故事卡。给故事卡评点的标准是什么了？我们可以按照一个查询完成的工作量是1个点，然后衡量该故事卡的工作量而适量的评点。

      3. 注意故事卡完成的工作量中包括自我测试和联调的时间。而不是单独的只是开发完成。

        敏捷开发强调成员之间的交互而不强调文档，但这并不意味着不需要文档，需求说明的好坏直接影响着客户价值的交替，我们先来看看下面的一张图：

       

客户      ： 客户高兴的把具有5个价值点的需求交代给需求人员

需求人员： 需求人员由于理解的不同，只从顾客那里接受了3个价值点

程序员   ： 由于需求人员表述的不清晰，最终程序员只理解了1个价值点，并交互给客户

客户      ： 当客户拿到只有1个价值点的产品后，客户哭了！！

因此作为需求人员，当在向程序员解析需求的时候，需要做到以下几点，防止价值点的丢失。

a.  功能点：需求包含了那些功能点

b.  约束条件： 每个功能点有什么约束条件

c.  流程图 ：功能点的业务流程是怎样的

d. 如果有界面的话，需要有页面元素图以及说明。

e. 验收：验收不同于测试用例，主要用来模拟用户的行为以及期望的响应

现在我们就以一个简单的登录界面，来讲讲应该怎样去描叙需求：

功能点：

         1. 用户可输入用户名、密码。可选择自动自动登录、记住密码。响应登录按钮

         2. 当点击登录时： a. 判断用户名、密码是否有为null，有则提示用户。

                                   b. 记录用户名、密码以及记住密码、自动登录的状态

                                   c.  发起登录请求，并响应登录状态。成功则调转到下一个界面，失败则提示用户

         3. 启动登录界面的时候，读取配置文件，访问记住密码和自动登录状态。如果记住密码为true，自动登录为false，则启动登录界面的时候，用户名和密码为上次登录退出时的用户名和密码。如果自动登录为true，则直接执行点击登录的事件。

约束条件：

         1. 用户名必须以字母开头，并且包含字母、数字，长度不小于6位，当焦点切换到密码的时候，自动验证输入的用户名的合法性

         2. 密码以*号隐藏

流程图：

        

界面（低保真--界面元素草图）：

     

验收