敏捷开发团队管理系列之一：序言与出发点
这是敏捷开发团队管理系列的第二篇。（之一，之二）
之前的各个系列中，已经涉及了很多团队管理相关的内容，比如松结对编程系列中提到过大型团队分拆为微观开发团队的管理，产品管理系列中提到过Product Owner团队的管理，敏捷开发绩效管理系列中提到过“用中医理论管理团队”，敏捷开发般若敏捷系列中提到过借助“无我、无人、无众生”的概念凝聚不同团队的目标于一处，等等。
本系列会专门从团队管理的角度，一方面将曾经提到过的内容加以贯穿，另一方面则会提及之外的一些未提及的内容，比如产品团队与开发团队的互动，测试团队与开发团队的关系与工作方式，等等，以供专门从事团队管理的读者借鉴。
出发点：结果导向敏捷开发团队的外在行为是“结果导向”，而内在支撑则是“团队工作”（TeamWork）。
所谓结果导向，是直指结果，而不拘泥于形式。
可以被拘泥的“形式”各式各样，比如方式、方法、流程、文档、部门、分工、职责……都是形式。这些形式本来是设立来帮助实现更好的结果的，但是如果拘泥于此，则可能起到反作用。
如果仔细审视敏捷宣言中右侧的内容，会发现他们都属于形式，而非结果：
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
这些形式曾经保证了众多早期军工、航天、航空项目的成功，但若在任何行业任何项目??比如敏捷开发出现时的互联网行业??拘泥于此，可能导致失败。
可怕的是，左侧的4条，也是形式而非结果。所以对敏捷宣言的正确理解是：在现今的多数行业中，如果以结果导向为出发点，则左侧的形式胜过右侧的形式。
支撑点：团队工作为什么说团队工作利于结果导向的实现？
有一个兄弟射雁的例子可以说明：三个兄弟看着大雁飞过，一个说要射下来烤着吃，一个说要炖着吃，另外一个则要炒着吃，三人争执不下，大雁都飞走了。
比如有一个Bug，人们不去分析怎样改正怎样预防，而是讨论是谁的责任；比如有一个任务，人们不去分析怎样做快，而是讨论应该谁做；比如有一个变更，人们不去分析变更前后甲乙方是否有利，而是讨论应该哪些部门走怎样的流程；比如有一个产品，人们不去分析怎样做才能成功，而是讨论成功后应该怎样考核……很难直指结果，而陷入部门和个人的纷争之中。
这里倒不是说后者不需要考虑，而是说出发点问题。如果思考问题的第一念头是“我”“我们”“他”“他们”，那么团队协作建立不起来，敏捷开发也做不好。
本系列的内容本系列将涉及几种常见团队的关系问题：产品团队与开发团队，设计团队与编码团队，编码团队与测试团队……以及团队内部的工作方式。
其间会引用几个以往见过的以及现在身在其中的团队的做法，并分析其应用的环境、潜在的风险。
