建议用 Firefox 85+、Safari 14+、Edge 87+ 浏览
我的文章 我的评论 我的书评 我的知乎*
书单 书讯 书评
需求知识体系 特性 用例 统一用例方法 用户故事 需求工具
业务建模 UML OOD
敏捷知识体系 敏捷方法 敏捷问答 敏捷工具 敏捷评论 敏捷资源
业务模式 需求模式 架构模式 设计模式 大道至简:实话设计模式 Web 应用架构模式
.NET Java JS 笔记
Amazon* ITPub* Martin Fowler* 教程
需求分析需求模型非功能需求业务需求分析
SpringJSF
> >
在线/117 登录/0

案例分析:当敏捷团队遭遇了公司政治

阅读数:11.5K
基本历史

浓缩的才是精华:本案的可贵价值!我想本案可以用一句话概括成:

你们有一个敏捷团队,现在(非敏捷的)公司领导/管理层处于种种目的(比如公司政治目的),偏要安插一个与敏捷文化格格不入、大家都讨厌的人(比如浮夸,不干实事,本身技能水平达不到项目要求,但喜欢处处卖弄老资格、当领导、指手划脚),你们怎么办?

感谢 Richard!从本案涉及的内容来看,显然具有很高的价值,它反映了敏捷开发、敏捷实施中一个非常实际的经典问题。我想,许多公司尤其是处于转型期的国内企业或多或少都有可能遇到此类棘手的问题,应该能够引起大家的广泛共鸣。

作者给出了他们的解答,在不到一个月(3 周)内解决问题,让 A(麻烦制造者)走人。这已经做得相当不错了,有理有据,用事实说话。如果我是当事人,未必能比作者做得更好。

然而,有没有更好的、更敏捷的解决方案?作者的方案是否是唯一的解决之道呢?我不知道。但我想,应该还有值得改进的地方。

敏捷团队对于此类问题,到底应该怎么做?怎样做是以人为本,而且风险更小?值得我们进一步探讨。
1)采用“结构化”的案例分析,尽量不要记流水账。

也就是要概括、提炼,屏蔽掉无关和琐碎的细节,做到结构分明,条理清晰,重点突出,让人一目了然。

本案的流水记账方式让人感觉有点发牢骚,怨情满腹,可读性较差。

可能的话,还可以分门别类地介绍一下项目地域、规模、应用特点、来龙去脉等背景信息。

2)如果人物众多,应该排一个人物表,比如:

A 高级工程师,麻烦制造者,作者的下属(同级?)

B Team Lead,与作者共事的管理者和支持者

D 作者的上司,不作技术性工作的经理

H 开发组的上司(大部门领导?)

J 前任 QA Lead,德高望重的老员工

作者:一个新成立小组的 QA Lead,本文主人公(Agile Coach?)

事实上,我也是在列了这张人物表之后,才把本案错综复杂的人物关系理清楚(有没有真的理清楚,不敢确认)

先提这两点 ...
你已经做到了威逼利诱,想到了各种手段,支持。

但我的一个疑惑是:他为什么会如此雷打不动,坚持这么混下去?

显然,A 不把你放在眼里。他非常善于演戏,而且只听领导 D 和 H 的,不把你当作领导。

难道没有什么东西可以对他形成制约?也许和你们公司的考核激励制度有关,要么他有什么背景。不知道你是否管理他的薪水?考核机制说不定是一个关键因素。

像这样的老油条,的确不应该多留。
你们对于 A 的处理,大体上是对的。如果我遇到和你类似的情况,我想,我也会采取类似的做法,收集证据,让事实说话,这是很自然的科学的工程师们的做法。而且你们已经做到了仁至义尽,给了他一次次机会。

值得思考的是,谁都知道,这样的人对于软件研发没有价值,但问题是你们公司什么还会留他?是关系户,亲眷,公司政治,文化,还是其他什么原因?为什么 A 不能像一个新人,从零开始,被你们公司改造,真的无可救药了吗?我想,这些围绕 A 事件的因素和现象暴露了你们公司文化、管理上的缺陷,或将成为你们后续实施敏捷过程的障碍。

我想,你们团队可能做到了一些部分的敏捷实践,但在公司层面、组织层面,离敏捷可能还很远。

