五、敏捷开发为何提倡小版本?小版本有哪些优势?
小版本的目的就是分解复杂度、降低风险，改善团队士气等;小版本有众多优势：
1、总体风险比较少：小版本变化小，总是在上一个版本基础上局部调整和增加，技术复杂度低;由于规划的功能较少，工作量也易于估算，所以其总体风险比较少，常常能如期发布;
2、需求的接纳能力强：由于小版本快速实现并发布测试，然后就进入下一个版本的规划实现周期，这样新需求一旦提出就能快速进入开发视野，就能尽快实现;
3、测试和开发高效协作：开发和测试可以并行工作，当开发实现第一个版本时，测试设计测试方案和用例;发布第一个版本后，开发就进入下一个版本轮次，测试就应用测试方案测试刚才发布的版本，提交Bug;开发在下一个版本结束时修正所有上一轮发现的Bug，然后发布新版本，如此循环往复，开发和测试实现高效协作;
六、敏捷开发与重构的关系如何?
敏捷开发以重构为基础，时时刻刻处于重构过程中;
七、敏捷开发为何强调团队人员的参与、用户的参与?
敏捷强调团队成员的高度参与就是要统一认识，把团队的目标变成每个人的工作目标，使之为每个团队成员的认同，形成高度的凝聚力，以达到群策群力、高效协作的效果。
由于没有高度细化的文档，成员之间交换信息的唯一渠道就是面对面沟通，良好的团队氛围和协作关系促进这种沟通，并使消息有效传达。
用户由于缺乏专业训练，无法清晰、准确的表达其意图，导致需求的歧义和模糊;用户的参与使模糊、边界不确定的需求在互动的过程中得到确认和完善;在用户参与过程中，我们常常可以听到这样的话：
“是的，就是这样的”
“这正是我想要的……”
“这里需要修改一下……”
“我的想法是这样的……”
这个过程中，用户承担了一部分测试人员的角色。我们努力做的事情就是实现用户需要的东西，并最终让用户喜欢它，唯有用户喜欢它才能用好它，那么我们怎能不认真听取用户的意见呢?一句话总结就是：用户参与帮助我们做正确的事情!
八、怎么才能评估团队是否已经敏捷了?
由于敏捷开发没有标准的可供参考的实践过程，所以很难通过某个过程而断定其开发过程敏捷了，那么如何来评估团队是敏捷的呢?一般采用的办法是根据团队呈现出来的氛围、项目运作状态、团队成员的感性认识等方面来评估团队和其开发过程是否敏捷，常见评估项目团队是否已经敏捷的方法如下：
• 团队有共同的愿景，并且对这个愿景充满信心;
• 团队有明确的阶段目标并且为每个成员所知晓;
• 团队知晓当前计划：做什么、何时完成、预期效果等;
• 团队任务是低耦合的，并且紧密协作;
发布过程是轻松愉快的，构建版本并不断测试是常态行为之一。
九、敏捷开发能缩短项目时间并提高质量吗?
从我的实践经验来看是可以的，但目前无法提供量化的数据做参考，只能从几个方面评估和推断：
• 用户的参与帮助团队把功能一次性完成并做正确，缩减了返工的时间;
• 不断的重构和测试发布能把问题发现在早期，整体质量显著提高;
• 过程目标导向，使团队高度集中于项目目标，提高了生产力;
• 不断的发布对团队是种正向激励，荣誉感和成功欲使团队保持持续的激情;
以上是一些敏捷开发过程当中的疑问，其实还有很多，目前我这边还只是主推让开发和测试团队敏捷，PD团队还在摸索当中。下次我会分享一下如何在需求这个层面用敏捷的方式来设计，去产出PRD文档。敏捷设计、敏捷开发、敏捷测试连在一起，这样才能最大限度的发挥敏捷的效用。
