敏捷教练第四章

第四章建立敏捷团队

和一个亲密的敏捷团队一起工作是很令人激动的。但是一个紧密的团队不是一下子就建立起来了，需要花费时间凝聚到一起。当一个团队不齐心协力时，人们感觉到很失意。他们生产的软件业能反馈出这个问题。

当在一起工作时，你能通过建立一些条件，来帮助团队凝聚到一起。改善工作环境，使得团队能有1个在一起工作的环境。寻找方法来帮助团队建立对工程的共同感觉。

4.1 Helping a Team Jell（帮助一个团队凝聚到一起）

一个有效的团队工作起来就像一台装满油的机器。仔细观察，你会看到他们不仅仅是遵循日常工作。当他们遇到问题的时候，他们会调整工作方法。当需要做一些事情的时候，会有人主动站出来去做。

Social Glue（社会凝聚力）

团队花费时间凝聚到一起。需要花费时间了解每一个人、建立信任。通过在一起工作，团队开始了解其他人的观点和问题。开会，特别是站会和回顾会议，提供了给大家互相学习的机会。

要给大家更好的了解对方建立机会。你可以共享个人历史情况或者安排一次团队外出，例如吃饭或者打保龄球。当团队休闲时，一个故事就会在谈话中讲述出来了。这个帮助我们建立社会凝聚力，使团队成员能绑定到一起。

Liz Says. . .

Eat Lunch Together

尽可能地和团队一起吃中午饭。在非正式的场合听团队讲话，会帮助你更好地了解团队。

你将发现团队经常会讨论一些在午餐外遇到的问题-可能在回顾会议上他们都没有使用的方式。举个例子，他们可能很真诚但是也很粗鲁地对待某人，这个是在团队例会上不会出现的。

向往过程改进也是被讨论的，也是在非特殊的、非行为讨论的方式，这个也是在回顾会议上不会出现的。

我有1个习惯，在午餐时，会带笔盒卡片，因为他们放在我的口袋里面很容易。总是有些事情，我想记下或者能跟得上。

Build Trust（建立信任）

团队合作需要信任，George Dinwiddie写到“信任来源于合理的自我公开，你不需要谈论你所有的事情，但是你也不能过于秘密。你可以引导团队建立信任，通过展示出来如果公开后，是很安全的。你的动机也是透明的，公开你的经验、你的观点、你的感觉，做这些的时候，也邀请其他人坦率。当你犯错误的时候，要承认。并且要经常的寻求帮助。

但是，当人们感觉到不安全时，信任是不能生根的，如果有责怪的习惯或者人们批评错误，他们感觉到不安全。当团队成员需要帮助时，他们要感觉到很舒服。当团队成员感觉到安全，他们就会愿意共享建议、帮助其他人。

如果人们真的感觉到不安全，举个例子，如果他们害怕他们将失去工作，你就不能做敏捷引导了。在这种情况下，你需要用你能去做的方法去支持团队，直到困难解决。

Sharing Personal Histories

在Overcoming the Five Dysfunctions of a Team书中，Patrick Lencioni提醒你帮助一个团队使得公开更舒适，通过花些时间共享个人历史。

他建议进行一个练习，每个人讲一个过去他遇到的挑战的故事。这个故事可以是小时候的、学习的、第一份工作的，以一些基础信息开始，比如他们来自于哪里，有多少个兄弟姐妹。

当团队中的每个成员讲了故事后，他们已经有了一次和团队成员公开的练习。当团队中的中听了这个故事，他们可以更清楚地了解讲故事的人，了解个人信息可以帮助建立共鸣。

Lencioni强调了练习的目的是使团队在一开始更清晰。你需要关心这个，每一个人都要知道他们没有被让去讲他们不希望共享的事情。

 

Trust Requires Safety

by Rachel

我和一个公司一起工作，IT主管Brian，关心团队是否缺乏公开性。团队一起思考了站会的动机，但是看起来是缺乏信任的。当他们遇到困难的时候，他们不寻求帮助，人们保持安静。

Brian每天下午在办公室召开scrum会议，所有团队的领导和项目经理来参加。我作为观察人员参加了这个会议

Brian组织这个会议。我观察到，他很高兴向来晚的人收罚金。他转着圈，问每一个人的报告，他接二连三的问题，使得他们偏离了汇报。他看起来一直都是了解所有的情况，为了过去的错误责罚他们、提醒他们如果交付晚了的结果。每个人都知道他没有忍受这种痛苦、公司成员最近解雇很多。

看起来Brian的会议形式缺乏信任，有很多工作需要去完善。他需要学会何时给反馈、什么时候保持安静和去聆听。

 

Bridge the Gap（跨过障碍）

