以下是一套用于思考如何设计一个合理的团队结构的指导原则。每一个指导原则，以向现有团队或者拟议的团队提出一个问题的形式出现，并且这些问题需要迭代地询问。询问现有团队或拟议团队每一个问题后，根据答案改变团队结构；当团队结构改变后，重新再询问，直到对于每一个问题，你都可以回答“是”。
这个结构是否可以突出优势，弥补不足，并帮助团队成员提升积极性？
没有人喜欢呆在一个他们无法发挥自己特长或经常做他们不擅长的事情的团队中。好的团队成员愿意去做任何可以使项目成功的事情，但是这个不能消除我们尽力去找到一个可以突出尽可能多的团队成员优势的团队结构的目标。
这个结构是否可以最小化必须安排到两个项目上的人数，并且可以避免任何一个人为三个项目工作?
企业设计出一个经过很好考虑的良好团队结构，它不会试图做太多并发项目，这样将可以让多任务的程度降低到一个可以接受的水平。如果企业没有试图去进行太多并发的项目，但有超过10-20％的团队成员属于一个以上的团队，那么要考虑新的团队设计方案或推迟一些项目。
这个结构是否可以最大化团队成员相处在一起的时间？
如果有相同的因素，你应该偏向于设计一个让团队成员可以保持长期在一起的结构。团队成员学会很好的协作需要时间，通过尽可能多地让团队呆在一起，逐步偿还这个长期的学习成本。理想情况下，甚至找一个团队结构，让团队在一起的时间比现有项目更长一些。
是否组件团队的使用是受限制的，并且只有在简单适当的情况下使用？大部分的团队应当围绕交付端到端的、可以工作的功能特性来创建。在某些情况下，是可以接受的一个组件团队开发可重用的用户界面组件，提供数据库访问组件，或类似的功能；但这些应该是例外。
只有两个匹萨，你的团队是否够吃？
由于令人信服的小团队具有的生产率和质量优势，对于大多数团队来说，一个好的团队结构设计应该保持团队规模是5至9名成员。
这个结构是否可以最小化团队之间的沟通路径的数量？一个拙劣的团队结构设计将导致团队之间的沟通路径看似无限的。团队会发现，在没有事先与很多其他团队协调的情况下，自己无法完成任何工作。一些团队间的协作总是必须的，但是，如果一个团队想在一个表格上增加一个字段就要和三个其他的团队协调，那么这个沟通成本太高了。
这个结构是否可以鼓励那些不主动沟通的团队之间的沟通？
有些团队会自然地相互沟通。有效的团队结构设计鼓励那些应该沟通但是可能不会主动沟通的团队或个体之间的沟通。事实上，把一个人放到两个团队中可以加强团队之间沟通。如果两团队之间缺乏沟通是一个问题，把一个人的时间拆分给两个团队是简单合理的。
这个结构是否支持对责任制的清晰的理解？为了项目的整体成功，一个设计良好的团队结构会加强项目的共享、全团队的责任制的观念，同时提供其独有责任的明确指标给团队。
团队成员是否有对团队结构的设计提供一些输入？
在你转型到Scrum的早期，这个也许不太可能。团队成员可能没有足够的经验在每个Sprint结束时交付潜在可交付的产品。同样，有些团队成员最初可能非常抵触Scrum，他们不会在团队结构的讨论上给出建设性的贡献。在这种情况下，团队之外的管理者来设计团队的最初结构是可以接受的。即使这样做，他们也应该记住，这个责任最终将交还给团队。
作者:Mike Cohn