下一个艰巨的任务是:如何让你的老板 D 和 H 参与到这种敏捷变革中,你总不至于把自己的上司也炒了吧。那就不是敏捷了,是政变。

现在我们也知道你心中的敏捷,你说“这就是敏捷了”。我喜欢,也很理解你的单纯、直板、坦率和爱憎分明,这些都是技术人员的优良品质(我也是一名 14y+ 技术人员)。但坦率地讲,你说的这还不是敏捷,传统公司遇到此类问题,也应该这么做,这是任何一个具有科学逻辑思维的管理者应该想到和做到的。

然而,敏捷比这个,要求更多,更高。敏捷,首先是一种进步的开发哲学、价值观、原则、境界和思想,在很多情况下,并不是那些具体的时髦做法,你做到了那些实践,也未必能达到敏捷态。你们团队似乎采用了一些 Scrum 的做法,但显然离敏捷的真实态还较远。

掌握和吃透敏捷的关键在于,理解敏捷方法 XP、Scrum、AUP、Crystal、Lean、FDD、ASD、APM ... 的创始人为什么要这么做,他们的真实目标到底是什么?千万不要像某些明星那样(诸如 Jeff Xiong)机械、刻板地去理解。

敏捷不敏捷,本案其实分为两个部分。

可以从敏捷管理、敏捷开发两个方面来看。

1)本案的核心是,如何处理 A 的问题。这实际上是一个敏捷(团队)管理的问题。

作者借用了敏捷思维(他所说的“教条”),在不到 1 个月时间内,请 A 走人,消除了资源上的浪费。对于一个与敏捷文化格格不入的人,敏捷团队大体上也会这么做。

在处理 A 的这件事情上,可以说作者基本上做到了敏捷。这方面,作者叙述的已经比较充分。当然,我在上面也指出了还有一些不那么敏捷地方,有待改进。

区别在于,一个敏捷团队可能用更短的时间、更灵活、更有效和更温和的手段和方式来解决问题。

当然作者所提到的一些敏捷思维,也仅仅是敏捷管理中很小的一块,可谓小试牛刀。

2)由于本案的重点是如何对付 A,而不是讨论如何敏捷开发,所以作者对此着墨不多。

在敏捷开发这一部分,从种种迹象看,我感觉作者及其所在团队是不敏捷的,或者离真正的敏捷团队还有较大距离。后面我还会进一步分析。

那么,这家公司敏不敏捷呢?显然,是一家非常传统(效率比较低,因而缺乏竞争力)的公司,这点上我们和 Richard 的观点是一致的。像 Richard 这样的实干青年、敏捷程序员无疑是这家公司未来的希望!

总结一下,在处理 A 的这件事情(团队/人事管理)上,本案大体上是敏捷的(个别地方还不够敏捷)。在敏捷的开发方式和流程上,本案的团队似乎是不敏捷的,至少没有充分的事实来证明。

我倒想请问一下掌门,如果你们门下出现一个不认真修炼还要影响他人修炼屡教不改的弟子,那你是放任他继续成为害群之马,还是开革出派?我想这样的事情,即便不是发生在太极敏捷派内,凡是任何以广大门楣为己任的门派,都会选择第二条路吧?硬要把这个往敏捷上靠,我觉得就是扯淡

我觉得在概念上需要澄清一下。

现在我们可以达成一致的是:有两个明显的派别,传统派和敏捷派。对于“害群之马”,无疑在处理的结果上,传统派(那些优秀的传统派)和敏捷派都是一致的:清理门户。敏捷派一定会坚持原则,不会允许不遵守游戏规则的人留在团队里,破坏敏捷文化。

凉粉的意思是说,传统派也会这么做,所以不要把这件事往敏捷上扯。

我的观点是,虽然传统派、敏捷派都会选择“第二条路”,这没错,但在具体的做法和措施上,敏捷派肯定是与传统派有所区别的,有一些是传统门派不会做或做不到的。所以,把作者处理 A 的这件事扯到“敏捷”上,也未尝不可。

这实际上是一个逻辑问题。你可以想象,有两个圆圈,分别代表“传统派”和“敏捷派”,两者有交集,而敏捷派也肯定有自己独到的处理方式。

