论敏捷开发团队的最佳实践
我在知识星球任职期间，做了一些敏捷开发的实践，现记录一些关键的经验。
周期
一个完整的迭代是 15 天，其中：
- 前 8 天为开发时间。
- 8 - 13 天为测试&灰度时间。
- 13 - 15 天为修复时间。
团队组成
敏捷团队不宜臃肿，10-12人为最佳，一般2个后端、3个终端、1个测试、2个产品、2个数据分析大概这样子。
产品团队确定需求大方向，其他团队辅助需求的制定。数据团队从数据角度提供建议，研发团队从技术角度提供建议，测试团队从测试角度提供建议。
工作模式
需求评审
需求评审放在每期迭代的第13天，要求全员参加，产品团队讲解需求后，其他团队负责从他们自己的角度完善需求，给出工期。此外，还要一起评估需求的重要程度。
为什么要安排在第13天做这件事儿呢？
因为第13天刚刚进入修正日，大家刚从繁忙的开发、测试、上线中喘一口气，有精力去思考需求的合理性。此外，在第13天做需求评审，可以让产品团队有足够的时间去完善需求，避免在开发过程中频繁的改动需求。
确定需求
根据需求的重要程度、工期，确定需求的优先级，然后把需求放到需求池中，等待研发团队拆解任务。
拆解任务
确定需求后，各个部门的研发人员需要根据需求拆解任务，拆解的基本单位是1人/天，这样的拆解方法可以以1天为单位看到任务的进度，更好的把控项目的进展。
子任务的载体可以是 Tower 这种工具，甚至可以是一个Excel表格。
下面是知识星球团队的拆解任务的例子：
项目推进
每日碰头会 每日碰头会是团队成员每天早上的例行会议，主要目的是让团队成员了解团队的工作进展，以及简要的沟通问题，请注意“简要”这两个字，会议时间建议不超过15分钟。
在碰头会上，我们会把 8 天内无法完成的任务标记为黄色，把 13 天内无法完成的任务标记为红色。一般来说，红色的任务会被直接踢出本轮迭代，回到需求池参与到下一轮迭代。
紧急修复
如果是普通的 BUG 放在修正日处理，如果是紧急的 BUG 加塞处理。加塞处理的 BUG 必然会挤占原本的任务，不过这是正常的流程，被挤占的任务从本轮迭代中移除，参与到下一轮迭代即可。
团队风格
- 少开会。
- 开会时确定会议主题，确定必须参会人员，杜绝把话题铺开。
- 明确需求，避免在开发期间改动需求。
- 规范制度，包括 Code Review、上线流程、测试流程。
- 不卷没意义的事儿。
支付宝
微信