那么，开发团队的最佳规模是多少呢？Scrum提倡，用小规模保持敏捷性，用大规模完成重要的工作，并推荐了“7±2”模式，即5~9人的规模。

问：由于Scrum推荐了5~9人的规模，这让很多团队纠结，这个人数是否包含ScrumMaster和产品负责人？我的团队有10个人，是不是多了？另一个团队只有4个人，是不是太少了？

答：其实不需要纠结这个数字。无论是4个人、9个人还是10个人，这些数字本身并不重要。重要的是，团队能够拥有完成产品增量的所有技能，同时保持高效的协作。有些团队有11个人，如果可以确保高效协作就不必非要减去几个人。有些团队只有4个人，但是足以完成产品增量，也没必要再加人。

某团队有17个人，每天站会需要40分钟，而且站会上经常发现大家信息不对称。比如，A君和B君对项目任务的了解不一致，甚至在A君花了一天时间摸索新环境的搭建，并在站会上告知大家终于搞定环境后，B君却说：“环境我早就搭好了，你怎么又搭了一遍？”

当团队出现这样的情况时，意味着团队出现了信息断层，需要让团队协作更紧凑，可以考虑是否需要拆分成两个团队。

那么，开发团队的最佳规模是多少呢？Scrum提倡，用小规模保持敏捷性，用大规模完成重要的工作，并推荐了“7±2”模式，即5~9人的规模。

问：由于Scrum推荐了5~9人的规模，这让很多团队纠结，这个人数是否包含ScrumMaster和产品负责人？我的团队有10个人，是不是多了？另一个团队只有4个人，是不是太少了？

答：其实不需要纠结这个数字。无论是4个人、9个人还是10个人，这些数字本身并不重要。重要的是，团队能够拥有完成产品增量的所有技能，同时保持高效的协作。有些团队有11个人，如果可以确保高效协作就不必非要减去几个人。有些团队只有4个人，但是足以完成产品增量，也没必要再加人。

某团队有17个人，每天站会需要40分钟，而且站会上经常发现大家信息不对称。比如，A君和B君对项目任务的了解不一致，甚至在A君花了一天时间摸索新环境的搭建，并在站会上告知大家终于搞定环境后，B君却说：“环境我早就搭好了，你怎么又搭了一遍？”

当团队出现这样的情况时，意味着团队出现了信息断层，需要让团队协作更紧凑，可以考虑是否需要拆分成两个团队。