你们是完整团队吗？

winston

英文原文：Are You a Whole Team?

　　译/金毅

　　如果你的团队使用敏捷方法开发软件，那么采用完整团队方法（Whole-team approach）对于发挥敏捷实践的功效极为重要。

　　完整团队这一敏捷实践强调以整个团队为单位工作，把专人专责简化为职责均担，从而开发出高质量的软件——可以说它是一种“胶水型”实践：它将很多其它敏捷实践组织在一起。例如，在Lisa Crispin和Janet Gregory所列举的敏捷测试的“关键成功因素”中，完整团队位居榜首。

　　和其它实践一起协作，完整团队能发挥巨大价值，如降低交付风险、改善速率/发布周期、得到更优方案以及减少缺陷和其它浪费。然而完整团队和其它敏捷实践一样需要纪律性和勤奋。在此有四个“臭味”可能预示着你还没有发挥完整团队的功效——同时我也建议了一些解决方法，或许能帮你顺利过关。

　　臭味 #1: 强调头衔

　　我记得有个团队刚刚开始实施敏捷时，某个团队成员拿着组织结构图，义正言辞地跳出来指正：在程序员完成故事编码之前应该禁止测试人员介入。其实没必要把头衔搞得跟完整团队势不两立。但如果某个重要成员一意孤行，或者团队因为角色不同而不敢质疑技术主管，再或者团队期望“测试人员”完成所有测试，那我们就该担心自己实施完整团队的效果了。

　　解决方法: 打破角色和职责界限

　　如果你把工作简单地看作是一些待完成的活动的集合，那么你就可以打破角色和职责的界限，允许队员在多重领域创造价值。比如，解放程序员，让他们探索测试。类似地，当测试人员发现一个他们能修复的缺陷时，放手让他们去修复吧。

　　臭味 #2: 英雄主义

　　我们都见过这样的人：某个团队成员为了顺利发布，打算今天加班到很晚，或者周末加班。他上次就是这么干的，这次也将这么干。问题在于：英雄主义对项目有百害而无一利，它降低了团队的人员风险承受能力（也就是说，团队中有几个人离开，但还能保证项目正常运行），而且往往还会阻碍信息共享（当然不全是故意的）。学习和进步的瓶颈就在于此。引申出来的另外一些臭味是：是否任何人都能在任何时候休假呢？某人能轻而易举地离开项目吗？

　　解决方法: 摆脱依赖

　　如果你是团队中唯一更新白板或修复有问题的构建的人，去休个假，试试如果没有你会发生什么。

　　在每日站立会议中，如果你发现某位团队成员只是向你而不是所有成员陈述他的见解（假设你是主管），那么你只要避开他的目光，他就会自然而然地转向其他人，和团队一起达成一致，也会慢慢形成会议的主人翁精神。最好的团队领导者是信息共享者而不是信息囤积者(hoarder)。

　　臭味 #3: 大家每天固定位子就坐（一个萝卜一个坑）

　　大家是不是每天上班都坐同一个位子呢？选哪个电脑有什么影响吗？是不是每台电脑都有你需要的全部工具，同时配置完善足够你完成所有任务呢？如果不是，证明你们不经常结对，也不常交换结对伙伴。

　　解决方法: （真正地）结对编程

　　结对编程并且经常轮换结对伙伴是需要纪律性的。如果你没做，只能说明你不相信这有用。为了共享知识和技能，在看板系统中你可以安排学习和一些缓冲时间。你可能需要拒绝一些客户的要求，但短暂的损失将带来长期的收益：你整装待发，开始一起协作的极限编程之旅。而正是由于扫清了知识方面的瓶颈，你将会快速前进。试试结对吧。

　　臭味 #4: “编外”队员

　　在你的团队中，你有没有一个队员被排除在关键会议之外呢？这可能发生，比如技能存在很大差异时，团队中有兼职或共享成员时，或者团队主管认为不需要所有人都参加会议。

　　解决方法: 三驾马车

　　敏捷团队可以通过三驾马车来汇聚知识和意见。如果规定关键会议必须有测试人员、程序员和业务代表参加，将有助于团队分享对需求的理解，减少沟通隔阂，并且尽可能摆脱个人技能和见解的限制。Janet Gregory称之为三驾马车，而George Dinwiddie则引用电影“神勇三蛟龙”（Three Amigos）来命名它。不论你叫它什么，它都是完整团队的一个基础部分。

　　那么下次你参加回顾会议时，考虑考虑怎样在下一个迭代改进吧，或者想想你是不是那个唯一知道如何修复构建的人呢？你也可以去思考一下完整团队里那些臭味以及解决方法。抑或停下你思索的脚步，和其他队员讨论讨论这个话题。

　　关于作者

　　Matthew Philip以前是Asynchrony Solutions的敏捷教练，但他更喜欢说他是“敏捷团队队员”。想了解更多信息，请访问他的博客。

　　查看英文原文：Are You a Whole Team?