关于敏捷的一些体会

stand meeting

通过早上的计划会，可以把握项目进度，及时发现技术难点，共同解决。

通过晚上的回顾，可以总结出成功经验，进而推广之，避免重复造轮子。

测试

以前对测试不够重视，经过敏捷的实践，慢慢的体会到了测试的重要性。测试贯穿始终。

单元测试。容易做单元测试的代码，相对来说都好维护一些。在git看到的源码，大多都有专门的test目录。

正如我在微博里所说：

怎样的代码才是方便做单元测试的代码？我们为了写出方便测试的代码，需要怎么做？大概想了下，未必正确：有明确的输入，输出，功能单一，减少依赖 。转一句话：编码前考虑单元测试会时刻考验着代码质量意识，编码后再做就是惶恐的跟随者。不易于测试的代码，可能也会不易于扩展维护

交叉测试。可以突破开发者的局限性，我们知道自己代码的套路，所以设计case时对消极面的覆盖不够。交叉测试可以解决这个问题。

重构

代码总是不够完美，所以要重构。使之越来越趋向于完美。

StoryPoint

把Story分配到最合适的人。以前在分配任务时，总是把任务分配给最熟悉这一块的人，使得视野不够开阔，做的都是重复的工作。当有人临时有事时，却找不到backup顶上。

可以参考熟悉者提出的point，当项目紧急时，将Story份给熟悉者。项目不紧急的时候，可以分配其他提出的Point与熟悉者比较接近的。可以充分拓展每个人的知识面，提高平均技术水平。

持续集成

没写完