作为一名敏捷的团队领导者，你在团队中起着至关重要的作用：你为某个团队开展战略层面的工作，帮助他们达成开发目标。你根据具体情况指导团队交付成果，从而使团队与客户的价值体系协调一致。

　　你的职责可大致分为四类：人员、产品、流程和项目。根据你的具体背景、你的才干和职业道路而定，你不会将每项职责都发挥到极致。此外，随着你的团队进行演变（以及你被调到其他团队），你将会根据具体需求对每一类的职责进行具体调整。

　　人员职责

　　在人员这个类别中的职责主要是让团队成员尽量专心工作。

    避免分心。尽量减少打扰和外部职责，你的团队就能以最佳的状态进行工作。但问题在于，这类打扰和外部职责大多数都有貌似合理的理由。

　　最常见的分心理由就是预料之外的任务。不论是生产支持问题还是某人的紧急要求，团队成员都必须放下手头的工作并转换到不同的环境中。与其计算反复干扰的“平均”次数，不如与团队合作以最大限度地降低干扰的频率或干扰带来的影响。

　　另一种分心则是疏忽，在组织中普遍存在。当团队成员将他们对项目的亲和感和忠诚度投入到别的地方时，他们对项目的敬业度和对团队的参与度就会下降。当职能部门的管理者继续以个人为单位分派任务和掌控进度就会发生这种情况。当明知项目的价值较低但仍继续推进时也会发生这种情况——项目人员会将精力投入到重要性或关注度更高的工作上。你应当决定是要继续为团队而努力，还是叫停项目。

    培养协作意识。来自“命令-控制”式的环境或一度各自为政的团队成员倾向于埋头做自己的事情。如果有人发现自己的进度陷于停滞，他可能不太情愿向别人求助，其他人也不会知道他有这个需求。四处走走，听一听，看一看，你就能注意到这种情况，让团队成员向彼此求助。让人们开口|交谈，鼓励他们合作。

    让人们担起责任。敏捷规划从本质上就是互惠交换的关系。团队以承诺交付特定的成果为条件获得对设计、任务详细安排和工作预算（根据速度进行粗略估算）的控制权。如果团队未能履行承诺，则应当对他们进行问责，并帮助他们学会在下一次的工作中改进。

    支持个人成长和发展。你能很好地看清行动和决策所带来的影响。及时给予反馈，同时尊重反馈对象，以支持团队和个人的成长。与团队的管理者协作，帮助团队成员出色地承担团队义务并实现个人和职业发展。鼓励团队成员彼此进行反馈——教会他们怎么做到这一点。

    获取资源。团队需要各种资源，例如新硬件、外部专业力量的协助、培训，甚至是用于某些会议的食物。代表团队取得这些资金和许可并进行安排。

　　产品职责

　　你的这一类职责主要在于让所有人集中精力开发正确的产品。

    确保商业价值的流动。帮助产品负责人在待开发项列表上安排已经过排序的、有价值的待开发项供团队进行开发。帮助交付团队和项目负责人寻找有效方式共同定义交付订单的内容，从而为项目任务提供支持。你应当确保团队充分考虑到产能因素，确保遵从项目优先安排，并最终确保团队最大限度地提升其交付的价值。

    保持战术执行与战略意图相符。应常常检查所规划的可交付成果是否仍有价值。不断提醒团队具备全局观，因为短周期和较小的事件容易造成团队短视和感到机械式地重复。保留一份项目章程，确保团队一直相信项目章程中所描述的愿景，并控制该章程的参数。如果参数有变动，公开改变的内容，让团队成员知道。

    让利益相关人参与。项目规模越大，在组织内涉及到的范围越广，就可能会有更多的利益相关人。邀请这些利益相关人参加迭代演示，并举行规划会议以了解他们关于产品演变的意见。将项目的变化告知利益相关人。此外，还要对他们的期望进行管理，因为团队很可能无法满足他们所有的要求。

    外部协调。如果其他的软件团队能够为你的团队的解决方案提供一臂之力，让那些团队谈谈计划和共同担心的问题——如果你不主动提起，他们是不会自发地进行这么深入的沟通的。如果项目内容不只局限于软件，你应当成为非软件内容（例如营销、封装和第三方）的接触点。应就日程表和计划进行协调，并对依赖关系进行管理。

　　流程职责