在不同的角色中（例如开发人员、测试人员、分析人员、技术发起人）建立信任是需要花时间的。你可以建议他们短期内去做其他的角色，这样来跨过不同学科之间的障碍。举个例子，一个开发人员可以做测试人员1周。如果她没有做这个工作所需要的技能，他可以和其他人结对，尽力去做这个事情。最后一公里可以帮助他们更好地了解这个工作。

人们可能不会理解他的同伴做什么，总是假设他自己做的是更困难的。但是没有互相的尊重，一个团队是不能更加活跃的。你可以像团队中的每个人表示尊重，通过询问他们的观点、帮助他们、严肃地谈论他们关注的和问题。其他人会注意到这些，并且模仿你。

如果团队成员看起来不满意其他团队成员，邀请他们去喝咖啡，讨论问题。她做了什么假设，导致她用这种方法来认为她的团队成员？还有其他的解释吗？

4.2 Creating a Team Space

团队需要需要一个共享空间来保持交流充分。理想的对于整个团队，没有其他人，坐在同一个房间里。在团队附近有1个休息区域，在那里他们可以喝咖啡、闲谈、允许团队休息和建立友谊。附近的会议室也是有用的，可以有私人空间或者不干扰其他团队讨论。

然而，一些人可能不愿意挪到椅子或者坐在一起，因为一个公开的空间使人感到是暴露的和非个人的。鼓励团队去设计他们自己的空间，定制空间使得这个适合他们。一些植物、书、图画可以使一个空间感觉到在这里工作更安全，这个很令人吃惊。

有时当公司采纳了敏捷，需要他们花费很长时间才能意识到这个不仅仅是开发人员的工作。需要整个组织都进行改变。因此，你可能遇到一些阻力，如测试人员应该坐在开发人员的旁边、测试人员坐在产品管理着的旁边。要不断地和这些做战斗，因为当人分离的时候，很难建立起一个敏捷团队。

一旦大家都做到了一起，可以开始建立一个信息空间，在这里有用的信息被展示帮助人们安排时间和做决定。在第8章将有详细的指导。

不仅仅需要关注物理空间。虚拟的环境也需要支持合作。和团队安排一个会议，讨论出他们要把电子信息放在那里。鼓励他们建立wiki或者共享文档仓库而不是依赖于共享网盘。他们也需要清楚地了解开发和测试环境的一致性。

Type Assessments

为了帮助团队更好地了解他们的优点和不足，团队需要进行类型评估。建议团队采用Myers-Briggs Type Indicator(MBTI)或者Belbin Self-Perception Inventory

 

如果他们意见一致，那么每一个人分别使用评估，然后在团队中共享结果。这些测试不是性能或者能力的测试，但是能够找到团队常有中相互之间爱好和行为趋势。共享结果可以帮助团队成员更好地了解其他人的行为。

 

4.3 Balancing Roles（平衡角色）

在顾客和开发人员之间的关系是很关键了，因为他们需要在一起工作，创造出最好的产品。每个人都需要感觉到他们是团队的一部分，向着同样的目标去工作。对于整个团队，都要清楚了解角色的责任

顾客是拥有生意的、对软件应该做什么进行排序的。开发团队有责任觉得如何构建软件、和顾客交流要花费多少时间。顾客可以设定他们需要软件交付的时间，但是不能强迫他们接受范围，必须要和团队一起得出这个范围。

通常，顾客是产品经理，他和多个用户和投资人去觉得软件应该做什么。在大型开发中，顾客的角色很大，可能不是一个人，所以1个顾客团队形成了。团队需要包括所有的必要的专家去分析出用户故事和进行优先级排序。用户团队可能包含生意分析员、用户代表、交互式设计人员。这个混合依赖于产品和组织。

有时，最好的解决办法是“近顾客“，他和团队一起得出需求的细节，和”远顾客“。他们对生意优先级做决定。”近顾客“可以由和团队坐在一起的生意分析员担当，远顾客是产品经理，他和生意操作员和市场团队坐的很近。

如果角色不平衡了，一边或者其他边可能工作时间过长。如果顾客工作过度，开发人员就没有足够的时间、开发人员就在猜顾客想要什么。如果没有足够的开发人员，或者他们工作比预期的慢，老板就会不满意他们的输出。作为一个教练，你可以帮助他们把这种不平衡的副作用表现得更明显，这样管理者就会考虑解决这个问题。

4.4 Energizing the Team（给团队充电）

伟大的团队是自我激励的。有时，尽管，我们发现一个团队遇到困难了，他们呢还没有确信他们如何开始的。可能会有一些大的机会，但是他们只见树木，不能看到森林，他们被淹没了。下面是一些好的方法，帮忙如何给团队充电，帮助他们找到他们的自我激励。

Not Too Easy, Not Too Hard

伟大团队的秘密在于他们需要可到达的但是还有挑战的目标。每个人需要有充分的挑战，但是不能令人讨厌的或者令人焦虑的。最适宜的工作区域是人们能否最大程度的享受。