在敏捷实施过程中,尤其是在哪些观念、意识传统和落后的企业中实施敏捷研发,管理层硬要塞一个“麻烦人士”给你,可能是常有的事。本案恰好反应了这种现实,所以我说这是本案可贵之处。对于此类问题,与传统团队一样,敏捷团队当然也不能回避。虽然教父语录上没有圣谕指示,但我们还是必须要给出自己的 solution 来,而且是有别于传统团队的、敏捷的处理方式。

从 Richard 的叙述和答复中,读者已经可以看到一些思想和做法具有敏捷的特征,这些长处不能一味抹杀。比如,他观察、试验、取证、沟通、取得领导和同事的支持,最终的效果也还不错,比较迅速地避免了人事上可能给项目带来的风险。敏捷团队通常会欢迎尝试,反对先入为主,把一个人看死。当然,我在上面已经指出了,作者做得还不够敏捷,敏捷团队可能做得更好。

在本案处理 A 的这桩事情上,与其争论作者的处理敏捷不敏捷(有人认为敏捷度为 0,我不赞同,这显然不够客观),还不如争论一下敏捷派的做法到底与传统派有何不同。在这点上,“对自己表现十分满意”的作者其实也没有整理清楚。

这个问题,很可能是本案带给我们的最大收获之一。
只花 3 周是合理的,我原来设想是否能在 2 周(一个迭代)内解决问题。不管如何,这点时间还是需要的。从时间上来看,确实要比其他组“敏捷”得多。

应该是 yunfei 看错了。事实上,这篇故事我也至少认真读了 30 分钟,才确认自己大体看明白了。本案的叙述过长,而且涉及到很多细节,容易出错。

Richard,我看到你的故事中差不多有一大半的篇幅是在讲 A 如何如何不对,然后你如何如何应对。给人的感觉是,你要充分证明 A 是多么的无能和令人讨厌。但你明白,在本案中 A 绝对不可能有任何的申辩机会(主动权掌握在你手里),我们读者可以完全而且只能相信你的陈述。所以,要我们得出 A 错误,你正确,从而支持你的结论其实是相当容易的,也就是说这方面的篇幅可以大大缩短,更加的精练和概括。

另外,由于比重设置不当,你对你们团队是如何实际运用 Scrum 或者敏捷方法,谈到的较少。这方面能否再介绍一下,作一些补充?这样我想这个案例才更完整,对大家更有帮助。

对作者的努力全盘否定显然是不对的。作者在处理 A 的这件事情上,大体上是敏捷的,可以说作出了方方面面的尝试,应对方式还是比较专业的,值得我们表扬和学习!

敏捷团队大体上也会采取类似的动作,当然正如我前面指出的,敏捷团队可能还会做得更好。

仔细看了作者的叙述和答复后,以下是我找到的 16 点证据(有点长):

* 其中的一些做法可能是(优秀)传统派也会做到的,在前面贴子中我分析过,这可能是敏捷派和传统派的交集部分。讨论某个具体行为到底是传统,还是敏捷,意义不大,因为你很难界定清楚什么是传统,姑且当作敏捷好了,因为敏捷一定是建立在吸收了优良传统实践的成熟基础之上。

1、终于有人手可以分配过来时(2007年9月中),我得知一个我觉得能力很差的高级工程师A会被转移到我的组里帮我。我的第一个反应是,“能不能分配其他人手到我的组里。”我的上司D说,“先让这个人过来试试。”我就没有多说什么,那个时候我就已经预见了今天我不得不作出的处理。

2、我的第一个反应是从兵法“用人不疑,疑人不用”的角度产生的

3、这样到了九月底,我感觉可以让他转移到我的组里开始前期准备工作。我当时的感觉是,我要尊重我的上司D的安排,尽力和他一起携手合作。我马上就碰到了一个问题,他无意从自己的项目中摆脱出来,他的托词是,“我需要一点时间完成我手上的事务,这样可以很好的交接给其他人。”我就给了他一个星期,同时也和信任的Team Lead B进行了沟通。

4、这不是明摆着要消极处理他的新工作吗?我很不客气地回信,并抄送一封给我的上司D,表示了我对他的态度的不满。当时我的感觉是这个人不适合在我的组里做事 ... 我写的信让D很不高兴,因为我写得很不留情。这也是没有经验的管理者应该注意的,尽力避免这么直接的举动,多进行面对面沟通,实在不行才使用这种下下策。

5、同时也帮他开始建立开发环境,我花费了三天,才把他的开发环境整理清除,他被聘开始工作到现在,对自己的开发环境维护什么都没有做,一切都是乱七八糟,

