stand meeting
通过早上的计划会,可以把握项目进度,及时发现技术难点,共同解决。
通过晚上的回顾,可以总结出成功经验,进而推广之,避免重复造轮子。
测试
以前对测试不够重视,经过敏捷的实践,慢慢的体会到了测试的重要性。测试贯穿始终。
单元测试。容易做单元测试的代码,相对来说都好维护一些。在git看到的源码,大多都有专门的test目录。
正如我在微博里所说:
怎样的代码才是方便做单元测试的代码?我们为了写出方便测试的代码,需要怎么做?大概想了下,未必正确:有明确的输入,输出,功能单一,减少依赖 。转一句话:编码前考虑单元测试会时刻考验着代码质量意识,编码后再做就是惶恐的跟随者。不易于测试的代码,可能也会不易于扩展维护
交叉测试。可以突破开发者的局限性,我们知道自己代码的套路,所以设计case时对消极面的覆盖不够。交叉测试可以解决这个问题。
重构
代码总是不够完美,所以要重构。使之越来越趋向于完美。
StoryPoint
把Story分配到最合适的人。以前在分配任务时,总是把任务分配给最熟悉这一块的人,使得视野不够开阔,做的都是重复的工作。当有人临时有事时,却找不到backup顶上。
可以参考熟悉者提出的point,当项目紧急时,将Story份给熟悉者。项目不紧急的时候,可以分配其他提出的Point与熟悉者比较接近的。可以充分拓展每个人的知识面,提高平均技术水平。
持续集成
没写完