如果工作太容易，开发人员可能感觉到厌倦和没有动力。他们对于取得太容易不会感到自豪。如果有很多容易的工作区做，鼓励他们去找到自动化的方法。

 

有时，工作看起来是不可能的，远远超过了他们舒服的区域。这个会让团队麻痹。他们需要把工作分解成可以管理的一块一块、他们找到可以开始的那部分了吗？如果在指出后面需要再做什么前，需要更多的调查，鼓励他们去试验、验证他们的主意。

形成这样一种文化，试验一个问题的解决办法是ok的。正如Thomas Edison著名的言论一样：“我没有失败，我只是找到了10000中不能奏效的方法“。如果团队没有足够的信息在两到三种方法中做选择，他们应该去试验所有的。在每一次试验后，团队应该会了解更多。尽管开发一种以上的解决办法看起来是浪费时间，但是这个是一种快速的学习方法，一种减轻做错误决定风险的便宜方法。

Find a Compelling Goal（找到一个引人入胜的目标）

了解到他们正在生产一个有用的产品可以帮助团队更关注工作。尽管一个教练不能设定产品的方向，你可以帮助团队理解大的蓝图和团队的任务。如果你能的话，帮助团队做安排来满足最终的用户。用户需求对团队来说是更生动的，给他们一些概念，如何能生产更好的产品。

你可以帮助在工程内绘制蓝图，也可以帮助他们思考如何把这个和个人目标连接起来。敏捷团队计划和设计他们自己的工作。要清楚在软件设计、构建、测试上，他们有多少的自由度、一旦他们了解他们不需要等待允许，他们可以自由的开始。

Time for Innovation（改革时间到了）

我遇到很多敏捷项目中的开发人员，在进行一个连续的用户故事时，时间燃尽了。

如果他们没有时间去探索新技术或者试验创新的产品概念，团队会变得没有动力、在计划中留出一些时间来探索新的主意。这个可以为产品产生惊奇的动力。

当团队成员有时间去实践新的主意时，为他们打扫干净阻碍他们的事情，或者学习新的，然后他们就会很开心的工作。这个增强了团队的能力，也减少了工作的任务。帮助团队找到大项目中他们自己的小项目 ，通过听他们或者鼓励他们去实践自己的主意。

Gold Cards

by Rachel

我和一个使用金卡的团队一起工作，去找出问题。开发人员有机会使用金卡，然后按照他们自己选择的课题去工作一天，而不是按照白板上的工作去做。每一个团队开发人员每一个月有2张金卡，他们可以在站会上做使用金卡的决定。

我们花费金卡在各种各样的事情上：试用新工具、试验新的产品主意、学新的事情。在每个阶段末，我们向团队中的其他成员展示我们完成的。

在团队中，金卡导致了工作产品和支持架构的变化，它明确了我们更好地使用了时间。

金卡给团队提供了一种方法去展示新的产品主意给顾客，使得他们对产品充满了自豪感。这也是一种方法让他们去挑战工作。我们发现所有的开发人员在每一周的同一天使用金卡是很有效的。这个使得开发人员一起去实践他们的注意，一天不去进行项目让他们感觉ok。看一下完整的论文，如何去推销金卡管理：一个角度是金卡创造了个人绩效检查的基础，但是没有把他们和团队分开

Celebrate Success（庆祝成功）

找到一种方法去庆祝每次交付的成功。一起吃午饭或者喝酒庆祝成功，提高团队的凝聚力。帮助团队找到展示他们成功给其他团队和组织的方法。他们可以邀请人去看demo，在公司会议上展示产品、或者发送公告。

当其他人注意到他们的成功、欣赏他们时，团队会得到鼓舞。管理者和顾客的感谢很重要，考虑要暗示他们这样做。从用户得到反馈，特别是如果生活有所改善，是受到刺激的。Liz工作的一个公司，在咖啡机附近的墙上展示了一个从满意的和不满意的顾客那里来的email。

How Are We Doing?

by Rachel

我曾经和一个团队一起工作，他们认为自己是一个愚钝的私人项目。在最初的发布中，他们听到在过去的一周里，他们为公司创造了很多钱，这个鼓舞了他们。他们的项目被人注意到，然后有了不同

Don’t Demotivate（不要泄气）

人们远离积极性。如果没有事情使他们泄气，这是个好机会让他们保持积极性。什么使得人们高兴、什么使得他们工作中有积极性就是他们所做的。什么让人们不高兴、什么让他们泄气也是他们所工作时面临的形式。形势问题包含压力和公司的制度。

