在项目中期实践XP--第一次迭代小结
添加时间: 2007-4-9 3:49:33 作者: 系统工程师认证参考 阅读次数:33 来源: http://www.d9soft.com
第一个迭代周期已经完成，因为素材的限制，迭代周期很短，只有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卡片的描述方法也不同，第一次迭代中我们采用平铺直述的方式描述素材，但这好像不如用例模式的方式书写，这让程序人员有相当的问题需要询问“在场客户”，在第三次迭代中，将采用用例模式来书写素材。
上一篇文章: 数据库系统工程师上午试卷 下一篇文章: 网站项目工作流程:雅虎是这样运作的