这次迭代在很早的时候就似乎完成了大部分的工作。但是在最后一天还是相当的忙碌。
修改了许多细小的错误。教训:要把质量标准在一开始就制定清楚,并且定期检查。否则就永远也不会达到这个标准。
用户手册最终没有完成,缺少使用示例。而且对于质量也不很满意。教训:即便是文档也应该设置可衡量的标准,并且划分为不超过3天的小任务。
以上两个问题很大原因是由于这次迭代我的工作量较大。一次大范围的重构使我的主要精力投入在上面,现在还没有完全完成。教训:对于技术领导者而言,最重要的工作是:理解问题,管理交流,管理质量。另外,在重要的交付前进行重大重构是不明智的。再另外,完备的测试可以使你在想要告一段落的时候停止,而不会让改动把你拖入代码的泥潭。再再另外,改动应该首先实现功能,即使采用硬编码或重复代码也在所不惜,在随后的重构中逐步修正结构。可惜的是我采用的另一条路线,使得工作的难度增大。
感觉在前面的开发中积累了相当多的设计问题,因而才需要进行这次重构。目前似乎只要写代码,就会出现结构上的缺陷。还没有找到好的方法保证整体的设计质量保持在一个稳定的水平。感觉开发的问题不是速度不够,相反是太快了。
不过发布还是基本满意的,至少提供了团队内部总结前期工作的契机。也可以正式的获取一次客户的需求。
后面需要进行下一版本的功能定义。考虑采用Cooper的范例用户的概念,并把编写用户档案的工作正式列入任务列表。