| 编辑推荐: |
| 本文来自于infoq，你的领导（团队内的领导或者团队外的）越是尊重人，你的团队就越容易创造成功的敏捷项目是文章的重点。 |
|
快速了解重点
团队中每个人无论是什么角色，都要有主人翁意识，来服务整个团队
敏捷项目必需的是项目管理，而不是项目经理
领导者需要帮助团队不断学习；不是教他们如何做，而是指导和鼓励他们去不断探索
领导者需要保护团队的学习和产出不受外界因素的干扰
随时随地尊敬他人
组织中新来了一个团队 A。他们之前或多或少都在敏捷团队中工作并且成功过，但是他们对于这里来说是新来的人。管理层给这个团队指派了几个领导：一个敏捷教练负责帮助他们的项目，一个项目经理来汇报管理进度和状态，一个技术教练来帮助他们的团队学习如何使用
TDD（test-driven development，测试驱动开发，译者注） 和 BDD（Behavior-driven
development，行为驱动开发），以及一个人际教练来帮助团队学习互相沟通技巧。
这种情况大概持续了一周。一般来说，这个时间段应当能对前来帮助你的人做出一个合理的判断，他们究竟是否真的帮到你们了。这个团队反馈他们接触到的都是些微管理，而团队更像了解宏观层面上，他们团队究竟需要什么样的领导者。但是可以明确的是他们不需要微管理，并且他们也不需要那些被领导们强加的所谓的帮助。
这是我们 “敏捷项目实践” 这个系列的第四篇文章。这篇文章中介绍了你的团队可能缺乏的领导方式，以及什么情况下会需要这些方式。
团队领导应当是团队的服务者
Team A 的领导存在的问题之一是没有做到真正的服务团队。管理者简单地认为敏捷团队就需要这几种角色的领导来帮助团队走向成功。
很明显，管理者并没有真正理解敏捷为何物，也没有敏捷相关的经验。管理者想当然地认为团队仍然会向之前一样的产出，甚至包括像甘特图那类对于敏捷来说没有人任何意义的东西。
团队在他们的敏捷迭代过程确实存在问题：他们的故事规模太大了；他们没有按照预定计划完成故事；测试人员很晚才参与到他们的迭代过程当中。他们需要些时间来理解团队正在经历着什么，并且需要管理层离远点。他们觉得所需的是敏捷项目经理，是的，“敏捷项目经理”，他们故意用的这个术语。
团队中一个高级开发者 Danny 这样说：“我们的管理者认为项目经理会帮助一个团队走向成功。但是从我们团队成员角度出发，我们可能要优先考虑敏捷方面的因素，而不是项目经理的管理。我们需要一个能帮我们从不同角度来观察并分析我们团队现状的人。当我们开始着手物色相应的人选时，我们需要：一个能帮我们可视化我们的项目进展，并给与正向反馈的人；一个能帮我们解决项目过程遇到障碍的人；一个能帮我们收集数据，并在管理会议上进行展示分析的人。
团队成员通过开发经理向 HR 提出了招聘需求，并给出了对应的职位描述。团队成员坚持自己完成对候选人的面试，这样能够保证他们可以发现真正适合这些职位的候选人。
当前团队的规模，在敏捷化迁移的过程中属于中等水平。因此很多人改变了其原有的头衔和工作方式。研发经理不是一名敏捷专家，但是他对整个组织的运作方式了如指掌。他帮助团队找到了一位合适的人选
Jenny，来帮助团队更好的完成敏捷模式的转变。Jenny 拥有多年的敏捷项目经验，在工作流和迭代上都很擅长。所以她是这个角色的理想人选。
Kent Keith 列举了作为一个服务型领导应当具备的 7 个要素
擅长自我反省
善于倾听
能够服务于下属（Keith 称之为 “角色倒置”）
善于帮助别人成长
善于指导别人，但不是控制别人
能够调动别人的热情和积极性
能帮助别人互相产生良好的化学反应，而不是互相排斥
团队 A 需要的正是一名服务型的领导者来帮助他们学习并适应敏捷方式的开发流程，同时统计相关的基础数据。他们期待
Jenny 能帮他们做到这一点。
Jenny 决定首先帮助他们建立可回溯的项目开发方式。在制定执行计划期间，她要求团队选择出三个在下个迭代周期内需要完成的事情，而且只能是三个。团队最终决定如下：
创建一个能真实反应他们项目进度的看板，来替代之前人们想当然的项目进度。（更多细节参考 Customize
Your Agile Approach: Select Your Agile Approach That
Fits Your Context）。
他们需要好好算一算，看看能否在接下来的两周完成（真正的完成）4个故事。（参考 Customize Your
Agile Approach: Start with Results You Want ）
统计每个故事真正花费的时间。（参考 Customize Your Agile Approach: What
Do You Need for Estimation?）
团队决定先花两周的时间做个实验，这样他们不用在开始阶段就完全替代之前的工作方式。Jenny 表示赞同。与此同时，Jenny
更关心的是一次改变三种习惯会不会过多？
第一周，团队修改了项目进度看盘的状态，从三个（ 准备开始（Ready），进行中（In Progress），已完成（Done））变为了五个（
准备开始（Ready），开发中（In Dev），等待测试（Waiting for Test)，测试中（In
Test）， 已完成（Done））。这样能帮助团队更清楚的发现工作卡在了什么地方。
>
Jenny 通过看板发现了一些奇怪的问题。团队一开始决定在两周内完成四个 story，但是现在看板上却有六个。她向团队咨询为什么会出现这样的情况。
团队测试者 Traycy 说：“我是跟团队讨论过并且达成统一意见才这么修改的，因为我还有上次迭代没有做完的遗留工作需要处理。”
Jenny 跟项目所有者讨论，问他是更想让Tracy 先专注于当前的四个故事是否能够完成，还是需要同时兼顾遗留工作？项目管理者表示更期待看到团队在迭代周期内能否完成这四个故事，Tracy
可以不用担心遗留工作的问题。这样 Tracy 就在看板上删除了这两个卡片。
现在他们的看板上剩下了五张卡片，一个已经在开发中。他们的开发者 Danny 要求：“我打赌你也不想让我在这个迭代周期内处理这个不相干的故事咯？”
项目管理者表示赞同，所以 Danny 将这个卡片也移除了。现在团队只需要处理剩下的四个故事了。
>
这样的看板对 Jenny 来说则更加清晰和有意义了。她问项目管理者：“这些故事都在你的排期当中么？”
项目管理者表示是的。
“太棒了！那现在你们觉得哪个故事应当优先处理呢？” Jenny 向团队成员问道。
Danny 提出一个问题：“我们都习惯了之前的工作方式，但现在可能有些不适用了。你有什么好的建议么？”
Jenny 回答：“我当然可以给你们提供一些建议，但是毕竟你们很聪明，并且在这个项目上的经验远胜于我。我建议你们团队内部花费五分钟来讨论下这个事情，然后再看看是否还需要我的建议？”
于是团队成员开始讨论他们的几项任务。团队成员已经了解了结对（pairing）和多人（swarming）两个概念。同时他们还知道可以作为一个团队对一个故事做个探针（spike），看看这个故事是否比看起来要复杂。
大概三分钟，团队成员就决定了接下来要优先做哪些工作。Danny 说：“看，这就是我们如何来分配我们的五名开发人员和一名测试人员的。我们采用多人一组的方式，配置了三名开发人员在故事
1 上，并且 Tracy 也会开始这个故事的自动化测试准备。这意味着我们投入四名人力在故事 1 当中。”
Jenny 点头表示赞同：“看起来不错。在你的多人模式下，成员间多久会互相确认一次工作进度？”
Danny 说：“我们会每小时碰一次头。”
Jenny 回复道：“好的。那还有什么需要我参与讨论的内容么？对了，如果你碰到了一些困难，我可以帮你解决。”
Danny 回头看了下团队其他成员，其他人也点头示意赞同。“那是一定的。我们剩余的两名开发人员将投入到故事
2 当中。”
“好的”，Jenny 表示同意，“接下来我会跟项目管理者讨论下个迭代期间需要完成的任务，以及相应的优先级顺序。”
“所以你认为我们的计划会顺利执行？” Danny 有些不太肯定。
“我也不知道。你们这些家伙的计划听起来挺靠谱的。为什么不让我们每小时碰一下，然后看看究竟是否能在两天或者更多的时间内完成这个故事呢？这也能帮助你规划你的迭代时间。”
Jenny 回复道。
四名成员每小时都会互相确认一下进度。事情看起来进展顺利，直到第二天的中午。看板上的卡片数量多于四个。Jenny
也不确定是谁增加了新的卡片。
敏捷开发也需要项目管理
让我们先看看 Jenny 都做了哪些工作。她帮助团队可视化自己的工作进展，并且就如何协同工作给出了一些小建议。Jenny
倾听了团队的意见，并且在指导团队如何处理自己工作的同时，还能兼顾整体协作。她为整个团队服务。
Jenny 帮助团队完善自我管理。现在这个团队能够进行自适应调整，正向自我组织的方向发展。虽然发展的过程可能需要一些建议，但是毕竟在正确的方向上前进。
Jenny 的座右铭是：
每个项目都需要项目管理，但是不是每个项目都需要项目管理者。
因为 Jenny 并没有在项目管理角色上花费过多时间，所以她能够帮助团队发掘自身的项目管理能力。
项目成员认为他们能在 2 - 3 天的时间完成一个故事，这也正是他们为什么认为能在一个迭代周期内完成
4 个故事。三天过去了，他们的看板是这样的：
>
Jenny 很关心为什么开始只有 4 个卡片的看板，在第三天会有六个卡片？并且没有一个卡片是处于系统测试中（System
Test）或者已完成（Done）状态的？她需要跟团队沟通，确认都发生了什么事情。
团队采用了多人协同的方式，所以他们没使用站立会议。她决定去问问团队成员能否通过举行一个 “ 精益咖啡
”（Lean coffee）的方式来分析下现在的看板。Jenny 建议时间控制在 45 分钟左右比较合适。
Jenny 牵头举办了精益咖啡，并向团队成员解释道原因是因为有些问题需要跟大家进行讨论。她认为其他人可能也有一些问题想要讨论。在活动挂图（flip
chart）中她写下了第一个问题：“为什么现在看板上有 6 张卡片？” Jenny 的问题不止这一个，但是她决定从这个问题开始。团队成员在活动挂图上写下了其他问题：“我们什么时候开始系统测试？”
这个团队是作为一个整体开展工作的，但是现在看起来并不是这样子。
五分钟头脑风暴结束后，团队成员对活动挂图上的问题进行投票来决定问题的讨论顺序。幸运的是，Jenny
的问题 “ 为什么现在看板上有六张卡片？” 排名第一，所以他们先就这个问题展开了讨论。
Danny 开始解释原因。他们发现第一个故事是一个很大的故事，远不是三天就能够完成的。于是他们将第一个故事拆分为两部分。第一部分正在等待系统测试，第二部分仍然在开发阶段。其他两个开发人员负责的故事也在开发阶段。
Jenny 继续问道：“ 这样就能说通了。感谢你的解释。那么现在为什么处于等待系统测试的阶段而不是已经开始系统测试了呢？”
Tracy 解释道：“ 我们正在试图深入理解第一个故事和第二个故事。我们认为如果能深入理解会对我们即将开始的测试有帮助。”
Jenny 继续说：“ 我能够理解你的想法，换我来的话可能我也会这么处理。但我需要纠正你的一点是”，Jenny
笑了一下：“ 你为什么不尝试跟项目管理者和我进行沟通，让我们来帮助你理解故事呢？我们会很高兴帮你的。我可以借此机会了解到更多的系统相关内容，项目管理者也可以更加合理的评估他的故事的规模大小。”
Trancy 皱起了眉头。接着她说道：“ 我不那么认为。” 她转过去看了看其他队员，“ 你们怎么看？”
每个人都摇了摇头。
“ 天呐 ”，Jenny 说道，“ 项目管理者是需要你们反馈故事进展的。这是一种双向学习。”
Jenny 开始绘制她的双向学习曲线图表，来帮助团队理解并讨论。
>
Johanna Rothman 版权所有，来源自 “ 创建属于你的成功敏捷项目
”
当 Danny 看到这幅图之后，他说到：“ 噢，这样来说，当我有了一个关于架构或者设计的想法后，我可以针对这些想法制定计划，然后将我的想法跟每个人来分享。然后我们可以都参与到计划的讨论当中，从而调整优化我的假设，重新规划相关的计划并继续执行，是这样吗？”
“ 是的，太准确了！” Jenny 说道。“ 这就是将你所想展示给大家的方式。让大家参与到 WIP
(work in progress，正在进行当中的工作）的管理当中来，这样你就能专注于解决很少一部分的想法或者假设。
团队成员在一个时间箱之内完成了这个问题的讨论。接下来是清单上的另一个问题。
在结束了精益咖啡之后，他们总结如下：
立刻开始当前故事的系统测试，以便可以将其移动到已完成一栏。
参考上图流程，花费几分钟向团队成员及时的介绍自己的代码或者设计进展，真正的像一个团队互相检查，及时调整工作的前进方向。
如果他们想优化一个故事，他们需要邀请项目管理者加入到优化的讨论当中。
在下个会议之前，他们会思考 WIP 的局限性。他们想看看下次会议之前能够完成多少工作。
现在，团队能够完成一个故事并且管理他们的迭代周期了。
团队领导需要帮助团队成长
在这一周的时间当中，Jenny 发现团队间的白板会议变多了。他们已经知道采用时间箱的方式来管理这类会议。团队成员有一个要求
“ 10 分钟内完成白板会议，然后开始编码或者测试。 ”
不仅仅是 Danny 和 Tracy 负责白版会议，团队中的每个成员都尝试作为会议的主持人。
Jenny 向团队成员询问她是否可以参与到他们的讨论当中，团队成员表示同意。在 Jenny 参加的多个讨论中，她最感兴趣的一次是：一个初级开发人员向
Danny 解释一些性能相关的改动。一个新手测试人员站起来并指出一些关键点所在：“ 这是个漏洞，我在之前的工作中遇到过，并且我们是这样修复的。”
Danny 和 Tracy 坐下来听其他成员讨论问题所在以及可能的解决方案。
在会议结束后，Jenny 问 Danny 和 Tracy ：“ 能不能耽误你们几分钟，我想跟你们俩讨论一些问题。
”
俩人耸了耸肩：“ 没问题，当然可以。 ”
Jenny 将他们带到一个小会议室中，关上门，然后笑道：“ 你们两个刚才的表现作为一个领导来说，简直是太棒了！”
Danny 问道：“ 我们做了什么？我们刚才什么都没说。”
“ 对！” Jenny 说道：“ 你们做到了倾听。你们安静地倾听，帮助团队中的每个人释放出了自己的能量。你们知道你们不用事必躬亲，你们帮助其他人阐明自己的观点。我的印象特别深刻。”
Trancy 说：“ 如果我们每次都告诉大家该怎么做，那么我们和大家都学不到什么新东西。”
Danny 回应道：“ 啊哈，谢谢。我仍然认为，如何把控好什么时候该说，什么时候不该说，是一个非常有挑战性的事情。”
“ 非常正确。” Jenny 说：“ 但这很值得。尽管有时候你不得不说：‘我不知道我该跟你讲到什么程度，什么部分让你去自己探索……’
我有时也跟大家讲，每个人都是项目领导。这也正是我们所需要的。”
领导需要保护团队
在接下来的迭代当中，Tracy 找到了 Jenny：“ 我需要在接下来的几天当中去协助其他团队。”
Jenny 说：“ 是谁要求你去帮忙的呢？”
Tracy 说，“ 我的经理。”
“ 明白了。接下来你只需要专注在这个项目上。我会马上跟你的经理去沟通，并向她解释为什么你现在不能去支持别的工作。我会帮你顶住压力的。”
Tracy 说，“ 你确定？”
“ 噢是的，” Jenny 回道：“ 我非常肯定。”
Jenny 接下来去找 Trancy 的经理，然后解释了 资源优先和工作流优先 之间的区别，以及如果推迟当前工作可能带来的成本，并且当前项目的优先级是高于其他项目的。
接下来，她跟 Tracy 的经理一起商量如何能够优化一下方案，使得 Tracy 不用支持其他工作。
尊敬他人
团队通过几次迭代来熟悉并理解如何创建小的合理的故事、协同工作、以及管理好他们的 WIP。他们通过统计发现，每个故事实际所需的时间是
2 天到 5 天。
在这个过程当中，Jenny 提供了一些建议。有些被团队采纳，有些被团队放弃，还有一部分建议团队在其上做了一部分的改善。
Jenny 采用服务式领导的形式与整个团队进行接触和沟通，并给予团队成员充分的信任。一个有敏捷思想和合理环境的敏捷团队，不需要太多的管理来干涉。这样的团队需要的可能是一个项目改进指导人、一个教练。他们可能需要掌握如何相互学习。同时，他们还可能需要某些人来保护他们的团队，替他们承担外界的压力，这样他们才能持续稳定的一起工作。
我希望读者可以认真的思考什么样的管理是你的团队所需要的，什么是你们不需要的。敏捷团队不需要琐碎的管理。他们可能需要被指导。通常来讲，团队刚刚接触敏捷，或者新加入的团队，都需要一些指导来帮助他们找到自己合适的敏捷工作方式。尤其是那些初涉敏捷方式的项目经理来说，团队可能需要另外一个能帮助和保护团队的人的存在。
|
