BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

文章:一个敏捷教练中止越轨列车的故事

| 作者 Richard H.B. Sun 关注 0 他的粉丝 发布于 2007年11月20日. 估计阅读时间: 1 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

本文作者是一个敏捷教练,自称没有太多的管理经验,在最近一次对下属的工作处理过程中“饱受打击”。他对这段经历进行了深刻的总结,对如何使用敏捷教条对管理问题进行分析有了新的感悟,以及如何采取合适策略来解决此类问题。

沟通对于任何一个团队的重要性都不言而喻,沟通的好,皆大欢喜,沟通的不好则陷入到“办公室政治”的争斗之中,不得开心颜。对于敏捷教练而言,重要的就是能够及时地发现问题,最好在问题初次抬头时就能够发现,然后完善解决。但事实证明,这不是一件容易的事情,因为既然是类管理的工作,那么就牵涉到人文、心理、性格等诸多因素。本文作者作为文中所述事情的亲身经历者,就是因为一直没有下决心,或者说从一开始就没有采取正确的措施去处理问题,白白耗费了项目的开发时间。

作者在文末总结到:

我的错误就是我怀疑了但是没有及时直接向D沟通我的担忧,但是就算我及时沟通了,也不会给我多大帮助。因为当时的人事资源就是那样的,我没有拒绝的余地。我所做对的,是对我所能够控制的局面进行了有效的监控;我利用了我所学的敏捷开发知识准确地判断了事态可能的发展;我对事态发展作出了一步步的盘算及后果的考虑,作出了先影响甚至控制A的战略,然后作出了如果A不合作,必须让更高管理层替我解决问题的战略。

我想如果你现在置身于一个团队之中,更巧地是你还大小是个“头目”,那么本文一定会给你多多少少的感触,也欢迎你发表自己对团队管理的评论!

阅读全文:一个敏捷教练中止越轨列车的故事

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

题目有点吓人 by Xu Alex

其实这和Scrum没什么关系。放在一般的项目里同样有这种问题。这是项目组人员管理的问题。通常好的做法是先任命Team Leader,然后由HR提供人员来供TL挑选。当然现实中未必有这么理想。但是至少TL应该具有拒绝不合适的人员加入的权利。

在Scrum的实践中,现在推荐的一种做法是签合同(申明)。有两种合同,一个是TM和Scrum Master,Product Owner签的,大家明确一下职责并发誓遵守,每个TM加入的时候都要签字。另一个是scrum master和公司管理层签的,确保整个项目的执行能够有相对独立的空间,尽量少的受到管理层的骚扰。当然Scrum master应该具有权利,清除出破坏规则的人。

当然你说的是现实,很无奈!

支持及反对 by Jacky Li

我在www.infoq.com/cn/news/2007/07/cultivating-agile... 一文中曾经说过,“我们会无缘无故的讨厌一件事情,会因为看一个人不顺眼而敌视他所说的一切,会骄傲自满,会自私自利,会固步自封,会讳疾忌医。也许,我们并不会因为知道敏捷可以帮助我们为客户交付最大的价值而轻易接受它,在实践中改变认知。”

我们不能空喊着“个体与交互胜过过程与工具”,而不去思考如何塑造有利于个体与交互的环境,解决对个体与交互造成制约的种种问题。从这一点上来看,作者的故事还是很有启发性的。

但是,我感觉这个不应该算是和敏捷开发有什么关系的事情,难道除了敏捷以外,我们就应该“容忍开发进度中任何能够造成进度停滞的问题”么?协调能力,沟通技巧,难道不应该是所有优秀的team leader理应具备的素质么?

“which is more important, person or process?”Agile和CMMI会给出不同的答案,但是如果我们相信Agile Manifesto的正确性,我们就不应该再继续试图把敏捷从软件开发中剥离开来。

敏捷,并不是特立独行的一份子,而是某种可以帮助我们认识软件开发真正价值所在、核心所在的思维方式,行为方式,正是因为在传统软件开发中存在着错误的认知,所以我们在提倡敏捷,宣传敏捷,以帮助开发者从误区中走出,改善开发过程,提高开发效率。但这并不代表着我们可以把一切归于敏捷,或是更有甚者,用敏捷来标榜自己(此处并非攻击作者,而是笔者另见的他人)。

使用敏捷开发,敏捷项目管理的我们,只是做了该做的事情而已。

Re: 支持及反对 by Richard Sun

我是本文作者,之所以写这篇文章的目的是,敏捷开发中很重要的一个环节是发现问题,从根源上解决这个问题。很多读者对事实的实际发生根本不了解,所以会误解为我给这个开发者穿小鞋。事实上,这个开发者"A"从一开始就说“我会帮助你完成该完成的。”暗地里,他在三个星期中什么都没有做。我和他沟通无数次说,你要专心把一件工作做完再转到另一工作上,而不是这里忙一点,那里忙一点,最后什么都没有做完。我把自己的想法很清楚地传达给他 -- 我想看到实质性的工作进展。敏捷需要清晰的交流,我觉得我做得很好了。和我一起工作的"B"同样做了口头,文字上的交流。我和"B"在三个星期内做出的努力得到的结果是0。

最近我和文中的"B",还发现"A"从被雇用以后的八个月里,总共提交了15次代码,其他QA提交了百次以上。我和"B"都发现"A"根本就不愿意在我们组里工作。与其让他不工作,不如将其调离我们组,这就是我和B最后所做的。

还有,最后"D"分配给我一个新的人手“W”,我和“W”在两天内就完成了"A"本来三个星期内该做甚至能做得更多的事情。所以请不要提醒我说沟通很重要,或者这不是敏捷。你要是站在我的立场上,你也会作出我的选择,因为“B”都这么做了。

Re: 支持及反对 by 杜 军

"最近我和文中的"B",还发现"A"从被雇用以后的八个月里,总共提交了15次代码,其他QA提交了百次以上。我和"B"都发现"A"根本就不愿意在我们组里工作。与其让他不工作,不如将其调离我们组,这就是我和B最后所做的。"

为什么这个人如此不愿意在你们组里工作? 既然他是所谓的高级工程师,难道此人就如此一无是处? 你了解你的这个手下到底在想什么吗?如果你能指到此人的真实想法然后在做决定是否会更好一些?

很明显是标题党 by t t

但是内容很不错。

Re: 支持及反对 by Jacky Li

我的意思是,这个故事没必要往敏捷身上套,你说,“敏捷开发中很重要的一个环节是发现问题,从根源上解决这个问题”,但是,难道不使用敏捷开发的软件开发流程,“发现问题解决问题”就不是它们的重要环节了么?

“敏捷需要清晰的交流”,这句话没错,但是,我的看法是,软件开发需要清晰的交流。不要硬生生的把敏捷从软件开发中隔离出来。

