拥抱变化 敏捷开发

二弟的一篇介绍 敏捷的文章，希望有机会在 GBS 的系统实施中能够早日用上 敏捷


关于敏捷
2008-08-27 10:02 | (分类:默认分类)
今天写实习总结，描述了一下这几个月的收获。截取其中的一段关于敏捷的感想。

Scrum对于我这样的开发人员来说，让我可以直接参与到整个开发周期的各个阶段。在评估会议时，团队中的每个成员都有权对产品的需求项进行评估，确定需求的工作量大小。在Sprint 计划会议1中，由Product owner对该Sprint中的需求项进行需求描述，明确具体的需求。在Sprint计划会议2中，Scrum master组织团队对既定产品backlog的需求项进行任务划分，将每个任务细化到每天的工作中，确保在Sprint周期中，每个人的任务分工明确。

在Sprint每日的例会中，每个开发人员报告自己的工作进度，并明确下一天的任务，遇到障碍，可以及时找到相应的人员开会解决。在Sprint的评审会议中，对Sprint的完成的任务进行提交演示，并可以增加新的需求项。在Sprint的回顾会议中，确定这个Sprint的成功和失败的经验，及时总结。

我们开发人员在整个Sprint周期中，可以明确需求，并自主地安排工作进度，在技术增长的同时，也增加自己的工程管理的经验，有利于个人职业生涯的发展。Scrum相比于其他的过程模型，更加注重团队个人素质的提高，并且能够快速的应对变化。

TDD也是一种敏捷开发的方法。它的主要思想是通过建立一套可执行的测试用例，保证代码的实现与具体的需求的一致性，以测试用例作为中介，建立一个有序的工作方式：从需求用例中导出测试用例，从测试用例中导出代码的接口和实现。

在我平时的开发过程中，严格的遵守了TDD的指导。拿到一个具体的Use case时，先测试几组测试数据，然后用JUnit建立一个Test case与Use case对应，在Test case中采用Mock对象，先虚拟地对测试方法进行实现，等测试通过之后，再抽取出具体的接口，然后实现。

我觉得TDD的好处是在产品的开发过程中建立了一套可运行的Test case，让需求变得具体，可控。一旦需求发生了变化，可以从Test case 入手，然后再修改实现代码。使需求的变更在代码的级别变得可控。

我还学习了基于Java平台的动态语言Groovy。这是一种敏捷的开发语言，比Java语言具有更高的抽象性，用少量的代码表现更多的功能。

在IBM的收获是让我体验到了“敏捷”无处不在。从敏捷软件过程的Scrum方法，到测试驱动的开发方式，到敏捷的开发语言，整个软件工程的各个方面都有敏捷的出现。我考虑过这个问题，为什么这两年敏捷变得如此的流行。我觉得一个原因是让需求的变更变得可控。软件工程发展了10多年，积累的大量的原始资源，各种平台，中间件林立。客户对软件的需求从最初的简单发展到如今的非常复杂，业务变更非常频繁。过去那种僵硬的，按步就搬的开发方式和管理方式已经不再适应变化。比如采用瀑布模型，开发了几个月客户才看到最终产品，但是最初的需求已经改变地面目全非了。Scrum的好处是它把“变”与“不变”控制地很好，在Sprint进行中Sprint backlog是不应发生改变地，保证了工作的有序。在Sprint的开始和结束之后可以进行需求的变更。由于Sprint的周期长度较短，这种短暂的稳定，可以让团队在正确的道路上持续的前进，而不是全程的变化，找不到正确的道路。

敏捷是软件工程的发展方向，让我们拥抱变化，让生活变得更美好一点。