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

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