Re: 支持及反对 by 熊 节

> 敏捷开发中很重要的一个环节是发现问题,从根源上解决这个问题。

但我在文中看不出你有什么机制或者方法来发现“开发者A”所存在的问题。你提到他的问题,在我看来,都是你“认为”他“应该”怎么怎么。好吧,他没有照你“认为应该”的那样去做。so what?他造成了什么损害?哦,你“心里急啊”。仅此而已吗?难怪你老板一直把他扔在你组里呢。

你号称自己在做敏捷,号称自己很看重发现问题解决问题,可是对于“开发者A”的问题在我看来你就没有认真的去发现。如果你做了,你的数字在哪里?你的证据在哪里?如果你有他给项目造成损害的数字和证据在,老板还会坚持让他在你项目里呆着吗?

即便不说发现问题,你也同样没有体现出解决问题的决心和行动力,当然这就扯远了,打住。

Re: 支持及反对 by Jacky Li

>让我认识到如何使用敏捷教条对管理方面的问题进行分析

再来看一下文章第一段的这句话,敏捷都已经成教条了呢~~

Re: 题目有点吓人 by Jacky Li

>我认为作者在自己的工作中很好地实践了敏捷的思想,我辈还是不要站着说话不腰疼的好!

我还是那句话,作者的做法完全无关敏捷,而是一个正常的软件开发流程所应做的。而且,你如何知道我是站着说话不腰疼?

Re: 题目有点吓人 by Xu Alex

上 里巴人:
我想你没有明白我的意思,这里所说的"合同"不是法律层面的.只是一种约定,为了确保Scrum这种游戏能够顺利的进行下去。这就好像我们要进行一场足球比赛,那么每个相关的人员就要遵守自己的规则。包括球员,裁判,教练以及观众。如果这个前提不能够满足,那么比赛就无法正常进行。

所以我的观点和 凉粉 小刀一样,这个问题不是比赛中的问题,而是比赛前的问题。不管你是想用442,还是541,这种队员都不应该派上场。也就是说,和你用什么管理方式无关。

作者提到了Scrum,我猜想你是在用Scrum,并且担当Scrum Master的角色。有一点不解的是,Scrum Master不应该为TM分配任务,而是应该由所有TMs一起来讨论,设立任务。然后,每个TM根据自己的喜好来认领这些任务。此外,好像你也没有进行daily Scrum,要不然也不会到后来才知道A很多工作都没做。

最后提一点建议。中国人都有摸石头过河的习惯,但通常河上都是有桥的。只是你要往前多走些路才可以发现。

作者回复答疑 by Richard Sun

我是作者,进行更进一步的答疑。

首先,这个"A"一上岗我就知道他有点不对头。当时他的工作和我的不冲突,所以我也没有仔细观察他的工作行为。当"D"我的直系上司把他分配给我时,我就知道这人会出问题,有读者问得好,既然知道"A"不行,为什么不直接就处理掉。这就是敏捷有时无法做到的--我要合理安排我和直系上司的关系,我不能直接反对他的决定,当时我没有直接的理由回绝,而且我应该给我的上司"The benefit of the doubts"。所以我没有直接回绝。

"A"加盟以后,我确实存在幻想说,疏导一下,沟通一下,甚至威逼利诱一下,能让他迷途知返。要知道那时的"A"已经6个月没写一个QA Test Case。我想万不得已强势干预一下,他也能迷途知返,迅速进入角色。结果三个星期下来我和"B"没有让他做出一点成绩。他一边用在我的组里做事搪塞其他人,一边又和我搪塞他在忙一些不重要数据收集任务。我的老天爷,一月底出货,我有一堆的东西要完成,不能这样浪费我的时间啊。

由于原有篇幅有限(编辑限制的),我实在没有更多的文字表达我的问题--不管我怎么威逼利诱,这家伙就是不做正事。整到我要坐在他身旁,监视他的一举一动。大家要知道,这根本就不是Scrum,或Pair Programming了,这等于是让我把自己设计测试案例的时间花费在“管理”这个不愿做事的人身上。所以我最后不得不使出狠招,把他踢出我的小组。

没想到我第一次作镇领导,就要做这种事。而且还耽误了一些进度。好在我懂点敏捷开发,知道尽早排除问题,及时向我的直系上司汇报问题,并请求干预。让我感到悲哀的是,大家都看见这个“A”是个不务正业的人,开发者知道,我们测试也知道,开发者的上司也知道,就是我的上司“D”不知道,天真地认为他能帮我解决问题,结果,我还要用这么极端的方法把他踢出小组。所有的人都用一种“他现在还没有做出太大的破坏先留着他”的看法失望地等待他能改变。最后还要我来直接干预,这就是我的失望,我们的公司并不敏捷,我所能做到的是,尽可能快地解决问题,我给了这个人三个星期,从某些人的看法来讲已经很不敏捷了。我只是觉得我还是很敏捷地处理了这件事。

Re: 作者回复答疑 by Jacky Li

>好在我懂点敏捷开发,知道尽早排除问题

那就是说,不懂敏捷开发的人,就不知道尽早排除问题了?这不是胡扯是什么?

当韩非子说“千丈之堤毁于蚁穴”的时候,敏捷在哪里?当乐府说“君子防未然,不处嫌疑间”的时候,敏捷在哪里?当孙子说“水无常势,兵无常形,能因敌变化而取胜者谓之神”的时候,敏捷又在哪里?

楼主仿佛是要千方百计的要把敏捷推上神坛,让不懂敏捷或是初涉敏捷的人觉得敏捷深不可测,于是“敏捷教练”的头衔就会罩上一层光环。久而久之,在被楼主影响的人的心中,敏捷就会变成一个buzzword,变成“宗教信仰”——www.infoq.com/cn/news/2007/10/religous-continued

作者厌恶 A 合理,但为什么连自己的上司 D 也讨厌? by Zhang Charlie

看完整篇故事,总体上我赞成作者和 B 的作法,A 的工作态度有问题,不适合留在项目组里。

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


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


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

太极敏捷派掌门 张恂
www.zhangxun.com

为什么用敏捷来命题 by Richard Sun

作者答疑,

之所以用敏捷,我对这件事情的处理是有一个比较的,"A"在八个月内没有做任何正事,除了把手上的活分配给他人,自己就是关在办公室里没做一点事情。我在三个星期内,收集了证据,暴露了他的不作为给我们的直系上司,并将他调离我们组,解决了这个问题。这里就有一个比较,八个月很多人对他的容忍,让他白拿八个月的工资。和三个星期,给他一次次机会,没有效果,最后让上司出面解决。这就是敏捷了。

我记得我接受的训练,流程必须是流畅的,象生产线,没有失误阻止产品流过生产线,任何阻止生产流程的失误必须从根源解决。只有这样才能完全根除浪费,达到敏捷。我正是运用了我接受过的训练,解决了问题。不仅解决了我的问题,还帮助我的同事"B"解决了同样的问题。“A”不在我的组里破,也调离了B的组。

