敏捷开发方法综述

实施SCRUM，必然会存在不少问题，SCRUM不是解除一切困难的仙丹。是否是先分析一下开发中存在的主要问题，再看看SCRUM可否针对性的解决问题，这样有目的性的实施SCRUM才能体现其优势。  
另外：SCRUM强调的精神在于拥抱变化，而不是强调可以严格的按照计划实施进度，每个SPRINT完结时，都或多或少会存在一些没法按时完成的story，这是正常的，尤为是在第一次实施SCRUM的团队中，这种不许确性，尤为明显。通常来讲，经过3到5个SPRINT，这种状况会有所好转，但不会彻底消失，请记住scrum不是解决进度问题的完美开发方式。SCRUM的精神在于，经过逐步的，渐进的方式，有序的搭建一个系统的一部分，在这一部分稳固，牢靠的基础上再对第二部分，第三部分进行构建，同时在构建的过程当中，不断根据新的状况，对旧的代码进行修订、重构。 
因此，在实施SCRUM的过程当中，首要强调的是质量，不会承诺过多的story，能够要求member，能够不按时完成，可是一旦完成的代码，必须是0 BUG（固然不可能彻底作到，是一个目标）。  
对于BUG问题，SCRUM的一些辅助手段，是否有严格的执行呢？好比，code review, daily build, unit tests. 
我提供我所在团队的一些保证质量的小手段： 1. 每位成员的代码，“必须”通过2到多位成员的审核并取得赞成，方可提交。这种作法比较有争议，短时间来讲，reviewer和reviewee两方面的工做量都会增长，致使表面上的效率降低。可是从长期来讲，通过实践证实，是有利的，大大减小了错误的发生，尤为是一些对系统结构有重大影响的问题，通常都能经过审核发现。而且，这种审核是事前的、零碎的、不间断的，就咱们来讲，通常完成一个task后，而不是一个story，相应的代码提交以前，就会有这种审核。频度最长不超过3天就会有一次。比起某些大块“代码走读”式的审核，更有效率。 
2. 严格执行单元测试。你们都知道须要作单元测试，可是是否定真对待了？是真的想尽办法构建测试案例，仍是应付了事？认真对待单元测试，无单元测试的代码严禁提交。甚至于在条件容许的状况下，实施测试驱动开发。即先有单元测试，后有代码。 
3. 一个良好的每日构建、每日运行工具。这种工具备不少开源的，很是好用。条件容许的状况下，尽可能作到每提交构建，每提交测试。 
随着Agile敏捷开发的流行，愈来愈多的公司采用敏捷开发用于软件产品和应用的开发。笔者的产品开发团队在两年前开始采用敏捷开发方法，一直实践到如今，并取得不错的成果，包括：产品功能更加符合市场和业务人员的需求，开发效率得到提升。本文从实践的角度介绍笔者所在团队的产品敏捷开发过程和做者的敏捷开发体会。 

 1) 注重概念和架构设计，而轻详细设计       敏捷开发中，注重概念和架构设计，而轻详细设计。这里的概念设计，能够当作是为何要作这个产品或模块，强调的是产品的路线规划、市场趋势、客户价值、技 术趋势等。架构设计，能够当作从总体上看，概念设计应该用什么方式实现、分几个层次、多少组件、不一样层次和组件之间关系是什么。详细设计，则是具体的设计 和作法、API接口等。       一个产品，特别是面向行业的产品，概念设计和架构设计很是重要，须要考虑行业将来的发展方向，产品在市场中横向和纵向的比较，技术的发展方向，和每一个模块 的投入和收益的比例等，这样才能尽量保证产品沿着正确的方向前进。在产品中新增或删除一个模块须要很是谨慎，由于一旦新增模块被客户使用，之后就很难在 产品中去掉这个模块。还须要考虑产品各个版本之间的兼容性，以及客户的升级迁移。因此，在开始正式开发以前，经过概念设计和架构设计，梳理思路是很是必要 的。       之前在作项目时，大可能是从技术角度来考虑哪一些功能模块须要作，哪一些功能模块先作，而没有一个系统化的分析方法。形成的结果是有一些功能模块投入不少资源，却并不必定是客户最想要的。       

2）在敏捷开发中，更加注重客户需求。若是对产品进行SWOT分析，就能选出付出最小工做量，但能得到最大价值的模块。       SWOT分析阶段会在概念设计和架构设计以后进行，输入是概念设计和架构设计，输出是模块的重要度和须要的时间。这样按照性价比能够进行排序，选出最能符合市场的模块。       一款产品哪一个模块重要，哪一个先作，须要花多少资源和时间投入，花这么多时间和资源的模块是否在客户心中有相应的重要程度等，这些都是由这款产品的市场策略来决定。全部产品都是为了市场和赢利为目的，Agile方法更好地帮助企业实现了这一点。      

 3) 业务和客户驱动，而非技术驱动       这点说是体会，也能够说是教训。在咱们的产品开发过程当中，在某一新版本中从新设计了老版本的某一个重要模块，而引起了几个问题：一是，新版本的模块和老版 本模块的兼容性问题，致使老版本客户没法平滑的迁移到新版本；二是，新版本的改进是纯技术方面的从新实现，无论对客户而言，仍是对内部的架构而言，都没有 明显好处；最后致使的结果是咱们花了不少资源和人力去从新实现，可是在最后因为种种考虑仍是废弃了从新实现的模块，依然沿用老模块。       在产品的敏捷开发中，虽然说拥抱变化，但不盲目变化。产品的改动须要通过概念设计、架构设计以及SWOT分析后，三思然后行。敏捷开发中也强调"在整个项目开发期间，业务人员和开发人员必须每天都在一块儿工做"，确保技术人员可以开发出客户须要的产品。       

4) 时刻考虑版本兼容性       敏捷开发，废除了过多冗余的文档和繁杂的设计，强调拥抱变化。但做为产品，敏捷开发不意味着盲目地去变化。       当设计变更、API接口重构、配置文件变动时，要时刻考虑产品的架构、规划路线图，老版本的兼容性，及迁移平滑性。不然，随着版本的增多，必将面对着大量的维护工做。       

5) 轻文档，但非无文档       敏捷开发强调沟通的重要性，而轻冗余文档。但敏捷开发并不意味着无文档。在敏捷开发过程当中，适量的文档仍是颇有帮助，有助于整理思路，加快沟通和讨论。       咱们产品中的文档包括：概念设计文档、架构图、当前版本要实现的功能列表，以及SWOT分析。       这些文档在每一个产品版本开始以前会有产生，在每一个迭代的过程当中根据业务人员和市场的反馈也会有一些变动。经过咱们实践证实，这对产品的思路、沟通讨论都很是有帮助。       并且这些文档，大可能是几页PPT，书写和维护工做都很小。   敏捷开发过程       敏捷开发改进了产品的开发流程，提升了整个团队的效率。下面分析敏捷开发前和敏捷开发后的产品开发的各个阶段。