迭代尾声

      团队因为Oracle的问题，浪费了整整一天的时间。而这种浪费仍然在继续。
      在项目开发的过程中，风险无处不在。开发没有十拿九稳的事，如果没有丰富的经验，千万不要因为事情简单而忽视它的存在，那是致命的。今天的工作有两个，一是搞定CastleAR与Oracle的结合问题，另外一个为小层剩余油的代码完成测试工作。这两个问题都有可能延续到明天。
      今天周六，处在迭代尾声。回头来看，本次迭代的实现并不理想，这种结果是在意料之内的。因为本周的迭代计划完全基于主观。在项目的初期，不可能直接基于客观的因素制定计划，熟悉的团队和丰富的经验可以增加迭代计划的有效性，但不可能所有的内容都在预料之内。因此，在项目初期的迭代计划非常重要，第一次迭代的速度要尽可能的快，周期尽可能的短。因为除了进行用例初探外，团队开发速度的测试也非常重要。
      回顾本周工作，也是本次迭代的工作，环境配置和需求的进一步细化算是基本完成了，而这种完成需要在下一次迭代里得到检验。检验的结果多数会让我们发现好像浪费了大量的时间，因为真正写代码的时候我们会发现有些需求与实际的设计和编写存在差异性，这很正常。因为需求和设计的过程对实际的环境考虑较少，当实际编码时多数会受限于团队的实施能力以及一些客观因素。因此在需求整理的过程中，有一个重要的任务就是简单实现，尽可能寻找在项目开发过程中的风险加以解决。小层剩余油研究的部分只完成了一个方法，另外两个方法需要推迟到下周。这不是人员的问题，正如我前文所述，项目初期对任务的划分多数是主观基于经验的，尽快的寻找出两个业务价值高实现起来相对简单的任务进行测试。从而计算出团队速度。在这种速度的基础上，提出的迭代才可能更客观。因此，在迭代的初期、中期和后期需要对这种任务的实现不断的评估和调整。第三个任务就是架构的演化，随着需求的不断明朗，以及小层剩余油代码的交付，架构的稚形也随之涌现。明天我们需要对现在的代码进行架构性的重构。那么在第一次迭代我们基本了解了团队的初始速度，从前期的预想来看，不容乐观。这种风险我们在项目前期就应该发现的。比如开发人员不甚了解.Net框架的风险，对于持续集成工具熟悉程度的风险等等。对于教练来说，这是我的失职。

      因此，我们需要对本次迭代出现的问题进行总结，然后基于总结提出下一次迭代计划。这个计划的目标是基于团队的因素尽可能的提供团队的并行开发速度以及迭代工作的有效性。
      我们正处在细节阶段的初期，因此风险的不断涌现是很正常的。这个时候的风险列表要不断的更新。对于风险中的可抗因素和不可抗因素要有清楚的认识。我一直在说项目的目标，从公司的角度是为了赢利。但从项目组的角度则是为了提供能够符合用户需求的软件，这非常重要，到什么时候都不能变。