首次敏捷项目开发实践

 

首次采用敏捷方式进行开发，我想把我们的做法与大家分享下，同时希望大家指出我们的不足和需要改进的地方，让我们的项目进行的更顺利，目前项目已过三分之一，客户比较满意，还算顺利。

 

项目简介：一个DMS小项目，预计时间14人月.客户需求不是很明确，想一边做一边提，适合引入敏捷开发（实际上用户的需求也一直在变，当他们看到每次的small release时都会有新的想法）。

 

Team主要成员：一个team leader（兼BA职责），两个工程师，一个UI设计师。

成员主要职责：team leader主要负责召开会议，明确每天的开发任务以及项目的总体大概进程，保持团队成员清楚的知道项目目前的状态，保持团队沟通顺畅让团队保持高昂的士气。还有个作用是敢于对项目的成败负责（当然团队每个成员都有责任）。工程师的主要职责是开发，设计师主要职责是UI设计。

 

开发环境配备：硬件：两个PC机两个显示器两套鼠标键盘（工作的时候切换到一个PC机上pair编程，共享一个主机，用转换器使一个主机上面接两个显示器，两套鼠标键盘，这样就不用挤在一个显示器前抢一套鼠标键盘pair了），一个测试服务器，上装svn服务器和cruisecontrol来管理代码和实现定时自动化测试（测试一定要自动化，这样可以让机器来干它喜欢并擅长干的事情，让工程师专注自己的业务；我们使用yahoo的一个模拟熔岩灯来监视测试结果。），一个发布服务器，客户可以远程及时试用后给出反馈意见和建议。

 

开发简介：

一、迭代（Iteration）和发布（ release）计划

由于项目开发人员比较少，我们决定采用最短的迭代周期（一周），每个迭代前由BA评估story需求风险，开发人员评估story技术风险和cost，选出能在本轮迭代周期中完成的任务；每个迭代结束来一次small release

 

二、我们对实现XP价值观所做的努力

1、   沟通（communication）

再怎么强调沟通的重要性都不为过，尤其是在软件行业。所以在XP中communication被放在首位也不为奇。

我们项目组每天早上开一次Standup Meeting，通报彼此昨天做了哪些工作，以便让开发小组所有人了解各自的工作情况，然后确定今天要做的task，目前公司地牌儿还不够辽阔，我们小组还没有足够的地儿挂白板，就把story和task写在Excel表里面；每个星期一的早上（迭代开始前）会有一个IPM（迭代计划会议），主要内容是大概确定本次迭代周期开发需开发的story，工程师评估每个story完成所需的时间开；每个周五下午（迭代结束前）会有一个Retrospective（迭代结束前会议），会议主要内容是对本次迭代做的好的方面以及待改进的地方进行总结；工程师pari编程。

2、   简单（simplicity）

保持代码和设计尽可能简单是系统可扩展性和可维护性的重要保障。关于Simple Design的讨论可见徐X的 Agile 101: Pair Programming & Simple Design  。kent beck用四个条件定义了简单的系统代码：运行所有的测试获得通过、意图明确、没有重复、使用尽可能少的类和方法。我和accompanier也一直在向这个目标努力。

3、   反馈（feedback）

没有持续的反馈，敏捷将无从谈起。customer、accompanier、team以及test result的反馈给我们向用户交付真正需要的系统提供了保证。我们的BA每天和客户沟通，掌握用户真正、迫切需要的功能和需求。由于我们的系统是一周发布一次，所以客户也能在很短的时间内知道完成的新功能，并及时提出改进意见和建议（其实客户的需求也是一直不停地在变的）。

4、   勇气（courage）

为了使代码更加清晰、质量更好，对工作代码进行大范围的修改和重构需要勇气，把某些代码彻底抛弃需要勇气，告诉客户无法再添加新功能需要勇气。我和accompanier目前都还有这样的勇气，希望系统越来越大、代码越来越多的时候还有这样的勇气。

 

三、测试驱动开发（TDD）

关于TDD我们一直在尝试寻找更爽的方法，目前采用的是webwork、spring、hibernate的组合框架，在大脑里无意识的已经存在了三层结构，我觉得采用TDD，这三层结构应该是最后被驱动出来产生的，而不是一开始就定好三层，然后再TDD编码。

我们目前是分别对每层进行TDD，还是觉得service层驱动最有成就感，看到green bar 就令人兴奋，action层老是mock来mock去的走流程实在属没啥意思。

最近又看到了 使用Selenium和Castle进行测试驱动开发 ，本想采纳，但是使用Selenium进行至顶向下的驱动的话通过一个测试所需的时间太长了，我是对 green bar有点上瘾了的人，不能忍受那么长时间的red bar，怀疑它会对偶的身心健康造成影响，所以就作罢，还是由底至上的方法使测试通过的实践最短，不知道各位对这样的三层结构是怎么TDD的？

 

Robert C. Martin大叔的TDD三条军规如下：

1.除非这能让失败的单元测试通过，否则不允许去编写任何的产品代码。

2.只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败）

3.只允许编写刚好能够导致一个失败的单元测试通过的产品代码。

对于任何功能，一定要从编写它的单元测试开始；但是到了原则2，你就不能再为那个单元测试写更多内容。只要一出现该单元测试代码编译失败，或是断言失败，你就必须停下来开始编写产品代码；但是到了原则3，你就只能编写产品代码，直到让测试编译成功或通过断言为准。

 

这三条军规我觉得太经典了，完全做到了才算TDD做到位了。

 

前几个迭代周期我们没有采用TDD,功能代码写了然后写测试，两个月后对系统进行了一次比较大的重构时，所有的测试都通过了，但是发布上去了还是由bug，所以这种干法是不行的，测试不能达到令人满意的覆盖度。TDD完全可以使测试达到令人满意的覆盖度。基本上只要测试通过了，就能确定重构没有对系统造成影响。

 

四、验收测试（acceptance test）/客户测试(customer test)

    验收测试我们是放在最后做的，由BA代客户写验收测试，工程师使用selenium 进行验收测试的实现，我们发现selenium对frame支持的不是很好，有这儿我想到采用至顶向下如： 使用Selenium和Castle进行测试驱动开发 进行TDD的话是最合理的，不知道大家是不是这么做的？

 

五、pair 编程

    pair的好处我就不说了，试过了就知道了。