|
首次采用敏捷方式进行开发，我想把我们的做法与大家分享下，同时希望大家指出我们的不足和需要改进的地方，让我们的项目进行的更顺利，目前项目已过三分之一，客户比较满意，还算顺利。项目管理者联盟
项目简介：一个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被放在首位也不为奇。talent.mypm.net
我们项目组每天早上开一次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)service.mypm.net
没有持续的反馈，敏捷将无从谈起。customer、accompanier、team以及test result的反馈给我们向用户交付真正需要的系统提供了保证。我们的BA每天和客户沟通，掌握用户真正、迫切需要的功能和需求。由于我们的系统是一周发布一次，所以客户也能在很短的时间内知道完成的新功能，并及时提出改进意见和建议(其实客户的需求也是一直不停地在变的)。项目管理者联盟
4、 勇气(courage)pmp.mypm.net
为了使代码更加清晰、质量更好，对工作代码进行大范围的修改和重构需要勇气，把某些代码彻底抛弃需要勇气，告诉客户无法再添加新功能需要勇气。我和accompanier目前都还有这样的勇气，希望系统越来越大、代码越来越多的时候还有这样的勇气。项目管理者联盟
三、测试驱动开发(TDD)service.mypm.net
关于TDD我们一直在尝试寻找更爽的方法，目前采用的是webwork、spring、hibernate的组合框架，在大脑里无意识的已经存在了三层结构，我觉得采用TDD，这三层结构应该是最后被驱动出来产生的，而不是一开始就定好三层，然后再TDD编码。项目管理者联盟
我们目前是分别对每层进行TDD，还是觉得service层驱动最有成就感，看到green bar 就令人兴奋，action层老是mock来mock去的走流程实在属没啥意思。项目管理者联盟
最近又看到了使用Selenium和C astle进行测试驱动开发 ，本想采纳，但是使用Selenium进行至顶向下的驱动的话通过一个测试所需的时间太长了，我是对green bar有点上瘾了的人，不能忍受那么长时间的red bar，怀疑它会对偶的身心健康造成影响，所以就作罢，还是由底至上的方法使测试通过的实践最短，不知道各位对这样的三层结构是怎么TDD的?项目管理者联盟
Robert C. Martin大叔的TDD三条军规如下：项目管理者联盟
1.除非这能让失败的单元测试通过，否则不允许去编写任何的产品代码。项目管理者联盟
2.只允许编写刚好能够导致失败的单元测试。 (编译失败也属于一种失败)项目管理者联盟
|
