敏捷开发FAQ[转]

敏捷开发与没有规范，没有文档的代码编写者的区别

与某些观点相反，敏捷开发人员并非不按规则或限制编写代码的特立独行者。“牛仔编码”是缺乏规则和管理糟糕的迹象，并且很不专业。如果团队里面存在这样的编写代码的现象，为了客户的利益着想，您应该竭尽全力地改变这种情况。

 

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

但现实中的情况是大多数人不喜欢编写文档、也不太喜欢研读文档，因此太多的文档只会消耗团队有限的时间，并不能带来多大的好处；

一份概要性的高阶的文档是用户和开发团队之间的契约，双方的一致理解有助于沟通和互动；用户只关心他要什么，不关心如何实现，更不关心实现有多难，所以我们不能奢求用户理解我们遇到的技术问题，甚至读懂我们的代码或者注释；

敏捷开发重视文档的作用，也重视文档的维护；它认为文档宜少且精炼，一般情况下建议开发并维护三份文档：

《软件需求规格说明书》或者《产品规格说明书》：定义软件应该具有的功能、边界等，使软件相关的涉众对软件有一致的理解，它作为用户同开发团队之间共同的讨论基础，并在开发过程中不断的更新维护；

《架构设计文档》：软件如何实现，内部之间是什么关系？

《项目管理计划》：计划如何分期实现、测试、发布等；

 

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

     敏捷开发是以小周期代替大周期，小周期包括：需求、设计、开发、测试、发布，这个过程中是包括设计环节的，也就是说需要做系统设计；

     由于做完整的设计需要有相对完整的资料和比较长的时间，与小周期是相对立的，因此敏捷开发不主张高度细化和完整的设计，提倡做出一个大粒度的框架性设计，一般指架构设计或者系统设计或功能模块的概要设计，避免在以后的重构中发生架构级别的变化，然后在逐步实现的过程中逐渐深入展开、细化；

       做到概要设计即可，不用到详细设计。[即可划分模块，类，公共接口]。

       类的实现可以由编码人员直接确定，完成项目后，可以通过后处理工具得到类的实现模型和类关系图。

    传统的一些设计方法比如结构化设计、面向对象分析(OOA)、面向对象设计(OOD)、自顶向下、快速原型法都是可以融入敏捷开发过程中加以使用的；

 

敏捷开发是否需要项目计划？

     商业软件开发需要承担获取利润的责任，因此对产品的功能完整性、稳定性、即时性等都有较高的要求， 它是一种有组织有目标的行为，因此它需要项目计划，但这个计划是一个短程计划，根据未实现的功能情况、前一个版本的反馈和组织目标制定开发计划；唯有这样才能不断的融入新的变更；

       年度规划，月度实现计划。[年度规划一般不可变，月度计划则可以依据实际情况对需求实现进行进度安排]

 

敏捷开发的迭代周期大概多长？

       对于通用小项目而言，可以每月交付一个大的功能版本，每两周交付一个变更或Bug版本。在进行项目开发进度估算时候需要对交付的内容大致有一个规划。

当然也不能频繁的发布，特别是重大Bug的紧急发布，这样会降低用户的期望并提高用户成本，给用户心理上带来额外的负担：他会认为产品质量低，质量控制不严谨等；

 

敏捷开发为何提倡小版本？小版本有哪些优势？

     小版本的目的就是分解复杂度、降低风险，改善团队士气等；小版本有众多优势：

Ⅰ、总体风险比较少：小版本变化小，总是在上一个版本基础上局部调整和增加，技术复杂度低；由于规划的功能较少，工作量也易于估算，所以其总体风险比较少，常常能如期发布；

Ⅱ、需求的接纳能力强：由于小版本快速实现并发布测试，然后就进入下一个版本的规划实现周期，这样新需求一旦提出就能快速进入开发视野，就能尽快实现；

Ⅲ、测试和开发高效协作：开发和测试可以并行工作，当开发实现第一个版本时，测试设计测试方案和用例；发布第一个版本后，开发就进入下一个版本轮次，测试就应用测试方案测试刚才发布的版本，提交Bug；开发在下一个版本结束时修正所有上一轮发现的Bug，然后发布新版本，如此循环往复，开发和测试实现高效协作；

 

敏捷开发与重构的关系如何？

敏捷开发以重构为基础，时时刻刻处于重构过程中；

 

敏捷开发为何强调团队人员的参与、用户的参与？

人是一切关系的主体，是生产力提升的主体；敏捷强调团队成员的高度参与就是要统一认识，把团队的目标变成每个人的工作目标，使之为每个团队成员的认同，形成高度的凝聚力，以达到群策群力、高效协作的效果；

     由于没有高度细化的文档，成员之间交换信息的唯一渠道就是面对面沟通，良好的团队氛围和协作关系促进这种沟通，并使消息准确有效传达；

     用户由于缺乏专业训练，无法清晰、准确的表达其意图，导致需求的歧义和模糊；用户的参与使模糊、边界不确定的需求在互动的过程中得到确认和完善；

     我们努力做的事情就是实现用户需要的东西，并最终让用户喜欢它，唯有用户喜欢它才能用好它，那么我们怎能不认真听取用户的意见呢？

     一句话总结就是：用户参与帮助我们做正确的事情！

 

怎么才能评估我们团队和开发过程已经敏捷了？

     由于敏捷开发没有标准的可供参考的实践过程，所以很难通过某个过程而断定其开发过程敏捷了，那么我们如何来评估我们的团队和开发过程是敏捷的呢？这里采用办法是根据团队呈现出来的氛围、项目运作状态、团队成员的感性认识等方面来评估团队和其开发过程是否敏捷，我们认为评估项目团队和开发过程是否已经敏捷的方法如下：

 

1、团队有共同的愿景，并且对这个愿景充满信心

2、团队有明确的阶段目标并且为每个成员所知晓；

3、团队知晓当前计划：做什么、何时完成、预期效果等

4、团队任务是低耦合的，并且紧密协作；

5、发布过程是轻松愉快的，构建版本并不断测试是常态行为之一；

 

敏捷开发能缩短项目时间并提高质量吗？

     敏捷开发能缩短项目周期并提高整体质量吗？能，但我目前无法提供量化的数据做参考，只能从几个方面评估和推断：敏捷开发是能缩短项目时间并提高质量的；

1、用户的参与帮助团队把功能一次性完成并做正确，缩减了返工的时间；

2、不断的重构和测试发布能把问题发现在早期，整体质量显著提高；

3、过程目标导向，使团队高度集中于项目目标，提高了生产力；

4、不断的发布对团队是种正向激励，荣誉感和成功欲使团队保持持续的激情；

 

敏捷开发与CMMI最大区别：

我觉得CMMI是由大及小的过程，Agile是由小及大的过程。

CMMI是给出所有可能需要考虑的点，让你从中选择你可能需要的

Agile是给出所有必须考虑的点，然后让你再在其上进行扩展

方法无所谓好坏，关键要选对、用对方法，如果只是对于这些书籍上的理论进行讨论，本身就是有缺陷的。