6、我的分配是很清晰的,阅读文档,准备写测试计划,有任何问题,尽管问我。

7、周五中午B跑来跟我说,开发部上司H很不满A不准备在下一周进行程序发布测试(Release Verification Testing),我说我完全支持A的决定,心里还有高兴,A终于可以专心做正事了。我甚至对B说我觉得A需要一点时间阅读文档。如果他能专心做事有进展,我会帮他处理这些杂事的。

8、于是我和B起草了一封信说A一个星期下来没有实质性进展,反而有负进展。他的态度是我们不能容忍的。希望D能替我们安排一个好的解决方案,我们对事情发展到这个状态已经无能为力了。

9、我列举了几种处理方式:

1)调离A,在分配新的人员给我。后果是要重复一系列培训,开发环境设置等工作。

2)分配新的人员给我,让A和这个新人一起协作相互牵制,如果A合作不顺就要。后果是我不需要太多介入培训新人,帮助设置开发环境的问题。而且我可以继续我的测试工作。但是要更多地管理。

3)继续给A一定的时间,我会更严格地监管A,后果是我要花费很多精力监视,甚至介入A的工作,我的测试进度将受影响。

10、我所做对的,是对我所能够控制的局面进行了有效的监控;我利用了我所学的敏捷开发知识准确地判断了事态可能的发展;我对事态发展作出了一步步的盘算及后果的考虑,作出了先影响甚至控制A的战略,然后作出了如果A不合作,必须让更高管理层替我解决问题的战略。最后是在管理控制的同时收集下属的不当所作所为,作为我的战略资源,同时发动我的同事,我的上司对我进行支持。整个事件从发生到解决,花费了一个多月时间,我用最迅速比较妥帖的方式处理了这件事,而且没有耽误我自己的测试工作。

11、我和他沟通无数次说,你要专心把一件工作做完再转到另一工作上,而不是这里忙一点,那里忙一点,最后什么都没有做完。我把自己的想法很清楚地传达给他 -- 我想看到实质性的工作进展。敏捷需要清晰的交流,我觉得我做得很好了。和我一起工作的"B"同样做了口头,文字上的交流。

12、我和"B"都发现"A"根本就不愿意在我们组里工作。与其让他不工作,不如将其调离我们组,这就是我和B最后所做的。

13、"A"加盟以后,我确实存在幻想说,疏导一下,沟通一下,甚至威逼利诱一下,能让他迷途知返。要知道那时的"A"已经6个月没写一个QA Test Case。我想万不得已强势干预一下,他也能迷途知返,迅速进入角色。

14、好在我懂点敏捷开发,知道尽早排除问题,及时向我的直系上司汇报问题,并请求干预。

15、我在三个星期内,收集了证据,暴露了他的不作为给我们的直系上司,并将他调离我们组,解决了这个问题。这里就有一个比较,八个月很多人对他的容忍,让他白拿八个月的工资。和三个星期,给他一次次机会,没有效果,最后让上司出面解决。这就是敏捷了。

16、我可以保证,我是一个很容易让人喜欢的人物,我很单纯,很直板,有时过于爱憎分明,我是个Team Player。我不能说是我是一个优秀的Scrum Master,但是让我进入一个Agile team,你肯定会喜欢我的配合,我对事情的判断,我能够提问,我能够把事情做完做好等等品质。说不定你会有机会和我合作,那时你就知道我这个人是多么可爱
前面我分析过本案敏捷不敏捷,分为两个部分。在处理 A 的事情上,作者运用了一点敏捷管理思维,在结果上较为敏捷地解决了问题,但在细节上还不够敏捷。

在敏捷开发层面,由于不是本文的重点,作者对此叙述不多,只是偶尔地提到了 Scrum、Scrum Master 等概念。

我认为本案不像一个敏捷开发团队,有这样几点理由:

1)同一个产品的开发者、QA 似乎不在一起同步工作

作者作为 QA Leader,负责产品的测试,A 到来后,一共只有 2 名 QA (测试员),他们一起支持 7 名开发者(程序员)。而 QA 的领导是 D,开发组的领导是 H,谁是整个 team 的领导?