对我写的有疑问的朋友,我可以保证,我是一个很容易让人喜欢的人物,我很单纯,很直板,有时过于爱憎分明,我是个Team Player。我不能说是我是一个优秀的Scrum Master,但是让我进入一个Agile team,你肯定会喜欢我的配合,我对事情的判断,我能够提问,我能够把事情做完做好等等品质。说不定你会有机会和我合作,那时你就知道我这个人是多么可爱

有扯淡的趋势,建议打住 by 熊 节

> 软件研发的敏捷文化其实更强调一种包容与和谐的文化。敏捷并不是要把不参与技术工作的人,不能立马增值、兑现和提升生产率的东西,统统都看成自己的对立面和敌人。

不能立即兑现不等于没有未来的预期收益,消除浪费不等于不做远期投资。远期投资是否值得做,往简单了说,用财务技术就可以算出来。这都纯粹是技术活,别动不动的就扯什么文化的淡。首先把“把浪费看成对立面和敌人”曲解为“把不能立马兑现的东西统统看成对立面和敌人”,然后拿这个自己立起来的靶子来炮轰“很多一些技术人员”,最后说自己掌握了“包容与和谐的文化”,整就是一个扯淡的套路。打住吧。

熊节胡扯敏捷 XP by Zhang Charlie

Re: 为什么用敏捷来命题 by 熊 小

Kent Beck在极限编程第二版中,引用了约束理论,我觉得不妨适用在这里。无论是人,还是流程,只要构成了对当前项目影响最大、产生浪费最多的阻碍因素,也就是瓶颈,就应该尽量移除之。从这个角度来看,如果一开始A没有构成最大的瓶颈,暂时放着问题也不大,随着项目的进程,他成了瓶颈,那就搬走吧。
ps:约束理论

Re: 为什么用敏捷来命题 by 熊 小

Re: 熊节胡扯敏捷 XP by Jacky Li

这个~~熊节楼上的话是在就事论事啊~~

Re: 熊节胡扯敏捷 XP by Xu Alex

我现在对"敏捷"这个词有点过敏。前几个月,有一期《程序员》的标题叫“敏捷的三重境界”。看得我只起鸡皮疙瘩。

呵呵。打住!

本文完全是敏捷实践的反例 by 曹 云飞

文章的题目改为:一个敏捷初哥放任越轨列车的故事。这样更符合文章的内容。同学们以批判断的眼光来看作者对项目中问题的反应,作为教训,不要再犯类似作者的错误。

支持你的可爱!但关于敏捷 ... by Zhang Charlie

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

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

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

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

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

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

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

太极敏捷派掌门 张恂
www.zhangxun.com

能否分享一下你的具体理由? by Zhang Charlie

why?

Re: 能否分享一下你的具体理由? by Jacky Li

>why?

掌门这话是跟谁说呢?

cao yunfei by Zhang Charlie

呵呵,不用客气。

>why?

掌门这话是跟谁说呢?

不要对一位只有三年编程经验的缺德记者抱有任何幻想。 by Zhang Charlie

有感而发,凉粉,thanks!

by Zhang Charlie

从 1 万元的,到 20 万元的都有,您要哪一款?

有感而发。

hehe,敏捷是款时装 by Zhang Charlie

从 1 万元的,到 20 万元的,都有,您要哪一款?

有感而发 ...

我现在对"敏捷"这个词有点过敏。前几个月,有一期《程序员》的标题叫“敏捷的三重境界”。看得我只起鸡皮疙瘩。

呵呵。打住!

Re: 能否分享一下你的具体理由? by 曹 云飞

“那个时候我就已经预见了今天我不得不作出的处理。”
实际上从一开始作者就知道A的情况,A的弱点。
“我知道,这样的人不能重用,我对他没有信任感。”
在这样的认识前提下,作者应该作出的反应是什么呢?我觉得应该是细粒度的监控,充分的沟通,每天早上和A来个2分钟的meeting,每周起码两次小组scrum meeting。但是作者没有做这些,“我在周一分配了任务让他阅读文档,我给了他一个星期。” 对于一个你不信任的人,你知道弱点的人,为什么会放任他自己干一个星期而不管不问?整个火车越轨的过程长达3个月,太长了!作者的反应太不敏捷了。
抛开敏捷不谈,任何管理者,对于同事在3个月的时间里“不出活”的现象也无法容忍,绝对不能坐视事态发展3个月。实际上最多一个月,作者就应该解决问题,3个月才解决已经失职了。

Re: 不要对一位只有三年编程经验的缺德记者抱有任何幻想。 by Jacky Li

有人身攻击的倾向了,建议打住

Re: 不要对一位只有三年编程经验的缺德记者抱有任何幻想。 by blogbin avatar

和敏捷有点关系,不过题目改为上班这点事,可能更为贴切一些

不错,作者有点先入为主 ... by Zhang Charlie

他所做的一切好像就是为了用证据来证明 A 的无能,证明自己一开始就下的结论。为了证明,就需要时间来等待,却忘了敏捷项目应该做的事和达到的效果。

Richard 在前面也亮出了他对“敏捷”的定义和理解,他认定这就是敏捷,显然是非常片面的。

我觉得在这起事件中,A 的越轨毫无悬念,本在大家意料之中,而作者对于敏捷的误解才是真正“出轨的列车”,这可能是一个有趣的新发现。

是三个星期!!不是三个月!!! by Richard Sun

作者再次答疑,--是三个星期!!不是三个月!!!
我容忍了"A"三个星期,另外一个组容忍了八个月。不要搞错!

如果是三周,我觉得在合理范围之内。兼一点建议 by Zhang Charlie

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

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

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

另外,由于比重设置不当,你对你们团队是如何实际运用 Scrum 或者敏捷方法,谈到的较少。这方面能否再介绍一下,作一些补充?

这样我想这个案例才更完整,对大家更有帮助。

浓缩的才是精华:本案的可贵价值! by Zhang Charlie

我想本案可以用一句话概括成:

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

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

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

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

敏捷团队对于此类问题,到底应该怎么做?怎样做是以人为本,而且风险更小?值得我们进一步探讨。

Re: 是三个星期!!不是三个月!!! by Jacky Li

这只能说明能看完这篇流水帐就已经不容易了,更何况还要看懂细节

建议以后 InfoQ 的案例故事这样写: by Zhang Charlie

1)采用“结构化”的案例分析,尽量不要记流水账。

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

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

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

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

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

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

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

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

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

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

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

先提这两点 ...

Richard,有几个重要问题请解答: by Zhang Charlie

为了细致了解你们有多敏捷,我想到了这样几个问题。

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 是什么态度?

