在软件测试中有关敏捷项目基本步骤的介绍

一、根据发布目标分析需求，把需求分析成独立的故事，初步的分析可以是粗略的，随着需求的不断深入刻意对故事进行整合或者切割。

        要注意的是分析出来的需求尽量在发布目标的范围之内，超出发布目标的需求应该尽量避免过深分析。

        所谓的发布目标是确定了这个版本可以让用户满意的条件。

        故事模式：做为（用户角色），我可以（做什么），以便（业务价值）。后面的业务价值在比较简单或者大家都比较明确的时候刻意不需要注明。

        当前团队实践推行方法：

        第一阶段，这个分析工作开始由PM进行收集、整理和分析。

        第二阶段，当大家都为用户故事的方式接受以后，采用需求讨论的方式来明确和分析用户故事。

二、对分析的故事进行相对估计，估计出来的故事点是对用户故事和复杂度的无单位估计值，使用的数值大小本身没有绝对意义，只有相对于其他故事规模的相对意义。

        比如，用户登录这个用户故事的估计值是2，那么做为同等开发规模的用户推出，这个用户故事的估计只也应该是2。

        当前团队实践推行方法：

        第一阶段，这个估计的工作暂时由PM来负责完成，但是由于一个人的估计肯定会有偏差，所以在估计完成之后需要进行调查来进行修正。

        第二阶段，用估计扑克会议来统一的对用户故事进行估计，当主持人拿出一个新的用户故事之后，大家给出自己对这个故事使用扑克打分，然后取出平均值，对差异较大的估计值要给出解释，来消除对用户故事的错误理解。估计扑克会议的实践不超过１个小时。

三、准备产品调查，对用户故事进行功能存在，和功能缺失性的产品调查，然后根据调查结果对用户故事进行划分，划分成3类：基本需求，线性需求，非线性需求。

        此外还有反对的需求、存在疑问的需求、无所谓的需求3种类型的需求，这些需求将根据进一步的发展进行确认。

        当前团队的实践推行办法：

        第一阶段，由PM发出调查问卷在参与到项目的开发团队、测试团队、技术支持团队来进行调查，然后汇总答案根据存在问题和缺失问题的答案，对用户故事进行定性。

        第二阶段，由PM发出调查问卷扩展到相关的用户群体中进行调查，然后汇总答案根据存在问题和缺失问题的答案，对用户故事进行定性。

        四、确定发布规划，首先要确定的是迭代周期的长度，以周为单位，然后估计出每个迭代周期团队的速度。然后可以从用户故事池中选择出合适的用户故事来填充到第一次和第二次的迭代周期中。其余的暂时可以先不用填充，随着每次迭代周期的完成来对发布计划进行更新。最后根据估计的速度和需要开发的故事来确定需要几个迭代周期，并最终有几个迭代周期来确定需要开发的时间周期。发布计划可以以功能来驱动进行，也可以以日期来驱动进行。 

        发布规划的特点，以月做为时间范围，规划对象是用户故事，估计的单位是故事点。

        当前团队的实践推行办法：

        第一阶段，使用1周做为迭代周期，开始时软件测试团队速度使用估计的方式做出简单估计，根据每个周期结束后的团队速度再进行发布计划的调成。迭代周期内用户故事的完成暂时以开发完成做为标准。

        第二阶段，使用2周做为迭代周期，可以使用原有的历史速度做为团队速度，多出的一周时间做为测试修复时间，迭代周期内用户故事的完成以测试完成，完整的功能提交做为标准，并在开发过程中熟练使用单元测试来进行确保功能的完整完成。

        五、确定迭代规划，根据填充到迭代周期内的用户故事来分解成工作任务，工作任务包括设计工作，不同层次的开发工作，调试工作和测试工作等等具体的任务，然后对任务进行估计，这时候估计的单位以理想工作小时做为单位。比如，设计需要两个人小时，开发持久层需要1个人小时，调试持久层需要半个人小时，开发业务层需要2个人小时，调试中间层需要1个小时等。

        然后根据每个故事的人小时和这个迭代周期内参与的人数，以及每个人所能参与的实际有效时间（注意有效时间约为每天6小时，需要考虑到会议，讨论，头脑休息等非理想工作时间）来判断这个迭代周期的填充是否足够，如果不够则再加入一个用户故事，如果超出则移出一个用户故事到下一个迭代周期中。

        迭代规划的特点，以周做为时间范围，规划对象是工作任务，估计的单位是理想小时。

        当前团队的实践推行办法：

        第一阶段，使用速度驱动的方法来进行迭代规划，即确定了本次迭代的速度，然后选择用户故事扩展成任务，对任务进行估计。

        第二阶段，使用承诺驱动的方法来进行迭代规划，即提出一个故事，把故事扩展成任务，对任务进行估计，让小组承诺是否可以完成这个故事，如果可以在迭代周期内完成则加入这个故事，如果不能完成则推迟到下一个迭代走起。

        六、迭代开始，在迭代开始时召开迭代启动会，分配迭代周期内的用户故事和工作任务到个人，每个工作任务必须精确到个人，同一个用户故事的不同工作任务可以根据情况适当分配给不同的人来完成。

当前团队的实践推行办法：

        第一阶段，任务分配给个人，通常一个故事的任务分配给同一个人。

        第二阶段，任务分配给结对，通常一个故事的任务分配给同一个结对。 

        七、迭代进行，每日早对昨日完成的工作任务和问题进行汇报，并且同时计划今天需要完成的工作任务，对于迭代过程中的进度和问题进行及时的观察和调整，要求每个人完成某个任务之后要及时的告知整个小组知道（qq群的方式最为快捷）。

        当前团队的实践推行办法：

        第一阶段，由PM及时地对当日工作进行询问。并负责把遇到的问题跑出来进行解决。

        第二阶段，小组成员主动地对已经完成的任务进行汇报，并及时把自己遇到的问题抛出来。

        八、迭代结束，确认本次迭代完成的用户故事，对于完成一部分的用户故事计算到下一次迭代中。并对本次迭代的过程资产进行总结，形成FAQ方式的文档进行规整。

        同时根据新的需求情况，资源情况，已完成功能的回馈，以及开发中遭遇的不确定性问题，对发布规划和迭代规划作出调整。

        当前团队的实践推行办法：

        第一阶段，使用学习网站，或者博客等方式对经验进行记录。

        第二阶段，使用完善的skills对经验进行记录，可以方便的组织成培训文档，并方便的进行搜索，查找。

        九、迭代测试，为了保证用户功能完整的提交，每个用户故事开发完成之后都要对该用户故事进行测试，然后在针对开发中出现的问题进行修复，以便完整的完成一个用户故事。

        第一阶段：测试迭代周期和开发迭代周期分开。

        每次迭代开始阶段由PM告知开发组需要开发的和修复的的用户故事，同时告知测试组本次迭代需要测试的故事，需要准备的故事，需要复测的故事。

        并在分配任务时，把修复故事的工作规划到本次迭代中来。

        每次开发完成的用户故事点算作本次迭代的速度。

原文转自：http://www.ltesting.net