敏捷开发的落地实践.pdfVIP

敏捷开发的落地实践 敏捷开发是一种面临迅速变化的需求快速开发的能力，非常适合需求变化频繁的产品研发，可以快 速的响应需求的变更并拥抱这种变化。很多人认为敏捷开发只是开发团队走敏捷的模式，这是一个 误区，实行敏捷开发不仅要求开发的敏捷，也要求测试的敏捷，需求分析的敏捷，即整个软件产品 的研发过程都需要敏捷起来，才能真正意义上实现敏捷。敏捷开发模式的介绍已经有很多，大多停 留在理论层面，本文从实践的角度，从需求规划，产品开发，产品测试三个维度，介绍软件产品研 发过程如何走敏捷开发的模式。 产品的敏捷设计 从需求规划，需求分析到需求设计的过程，都可以归类为产品的设计过程，这中间现在有很多细分 ，诸如市场调研、竞品分析、交互设计等，其本质都是都是产品设计，并在最终可以形成一份产出 物《产品需求设计说明书》，以提供给开发和测试人员去实现产品。瀑布型开发模式要求需求必须 先全部梳理清楚，才会投入开发资源，这样的好处是需求完整，可以从整体上把握产品；而敏捷模 式下的产品设计，也需要从整体上规划产品，但会拆分成若干个相互间较为独立的部分，分别实现 ，最后又能整合成为一个完整的产品，这就对产品设计人员提出了更高的要求。 通常情况下，当我们接到一部分产品的需求之后，会按业务优先级来做分析，并将相互关联的需求 放在一起，或者是按优先级高低进行分类，这个过程将需求进行了划分，可以依据这个划分来决定 哪些需求是要先做的，哪些是可以后做的。不过这里有一个问题需要注意，那就是什么样的需求适 合拆分，一般有以下几种类型： 1、各需求功能之间较为独立的适合拆分。一个产品有十个功能点，各个功能点之间相互依赖关系 不强的，松耦合的，就可以每个功能点单独抽取出来做设计； 2、需求功能本身的逻辑遵循某种操作流程的适合拆分。功能的实现是按照一个较为固定的流程一 步一步往下走的，这样可以将每一个步骤单独拆分开来设计； 3、产品上线之后的版本维护适合拆分。上线之后，对一些 BUG 、问题、小需求的缝缝补补，都适 合用敏捷的方式来设计； 4 、产品上线后的新增需求适合拆分。新增需求一般都针对某个功能模块来进行设计，相对来说较 为独立，因此也适合敏捷设计； 拆分后的需求会分别写 PRD ，最后合成一份。敏捷开发模式中把需求都称为 Backlog ，维护 backlog 表就是一个对产品需求进行拆分的过程，拆分完成后再根据迭代计划来设计具体的实现。一般有 名称、优先级、工作量估算、描述、备注信息等几个维度，如下实例： 名称 优先级 工作量估算 描述 备注 （小时） 通常都把 backlog 存放在共享的 Excel 文档里面，以便团队成员都可以随时查看。一般来说这个文档 归产品经理维护，但也并不把其他团队成员排斥在外。开发人员和测试人员常常要查阅这个文档或 者修改工作量估算。需要注意的是，描述 Backlog 的时候只需说明要达到什么结果即可，而不能说 如何去达到。 产品的敏捷开发 需求 Backlog 清单都列出来了之后，开发人员需要根据排定的需求优先级，从需求池当中选出需求 排到当前的迭代中，直到所有需求的估算工作量加起来达到迭代周期的工作量为止，一般会留一小 部分时间来做为缓冲。开发人员集体估算每个需求的工作量并维护到上述的 Backlog 列表中，这些 都是在敏捷的迭代计划会上完成的。通常一个迭代的开始都是通过计划会议来开始的。 接下来是确定 Backlog 是否还需要拆分，即判定是否可以在一个迭代内完成，或者是否可以在一天 内完成，敏捷开发模式可以建立详细的考核机制，每天都跟踪之前一天的任务是否已经完成。开发 人拆分 Backlog 出来的结果就是一条条的 Task ，然后开发人员根据各自的任务来编写《产品系统设 计说明书》，最后汇总。 这里涉及到工时估算的问题，一般的估算方法都是让团队中不同级别的成员对某个 Backlog 进行 估时，并取某个中间值或者团队都可并接受的值为最终的估算工时。一般拆分的依据如下： 1、 每个拆分出来的 Task 都是可单独验证并上线的； 2、 每个拆分出来的 Task 都是可以在单个迭代内完成的； 每日站会可以跟踪需求实现的进度，检查每