我们不知道作者 Richard 是否是整个 9 人产品团队的 Team Leader,文中对此没有明确说明,作者也没有提到他是如何管理协调程序员的工作,以及整个研发团队的工作的。作者谈的最多的是,他的测试计划、测例编写如何重要。显然,作者并没有站在整个产品团队的角度上,发挥一名真正 Scrum Master 的作用。

所以,在管理结构上,似乎这个产品的程序员、测试员是两个分立的小组,各自独立工作,并没有形成一个紧密合作、有效反馈的敏捷团队。

2)模糊的测试迭代周期

作者在本案中并没有明确地提到 Sprint 或迭代的概念。

有一处小细节,讲到开发部门领导 H 不满 A 不准备在下周一进行 Release Verification Test,而作者支持 A 的决定,让他继续完成作者分配的工作:熟悉测试文档和环境。此处让人难以理解。通常 Release 级别的测试都是非常重要的,既然发布计划、迭代计划已经规定好要进行这项测试,怎么能说改就改呢?

在作者的回复中,他提到“一月底出货,我有一堆的东西要完成”。而在本案别处,我们没有看到作者对自己测试计划完成工期的明确描述,是否有更短的阶段目标,是否要配合开发组的迭代交付进行频繁地测试。从 10 月份到明年 1 月底,利用整整 3 个月的时间来完成所有测例的编写和测试,而不是根据开发进度和迭代计划,分批、分阶段、有选择的进行测试确认,不断与开发组的工作进行同步、协调、反馈,这么做显然是不敏捷的,依然是一种瀑布思维。
首先,我相信作者有不少做法是敏捷的,后面我会还分析到,这里先谈谈可能不那么敏捷的地方。

星期一,我和D见面,D马上和我说了他的安排,让A在我手下再干三个星期,然后他能转到其他组去。我从D那里得知A上一星期把时间都花在测试数据收集的工作上了,还表示了他对自己现在工作的不适应,希望调离。我可以看得出D和我一样对事态非常失望。

这里我感到奇怪的是,为什么你会从 D 那里得知 A 的工作,你们不是在一起工作吗?你不是已经安排他读文档,写测试计划了吗?他怎么还会我行我素地做别的工作?不服管理?(毕竟他原来做 TL,比你高一级)

难道你们一直就没在一起工作?或者,还没开始在一起工作?

如果是敏捷团队,这种状况不可能发生。因为是每天汇报进度,在一周之前,你就应该向 D 反映他不服从团队既定的工作计划了。
这一段可能是最不敏捷的,而且有点滑稽。可能也是很多读者认为你不敏捷的地方。

下午,我马上发现我的想法是极大错误,A 和开发者开会时净问一些没有一点技术背景的问题。我坐在那里看着开发者艰难地解答他提出的问题,还有他不着边际的回复,心里急啊!最后我坐了35分钟,借口离开去找 B 反映这个发现。我容忍了 A 四个星期的不作为,他已经开始破坏我的全盘测试计划。

你心里急,为什么不去帮他呢?你完全可以当场指出他的不足,进行纠正。你竟然还沉默了 35 分钟,然后向别人去反映他的缺点。这种做法,你们还是一个团队的同事吗?所以,我觉得开这样的会,对你们项目并不重要,真实的目的好像就是为了考验、审查他。

敏捷强调沟通,更强调协作,whole team building。敏捷团队的目标是为了项目目标更快、更好的实现,实现多赢,而不是乐呵呵去看别人的好戏,搞窝里斗,排挤人。

当然,我能理解你的心情,对他已经彻底失望,希望他尽快消失,所以不愿帮助他。你忘了,此时此刻是你对他进行培训教育的最佳时刻。

你竟然还容忍他“四周的不作为”,这是敏捷管理、敏捷团队和敏捷文化所不能容忍的!在四周内,你好像也没有分配 A 做什么实质上的任务。

你说他开始“破坏你的全盘测试计划”,有没有确凿的证据?我们好像只看到 A 眼高手低,能力不行,喜欢拍领导马屁。但这些好像还都不是致命的错误。一个人能力不行,行为不端,可以通过敏捷文化进行批评教育,培训改造。当然,如果 A 确实品行恶劣,缺乏诚信,那就算了。