　　至于流程方面的职责，你应当帮助团队使用其流程，根据具体情况对流程进行调整，助其顺利运作。

    承担流程管理工作。团队拥有一定的流程，他们会在完成任务后和其他场合对流程进行检查和调整。遗憾的是，许多团队未对流程给予足够的关注或根本不进行调整（或者干脆不知道如何进行调整）。帮助你的团队成员遵循他们选择的方式，并尊重他们达成的共识。指出他们尚未注意到的问题。引导团队成员继续改进和调整其流程。

    消除阻碍。阻碍（障碍）会妨碍团队的进度或产能，几乎每天都有。不断关注此类情况，你就能够先行对这些问题进行处理。任何团队成员都可以尝试解决这些问题，但在此过程中提供帮助或至少提供引导则是你的责任。消除一个既定的阻碍需要一些时间（尤其是在需要向团队外寻求帮助的情况下），因此记得跟进其进展。

    管理知识、信息源和工件。建立资源库以方便调用。保留需要保持更新的工件（例如计划、风险和问题），将其余的存档。

    追踪进度、趋势和指标。因为你的角色不涉及对解决方案的日常构建或定义，你能观察和分析解决方案所选取的路径。搜集与其相关的信息（尽量避免干扰团队集中精力工作），让人们能够看得到这些信息。提醒团队注意正逐渐显现的风险或趋势。你会其中某些风险或趋势加以缓冲，却又对另一些加以强化。确保仔细进行测量，因为测量结果往往会影响团队的行为。

    提升组织的敏捷性。不论你的团队是组织中的诸多敏捷型团队之一或是唯一的一个，改进组织的敏捷性能够提升团队的成果。在更大的范围内推行敏捷型团队需要有人支持和领导；作为组织内活跃的敏捷型团队实践者，你的参与是这一举措成功的基础。

　　项目职责

　　不论面对的是单一项目还是长期持续的价值交付协议，你还有另一类职责：将团队的工作与组织的需求联系起来。

    建立适合的团队，确保获得项目发起人的支持。你应当建立一个可以交付成果的团队，并能够通过名字认出整个团队的人。别忘了还有项目发起人！没有项目发起人的支持，你的团队要想成功恐怕是凶多吉少。

    正确地开始工作。即使有了正确的团队，有了项目发起人的支持，仅仅填写一张待开发项列表就急忙开展第一次迭代，这种做法是不负责任的。确保项目具备明确的章程，该章程由各方合作制定并经项目发起人签署——即使其中大部分内容是你自己写的。在那之后你才应当规划版本和迭代。

    为预算和预测提供数据。不论是不是敏捷型组织，大多数组织在开展新一轮工作前需要了解工作目标。你可以根据待开发项列表和其他来自产品负责人和团队的信息为他们提供相关数据。

    识别、管理和规避全局风险。团队中的大多数人都会埋头工作，可能没注意到并非迫在眉睫的风险。而你的视野更广，看待问题更客观，能够在风险实际出现前发现。确保整个团队懂得持续不断的风险管理是每个人的事——你只不过恰好是这项工作的领导而已。

    报告所需的信息。不论团队的计划和工件有多透明，这类未经处理的数据很少能对高管的高层决策提供什么帮助。对进度信息进行解释或汇总以回答管理层的提问并形成常态。

    培养与团队中各角色的关系

　　在传统的“命令-控制”式架构的组织模型中，项目主管会告诉团队成员组织希望他们做什么。沟通的形式多是通过你向下传达。相比之下，在敏捷型架构中，你还需要跟组织进行沟通，将团队的需求告诉组织。现在沟通的形式大多是向上传达。你不再只是为组织服务，而主要是为团队服务。

　　你与团队中各个角色之间有何关系？

　　与交付团队的关系：大多数团队成员按根据职能划分的层级结构进行报告，例如开发、质量保证（QA）或架构。你应当引导、激发和支持团队成员对团队而非功能组的忠诚。

　　作为项目主管，你应当引导、支持、鼓励和指导团队成员，而非只是检查他们的工作。你应协助他们为了服务于共同的目标而进行自我组织。这个团队的气氛轻松愉快；那个团队的人却很难管理。你要根据团队成员的看法，帮助他们尽可能快速有效地开展工作。你应当给予他们支持，让他们以更高明的方式工作，并且适应需求的变化，而不是只顾着榨干|他们的工作能力。

