你们是完整团队吗?

2019-05-06    来源:infoq.com

容器云强势上线!快速搭建集群,上万Linux镜像随意使用

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

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

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

臭味 #1:强调头衔

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

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

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

臭味 #2:英雄主义

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

解决方法:摆脱依赖

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

在每日站立会议中,如果你发现某位团队成员只是向你而不是所有成员陈述他的见解(假设你是主管),那么你只要避开他的目光,他就会自然而然地转向其他人,和团队一起达成一致,也会慢慢形成会议的主人翁精神。最好的团队领导者是信息共享者而不是所有信息都集中只有你知道,虽然表面上看来,是工程师教了他们自己如何解方程。

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

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

解决方法:(真正地)结对编程

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

臭味 #4:“编外”队员

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

解决方法:三驾马车

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

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

本文编译自金毅,原文作者Matthew Philip。

译文出处:infoq.com 转载请注明出处链接。

标签: 敏捷 

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点!
本站所提供的图片等素材,版权归原作者所有,如需使用,请与原作者联系。

上一篇:浅谈用户反馈与行为研究:有效分析和利用社交媒体数据的五个建议

下一篇:敏捷开发产品管理系列之三:产品用户群规划