不管 A 的能力如何,想方设法把一个人赶走,与想法设法把项目完成好,这是两个截然不同的目标,有的时候两者是矛盾的。这方面,我觉得你没有准确地抓住敏捷管理的目标。
我的组主要工作是设计测试案例,开发测试案例是给整个开发组织的最大价值,而不是把时间花费在无意义的流程改进或是为高层收集测试数据,没有人设计开发测试案例,收集的测试数据是没有意义的。而这种鸡毛蒜皮的小事正是 A 最感兴趣的事情。

你是 QA Leader,QA 的主要工作就是设计 test cases,开发 test cases 是整个开发组织的最大价值,不对吧?

什么是质量保证?QA 的工作其实远不只测试,这里我们先缩小讨论范围。即便测试,主要工作、最大价值也不是光设计、开发 test cases 吧。测例设计完了,还要执行测例,验证系统,收集数据,报告结果等等。设计完了,你不执行,不验证,怎么知道这些 test cases 设计的有效性?

还有,你们有没有自动测试?测试工程师很多时候是需要编程的。

所以,作为敏捷 QA,你们的主要工作和最大价值不光是设计/开发测例,更重要的是与开发人员紧密合作,用一切手段通过敏捷迭代尽早测试、自动测试、全面测试(以及其他质保工作),获得及时反馈,从而保障和显著提高系统开发的质量。

如果你们组或者你们公司目前 QA 的主要工作就是停留在设计 test cases 上,那么我觉得你们离敏捷测试、敏捷 QA 的距离还很远。
我仗着我有令箭和 A 的态度转变,就开始给他分配任务,每天和他进行2分钟的Scrum。同时也帮他开始建立开发环境 ...

2 分钟的 Scrum?我怀疑是不是作者的笔误?一个人打个哈欠,伸个懒腰,你有没有计算过,要花几秒钟?

通常,10-15 分钟的 daily stand-up meeting 是比较合理的。对于一个极不信任的人,显然作者尤其应该多花点时间了解和帮助。在本案中,2 分钟,只能说是走走形式而已。

从后面的结果看,事实上作者也没有能防止 A 至少花了 1 周以上的时间去干别的事情,实际没有控制住。或者说,是放任自流。

没有像敏捷 Scrum 所要求的那样,做到每日跟踪、控制进度,这也是很多读者质疑的地方。
为了细致了解你们有多敏捷,我想到了这样几个问题。

1)本案发生在东方,还是西方?从现象看,有点像国内的项目。

2)你们 team 采用的迭代长度是多少?

3)关系比较复杂。你和 B 不是一个 team 吧。那么,你的 team 里 QA 是否只有两个人:你和 A?Team Leader 是你吗?A 是 QA Leader,对不对?

4)你说:“我从 D 那里得知 A 上一星期把时间都花在测试数据收集的工作上了。”

你和 A 在一个 team 里,为什么还要从 D 那里获知 A 的工作情况,有点奇怪。

5)A 调到其他组后,情况如何?是否已经离开你们公司?

6)到目前为止,你有没有理解上司 D 为什么要把 A 分配到你团队的真正原因?

7)你们团队是如何进行绩效考核的?比方,你和 A 如何评估自己的工作,还是有其他人来评估你们的工作?根据什么来评估?

8)你 team 还有几名开发人员,他们对 A 是什么态度?
在本案中,A 无疑是一个令人讨厌的人物。作者后来找到的新人 W 仅用两天就完成了 A 花了三周还未完成的任务,说明 A 的表现实在是太差了。我们看到,A 完全不把作者(新任领导)放在眼里,不听劝戒,自说自话,形成了顶牛和扯皮的局面,作者对此也无计可施,只好最终借助外力将其赶走。所以,问题的关键是,在这三周里,A 为什么敢这么牛?仅仅是因为技术不行,能力不行,或者态度不行?我觉得,作者似乎没有把真正的原因找到。答案其实就隐藏在作者叙述的细节中(流水账的一个好处)。

我觉得,技术、能力和态度差当然是一部分原因,但 A 如此牛的真正原因主要有 2 个:1)岗位职责不清,A 正是利用了过渡期人员管理上的空白;2)A 不认同新分配工作的必要性和重要性。

1)关于岗位职责不清

看一看本案涉及的管理结构。作者,以及另一个团队(A 原来是该团队的 TL)的新 TL-B 其实原来都是 A 的下属,现在 A 被调到作者所在的测试团队,作为作者的下属,从事新的 QA 岗位。实际上,由于 A 原来做 TL 表现不好,被剥夺了领导职位,现在要让他听作者指派任务,心里上肯定会有抵触情绪,而这种情绪在 A 的实际行动上已经表现得非常明显。

