在上家公司所在的团队是前端、后端、测试、app同学都在一起的业务团队，团队中大部分研发流程与我们都类似，有些不一样的实践对我们也有参考意义。
1、新人串讲
新人加入项目后，需要做个 presentation，对项目整体做个介绍，听众就是项目组的其他同学。这个形式挺好，让新人上手项目更有目的性，对听众来说也是一种回顾，串讲完后会对新人提问和QA。
这个串讲形式不仅适用于新人，老人接手新项目时也一样会组织串讲。
2、详设评审
前公司的研发流程一月一迭代，在上一迭代的最后1周评审，然后留出1周用来做详细设计，主要是技术上的设计，并且组织详设评审。这个好处不用多说，降低开发风险，测试时也有依据。
3、迭代 master
刚说了一月一迭代，一个完整迭代流程为：需求评审 - 排期 - 详设 - 开发 - 测试 - 发布 - 总结。每个迭代都有一位 master，由项目组同学轮流，不分新人老人。master 要负责组织所有的会议，以及每天的晨会。
master 自己也一样要写代码，虽然这些琐事会占据不少时间，但一年只会轮到一两次，是个不错的培养 ownership 和沟通的机会。
4、迭代总结
前公司里一个迭代里的所有需求都集中发布，这个不太好，但是会多一个迭代总结的环节，是迭代 master 组织的最后一次会。
会议分3部分：1）测试同学汇报 bug 度量数据，各需求 bug 分布，以及每个人的千行代码 bug 数。2）迭代最后的发布问题复盘。3）本次迭代做得好与不好的地方，每个人轮流发言。
参考意义
现公司的前端组织架构上大多是职能团队，1个人要横跨多个业务团队，有些环节实践起来有所取舍，比如大需求也会有详设文档，默认后端充当 master，我们也有业务复盘。前公司在这方面做得还是很不错的，文档化与全员参与，所有的实践都是在强调这几个词：意识、表达、反思。