thanks

敏捷教条,敏捷教练? by Zhang Charlie

1)Richard,你说:

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

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

敏捷必须反对教条。

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

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

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

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

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

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

www.zhangxun.com

本案的不敏捷之处(一) by Zhang Charlie

首先,我相信作者有不少做法是敏捷的,后面我会还分析到,这里先谈谈可能不那么敏捷的地方。


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


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

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

如果是敏捷团队,这种状况不可能发生。因为是每天汇报进度,在一周之前,你就应该向 D 反映他不服从团队既定的工作计划了。

本案的不敏捷之处(二) by Zhang Charlie

这一段可能是最不敏捷的,而且有点滑稽。可能也是很多读者认为你不敏捷的地方。


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


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

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

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

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

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

不管 A 的能力如何,想方设法把一个人赶走,与想法设法把项目完成好,这是两个截然不同的目标,有的时候两者是矛盾的。这方面,我觉得你没有准确地抓住敏捷管理的目标。

本案的不敏捷之处(三):关于 QA 的主要工作 by Zhang Charlie


我的组主要工作是设计测试案例开发测试案例是给整个开发组织的最大价值,而不是把时间花费在无意义的流程改进或是为高层收集测试数据,没有人设计开发测试案例,收集的测试数据是没有意义的。而这种鸡毛蒜皮的小事正是 A 最感兴趣的事情。


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

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

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

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

如果你们组或者你们公司目前 QA 的主要工作就是停留在设计 test cases 上,那么我觉得你们离敏捷测试、敏捷 QA 的距离还很远。

不错,你能在三周内解决问题确实很敏捷了! by Zhang Charlie

你已经做到了威逼利诱,想到了各种手段,支持。

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

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

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

像这样的老油条,的确不应该多留。

总结:敏捷不敏捷,本案其实分为两个部分! by Zhang Charlie

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

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

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

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

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

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

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

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

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

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

太极敏捷派
www.zhangxun.com

Re: 总结:敏捷不敏捷,本案其实分为两个部分! by Jacky Li

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

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

硬要把这个往敏捷上靠,我觉得就是扯淡

你这个问题提得好!但这不是扯谈 ... by Zhang Charlie

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

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

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

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

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

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

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

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

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

这个问题,很可能是本案带给我们的最大收获之一(窃以为)。

你对我总结的其他内容,有何意见? by Zhang Charlie

_empty_

本案的不敏捷之处(四):留于形式的 Scrum by Zhang Charlie


我仗着我有令箭和 A 的态度转变,就开始给他分配任务,每天和他进行2分钟的Scrum。同时也帮他开始建立开发环境 ...


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

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

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

没有像敏捷 Scrum 所要求的那样,做到每日跟踪、控制进度,这也是很多读者质疑的地方。

总结:为什么说作者是敏捷的? by Zhang Charlie

对作者的努力全盘否定显然是不对的。作者在处理 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 为什么敢这么牛?真正的原因是 ... by Zhang Charlie

在本案中,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 的面,告诉他:没有必要演戏,浪费大家的时间。大家有什么想法意见都放到桌面上来谈,效果会更敏捷。

Re: 总结:A 为什么敢这么牛?真正的原因是 ... by 白 木强

教主啊教主:
也许您真的经验丰富,技术高超。但是您是不是也该明白,人没有全知全能的,您也有不知道的,不会的,不懂得。
绩效考核是不是就管发人工资,是不是直接领导就该有左右下属工资和奖金数目的权利,这些都是没有定论的。包括领导是不是该知道下属的收入情况就是个要探讨的问题。
既然您问的是这个事情在东方还是西方,那么您就是默认这个事情还不清楚。而且即便是东方,日本企业,韩国企业,新加坡企业,国内企业,大马的企业,印度的企业还是很有些差别的。即使是国内的企业,这个方面也会很有所差别。您就别在这个上面毁掉您的英名好吗?要发表意见,您也还是要先自己搞清楚吧。
至少您要问问明白,他们是用啥做的绩效啊?是不是这么时髦用的平衡积分卡啊,是不是搞得全面绩效考核啊,还是自己搞得独特的绩效考察方法啊。这些您都不问,上来就说三道四,会出问题的啊。
教主您如果希望到处宣扬您其实很多地方也不懂,至少绩效考核很不通,那您就随便了。不过我还是建议您,既然要开门立派,还是检点一下为好,省的别别人抓住的马脚去踢场子。gigix不就是因为这个被你死揪住不放到今天吗?您打了他这么久,您为何就不从gigix身上吸取点教训呢?
你要是不喜欢听,就当我没说。反正面子是您自己的,和我没干系。

您误解了,我又没说死,愿听高见 ... by Zhang Charlie

首先,张恂是敏捷教练,不是什么敏捷教主,您没必要自降身份。我当然也有不知道的,不会的,不懂得。这点,张恂很明白。既然我们敢开门立派,那么就不怕别人批评,不怕暴露自己的错误,相反欢迎大家的批评,尤其是有专业水准的批评。这点与 gigix 有显著不同。

我完全理解你说的意思,同时感谢你反映了很多术语,我的总结中并没有排斥这些可能性。可是你怎么不问问我会不会绩效考核,有没有做过绩效考评,怎么就知道我很不懂,很不通了?

我前面已经问过作者了,大概您没看到:他们是什么类型的公司,绩效考核是怎么做的。他一直不答,我只好根据最大可能性猜测了。我分析的情况,都是可能性,不是什么定论。既然是案例讨论,谁也不可能知道真实的情况到底如何,那么就应该允许大家探讨各种可能性。

没错,从 gigix 哪里,我们已经学到了很多经验教训,后面还会有专著发表。最重要的一点是:作为专业程序员,一定要有自知之明,不能自以为是,以及“做人要厚道”等等。

听你的意思,你有话想说。那么就痛快地讲出来,不要拐弯抹角的。我们很乐意向您学习!

太极敏捷派
www.zhangxun.com



教主啊教主:
也许您真的经验丰富,技术高超。但是您是不是也该明白,人没有全知全能的,您也有不知道的,不会的,不懂得。
绩效考核是不是就管发人工资,是不是直接领导就该有左右下属工资和奖金数目的权利,这些都是没有定论的。包括领导是不是该知道下属的收入情况就是个要探讨的问题。
既然您问的是这个事情在东方还是西方,那么您就是默认这个事情还不清楚。而且即便是东方,日本企业,韩国企业,新加坡企业,国内企业,大马的企业,印度的企业还是很有些差别的。即使是国内的企业,这个方面也会很有所差别。您就别在这个上面毁掉您的英名好吗?要发表意见,您也还是要先自己搞清楚吧。
至少您要问问明白,他们是用啥做的绩效啊?是不是这么时髦用的平衡积分卡啊,是不是搞得全面绩效考核啊,还是自己搞得独特的绩效考察方法啊。这些您都不问,上来就说三道四,会出问题的啊。
教主您如果希望到处宣扬您其实很多地方也不懂,至少绩效考核很不通,那您就随便了。不过我还是建议您,既然要开门立派,还是检点一下为好,省的别别人抓住的马脚去踢场子。gigix不就是因为这个被你死揪住不放到今天吗?您打了他这么久,您为何就不从gigix身上吸取点教训呢?
你要是不喜欢听,就当我没说。反正面子是您自己的,和我没干系。

