敏捷开发越来越火热，但在实际应用当中很多时候都是只有敏捷的“形”，却缺少敏捷的“神”，还只是在摸索中。

　　我们在借鉴一种新的模式的时候，最好能够批判性的吸收其精华的部分，不能全部照搬，照搬了反而会出问题。

　　其实敏捷对产品经理的要求是很高的，需要安排至少两个迭代的任务，两个迭代的规划。

　　对程序员的要求也很高，当所有的任务都拆散了之后，最终做出来的东西要形成一个产品，技术人员的整体意识要比较强，且一开始就得熟知产品的整个规划，否则到最后就会出现所有任务都已完结，合并出来的最终产物却是什么都不是。

　　并且敏捷开发不仅仅是IT部门的事情，还需要各个业务部门对敏捷的理解和支持，形成合力，从而提升开发效率和业务满意度。

　　运行一段时间的敏捷之后，发现最容易接受敏捷这种方式的是开发团队，不管是瀑布式还是敏捷，只是做工作的形式不一样了，进度更容易把握了，更能适应需求的变化了，实质其实并没有变化。

　　对测试团队来讲，测试资源调配会更加的紧张，敏捷要求做完一条侧一条，与原先的整体项目排期完全不一样；对产品经理来说，敏捷能让自身更好的掌握整个产品的进度。

　　但需求分析与产品设计阶段的敏捷拆分还是较为头疼的，究竟要不要写文档了，是不是有什么做什么，还是说要规划完整体设计之后才进行拆分？疑问很多，搜集了部分资料，结合敏捷实践的经验，分享如下：

　　一、敏捷开发最少需要维护哪些文档？

　　软件或者系统产品终归是人来维护的，业务知识和技能的传递就成为产品可持续发展的一个重要因素，这就需要有知识性的沉淀，需要有文档的产出。

　　实际情况是大多数人都不喜欢编写文档、也不太喜欢研读文档，因此太多的文档只会消耗团队有限的时间，并不能带来多大的好处；敏捷开发照样重视文档的作用，也重视文档的维护。

　　但文档宜少且精炼，一般情况下建议维护三份文档：

　　《产品需求规格说明书》

　　也即PRD：定义产品应该具有的功能、边界描述等，它作为产品团队之间共同的讨论基础，并在设计和开发过程中不断的更新维护，并记录所有的需求变更；

　　《系统设计说明书》

　　开发人员编写的技术设计，包含数据库E-R图，架构设计等：说明产品如何实现，内部之间是什么关系；

　　《测试用例和测试报告》

　　由测试人员编写：记录所有功能点的测试计划、过程和测试结果；

　　二、敏捷开发是否需要系统设计？

　　前面也提到过，敏捷开发对开发人员来讲实质差异不大，只是以小周期代替大周期。

　　小周期包括：需求、设计、开发、测试、发布，这个过程中的设计环节是指要做产品设计和系统设计；由于做完整的设计需要有相对完整的资料和比较长的时间，与小周期是相对立的。

　　因此敏捷开发不主张高度细化和完整的设计，提倡做出一个大粒度的框架性设计，一般指架构设计或者系统设计，避免在以后的重构中发生架构级别的变化，然后在逐步实现的过程中逐渐深入展开、细化。

　　传统的一些设计方法比如结构化设计、快速原型法都是可以融入敏捷开发过程中加以使用的。