敏捷开发有感.doc

主题: 大力提倡敏捷开发 第一次实施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敏捷开发的流行，越来越多的公司采用敏捷开发用于软件产品和应用的开发。笔者的产品开发团队在两年前开始采用敏捷开发方法，一直实践到现在，并取得不错的成果，包括：产品功能更加符合市场和业务人员的需求，开发效率获得提高。本文从实践的角度介绍笔者所在团队的产品敏捷开发过程和作者的敏捷开发体会。 敏捷开发体会 实施敏捷开发近两年来，我对在产品开发中应用敏捷方法有着深刻的体会。首先说下产品背景。我参与的产品是面向行业的产品，在全世界都有客户，有10年历 史，和一百多个基于不同版本的客户，我们的团队完全负责产品的未来发展方向、发布计划、架构、设计、开发进度、测试、客户支持等。在这样一个面向全球的产 品和自主的团队环境中进行敏捷开发体会尤其深刻。 1) 注重概念和架构设计，而轻详细设计 敏捷开发中，注重概念和架构设计，而轻详细设计。这里的概念设计，可以看成是为什么要做这个产品或模块，强调的是产品的路线规划、市场趋势、客户价值、技 术趋势等。架构设计，可以看成从整体上看，概念设计应该用什么方式实现、分几个层次、多少组件、不同层次和组件之间关系是什么。详细设计，则是具体的设计 和做法、API接口等。 一个产品，特别是面向行业的产品，概念设计和架构设计非常重要，需要考虑行业未来的发展方向，产品在市场中横向和纵向的比较，技术的发展方向，和每个模块 的投入和收益的比例等，这样才能尽可能保证产品沿着正确的方向前进。在产品中新增或删除一个模块需要非常谨慎，因为一旦新增模块被客户使用，以后就很难在 产品中去掉这个模块。还需要考虑产品各个版本之间的兼容性，以及客户的升级迁移。所以，在开始正式开发之前，通过概念设计和架构设计，梳理思路是非常必要 的。 以前在做项目时，大多是从技术角度来考虑哪一些功能模块需要做，哪一些功能模块先做，而没有一个系统化的分析方法。造成的结果是有一些功能模块投入很多资源，却并不一定是客户最想要的。 在敏捷开发中，更加注重客户需求。如果对产品进行SWOT分析，就能选出付出最小工作量，但能获得最大价值的模块。 SWOT分析阶段会在概念设计和架构设计之后进行，输入是概念设计和架构设计，输出是模块的重要度和需要的时间。这样按照性价比可以进行排序，选出最能符合市场的模块。