对于本案,一个真正敏捷的团队会如何做?(一) by Zhang Charlie

首先,谁也不可能知道本案真实的情况究竟如何。既然是虚拟的案例讨论,那么读者就可以 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 的薪资也必须调整,头一个月一般只拿基本工资(或更少的比例),相当于内部下岗。如果第二个月状况仍然没有改善,通常可以考虑解聘了。

Re: 您误解了,我又没说死,愿听高见 ... by 白 木强

教主大人,我一点也没有误解你,并且我越来越相信你和gigix本就是一路。不过这也没有任何关系,本身我就认为一个人可以从他找的对手看出个大概。然而我还是关心一些其他的事情,免得我看错了,毕竟我不是神仙,不能说上下都知500年。
不过我还死先解释一下,免得您搞错一些基本的事情。从广义上讲,任何人都做过绩效考评,任何人也都会做绩效考评。这是因为绩效考评可以算人类最基本的活动之一了。不过话要说回来,如果要是从专业的角度看,绩效考评又是一项很专业,并且要求很高的工作。在一个组织内容往往是所有人都会参与到绩效考评的活动中来,并且按照要求也必须学会如何进行绩效考评,否则绩效考评就失去了其作用。但是并不是做了、会了就说明懂了,而懂了更不说明就是通了。而就我观察您问的问题,和思考分析问题的思路,就已经看出您既不懂,更谈不上通。
当然您是教主,您又声称自己同gigix完全不同。您说您是专业程序员,有自知之明,不自以为是。那么你是否可以抽出宝贵的时间,去找一本人力资源的基础书籍,或者找一个人力资源方面的专业人士,请教一下,学习一下。然后再发表绩效考核如何如何的讲话呢?
其实我的意思再明白没有了,就是不说本专业的事情就别拿出专业以至于专家的口吻说话。这点我看您比gigix还差,他至少只在软件开发方面絮絮叨叨的,您却在所有与软件开发相关的领域都敢于发表看法。我说你们两个真是彼此彼此,各有千秋了。
至于您说您要发表啥专著,我建议您还是要抓住主题,软件开发外的事情还是别涉及。
敏捷我不太懂,毕竟是个新东西,我也仅仅是在学习和考察,毕竟工作中要遇到。这个方面如果您是专家,就请您多在这里做文章。这方面的人我也接触过几个,但是要么是学院派,固守与死板的系统;要么事狂飙派,很难控制。而国内几个最早推荐敏捷的人,我也都考察过,似乎里面没有您的踪影。而您的种种说法,我很怀疑您是真的敏捷。当然我这个是我外行人的疑问,不过这个事情又和我的工作很有关系,因此我特别希望找到答案。而您的咄咄逼人我确实不喜欢,至少您让我也摆出一副攻击的架势,免得反被攻击。而至少在我这个外行人眼里,这个讨论中有很多重要的内容您回避了。当然这可能是您认为这些本与敏捷无关,又可能会产生争议。但是这越发让我对您的疑虑增加起来。
至少目前我可以明确的说,你同我在国外接触的敏捷方面的人士的说法和观点有很大不同。能不能说这些不同,就是您的中国式敏捷的基础呢?这里另外一个疑虑,就是您的这些不同,究竟是手段方式上的不同,还是思想和根基上的不同呢?如果真的是如我的直觉告诉我,您是手段和方式上的类似,思想和基础目标上的不同,您大可不必搭车敏捷。比较一个学说的价值,不是能用它属于什么学派来衡量的。
叫您教主,其实是我真的找不到合适的词汇称号来表达我的意思。因为您似乎全知全能的,对各个方面都发表意见。而您对我最感兴趣的地方,却让我有最多的疑虑。当然这也是正常的,毕竟我是不是行业内搞技术的,也没有这个方面的经历,自然很多地方体会不到。不过既然我都有疑问,那么是不是其他有专业背景的也会有疑问呢?
其实我本不想发言,只不过今天注册了一个号,发表一次只针对自己专业方面的意见。同时也表达一些非我专业方面,但是我很关心的一些疑问。应该以后我不会发言了,因为在这里我实在只有看的资格,没有发言的资格。

我有在攻击你吗,有必要这么激动吗? by Zhang Charlie

我不是说了,要向你学习吗?扯别的东西,没有任何意义。

我态度这么诚恳,您还要发火,有必要吗?

张恂什么地方咄咄逼人了,你怎么不说自己咄咄逼人。你看,是你的话多,还是我的话多。我就贴了一个“掌门”的标签,本来就是开玩笑的,有必要激动吗。来点幽默行不行?

既然您承认自己是非专业的,那么我提醒您,分析、阐述问题要讲逻辑性,不要盲目下结论,而且最好概括点。

本案中,作者只字未提“绩效考核”,这是事实吧?而我觉得这可能是一个关键问题,所以向他询问,并给出了自己的建议。这有何错?

还有,哪些地方,我们回避了?您有哪些疑虑?

你直说好了,吞吞吐吐地干嘛?

你觉得不妥,你说好了,绩效考核应该怎么做?我们洗耳恭听。

哪来这么大火气?大家都是成年人了,实在没必要。

你愿意扯 gigix,欢迎到我的网站上去扯。在这里扯,偏题了。


而您的咄咄逼人我确实不喜欢,至少您让我也摆出一副攻击的架势,免得反被攻击。而至少在我这个外行人眼里,这个讨论中有很多重要的内容您回避了。当然这可能是您认为这些本与敏捷无关,又可能会产生争议。但是这越发让我对您的疑虑增加起来。

欢迎指教 ... by Zhang Charlie

木强先生,我猜您大概是一位 HR,那么您直说好了,您觉得我下面的这段分析以及其他有关绩效考核的分析评论有什么错误,您觉得正确的应该怎么样,欢迎指教?


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

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

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

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

Re: 我有在攻击你吗,有必要这么激动吗? by 白 木强

