一、如何实现小团队逆袭？

大团队的转型路径与小团队的改善路径完全不同。大团队从整体结构入手更加有效，而对小团队来说，由于其掌握资源较少，决策影响小，因此，应该更加关注团队内部的持续改善。

指导思想：目标驱动，从简单问题开始，持续改善。

二、当产品项目进入研发准备期，开发前都需要做哪些准备？

  1. 需求拆分
  2. 架构设计
  3. 需求依赖识别
  4. 工作量估算
  5. 排期

三、很多开发同事都是“新手”，为了让大家能够快速了解系统架构，熟练且正确地使用现成的系统开发框架，从而保证代码质量，减少后期缺陷太多的返工，这时就需要定义每个阶段的“完成”标准。

  1. 待开发 -> 设计：验收条件（或测试用例）必须写完，并经过产品人员、开发人员和测试人员共同评审，没有异议。
  2. 设计 -> 开发：完成设计文档的更新，设计评审完成。
  3. 开发 -> 测试：编写对应的自动化单元测试，确保所有单元测试用例成功通过，完成代码评审。
  4. 测试 -> 完成：全部测试用例都能通过，所有缺陷被修复。

简单描述一下「设计 -> 开发」阶段的工作流程：

  1. 开发人员拿到一个需求后，自己做初步设计。不需要写 Word 文档，只要用笔在白纸上画一画就行。
  2. 开发人员邀相关同事一起到白板前，一边在白板上画，一边给大家讲（一般只需要5分钟左右）。
  3. 大家直接给出反馈和改进建议。
  4. 开发人员根据讨论结果，编写设计文档。
  5. 提交文档，完成设计。

四、随着系统增加的功能越来越多，需要测试的回归内容比项目前期要多。另外，开发完成后，验收出来的缺陷数量也有所增加。团队虽然可以在比较短的时间内修复这些缺陷，但是，团队只有一名测试人员，来不及验证这些被修复的缺陷，怎么办？

  1. 强调开发人员的自测活动，增强测试用例的完备程度。
  2. 在每日站会时，由测试人员评估一下，当天下午4点之前是否能完成测试状态下所有需求的测试验收。如果能够完成，那么一切工作正常进行，如果无法完成，技术组长会指定当天完成需求开发的开发人员不再领取新的需求，而是和测试人员一起工作，协助其进行需求验收工作，直至测试人员评估可以4点以前完成所有需求的验收工作。

这就相当于在“测试”环节，我们限定了最高带宽，一旦超过了测试人员的生产力，那么就停止前面开发环节的生产，扩大“测试”环节的产能。