ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 在项目中期实践XP--第一次迭代小结

在项目中期实践XP--第一次迭代小结

原创 Linux操作系统 作者:agile_boy 时间:2009-03-31 14:02:31 0 删除 编辑

第一个迭代周期已经完成,因为素材的限制,迭代周期很短,只有1.5Week。目前已经开始第二个迭
代,我从第一个迭代中实施的实践以及从中得到的经验和教训包括:
 
 1、站立式会议
 的确有效果,继续执行。
 2、计划游戏
 我们根据实际的情况,修改了计划游戏选取素材,分配任务和领取任务的流程。但还是碰到了一系列
的问题。 首先就是大家对素材的估计相差较大,因为开发人员对素材的熟悉程度不同,导致对素材的
开发量估计相差较大,其次就是大家对理想工作时间的评估不同,还有一个问题就是因为是结对编程,
如果A和B程序员估计的每周理想工作日都为1.5D,那么结对者是否就是工作效率为3D每周?在讨论之
后,实际将理想工作日的评估改为实际工作日,估计工作效率为3D/实际工作日/每周/每人,因为工作
效率已经考虑了开会,结对等的影响,所以结对团队的工作效率是可以累加的。
 可能你认为这个计算方法很牵强,但既然是Spike,那就不妨一试。在迭代周期完成后,发现第一个迭
代周期中的个人工作效率为3.6D/实际工作日/每周/每人,也就是说,如果2人结对,一周可以完成7.2D
的工作任务。是否很奇怪?这给目前的这个迭代周期的任务安排带来困难。另外一个可能有争议的做法
是,我们采取的是按素材领取任务,而且素材完成期间不更换结对者。
 计划游戏中的将素材划分成Task后再进行估计开发时间这个想法的确不错,将素材拆成Task后再估计
准确率会大大提高。
 3、简单设计
 第一次迭代中,只有一个素材,而且领取素材的程序员对这个素材比较熟悉,因此设计做得很简单。
基本上在专门预留的本子上进行的设计书写,且仅仅写基础的框架和重要的内容。在第一次迭代的总结
上发现,这种方式有几个问题。
 首先就是原本考虑将这些草稿就是计划的想法错误了,因为字迹太过潦草,而且思想很跳跃,留下的
草稿没有办法给其他人了解。
 其次就是如果有测试先行的功能模块,的确可以不需要太多的设计,写测试代码就象写设计一样,但
是如果有功能模块没有写测试代码的话,就需要更详细的设计。
 因此,在第二次迭代中要求简单设计的过程需要写电子文档,同时,如果没有进行测试先行的模块,
设计需要多花些时间以弥补。
 4、结对编程
 结对编程的确增加了效率,一个素材原本估计需要6D实际工作日/单人,在结对的情况下,4D的实际工
作日就完成了,即使算上结对者,好像也只是用了8个工作人日,不过从这一个素材上并不能看出全
部,还需要日后在其他的迭代中反复检查。
 但结对编程的结对要求实在太高了,特别在我们目前的项目中(项目实施到中后期),Bugfix,联
调,电话支持等等,一旦某个程序员中间有其他事情的打扰,结对就经常中断,这样会明显影响结对的
效果。可能PP可能在项目的开发阶段实施比较合适,在中后期实施PD可能更好,我会在后期的迭代中观
察,如果需要,可以用PD代替PP。
 结对编程后其他感受是,程序人员会自觉的经常更换键盘,并大量的讨论;结对编程更容易让开发人
员感到疲劳;结对编程的开发人员最好是互补的,或者水平不要相差过多;对哪些应该结对,哪些不应
该结对开发,还有分歧,例如,在画界面的时候是否需要结对?目前来说认为需要。总的来说,对结
对,结对者还是认为有效果的,但是无法说明有多大的效果。
 至于第一次迭代的结对编程是否真的可以显著提高软件的质量,具体还要等测试完成所提交的报告才
能给出更全面的分析。
 5、测试先行
 第一次迭代中,并没有真正意义上做到测试先行。在所有代码中,测试先行的代码只有100多行,相比
开发代码要少得多。这主要是因为测试需要有大量得数据库操作,所以在第一次迭代中仅完成了非数据
库操作的测试先行代码。在第一次迭代后,已经专门花时间将这些数据库的测试代码单独抽取出来进行
了编写,方便日后的重用,因此真正意义上的测试先行需要在第二次迭代中才能看到效果。
 但是在第一次迭代的代码检查中已经发现了问题,开发人员所些的测试案例和相应的代码没有突出重
点,部分测试案例根本不是主路径或者烟雾测试案例,而是一些第三测试级别的容错性测试。
 6、代码规范
 代码规范做得还算可以,虽然在后来的代码评审中看到一些问题,但是问题不大。
 7、8小时工作制
 因为其他工作可能的影响,在我制订的“XP人的一天”中,每天结对的时间为6.5小时,程序人员是完
全按照其执行的。但下班后他们往往不愿离开,对这个问题上,以他们的意愿为主。
 8、重构
 结对开发人员会比个体开发人员进行更多有意识的重构行为,而且也会在相应的讨论中互相学习,而
且这完全是自发的,非常棒!
 9、持续集成
 目前正在进行持续集成的第一步环境的搭建,也就是自动定时编译发布环境,计划月内完成,等第一
步完成后,再搭建自动单元、黑盒测试的环境。附带说下,CruiseControl这个持续集成工具用起来真
的麻烦,而且主要用于Java的开发环境上。
 10、CRC卡片
 说实话,我不知道如何书写CRC卡片,我所见过不同的文章所描述的CRC卡片的描述方法也不同,第一
次迭代中我们采用平铺直述的方式描述素材,但这好像不如用例模式的方式书写,这让程序人员有相当
的问题需要询问“在场客户”,在第三次迭代中,将采用用例模式来书写素材。

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14639675/viewspace-582354/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-07-01

  • 博文量
    120
  • 访问量
    119269