看来我听说的关于您的事情是真的,至少从你这个发言中我看到您是很容易被激怒的。
不过在我等待您发火的同时,我特意请教了一个给我们公司实施Srum的顾问。当然可能存在翻译方面的问题,他对您所发表的见解也很觉得疑惑。但是抱歉,我不是这个方面的专业,我也不好转述他的意见。而我给他看了您的网站,自然也可能是翻译的原因,他对您的说法印象不是很好。具体原因他就没有说,大概是他觉得没有必要给我做专业上的解释。当然这里也可能存在他从业务上考虑,不希望我们在国内物色本地人才的缘故。不过我个人觉得后者不是太有可能,因为我相信他的职业操守。
当然请您一定要理解,我一直是很冷静而且步调很好的按照预先的计划,不带半点感情色彩的去和您讨论这个事情。当然我有我的小技巧,小圈套。毕竟我们都是成年人,如果不能克服对方的这些小伎俩,只能说太不成熟。这在技术人员身上不是什么大的问题,在管理和咨询方面的人讲起了就是巨大的缺陷。
当然最后我需要给您解答你认为我为什么要说,您的分析有问题,说法有问题的。当然我觉得这些都是问题,错误还谈不上,毕竟国内有国内的情况,风俗也不一样。
其实很简单,您首先提起了绩效考核这个问题。而这个问题至少在我们企业是个敏感话题,员工保密条例中将其列为商业秘密。当然国内大家可能没有这个意识,所以就很不在意这个事情。当然其他您的很多关于分配和考评的说法,都还应该继续推敲。不过由于前提条件就是问题,因此我就不想再多说。
不过最后我依然坚信,您和gigix是十分相类似的,至少性格和出事的很类似。并且可能是您的出境更加需要自己单独奋斗,所以您别他更加容易发火和固执,也更加听不得别人的非议。而gigix现在在TW工作,我相信这个公司是一个正规化的稳健发展的公司,这一点在行业内是有评论的。因此他的水平和能力我是相信还有一些,道德水准应该也有一些。而您则对他穷追猛打,从我刚才对您网站的研究,和网络上见到搜索所看到的情况,您已经坚持了很久。我不知道您和他之间究竟有什么矛盾,不过我觉得作为一个成年人最应该做好的就是把个人的感情同工作很好的区分开来。而这您显然没有做到,您花了大量的时间和精力在跟踪gigix,并且不时发生尖锐的评价。当然我不能说您说的话不对,但是我看到的往往都是道德层面的批判,而很少专业方面的点评。即使有也都是翻译或者个别地方认识的区别,而没有真正的思想根源上的差异。当然也可能我对国内的情况不是很了解,也许文革对您来说造成很大的影响。不过现在我认为,既然您希望开创一套自己的学说,就应该把精力投入在专业的事情上来。当然我说您和gigix本是一路,也不是在否定您,而是我认为您和他确实非常相像,而且都至少是声称自己是敏捷的。而至少现在gigix在一个敏捷的公司,您就我所知还是个体状态,至少在行业内没有他们那么高的声望。当然国内的情况可能正好相反,不过我确实没有在国内权威媒体上看到过对您的报道,而他们却经常性的出现。而就我这个外行所知,敏捷还仅仅是一个才兴起的学术潮流,我不知道您和他的争执是否会在中国敏捷的发展中起到一个好的作用。当然也许您本身就不是敏捷,因为我自己看到的情况,和今天顾问给我的对您的评价,您都不是敏捷的。您现在声称自己是敏捷的,我觉得可能是有不得已的苦衷。如果是这样,您去做这些事情,就好理解了。但是我想即便如此,依然应该以学问切磋,学术交流为重。当然gigix在这个方面也作的不好,但是至少在我看到的情况是您首先挑起了两个人之间的矛盾。当然网络上的交流在您看来可能仅仅是一种放松和随意的议论,不是专业论文,也不是专业讨论。但是我依然觉得个人的矛盾,不到万不得已还似乎不应该放到公开场合。即便有短暂的口角,也应该及时收场。
以上言论纯属一些个人的见解和对您为人处世方面的建议,自然我没有这个权利和能力向您教训应该如何做到君子风范,因此您可以当我自己在胡言乱语罢了。
就此一言之后,我要做的工作已经完成,对您的评价工作也已经完成。因此我就不会,也没有时间在做发言了。
总结下来,我给您的建议就是:
不是自己专业的事情,最好就不做评价。
对不是自己专业的人员,也不必多做专业化的诉说。
不要那么容易被激怒,即便对方很让您觉得讨厌。
不要把精力投入到人的个人评价中去,而应该多做本专业的研究和探索。
即便同别人有矛盾,也不要公开到公众场合。
即便已经公开,发生冲突的时候,也应该适可而止。
就此告别 祝您早日成功

Ok,我知道你的真实动机了。 by Zhang Charlie

我请你给出有关本案绩效考核的建议,可是你总是躲躲闪闪,不愿切入正题。

显然,从你的大幅论述中,我们看到你的重点,其实是评价(攻击)张恂,为 gigix 辩护,这才是你的真实动机,不是吗?这点上,你和 o6z 很像,你们与 gigix 是一伙的吧。害怕了,着急了,被激怒了?可是,这有用吗?

你愿意扯 gigix,那么关心 gigix,好的,我也扯一点。

谁都知道,2004 年以来我一直在批评熊节现象,张恂不搞人身攻击,而且主要是针对熊节的作品文字,质疑熊节的专业态度和专业水平,很多事实表明熊节并不具备专业的态度和能力,突出的是他的文采,这属于正常的批评吧。

在专业上,熊节迄今有许多伟大的创造,包括“颠覆软件工程话语体系”,Martin Fowler 毫不掩饰地告诉我们 XP 不包含“如何记录/传递”知识的功能,XP 把迭代的周期精确到一天,把 checkin/checkout 的频率规定到每半小时等等 ... 而这些,只是我目前分析研究的冰山一角。

张恂做的不过是坚守原则。

Jason Lai 提醒大家不要在 InfoQ 上搞人身攻击。你们分得清,什么是正常批评,什么是人身攻击吗?熊节搞人身攻击比你们厉害的多,有用吗?什么“裤腿撕咬者”、“躁狂型妄想症”、“躁狂症患者”等等,至今还在 CSDN 博客上挂着。这些丑陋的言行显然已经违反了 ThoughtWorks 的 values,当然也违背了一名专业程序员的职业道德和操守。

当然,以上只是我们的观点,你们认为熊节是英雄,是天才神童,是你们愿意捧的明星,那是你们的权利。而在熊节正式承认错误,公开道歉之前,张恂会坚持批评下去。

好了,打住。希望你说到做到,工作已经完成,不会再做发言了。你再扯与本案无关的事情,我不会答复你。你已经说了,自己是外行,该干嘛干嘛去,bye bye。

Re: Ok,我知道你的真实动机了。 by liu ozzzzzz