在Motivation to Work中，Herzberg解释了后勤因素。如果他们没有出现，这些因素就不会使得人们泄气，即使当他们出现了，这些因素还是不能激励他们。举个例子，即使他们在那里，快速计算机、得体的咖啡，相当好的薪酬都不会被注意，但是如果他们缺少就会使得雇佣人员很泄气。尽管这些后勤因素可以超出了教练的影响，还是值得和团队讨论是什么打扰了他们。你可以找到一些很容易处理的事情，例如提高工作环境

 

 

Beware of Incentives（当心动机）

小心使用各种动机去鼓励人。正如Kohn在Punished by Rewards中所说的，目标是鼓励个人提高生产率的动机是有破坏团队合作的，因为这样导致了团队没有达成一致，团队成员是在为了奖金所竞争

如果团队成员因为工作被提供了奖金，他们经常做他们可以取得奖金所必须的事情，不多也不少。如果管理者必须有奖金计划，那么让他们基于取得的团队或者公司目标，不是个人目标。当他们被做好工作和生产更好的产品的满意度所刺激时，团队可以工作得更好。

4.5 Hurdles

下面是你可能遇到的一些障碍

Teams Aren’t Cross-Functional（团队不是交叉职能的）

一些公司通过一些规则组织团队，例如分析员、设计人员、测试人员、软件工程师，等等，有分开的报告界限。对于敏捷，这个一个很严重的阻碍，因为和不同的人在一起工作建立更好的软件的交叉职能团队是一个很基础的敏捷规则。为了让敏捷更有效，每个人都应该允许同时开发工程，避免在各部门间的处理延迟。、

如果你在这个形式下引导一个软件开发团队，努力去其他部门去要一些附加的团队成员，例如测试人员和分析人员。在开发团队和其他部分投入的其他部门人之间要建立良好的关系。邀请这些虚拟的团队成员来所有的敏捷会议，在emali群组中加他们。组织聚餐和喝酒，让每一个人感觉是一个团队。

No On-Site Customer（没有现场顾客）

有时开发团队在一个地方工作、顾客在另外一个办公室工作。他们甚至不在一个时区内，特别是如果你需要和最终用户紧密交流但是他在不同的国家时。如果不能处理好，和远程顾客的工作可能会造成交流问题和不满。

和远程顾客建立一个好的关系是必须的。鼓励顾客和团队中的成员面对面的开会，以便他们能了解每一个人。第一次的计划会议是一个好的机会。后面，你可以使用电话或者非正式的渠道例如即时通信或者共享谈话窗口，来进行定期的交谈。

记住这个谚语“眼不见心不烦“。人类喜欢对看见面孔做出反应。使用网络摄像头，团队可以在PC或者远程会议上，看见其他办公室的人。很惊奇的，甚至只有静态的其他房间的人的图像，也能有所不同。

Team Is Too Big（团队太大了）

如果你的团队人数超过10个人，很有可能在团队沟通和责任分配上有负面的影响。有大量人的会议将花费更长的时间，使得每一个人都参与讲变得更难。每一个人都会对团队目标承诺更少，因为他们个人对团队的责任更少。和团队一起工作，找出一个方法，把项目划分为小团队-理论上的特征团队。Scaling Lean and Agile Development中有关于特征团队如何工作的建议

Team Is a Resource Pool（团队是一个资源池）

当进行几个项目的一群人好像一个团队一样在一起使用敏捷时，敏捷不会起作用。敏捷假设同一时间只有一个项目。当团队从事多个项目时，没有大的吸引人的目标。你会注意到不同项目变化时，有不同的优先级，这个造成的中断可能会扭曲项目。我们建议在这种情况下，不要使用敏捷。

Team Members Ostracize Someone on Their Team（团队成员排斥其他成员）

你可能会注意到，团队不愿意和团队中的一个人一起工作。是因为缺乏信任的问题吗？或者是一个比较实际的问题。可能是这个人遭受没有洗澡？

试着和团队交流（当这个被排斥的人不在周围的时候），去看一下他们的解释。也和这个被排斥的人交流。他意识到这种情况了吗？如果你担心他们因为疾病、压力或者悲伤会导致工作不集中，那么请HR过来协调。

Team Becomes Complacent（团队自满）

当团队不和其他团队交流或者不公开生意目标时，团队经常会变得很孤立。如果你担心团队变得太自满，那就值得去提高团队对于高级投资人员的可见度、增加对于团队他们所完成工作的生意价值的反馈

4.6 Checklist

l  为团队互相了解创造机会，这会帮助团队提高凝聚力。一般是花费一些非正式的时间在一起，例如午饭或者喝酒

l  建立共享空间，帮助团队更好地工作。尽量是所有团队都坐在一起

l  把各角色的职责弄清楚。得到顾客对于团队的支持。

l  保证团队有可达到的但是又有挑战的目标。确信工作不会太简单也不会太难

l  为发布安排食物或者酒进行庆祝。请顾客和管理者来答谢团队