既然 A 不愿听自己原来的下属(作者和 B),那么他听谁的呢?他听领导的,测试组的领导 D 和开发组的领导 H。当 H 和 D 介入后,A 明显改变了态度,至少在表面上作出了配合的表演。这说明 A 的很多工作其实是做给领导看的,他很善于逢迎拍马,欺上瞒下。

前面我还提到,A 的有恃无恐很可能与考核不到位有关。A 调换工作后,谁是他的直接上司,谁负责他的绩效考核?

我们看到作者作为 QA Leader,根本拿他没有办法。而 D、H 两位领导,究竟谁管他呢?好像 A 处于无人管的境地。如果作者能够影响他的奖金或津贴等直接利益的发放,说不定他会重视起来。作为管理者,作者解决此问题的关键在于,确切地了解 A 究竟怕什么,在乎什么,什么是他的核心利益,什么会对他形成真正的制约。至少我们知道一点,A 绝不怕作者和 B,他只怕领导,不敢和领导正面冲突,他还是很在意领导印象的。

如果在过渡期内,混来混去,还有工资福利好拿,还可以摆谱,A 有什么可怕的,继续混下去好了。

所以,从一开始,作者就应该与 A 明确上下级关系,明确他的岗位职责和要求。既然 A 来到你们组,就应该与他约法三章(敏捷游戏规则),如果做不到,就应该有相应的惩罚措施,而不是放任他玩 Tom and Jerry 的游戏。

2)关于没有工作认同感

A 对于作者三周的努力、规劝无动于衷,我想恐怕不单纯是技术原因,他不肯去做的根本原因在于:他认为不值得去做!

所以,才出现了这样一种局面:A 对作者阳奉阴违,抵制作者的测试计划。如果要解开这个死结,我想作者可以深入地了解一下:为什么 A 认为你们组的测试计划、测例编写不重要?那么他认为更重要的任务是什么?为什么他认为搞流程改进,收集度量数据,比实际编写测例更重要?他的这种想法,是否得到了公司内部其他什么人的支持?关于这些问题,本案一直都没有彻底搞清楚。

在这方面,我觉得作者缺少与 A 进行 face-to-face 的正面沟通。如果一开始双方能够像朋友那样,从帮助他的角度,交交心,掌握他的真实想法,转变他的思路,而不是一味地排斥、怀疑和指责,那么结局可能会好得多。

如果能力不行,可以培训。如果他固执己见,态度强硬,认为还有更重要的事情去做,那他又何必在作者的组里混上三周呢?其实作者完全可以当着领导 D 和 H 的面,告诉他:没有必要演戏,浪费大家的时间。大家有什么想法意见都放到桌面上来谈,效果会更敏捷。
首先,谁也不可能知道本案真实的情况究竟如何。既然是虚拟的案例讨论,那么读者就可以 brain-storming,探讨各种可能性。下面,我介绍一下一个真正的(IMHO)敏捷团队可能会怎么做,这是根据敏捷思维和敏捷原则推导出来的。不正确、不完整的地方欢迎大家补充。

基本上,我认为敏捷团队(以下用 AT 代表)大概可以在 2 周内解决问题。请注意,我说的是理想情况。

首先,AT 会和 Richard 一样,欢迎 A 的到来。本来就是人手不够,是作者主动向领导要求的,既然派来了,那么可以试一试,AT 欢迎尝试,这符合敏捷原则。

其次,我们会比作者更加坚持原则,注重沟通的透明性和反馈的时效性。在 A 到来后,我们会连同领导 H、D 以及 B 一道开一个 face-to-face 的启动会,立下规矩,明确 A 在新岗位上的职责以及奖惩措施。如果 A 做不到,搞阳奉阴违,那么就请走人(这种人没有基本的诚信)。会议上一旦做出的决定,会后必须遵守执行,除非大家一致同意变更。

不管 Scrum、还是 XP,都会做 daily meeting,有效的 check A 的工作完成情况。所以,不可能发生 A 不管作者的阻拦,连续蛮干三周的情况。既然 A 很听领导的话,那么我们会每隔两、三天通过邮件向所有的干系人 D、H 和 B,汇报 A 的工作情况与进度。