荣幸,您竟然认为我和此先生相像。惭愧惭愧,至于说你所认为的真实动机。我想你还是自己看他的发言为好,至少我觉得他是在考察国内的一些人的情况,而且似乎是在国外,并且有意思要到国内搞事情。这个大概你还是自己好好看看为好,免得断了您一条发财的路子。不过从你上面的话和他的回复,我看你已经被否定了。
说实在的,你再仔细看看,他并不认为gigix水平如何高,只不过就是一个在TW里面工作人员的水平,而他的眼光只是承认TW在行业内有声望并且在实施敏捷而已,并没有把他们看得多么重。他说你和gigix是一路,其实还是在评论你的水平也就是泛泛,和他要求的还是很远。
咱也觉得此位大人,眼光很高,说话很有些条理,骂人很隐蔽。有机会真想学习学习。不过我看他还是对你很客气的,比如你不懂Scrum这件事情,他就只说是一个顾问说的,而并没有详细说明。而且他还劝您稳守自己的学术派别,别跑敏捷这个酱缸里面和我们一起堕落。而且最后给您的建议,我看也很中肯。也就是骂了你,还要给你点教训。这样的人,我真想会他一会。
不过我要说清楚,我讨厌你的是你的学问,比如说啥银弹之类的,啥中国敏捷的,啥太极oo的,我对你这个人没有啥兴趣研究。虽然说你也够一个现象级别了,但是我确实不会和您一样投入精力去研究您。
哈哈,最后我发现此位仁兄居然全部都用“您”这个代词,貌似让我想起了某人。那么您就好自为之吧,让您的两周的迭代在Scrum下发扬光大吧。
您看我咋就学会这位仁兄的拐弯抹角的法子呢?惭愧啊!

Re: Ok,我知道你的真实动机了。 by liu ozzzzzz

当然如果您愿意和我这个草寇,研究研究这个案例,那么咱们就讨论讨论看看。不过我就怕您看不上我们这些人。当然你都发言那么多了,免不了有啥问题。我就给您一个机会,从新开始,把原来你的发言总结一下,以这个为基础。不过你最好把您以前说的,被您现在认为的有错误的地方明确点出了,以免的误导大众。
我也开始您您您了,妙哉。

Re: Ok,我知道你的真实动机了。 by liu ozzzzzz

如果张先生觉得公开场合与我讨论有所不便,我们可以私下交流。只要你说一声,我就到您网站上留下我的网上联系方式。

Re: Ok,我知道你的真实动机了。 by Jacky Li

好吧,既然掌门同学说是gigix违反了程序员的操守,说他在人身攻击,那么我就拿掌门同学两年来一直无时或忘,甚至还拿到InfoQ来攻击gigix的文章来说吧:

“看来胡扯,还是胡扯。熊名家真是灵舌利嘴、妙笔生花,普天之下、无人能敌啊。”,

“如果你不敢公开或者拿不出有效的证据,那我们只好认为你透明大作家又在瞎掰了。你知道吗?一个人老是闭着眼睛瞎说在软件科技界是令人非常不齿的行为。”

“这样傻冒(silly,演员表演冒傻气在文化娱乐界是常用的逗乐、活跃气氛的手段)还好意思上 University ? 应该先行补习算术。人说熊透明的文字是笑话,看来一点都不假。”

“熊透明所谓的‘……’完全是彻头彻尾的胡说八道。熊名家的这段名言逻辑上不管怎么解释,总归存在矛盾,读者朋友,您若不信,可以试试? ”

“作为小有名气的 XP 吹号手,对 XP 敏捷实践的理解竟然如此机械、呆板,除了肆意的“胡说八道”、 “睁眼说瞎话”或者“不学无术”之外,我看没有更合适的评语了”

我想冒昧的请问一下掌门,难道别人打了我的左脸,我就应该按照耶稣的说法,伸出右脸给他打么?或者您老人家认为,您是高高在上的人物,所以只有您攻击别人的权利,别人只有被您攻击的义务,那鄙人也实在无言以对。

这些应该是正常范围之内的批评和讽刺吧 ... by Zhang Charlie

请你仔细看一下我的用语,我并没有涉及到对熊节人身的攻击。我批评、讽刺的对象依然是 gigix 错误的(读者有权认为他们正确)言行,难道有什么不对吗?这个程度显然是与“裤腿撕咬者”、“躁狂症患者”不同的。

另外,你抄的时候,最好把上下文也抄上,看看我为什么会这么说。如果确实我批评、讽刺错了,我愿意道歉。

既然我能批评熊节,当然是对等的,也欢迎大家批评、讽刺、攻击(attack)我,来点挖苦也无所谓,但希望只针对我的观点和言行,就事论事,进行技术性批评,而不要搞人身攻击,诽谤和侮辱人格。


好吧,既然掌门同学说是gigix违反了程序员的操守,说他在人身攻击,那么我就拿掌门同学两年来一直无时或忘,甚至还拿到InfoQ来攻击gigix的文章来说吧:

“看来胡扯,还是胡扯。熊名家真是灵舌利嘴、妙笔生花,普天之下、无人能敌啊。”,

“如果你不敢公开或者拿不出有效的证据,那我们只好认为你透明大作家又在瞎掰了。你知道吗?一个人老是闭着眼睛瞎说在软件科技界是令人非常不齿的行为。”

“这样傻冒(silly,演员表演冒傻气在文化娱乐界是常用的逗乐、活跃气氛的手段)还好意思上 University ? 应该先行补习算术。人说熊透明的文字是笑话,看来一点都不假。”

“熊透明所谓的‘……’完全是彻头彻尾的胡说八道。熊名家的这段名言逻辑上不管怎么解释,总归存在矛盾,读者朋友,您若不信,可以试试? ”

“作为小有名气的 XP 吹号手,对 XP 敏捷实践的理解竟然如此机械、呆板,除了肆意的“胡说八道”、 “睁眼说瞎话”或者“不学无术”之外,我看没有更合适的评语了”

我想冒昧的请问一下掌门,难道别人打了我的左脸,我就应该按照耶稣的说法,伸出右脸给他打么?或者您老人家认为,您是高高在上的人物,所以只有您攻击别人的权利,别人只有被您攻击的义务,那鄙人也实在无言以对。

Re: 这些应该是正常范围之内的批评和讽刺吧 ... by liu ozzzzzz

张硕士您真强大。
我想你在
www.infoq.com/cn/news/2007/11/agile-product
的发言您还记得吧。
你这么说的:
“ 当我在 一个敏捷教练中止越轨列车的故事 中客观评论道:


看完整篇故事,总体上我赞成作者和 B 的作法,A 的工作态度有问题,不适合留在项目组里。但我同时也看到了一种可能不太好的情绪,作者为什么连自己的上司 D 也讨厌?牛到不把自己的上司甚至老板都放在眼里,恐怕不是一个好苗头。

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



而 InfoQ 明星编辑熊节对这段话的评论是:

