敏捷开发的八个实践经验.pdf

- 敏捷开发的八个实践经历 敏捷开发越来越炽热，但在实际应用当中很多时候都是只有敏捷的形〞，却缺 少敏捷的神〞，还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高 的，此外还需要各个业务部门对敏捷的理解和支持，形成合力。以下分享产品工 程里的八个敏捷开发实战经历。 在Scrum：兼顾方案与灵活的敏捷开发一文中，作者最后也提到过，借鉴一种 新的模式的时候，最好能够批判性的吸收其精华的局部，不能全部照搬，照搬了 反而会出问题。 其实敏捷对产品经理的要很高的，需要安排至少两个迭代的任务，两个迭代的规 划。 对程序员的要求也很高，当所有的任务都拆散了之后，最终做出来的东西要形成 一个产品，技术人员的整体意识要比拟强，且一开场就得熟知产品的整个规划 ， 否则到最后就会出现所有任务都已完结，合并出来的最终产物却是什么都不是。 并且敏捷开发不仅仅是 IT 部门的事情，还需要各个业务部门对敏捷的理解和支 持，形成合力，从而提升开发效率和业务满意度。 运行一段时间的敏捷之后，发现最容易承受敏捷这种方式的是开发团队，不管是 瀑布式还是敏捷，只是做工作的形式不一样了，进度更容易把握了，更能适应需 求的变化了，实质其实并没有变化 。 - 对测试团队来讲，测试资源调配会更加的紧，敏捷要求做完一条测一条，与原先 的整体工程排期完全不一样;对产品经理来说，敏捷能让自身更好的掌握整个产 品的进度。 但需求分析与产品设计阶段的敏捷拆分还是较为头疼的，终究要不要写文档了， 是不是有什么做什么，还是说要规划完整体设计之后才进展拆分疑问很多，搜 集了局部资料，结合敏捷实践的经历，分享如下： 一、敏捷开发最少需要维护哪些文档 软件或者系统产品终归是人来维护的，业务知识和技能的传递就成为产品可持续 开展的一个重要因素，这就需要有知识性的沉淀，需要有文档的产出。 实际情况是大多数人都不喜欢编写文档、也不太喜欢研读文档，因此太多的文档 只会消耗团队有限的时间，并不能带来多大的好处 ;敏捷开发照样重视文档的作 用，也重视文档的维护。 但文档宜少且精炼 ，一般情况下建议维护三份文档： 1、产品需求规格说明书 也即 PRD ：定义产品应该具有的功能、边界描述等 ，它作为产品团队之间共同的讨论根底， 并在设计和开发过程中不断的更新维护，并记录所有的需求变更; 2、系统设计说明书 开发人员编写的技术设计，包含数据库 E-R 图，架构设计等 ：说明产品如何实 现 ，部之间是什么关系; - 3、测试用例和测试报告 由测试人员编写：记录所有功能点的测试方案、过程和测试结果; 二、敏捷开发是否需要系统设计 前面也提到过，敏捷开发对开发人员来讲实质差异不大，只是以小周期代替大周 期。 小周期包括：需求、设计、开发、测试、发布，这个过程中的设计环节是指要做 产品设计和系统设计 ;由于做完整的设计需要有相对完整的资料和比拟长的时 间，与小周期是相对立的。 因此敏捷开发不主高度细化和完整的设计，提倡做出一个大粒度的框架性设计， 一般指架构设计或者系统设计，防止在以后的重构中发生架构级别的变化，然后 在逐步实现的过程中逐渐深入展开、细化。 传统的一些设计方法比方构造化设计、快速原型法都是可以融入敏捷开发过程中 加以使用的。 三、敏捷开发是否需要工程方案 敏捷开发只是把整体拆分成许多个体 ，产品的开发实现过程对产品的功能完整 性、稳定性、即时性等都有较高的要求。 它是一种有组织有 目标的行为 ，往往我们都将其作为一个工程来管理 ，这就是讨 论为什么有产品经理的同时还要有工程经理 ，为什么要求产品经理要有工程管理 的能力 ，因此它需要工程方案。 - 但这个方案是一个短程方案，根据未实现的功能情况、前一个版本的反应和组织 目标制定开发方案;唯有这样才能不断的融入新的需求变更; 四、敏捷开发的迭代周期大概多长 敏捷开发的迭代周期没有硬性的规定，结合工程里程碑、目标、功能实现情况、 产品稳定性综合决定，如果产品用户活泼、功能实现难度小、维护复杂度低，建 议以周为周期。 对于规模比拟大、维护复杂度高的产品，考虑以 2 周-6 周为周期发布较为适宜; 频繁的发布会降低用户的期望并提高用户本钱，给用户心理上带来额外的负担： 他会认为产品质量低，质量控制不严谨等 ; 五、敏捷开