根据 A 的能力情况,只要试一周就可以发现问题了。在周末的 review 会议上探讨 A 的去留。

如果发现 A 能力不行,他愿意继续在测试组工作,那么第二周就会派 A 去接受某种方式的培训,不再介入实际的工作,直到培训合格,符合岗位要求。在培训时,A 的薪资同时会做调整。

如果 A 固执己见,不愿做测试工作,那么第二周起就可以安排调离去其他组。

如果 A 无处可去,也不愿参加培训,不愿做测试工作,不愿接受 Richard 的领导,也没有其他团队欢迎他,而且领导 D 也强烈要求 QA 组暂时寄存 A,那么为了照顾公司人事安排上的困难,我们可以暂时接收 A,但会采取冷藏方式,不让 A 参加实际的项目工作和会议,以免影响士气,干扰项目进展。此时,对 A 的薪资也必须调整,头一个月一般只拿基本工资(或更少的比例),相当于内部下岗。如果第二个月状况仍然没有改善,通常可以考虑解聘了。
看完整篇故事,总体上我赞成作者和 B 的作法,A 的工作态度有问题,不适合留在项目组里。

但我同时也看到了一种可能不太好的情绪,作者为什么连自己的上司 D 也讨厌?牛到不把自己的上司甚至老板都放在眼里,恐怕不是一个好苗头。

D 只是个经理,他不做技术性的工作,是无法了解下属的真实情况。这是一个典型的例子,不懂技术也不懂下属能力的经理会误判下属的真实情况。或多或少的蛮横安排资源,不接受团队回馈也是 D 所犯的错误。敏捷开发的一个重要手段是团队自我管理,也就是在阵地上的士兵比在指挥所的军官更了解战场战况,有时将在外,必须拥有“君命有所不受”的权利。上司 D 经常如此蛮横地瞎指挥,下属一般都以自己最好的判断来尽力实施他的要求,但是做不到的时候也只有和他汇报,获得他的理解,我想这是很多技术人员经常碰到的问题。

软件研发的敏捷文化其实更强调一种包容与和谐的文化。敏捷并不是要把不参与技术工作的人,不能立马增值、兑现和提升生产率的东西,统统都看成自己的对立面和敌人。眼里只有“代码”,而没有“人”,我想这是很多一些技术人员经常容易犯的错误。
1)Richard,你说:

“让我认识到如何使用敏捷教条对管理方面的问题进行分析,如何采取合适策略来解决此类问题。”

不知道你所说的“敏捷教条”是何意?如果你认为敏捷是教条(dogmatic)的话,肯定是误解。西方的敏捷大师们提出敏捷思想和方法,正是为了反对传统的教条。当敏捷也成为教条时,表明它也该进入坟墓了。

敏捷必须反对教条。

2)文题是“一个敏捷教练中止越轨列车的故事”

而在文中,我们看到你担任的是 QA Leader 或者 Team Leader,并没有介绍你是如何做 Agile Coach 的。我想,Agile Coach 与 QAL、TL 的区别还是很大的。所以,本文讲的并不是 Agile Coach 的故事。

你提到:“第一次对项目和团队进行管理,我对自己的表现感到十分满意,近几年的敏捷开发实践毕竟是学有所成。但是我也意识到自己要好好学习更好人际沟通,在管理方面更加完善自己的能力。”、“我必须承认,我的管理经验是不足的。”

我从来没有听说过,哪个人,没有什么管理经验,第一次从事管理,就可以自诩为 Agile Coach 的,这样的 Agile Coach 是否太“廉价”了?

联系到你文中的其他一些文字,尽管我看到你“意识到自己要好好学习更好人际沟通,在管理方面更加完善自己的能力”,我还是看到有一种自满的情绪在增长。

你是否真的觉得自己从此跨上了管理者的“仕途”?对于成功的敏捷管理者,不存在什么敏捷的教条。实际上,作为第 2 条道路,成为一名资深的敏捷技术高手也未尝不可。这是我对你个人职业发展的一点建议。

<帮助> <全部评论> 共 0 个主题 0 条评论 (WhenAgileMeetsPolitics)
首页 | 使用指南 | 站点地图 | 版权声明 | 联系方法 | © 2005-2022 张恂 版权所有. 沪ICP备15017521号-2