文档介绍：敏捷开发的八个实践经历
敏捷开发越来越炽热，但在实际应用当中很多时候都是只有敏捷的“形〃， 却缺 少敏捷的“神〃，还只是在摸索中。敏捷开发对产品经理 /程序员的要求都是很 高的，此外还需要各个业务部门对敏捷的理解和支持， 形成合力。以下分统设计说明书？
开发人员编写的技术设计，包含数据库E-R图，架构设计等：说明产品如何实现， 部之间是什么关系；
3、？«试用例和测试报告？
由测试人员编写：记录所有功能点的测试方案、过程和测试结果；
二、敏捷开发是否需要系统设计 ？
前面也提到过，敏捷开发对开发人员来讲实质差异不大， 只是以小周期代替大周 期。
小周期包括：需求、设计、开发、测试、发布，这个过程中的设计环节是指要做 产品设计和系统设计；由于做完整的设计需要有相对完整的资料和比拟长的时 间，与小周期是相对立的。
因此敏捷开发不主高度细化和完整的设计，提倡做出一个大粒度的框架性设计，
一般指架构设计或者系统设计，防止在以后的重构中发生架构级别的变化， 然后 在逐步实现的过程中逐渐深入展开、细化。
传统的一些设计方法比方构造化设计、快速原型法都是可以融入敏捷开发过程中 加以使用的。
三、敏捷开发是否需要工程方案 ？
敏捷开发只是把整体拆分成许多个体，产品的开发实现过程对产品的功能完整
性、稳定性、即时性等都有较高的要求。
它是一种有组织有目标的行为，往往我们都将其作为一个工程来管理， 这就是讨 论为什么有产品经理的同时还要有工程经理， 为什么要求产品经理要有工程管理 的能力，因此它需要工程方案。
但这个方案是一个短程方案，根据未实现的功能情况、前一个版本的反应和组织 目标制定开发方案；唯有这样才能不断的融入新的需求变更；
四、敏捷开发的迭代周期大概多长 ？
敏捷开发的迭代周期没有硬性的规定，结合工程里程碑、目标、功能实现情况、
产品稳定性综合决定，如果产品用户活泼、功能实现难度小、维护复杂度低，建
议以周为周期。
对于规模比拟大、维护复杂度高的产品，考虑以 2周-6周为周期发布较为适宜； 频繁的发布会降低用户的期望并提高用户本钱，给用户心理上带来额外的负担： 他会认为产品质量低，质量控制不严谨等；
五、敏捷开发为何提倡小版本？小版本有哪些优势？
小版本的目的就是分解复杂度、降低风险，改善团队士气等 ；小版本有众多优势：
1、总体风险比拟少：小版本变化小，总是在上一个版本根底上局部调整和增加， 技术复杂度低；由于规划的功能较少，工作量也易于估算，所以其总体风险比拟 少，常常能如期发布；
2、需求的接纳能力强：由于小版本快速实现并发布测试，然后就进入下一个版 本的规划实现周期，这样新需求一旦提出就能快速进入开发视野， 就能尽快实现；
3、测试和开发高效协作：开发和测试可以并行工作，当开发实现第一个版本时， 测试设计测试方案和用例；发布第一个版本后，开发就进入下一个版本轮次，测 试就应用测试方案测试刚刚发布的版本，提交Bug；开发在下一个版本完毕时修正 所有上一轮发现的Bug,然后发布新版本，如此循环往复，开发和测试实现高效 协作；
六、敏捷开发为何强调团队人员的参与、用户的参与？
敏捷强调团队成员的高度参与就是要统一认识， 把团队的目标变成每个人的工作 目标，使之为每个团队成员的认同，形成高度的凝聚力，以到