第一个迭代周期已经完成，因为素材的限制，迭代周期很短，只有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卡片的描述方法也不同，第一
次迭代中我们采用平铺直述的方式描述素材，但这好像不如用例模式的方式书写，这让程序人员有相当
的问题需要询问“在场客户”，在第三次迭代中，将采用用例模式来书写素材。

原文转自：http://www.ltesting.net