不能立即兑现不等于没有未来的预期收益,消除浪费不等于不做远期投资。远期投资是否值得做,往简单了说,用财务技术就可以算出来。这都纯粹是技术活,别动不动的就扯什么文化的淡。首先把“把浪费看成对立面和敌人”曲解为“把不能立马兑现的东西统统看成对立面和敌人”,然后拿这个自己立起来的靶子来炮轰“很多一些技术人员”,最后说自己掌握了“包容与和谐的文化”,整就是一个扯淡的套路。打住吧。



Jason,我想你也是个拥有大学学历的人。熊节的这段话到底说了些什么,符合逻辑吗?反正我是没看懂,不知其所云。这难道不是在胡搅蛮缠?一个人为什么这么容易被莫名其妙地激怒,想方设法,迫不及待地要指摘别人?我想,莫名的愤怒恐怕恰是一种心虚、胆怯的表现。

请问,到底是谁在“咄咄逼人的质问,给讨论的气氛引入负面情绪,并且不尊重他人”? 作为讲职业道德的媒体,希望你们不要搞双重标准。”

我想你被白先生点到了痛处,您的莫名的愤怒是不是一种心虚、胆怯的表现呢?
一再声称你是欢迎批评的,但是别人只要对您有看法,我咋就看到你火冒三丈呢?
而你把gigix的那个发言,和下面您说的话做作对比:“
“看来胡扯,还是胡扯。熊名家真是灵舌利嘴、妙笔生花,普天之下、无人能敌啊。”,

“如果你不敢公开或者拿不出有效的证据,那我们只好认为你透明大作家又在瞎掰了。你知道吗?一个人老是闭着眼睛瞎说在软件科技界是令人非常不齿的行为。”

“这样傻冒(silly,演员表演冒傻气在文化娱乐界是常用的逗乐、活跃气氛的手段)还好意思上 University ? 应该先行补习算术。人说熊透明的文字是笑话,看来一点都不假。”

“熊透明所谓的‘……’完全是彻头彻尾的胡说八道。熊名家的这段名言逻辑上不管怎么解释,总归存在矛盾,读者朋友,您若不信,可以试试? ”

“作为小有名气的 XP 吹号手,对 XP 敏捷实践的理解竟然如此机械、呆板,除了肆意的“胡说八道”、 “睁眼说瞎话”或者“不学无术”之外,我看没有更合适的评语了””
您看看究竟哪个更像人身攻击呢?

你一直声称您是个硕士,想必你小学语文水平是有的。而你一直在说科学的逻辑,想必你逻辑也是有的。那么你就给我分析分析这个对比吧?

而且更加让我不理解的是,你把发生在infoq之外的事情也拿了做证据。你咋就不去自己看看自己当初究竟说了什么,做了什么,而就看见gigix说了什么做了什么?
而你一直声称自己有14年以上的开发经验,想必这十四年你不是关在监狱里面做的开发吧?而即便你是关在监狱里面,这点人情世故你还不懂。
是你的逻辑本身就是只对别人,不对自己,还是什么?

再说你觉得gigix对你的那个说法作出的反驳,你认为逻辑不清楚,你看不懂。是你真不明白,还是假不明白。如果你真不明白,用不用我给你讲解一下,给你这个硕士,而且是号称专业的硕士讲解一下?
动不动就说别人发火,你自己呢?你检讨过自己的言行没?你的专业和逻辑就是这样的水平吗?你的分析能力就是这样的?
如果就是如此,那你还有啥能力去做咨询工作,还有啥资格去给做流程设计,貌似你的意思你还能做绩效考核,你真能啊。就你这个水平,是不是在贬低咱们国家的硕士,贬低咨询从业人员,贬低人力资源从业人员啊。
你想要讨论问题,那咱们就来。你想骂人我也可以陪你,你想拿刀对拼,我也可以陪你。谁叫你说我们是草莽呢?我们一个粗人,啥也不怕你。
你说你不听好话,就找办的主,是不是也该给自己找找定位了?

Re: 这些应该是正常范围之内的批评和讽刺吧 ... by liu ozzzzzz

再次规劝张先生,还是把精力放到正经事情上去。
比如和我讨论讨论这个案例,或者回去写写你的书。
人的精力有限,你也三十出头了,这样的道理也该明白了。

总结:为什么本案不像一个敏捷开发团队?(一) by Zhang Charlie

前面我分析过本案敏捷不敏捷,分为两个部分。在处理 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 个月的时间来完成所有测例的编写和测试,而不是根据开发进度和迭代计划,分批、分阶段、有选择的进行测试确认,不断与开发组的工作进行同步、协调、反馈,这么做显然是不敏捷的,依然是一种瀑布思维。

zhangxun.com 提供了敏捷教练张恂针对此案全面、系统、结构化的案例分析,欢迎参与探讨:

当敏捷团队遭遇了公司政治

Re: 总结:为什么本案不像一个敏捷开发团队?(一) by liu ozzzzzz

有几个问题,还不是很清楚。
究竟是6个还是7个开发者,作者并未明确。而这些人究竟在组织结构上是如何配属,也没有明确。因此你说的这些还都是建立在假设基础上的。
而作者已经明确说明了自己身份的定位,是一个QA Lead,而不断的事情发展也明确的说明了他就是一个QA Lead,而不是Team Lead。
而进一步说,QA team和开发team究竟是不是该在一个小组工作,这也有多种选择。但是并不能说在一个小组就合作紧密了,不在一个小组就合作不紧密了。而特别是在存在数个开发小组,一个QA小组负责对他们进行支持的情况下,这个问题就更加需要考虑。而就如我开始就说了,作者并未明确说明,开发者配属的情况。因此这里仅仅就是假设的情况。

Re: 总结:为什么本案不像一个敏捷开发团队?(一) by liu ozzzzzz

而另外Release其实也是分级别的,特别是大型项目更多的会存在这个情况。
同时我关心的是,H为什么会对A有意见,而不是对QA小组有意见。这是说A属于另外一个小组吗?
另外QA完全可以在提供了明确事实的前提下,决定推迟Release Verification Testing。例如认为,测试的环境还不具备;代码中还存在致命错误;其他部分的程序还不稳定,单纯对此部分Release Verification Testing意义有限;等等。但是说需要学习熟悉等等,这个理由不充分。
同时也请注意,测试分阶段进行这个事情非常复杂。多数情况下,测试计划和测试打的框架都已经在前期设定,并且修改起来会相当的谨慎。除非需求发生变化,或者测试中被发现存在问题。而这里的情况是不是在说单元测试,是QA而不是程序员写的?
另外还存在一些问题,但是现在不想说,因为不希望制造更多的线索。

Re: 支持你的可爱!但关于敏捷 ... by Wu Junyin


太极敏捷派掌门 张恂
www.zhangxun.com


您这个名号是谁封的吗?
怎么还老换呢?
还是自封的?

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

72 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT