Scrum敏捷方法在快速开发中实践及改进.docVIP

Scrum敏捷方法在快速开发中实践及改进摘要：敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，是为了解决项目的复杂性，以最快最科学的方式实现需求的开发方式。敏捷开发强调产品质量，更适合于开发进度不是很紧迫的环境。但是国内的软件项目开发往往更注重于开发周期。该文介绍了一种敏捷方法Scrum，通过在实际项目中的应用经验，针对快速开发环境，做出了一些改进。 关键词：敏捷开发；Scrum；快速开发 中图分类号：TP312文献标识码：A文章编号：1009-3044(2012)21-5168-02 在当前的软件项目开发中，敏捷方法被大量应用。敏捷的优点不断的被发掘。但是什么是真正的敏捷方法也在不断的争论中。敏捷是一个思想，而不是过程。敏捷宣言中只提到了四大主题思想和十二项原则。由此引出的敏捷方法有很多，像极限编程，特征驱动开发，精益开发，水晶开发，动态系统开发方法，Scrum等，其中的Scrum方法在国内应用的最为广泛。 1 Scrum介绍 Scrum不是一个技术或流程，而是一个开发框架。Scrum将开发过程分为多个Sprint周期，每个Sprint代表一个2-4周的开发周期。在项目开始前，将项目分成很多细小的任务。所有开发者一起对这些任务评估。每一项的任务的开发时间取所有人评估的中间值。然后根据任务的优先级分配到不同的Sprint中。每一个Sprint包含完整的设计，开发，测试，发布环节。当一个Sprint的任务不能完成时，必须对剩下的任务重新规划。在Sprint的开发过程中，每天开发团队都应举行一个简短的进度会议（Stand up meet ing）。团队中的每个成员汇报当天的工作进展，以及遇到的问题。 这个会议应该尽可能简短，不能开成问题讨论会。在每个Sprint结束后，需要对这个Sprint进行回顾。主要总结4点：1）什么做的好？2）学到了什么？3）有哪些不足？4）下一次哪些要做的更好？在进行完所有环节后，进入下一个Sprint。 2 Scrum实际应用中的问题 目前，很多公司都采用或正在尝试Scrum方法，Scrum的效果毋庸置疑。但是当敏捷方法在国内一路高歌猛进的同时，也有些不同的声音。有人认为，敏捷开发对开发者的素质要求很高，对产品质量要求很高，但是国内软件开发对开发周期更加关注，敏捷不适合国情。国内一个软件项目定计划时，开发时间总是定的不足，开发者要经常性的加班。在这种情况下，敏捷开发往往会被肢解，裁剪或简化一些保证质量的流程，如code review，unit test。这样违背了敏捷的基本原则，已经不是敏捷方法了。敏捷以持续交付的方式来保证客户的需求被正确实现。笔者认为这是敏捷最重要的部分，也是当前被广泛接受的开发模式。敏捷最重要的是概念，而不是要求你必须尊循它的所有原则。所以可以根据项目的实际情况对开发流程适度调整。笔者以多年的敏捷项目开发经验，对Scrum方法进行了改进，使之更适合于开发周期短的项目。 3 Scrum方法的改进 3.1渐进细化 敏捷开发将一个项目周期拆分成许多个小的迭代周期。每个迭代周期都包括需求，设计，开发，测试，发布所有环节。由于需求的不断变更，这种迭代可能产生重复的，无效的劳动。例如，上个周期完成的一个功能，这个周期中可能被移除。采用逐渐细化的方法可以减少迭代产生的无效劳动。 1）Code Review从大到小 传统的开发模式在设计阶段需要有相对完整的需求和相当长的时间，必须考虑到方方面面。 敏捷开发不主张高度细化和完整的设计，提倡做出一个大粒度的框架性设计，一般指架构设计或者系统设计，避免在以后的重构中发生架构级别的变化，然后在逐步实现的过程中逐渐深入展开、细化。敏捷提倡的是持续重构，所以要做大量的Code Review来保证程序质量。通过实践经验，对Code Review的范围做适当调整。在项目初期的迭代周期中，Code Review主要关注架构设计，模块接口。随着迭代周期的增加，逐渐扩展到业务逻辑，界面行为，具体代码。这种方式可以减少由需求变更带来的影响。 2）测试粒度由粗到细 Scrum推崇测试驱动。然而在实际应用中，能完全做到测试驱动的不多。但是足够的测试用例是产品质量的保障。在初期的迭代周期中，测试用例覆盖在功能的主要测试分支，并不是覆盖所有分支。在后期迭代中（需求基本确定，主要是界面需求确定后），逐渐完善所有的测试分支。这种延后测试，不仅可以减少由需求变动带来的测试用例维护问题，而且增加了Code Review效果。当开发者写测试用例时，相当于再次review代码。这时更容易发现当时未考虑到的问题。 3.2重视必要的文档 敏捷开发强调沟通的重要性，强调源代码就是设计，而轻冗余文档，但敏捷开发并不意味着无文