　　与产品负责人的关系：正如你向交付团队提供支持一样，你还应当支持产品负责人。许多产品负责人会写出待开发项并排定其优先级——然后时间就用完了。你可以预先将待开发项全部整理一下，为下一个规划周期进行准备。另一个可提供支持的领域就是与团队中全体成员建立并维持联系。去和利益相关人、管理者和顾问委员会沟通；维持互惠交换关系；进行对话以产出有用的工件——这一类和其他类别的支持活动通常需要耗费大量的时间。由于产品负责人需要维护功能路线图，她需要与比她自己更忙碌的人交谈，因此你应当帮助他建立和维护这类联系。而在谈话中究竟会透露什么信息（任何与该领域相关的信息、产品要求、路线图等）往往由产品负责人自己决定。

　　如果产品负责人没有履行其职责，你应该怎么做？产品负责人未能承担起责任是一个非常重大的风险，可能是整个团队成功的最大阻碍。如果产品负责人由于正当的理由遇到了麻烦，你可以挺身而出，帮助这位不称职的产品负责人。也许现在他正焦头烂额，需要更多培训，或暂离工作岗位。但是如果产品负责人不承担其责任，不称职，或不希望承担这一角色——你就不必替他出头。将问题的根源暴露出来，以此让产品负责人承担起责任，因为这个问题在组织内的牵涉更广，仅凭你一己之力是无法解决的。

　　与利益相关人的关系：利益相关人不太可能与团队进行日常互动，他们往往只会直接与两个人沟通：产品负责人，与他谈要求、系统细节和优先级；以及你，其他一切事物的联络人。他们希望你倾听他们担心的问题，邀请他们参加相关会议，告诉他们最新消息。如果产品负责人很忙而利益相关人很多，与他们沟通的担子就会更多地压向你这一边。

　　照料好你的利益相关人。他们大多身居要职，如果他们觉得不受重视，你和你的团队就可能不会有好果子吃。以最大限度地提高交付成果的价值为宗旨，帮助他们管理与团队的互动。以包容、开放和体贴的方式与他们沟通——他们也会相应地投桃报李。

　　与项目发起人的关系：项目发起人（通常是公司或工程部的总裁或部门主管）是重要的利益相关人：他们代表着高管和公司在项目中的利益。他们以公司资金和其他资源为赌注，运行项目，收获组织回报。许多项目有一个或两个发起人。

　　你本人应当结识项目发起人。你早在起草项目章程的时候就会与项目发起人互动。尽管你和项目负责人很有可能是章程的作者，但发起人是唯一的签字人，他们可以轻易变更章程，甚至叫停整个项目。之后，他们会在必要的时候于会议上为项目辩护或为你争取更多时间和资源。

　　你与项目发起人之间的互动与按照传统方式运行的项目中的互动很相似。发起人会问：

    ­­——我们是否能够按预定完成目标？

    ——有哪些风险？

    ——我们能如何增加成功的机会？

    ——还有什么事需要告诉我的吗？

    ——你需要什么？

    ——我能帮你什么忙？

　　与团队成员管理者的关系：大多数实施敏捷式开发的组织都是在现有的架构上叠加敏捷式结构。如果你的组织是按职能划分的层级结构，你的团队成员会来自多个不同的技术职能部门，例如开发、测试和数据库设计。这些团队成员会向多个管理者报告，其中一个也许正好就是你的老板。这些管理者也许与团队联系密切，或者在日常活动中不怎么参与你的团队。

　　你和职能部门的管理者的总体目标都是一样的：让你的组织持续交付价值。你们的策略也应该是一样的：充分发挥相互协作的自组织团队的力量。如果情况确实如此，你和职能部门的管理者之间应该能够建立良好的关系，为你的团队锦上添花。如果情况不是这样，你可能会遭遇敌对关系、部门对抗和公司政治的洗礼，令团队成员垂头丧气。　　

　　原文经许可，摘自Gil Broza分别于2012年1日和2日发表在ProjectsAtWork上的两篇文章The Human Side of Agile和Agile Team Relationships。ProjectsAtWork于2012年登记版权。秦岭 译。

　　Gil Broza是3P Vantage的所有者，著有The Human Side of Agile一书。

　　本中文版由世界经理人（www.ceconline.com）组织翻译并编辑。