【敏捷团队】6.敏捷回顾

        必要的回顾，对于总结和提高，是有好处和帮助的，但是需要明确总结不是批斗大会，更不应该是绩效考核的评判标准，而是一种自我提高的手段。

        多使用一下产品是熟悉产品最快捷的方式，如果对业务有不明确的地方，就先从实际产品的使用入手。

        由于敏捷开发，不提倡繁重的文档，几乎能提供出去的相关文档很少，而且不是很详细的那种，所以这个时候，开发的站会，有必要引入“测试入会”的机制，TDD（测试驱动开发）为主，当开发一个新的功能或者模块的时候，需要测试用例先出来，这里需要产品、测试、UI、研发等多个参与者开会讨论确定，然后研发根据相关测试用例进行编码及单元测试工作，这样有助于代码质量的提高和测试效率的提高。

        如果可以，开发和测试合并成一个统一的部门，一致对外，即产品的好坏，形成一个整体，开发重点跑单元测试，测试则可以重点关注表现层的实现，晨会上可以直接有效沟通需要优先修改的bug，及时互通信息和反馈，做到大问题没有，小问题尽早发现尽早解决。

        按照产品而非职能来划分部门，在行政上属于一个部门，有利于成为一个真正的团队，而非敌对的对立面，在每次例会中，测试多多参与，角色转变，可以直观高效将重要问题的关注点列出来，更利于产品更好形成。

        关于代码重构，由于各种情况，代码应对某些边缘情况容易考虑不全，出现问题，而很多情况这些问题又不是简单修改一下代码就能解决的，这个时候，通常会进行代码重构工作，重构代码如果处理的好，可以让程序增色不少，但是如果处理不好，就容易出现功能性问题，引发更多更大的问题，所以这个时候，需要code review来控制，并且不要过分要求完美，以功能性为提前来进行。

        作为master，要确保目标的达成，团队研发的进度，团队状态的高度可视化，激励创造力，提高团队的水平。

        最后，绩效考核，因为敏捷开发比较注重团队性，所以可以考虑团队绩效取代个人绩效，然后在各个团队中分别对成员的表现进行进一步的考核，以团队作战考核为主。