论文部分内容阅读
摘要：敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，是为了解决项目的复杂性，以最快最科学的方式实现需求的开发方式。敏捷开发强调产品质量，更适合于开发进度不是很紧迫的环境。但是国内的软件项目开发往往更注重于开发周期。该文介绍了一种敏捷方法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重视必要的文档
敏捷开发强调沟通的重要性，强调源代码就是设计，而轻冗余文档，但敏捷开发并不意味着无文档。实际是，源代码清单本身就是软件开发所产生的最终文档。敏捷开发所排斥的是软件设计、研发过程中过多的冗余文档。这里强调的是开发中将需要共享的知识形成文档。尤其是在模块化开发的项目中，每个人对于其他人开发的模块并不熟悉，这时知识的共享就更重要。
3.3持续重构
敏捷开发以重构为基础，时时刻刻处于重构过程中。所以在每个迭代周期必须留出足够的重构时间，这是保证产品质量不会因需求的频繁改动而变差的重要措施。重构不等于重做，它必须是可控的。当项目进行到后期时，重构的范围应尽可能小，必须考虑到重构的风险。重构必须以足够的测试为保障。
4结束语
Scrum是一个框架，不是流程，不能完全照搬。必须通过实践-总结-实践的方式，选择适合自己的方法。敏捷开发强调的是以人为本，这意味着，需要根据开发团队的素质，来选择合适的方法。Scrum给了开发团队足够的发挥空间，只需要遵守基本的敏捷原则，这也是Scrum能广泛应用的原因。
参考文献：
[1]杨帆,徐俊刚.一种改进的Scrum敏捷软件开发方法[J].电子技术,2011(9).
[2]韩鹏.小规模团队的敏捷开发研究[J].软件工程师,2011(7).
关键词：敏捷开发；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重视必要的文档
敏捷开发强调沟通的重要性，强调源代码就是设计，而轻冗余文档，但敏捷开发并不意味着无文档。实际是，源代码清单本身就是软件开发所产生的最终文档。敏捷开发所排斥的是软件设计、研发过程中过多的冗余文档。这里强调的是开发中将需要共享的知识形成文档。尤其是在模块化开发的项目中，每个人对于其他人开发的模块并不熟悉，这时知识的共享就更重要。
3.3持续重构
敏捷开发以重构为基础，时时刻刻处于重构过程中。所以在每个迭代周期必须留出足够的重构时间，这是保证产品质量不会因需求的频繁改动而变差的重要措施。重构不等于重做，它必须是可控的。当项目进行到后期时，重构的范围应尽可能小，必须考虑到重构的风险。重构必须以足够的测试为保障。
4结束语
Scrum是一个框架，不是流程，不能完全照搬。必须通过实践-总结-实践的方式，选择适合自己的方法。敏捷开发强调的是以人为本，这意味着，需要根据开发团队的素质，来选择合适的方法。Scrum给了开发团队足够的发挥空间，只需要遵守基本的敏捷原则，这也是Scrum能广泛应用的原因。
参考文献：
[1]杨帆,徐俊刚.一种改进的Scrum敏捷软件开发方法[J].电子技术,2011(9).
[2]韩鹏.小规模团队的敏捷开发研究[J].软件工程师,2011(7).