文章
一个敏捷教练中止越轨列车的故事
作者 Richard H.B. Sun 发布于 2007年11月19日 上午3时14分
我必须承认，我的管理经验是不足的。最近一次我对下属的工作处理的介入让我学到不少我以前没有经历过的工作经验，在此和大家分享一下我的认识和感悟。这件事情的处理，一般人可能认为这无异于办公室政治风云，对我来说这是一次很好的管理经历。让我认识到如何使用敏捷教条对管理方面的问题进行分析，如何采取合适策略来解决此类问题。
数月前，我被分派到一个新成立的小组做QA Lead，开始了我的管理“事业”。当时只有我一人协助三个开发者。随后，增加到协助4.5个开发人员，外加两个客户端开发者。很快我就发现自己被很多事情所包围，无法在短期内完成一下子堆积起来的工作。也就是这时，我和我的上司D提议增加人手。当时是2007年6月，正好没有人手，我就按照自己知道的敏捷互动知识，对自己的工作进行安排，一件件地处理。到了得心应手的阶段时，终于有人手可以分配过来时（2007年9月中），我得知一个我觉得能力很差的高级工程师A会被转移到我的组里帮我。我的第一个反应是，“能不能分配其他人手到我的组里。”我的上司D说，“先让这个人过来试试。”我就没有多说什么，那个时候我就已经预见了今天我不得不作出的处理。
我的第一个反应是从兵法“用人不疑，疑人不用”的角度产生的，当时我们组聘用了A，我们在面试时看好这个人，但是雇用之后我和他的一些互动中发现此人除了知道如何使用Visual Studio .NET 2005，其他什么都不会；而且他还不愿意学这些能够帮助他适应新环境的东西。后来因为A是以高级工程师，开始成为我当时所在组的Team Lead。作为Team Lead那一段时间，我们整组发现他无法对管理层作出的无礼要求进行抵挡，甚至谈判，只知道如何一味地向管理层妥协。然后自己不身先士卒，而是把一些重要的东西摊派给属下。然后自己就开始进行一些无关紧要的流程改进工作。我是看在眼里，记在心里，因为我很早就被调到我现在的岗位，所以也没有说些什么。我知道，这样的人不能重用，我对他没有信任感。
就这样到了九月底，我感觉可以让他转移到我的组里开始前期准备工作。我当时的感觉是，我要尊重我的上司D的安排，尽力和他一起携手合作。我马上就碰到了一个问题，他无意从自己的项目中摆脱出来，他的托词是，“我需要一点时间完成我手上的事务，这样可以很好的交接给其他人。”我就给了他一个星期，同时也和信任的Team Lead B进行了沟通。B原来是个开发者，在9月份转来做QA，因为他的经验丰富，而且A在组里不做正事，其他组员意见很大，所以A转到我的组后，就丢掉了Team Lead的头衔。我和B的沟通是，A应该把工作重心放到新的工作上去，而不是找借口推托自己应该承担的责任。B向A转达了这样的意向，但是一时间没起什么作用。
随后，A以领导的名义向我们的上司D回信，列出我们这组人在08年应尽的义务。我一看，心里就腾起一股火气，他自己承担的任务里，没有一项是和他新工作相关的，而且每个都要花费不少时间操作。这不是明摆着要消极处理他的新工作吗？我很不客气地回信，并抄送一封给我的上司D，表示了我对他的态度的不满。当时我的感觉是这个人不适合在我的组里做事。精简敏捷开发的宗旨是团队需要集中注意力处理当前最重要的事务，在最短时间内用最便宜的手段为整个商业组织创造价值，我的组主要工作是设计测试案例，开发测试案例是给整个开发组织的最大价值，而不是把时间花费在无意义的流程改进或是为高层收集测试数据，没有人设计开发测试案例，收集的测试数据是没有意义的。而这种鸡毛蒜皮的小事正是A最感兴趣的事情。我写的信让D很不高兴，因为我写得很不留情。这也是没有经验的管理者应该注意的，尽力避免这么直接的举动，多进行面对面沟通，实在不行才使用这种下下策。我和B沟通后，B又写信给A说，你的首要任务是对新责任负责。A回复说，我不觉得这个新项目有什么重要的，大家对此都没有什么重视，所以还是让我完成我的测试数据收集。A的信送出后，我也没来得及看。一天后B找到我，跟我说了这事，我才知道B也火了，也写了一封措辞严厉的信给A并抄送了我们的上司D。当然D也找B谈话说不能这么不留情面（大家知道了，要先进行面对面沟通，之后才能作出这样肆无忌惮的举动）。
又过了一个星期，事态有所改进，开发组的上司H也不知从哪里知道了这件事，写信给A说要把工作重心转移到我分配的事务上。然后我们上司D也对A做特别安排，让他全力帮助我。A态度马上大转变，说他会全力和我一起协作，我仗着我有令箭和A的态度转变，就开始给他分配任务，每天和他进行2分钟的Scrum。同时也帮他开始建立开发环境，我花费了三天，才把他的开发环境整理清除，他被聘开始工作到现在，对自己的开发环境维护什么都没有做，一切都是乱七八糟，然后自己还不懂到我们的开发测试Wiki上找答案。让我可笑可气的是，他拿了一个很简单的问题问我如何处理。错误信息就在他面前，读一读，再考虑一下就能解决，A的处事态度怎么能这么不认真，还是能力不行？三天之后，一切都搞好了，我觉得，A也该开始阅读项目文档，并向我向开发者提出大量的问题。
事实还不是我想象的那样，时间到十月初的第二个星期，我在周一分配了任务让他阅读文档，我给了他一个星期。我认为，作为高级工程师，是知道自己该做什么，我的分配是很清晰的，阅读文档，准备写测试计划，有任何问题，尽管问我。周五中午B跑来跟我说，开发部上司H很不满A不准备在下一周进行程序发布测试（Release Verification Testing），我说我完全支持A的决定，心里还有高兴，A终于可以专心做正事了。我甚至对B说我觉得A需要一点时间阅读文档。如果他能专心做事有进展，我会帮他处理这些杂事的。下午，我马上发现我的想法是极大错误，A和开发者开会时净问一些没有一点技术背景的问题。我坐在那里看着开发者艰难地解答他提出的问题，还有他不着边际的回复，心里急啊！最后我坐了35分钟，借口离开去找B反映这个发现。我容忍了A四个星期的不作为，他已经开始破坏我的全盘测试计划。
于是我和B又找了我们前任QA Lead —— J。J是个德高望重的人，A之前的QA Lead，给了我们的建议是，直接找上司D。于是我和B起草了一封信说A一个星期下来没有实质性进展，反而有负进展。他的态度是我们不能容忍的。希望D能替我们安排一个好的解决方案，我们对事情发展到这个状态已经无能为力了。周末，我仔细想了一下，和D见面时不能透露无望的神情。读者如果看过《教父》，知道Don Corleone在电影一开始接见好莱坞大明星Johnny Fontane，Johnny希望Don帮他摆平一个电影角色的，当时他无望地对Don说，“Godfather, I don’t know what to do…”Don的反应是痛斥Johnny的无能，说“You can be like a Man!!...”我当时的感受可能就和Johnny Fontane差不多。我在周日晚上仔细考虑了一下，知道自己不能象废物一样给上司D汇报这一情况。而且Ken Schwaber在他的书中提到，Scrum master必须能够对情况和发展作出合理判断，把各种可能发生的事件和后果进行总结归类，再同管理层进行沟通，帮助管理层理解种种处理的不同后果。我列举了几种处理方式：
- 调离A，在分配新的人员给我。后果是要重复一系列培训，开发环境设置等工作。
- 分配新的人员给我，让A和这个新人一起协作相互牵制，如果A合作不顺就要。后果是我不需要太多介入培训新人，帮助设置开发环境的问题。而且我可以继续我的测试工作。但是要更多地管理。
- 继续给A一定的时间，我会更严格地监管A，后果是我要花费很多精力监视，甚至介入A的工作，我的测试进度将受影响。
星期一，我和D见面，D马上和我说了他的安排，让A在我手下再干三个星期，然后他能转到其他组去。我从D那里得知A上一星期把时间都花在测试数据收集的工作上了，还表示了他对自己现在工作的不适应，希望调离。我可以看得出D和我一样对事态非常失望。D要我和A商量好三个星期必须完成的任务，然后等A休假回来后在安排A的工作事宜。我带去的事情处理方案，和收集的汇报都没有用到。下午，我从D那里接到通知说A马上就转到另一个组。事情就这样解决了。
读者会问这件事和敏捷开发有何关系？我的感触是，敏捷开发是不能容忍开发进度中任何能够造成进度停滞的问题。敏捷开发必须像耍独孤九剑一样连贯自如，任何问题必须从问题一发生就马上解决，同时不断改进，根据情况不断调整战术保证进度的高速进行。在这件事情上，上司D一开始犯的错误就是高估了A的技能。我觉得他对A一直抱有一种没有理由的错误判断——A是个处理能力和技术能力强的专家，其实这和现实差得太远了。D只是个经理，他不做技术性的工作，是无法了解下属的真实情况。这是一个典型的例子，不懂技术也不懂下属能力的经理会误判下属的真实情况。或多或少的蛮横安排资源，不接受团队回馈也是D所犯的错误。敏捷开发的一个重要手段是团队自我管理，也就是在阵地上的士兵比在指挥所的军官更了解战场战况，有时将在外，必须拥有“君命有所不受”的权利。上司D经常如此蛮横地瞎指挥，下属一般都以自己最好的判断来尽力实施他的要求，但是做不到的时候也只有和他汇报，获得他的理解，我想这是很多技术人员经常碰到的问题。
我的错误就是我怀疑了但是没有及时直接向D沟通我的担忧，但是就算我及时沟通了，也不会给我多大帮助。因为当时的人事资源就是那样的，我没有拒绝的余地。我所做对的，是对我所能够控制的局面进行了有效的监控；我利用了我所学的敏捷开发知识准确地判断了事态可能的发展；我对事态发展作出了一步步的盘算及后果的考虑，作出了先影响甚至控制A的战略，然后作出了如果A不合作，必须让更高管理层替我解决问题的战略。最后是在管理控制的同时收集下属的不当所作所为，作为我的战略资源，同时发动我的同事，我的上司对我进行支持。整个事件从发生到解决，花费了一个多月时间，我用最迅速比较妥帖的方式处理了这件事，而且没有耽误我自己的测试工作。第一次对项目和团队进行管理，我对自己的表现感到十分满意，近几年的敏捷开发实践毕竟是学有所成。但是我也意识到自己要好好学习更好人际沟通，在管理方面更加完善自己的能力。
-
其实这和Scrum没什么关系。放在一般的项目里同样有这种问题。这是项目组人员管理的问题。通常好的做法是先任命Team Leader，然后由HR提供人员来供TL挑选。当然现实中未必有这么理想。但是至少TL应该具有拒绝不合适的人员加入的权利。 在Scrum的实践中，现在推荐的一种做法是签合同（申明）。有两种合同，一个是TM和Scrum Master，Product Owner签的，大家明确一下职责并发誓遵守，每个TM加入的时候都要签字。另一个是scrum master和公司管理层签的，确保整个项目的执行能够有相对独立的空间，尽量少的受到管理层的骚扰。当然Scrum master应该具有权利，清除出破坏规则的人。 当然你说的是现实，很无奈！
-
我在http://www.infoq.com/cn/news/2007/07/cultivating-agile-attitude 一文中曾经说过，“我们会无缘无故的讨厌一件事情，会因为看一个人不顺眼而敌视他所说的一切，会骄傲自满，会自私自利，会固步自封，会讳疾忌医。也许，我们并不会因为知道敏捷可以帮助我们为客户交付最大的价值而轻易接受它，在实践中改变认知。” 我们不能空喊着“个体与交互胜过过程与工具”，而不去思考如何塑造有利于个体与交互的环境，解决对个体与交互造成制约的种种问题。从这一点上来看，作者的故事还是很有启发性的。 但是，我感觉这个不应该算是和敏捷开发有什么关系的事情，难道除了敏捷以外，我们就应该“容忍开发进度中任何能够造成进度停滞的问题”么？协调能力，沟通技巧，难道不应该是所有优秀的team leader理应具备的素质么？ “which is more important, person or process?”Agile和CMMI会给出不同的答案，但是如果我们相信Agile Manifesto的正确性，我们就不应该再继续试图把敏捷从软件开发中剥离开来。 敏捷，并不是特立独行的一份子，而是某种可以帮助我们认识软件开发真正价值所在、核心所在的思维方式，行为方式，正是因为在传统软件开发中存在着错误的认知，所以我们在提倡敏捷，宣传敏捷，以帮助开发者从误区中走出，改善开发过程，提高开发效率。但这并不代表着我们可以把一切归于敏捷，或是更有甚者，用敏捷来标榜自己（此处并非攻击作者，而是笔者另见的他人）。 使用敏捷开发，敏捷项目管理的我们，只是做了该做的事情而已。
-
我是本文作者，之所以写这篇文章的目的是，敏捷开发中很重要的一个环节是发现问题，从根源上解决这个问题。很多读者对事实的实际发生根本不了解，所以会误解为我给这个开发者穿小鞋。事实上，这个开发者"A"从一开始就说“我会帮助你完成该完成的。”暗地里，他在三个星期中什么都没有做。我和他沟通无数次说，你要专心把一件工作做完再转到另一工作上，而不是这里忙一点，那里忙一点，最后什么都没有做完。我把自己的想法很清楚地传达给他 -- 我想看到实质性的工作进展。敏捷需要清晰的交流，我觉得我做得很好了。和我一起工作的"B"同样做了口头，文字上的交流。我和"B"在三个星期内做出的努力得到的结果是0。 最近我和文中的"B"，还发现"A"从被雇用以后的八个月里，总共提交了15次代码，其他QA提交了百次以上。我和"B"都发现"A"根本就不愿意在我们组里工作。与其让他不工作，不如将其调离我们组，这就是我和B最后所做的。 还有，最后"D"分配给我一个新的人手“W”，我和“W”在两天内就完成了"A"本来三个星期内该做甚至能做得更多的事情。所以请不要提醒我说沟通很重要，或者这不是敏捷。你要是站在我的立场上，你也会作出我的选择，因为“B”都这么做了。
-
"最近我和文中的"B"，还发现"A"从被雇用以后的八个月里，总共提交了15次代码，其他QA提交了百次以上。我和"B"都发现"A"根本就不愿意在我们组里工作。与其让他不工作，不如将其调离我们组，这就是我和B最后所做的。" 为什么这个人如此不愿意在你们组里工作? 既然他是所谓的高级工程师,难道此人就如此一无是处? 你了解你的这个手下到底在想什么吗?如果你能指到此人的真实想法然后在做决定是否会更好一些?
-
但是内容很不错。
-
我的意思是，这个故事没必要往敏捷身上套，你说，“敏捷开发中很重要的一个环节是发现问题，从根源上解决这个问题”，但是，难道不使用敏捷开发的软件开发流程，“发现问题解决问题”就不是它们的重要环节了么？ “敏捷需要清晰的交流”，这句话没错，但是，我的看法是，软件开发需要清晰的交流。不要硬生生的把敏捷从软件开发中隔离出来。
-
> 敏捷开发中很重要的一个环节是发现问题，从根源上解决这个问题。 但我在文中看不出你有什么机制或者方法来发现“开发者A”所存在的问题。你提到他的问题，在我看来，都是你“认为”他“应该”怎么怎么。好吧，他没有照你“认为应该”的那样去做。so what？他造成了什么损害？哦，你“心里急啊”。仅此而已吗？难怪你老板一直把他扔在你组里呢。 你号称自己在做敏捷，号称自己很看重发现问题解决问题，可是对于“开发者A”的问题在我看来你就没有认真的去发现。如果你做了，你的数字在哪里？你的证据在哪里？如果你有他给项目造成损害的数字和证据在，老板还会坚持让他在你项目里呆着吗？ 即便不说发现问题，你也同样没有体现出解决问题的决心和行动力，当然这就扯远了，打住。
-
>让我认识到如何使用敏捷教条对管理方面的问题进行分析 再来看一下文章第一段的这句话，敏捷都已经成教条了呢～～
-
我想这儿作者用“教条”的意思是说“敏捷原则”或者“敏捷的指导思想”，小刀同学大可不必如此追究作者用词的问题，而且我不认为这儿用“教条”就有什么不妥。 从文章中来看，作者所表达的观点还是非常中肯的。在团队中作者的角色应该是敏捷教练，文章中所发生的这件事情是作者身为教练的经历，为何就不能作为敏捷的案例来讲呢？敏捷是软件开发中的一个方法，但是它有自己的特性，那就是强调沟通，如果是传统的方法，一切用制度和文档来约束，可能就不会产生类似的故事。
-
在Scrum的实践中，现在推荐的一种做法是签合同（申明）。有两种合同，一个是TM和Scrum Master，Product Owner签的，大家明确一下职责并发誓遵守，每个TM加入的时候都要签字。另一个是scrum master和公司管理层签的，确保整个项目的执行能够有相对独立的空间，尽量少的受到管理层的骚扰。当然Scrum master应该具有权利，清除出破坏规则的人。 当然你说的是现实，很无奈！
Alex Xu说的这个事情让我想起开发项目的过程中，经常和客户所签订的一系列合约，可是谁能保证所有事情都是按照合约来做的呢？很多情况下是，客户对项目还不是特别了解，在咨询师的诱导下，签了合约，后来客户发现自己想要的原来不是这个样子，于是提出新的要求。这时候你是拿着合约告诉他开始时我们是这样谈的啊，而且有合约，还是“屈从”于客户呢？我想很多情况下是后者吧！ 理论和实践有区别，方法中的实践和现实也有区别，那么为什么不去面对现实，在现实中领悟这些方法去解决问题呢？我认为作者在自己的工作中很好地实践了敏捷的思想，我辈还是不要站着说话不腰疼的好！ -
>我认为作者在自己的工作中很好地实践了敏捷的思想，我辈还是不要站着说话不腰疼的好！ 我还是那句话，作者的做法完全无关敏捷，而是一个正常的软件开发流程所应做的。而且，你如何知道我是站着说话不腰疼？
-
如果楼上说作者的做法完全无关敏捷，那么敏捷中的哪一个地方不是“正常的软件开发流程所应该做的”？可否给我们Share一下你所理解的敏捷？敏捷教练除了“正常的软件开发流程所应做的”之外，还应该做什么？请赐教！
-
上 里巴人: 我想你没有明白我的意思,这里所说的"合同"不是法律层面的.只是一种约定,为了确保Scrum这种游戏能够顺利的进行下去。这就好像我们要进行一场足球比赛，那么每个相关的人员就要遵守自己的规则。包括球员，裁判，教练以及观众。如果这个前提不能够满足，那么比赛就无法正常进行。 所以我的观点和 凉粉 小刀一样，这个问题不是比赛中的问题，而是比赛前的问题。不管你是想用442，还是541，这种队员都不应该派上场。也就是说，和你用什么管理方式无关。 作者提到了Scrum，我猜想你是在用Scrum，并且担当Scrum Master的角色。有一点不解的是，Scrum Master不应该为TM分配任务，而是应该由所有TMs一起来讨论，设立任务。然后，每个TM根据自己的喜好来认领这些任务。此外，好像你也没有进行daily Scrum，要不然也不会到后来才知道A很多工作都没做。 最后提一点建议。中国人都有摸石头过河的习惯，但通常河上都是有桥的。只是你要往前多走些路才可以发现。
-
我是作者，进行更进一步的答疑。 首先，这个"A"一上岗我就知道他有点不对头。当时他的工作和我的不冲突，所以我也没有仔细观察他的工作行为。当"D"我的直系上司把他分配给我时，我就知道这人会出问题，有读者问得好，既然知道"A"不行，为什么不直接就处理掉。这就是敏捷有时无法做到的--我要合理安排我和直系上司的关系，我不能直接反对他的决定，当时我没有直接的理由回绝，而且我应该给我的上司"The benefit of the doubts"。所以我没有直接回绝。 "A"加盟以后，我确实存在幻想说，疏导一下，沟通一下，甚至威逼利诱一下，能让他迷途知返。要知道那时的"A"已经6个月没写一个QA Test Case。我想万不得已强势干预一下，他也能迷途知返，迅速进入角色。结果三个星期下来我和"B"没有让他做出一点成绩。他一边用在我的组里做事搪塞其他人，一边又和我搪塞他在忙一些不重要数据收集任务。我的老天爷，一月底出货，我有一堆的东西要完成，不能这样浪费我的时间啊。 由于原有篇幅有限（编辑限制的），我实在没有更多的文字表达我的问题--不管我怎么威逼利诱，这家伙就是不做正事。整到我要坐在他身旁，监视他的一举一动。大家要知道，这根本就不是Scrum，或Pair Programming了，这等于是让我把自己设计测试案例的时间花费在“管理”这个不愿做事的人身上。所以我最后不得不使出狠招，把他踢出我的小组。 没想到我第一次作镇领导，就要做这种事。而且还耽误了一些进度。好在我懂点敏捷开发，知道尽早排除问题，及时向我的直系上司汇报问题，并请求干预。让我感到悲哀的是，大家都看见这个“A”是个不务正业的人，开发者知道，我们测试也知道，开发者的上司也知道，就是我的上司“D”不知道，天真地认为他能帮我解决问题，结果，我还要用这么极端的方法把他踢出小组。所有的人都用一种“他现在还没有做出太大的破坏先留着他”的看法失望地等待他能改变。最后还要我来直接干预，这就是我的失望，我们的公司并不敏捷，我所能做到的是，尽可能快地解决问题，我给了这个人三个星期，从某些人的看法来讲已经很不敏捷了。我只是觉得我还是很敏捷地处理了这件事。
-
>好在我懂点敏捷开发，知道尽早排除问题 那就是说，不懂敏捷开发的人，就不知道尽早排除问题了？这不是胡扯是什么？ 当韩非子说“千丈之堤毁于蚁穴”的时候，敏捷在哪里？当乐府说“君子防未然，不处嫌疑间”的时候，敏捷在哪里？当孙子说“水无常势，兵无常形，能因敌变化而取胜者谓之神”的时候，敏捷又在哪里？ 楼主仿佛是要千方百计的要把敏捷推上神坛，让不懂敏捷或是初涉敏捷的人觉得敏捷深不可测，于是“敏捷教练”的头衔就会罩上一层光环。久而久之，在被楼主影响的人的心中，敏捷就会变成一个buzzword，变成“宗教信仰”——http://www.infoq.com/cn/news/2007/10/religous-continued
-
看完整篇故事，总体上我赞成作者和 B 的作法，A 的工作态度有问题，不适合留在项目组里。 但我同时也看到了一种可能不太好的情绪，作者为什么连自己的上司 D 也讨厌？牛到不把自己的上司甚至老板都放在眼里，恐怕不是一个好苗头。
D 只是个经理，他不做技术性的工作，是无法了解下属的真实情况。这是一个典型的例子，不懂技术也不懂下属能力的经理会误判下属的真实情况。或多或少的蛮横安排资源，不接受团队回馈也是 D 所犯的错误。敏捷开发的一个重要手段是团队自我管理，也就是在阵地上的士兵比在指挥所的军官更了解战场战况，有时将在外，必须拥有“君命有所不受”的权利。上司 D 经常如此蛮横地瞎指挥，下属一般都以自己最好的判断来尽力实施他的要求，但是做不到的时候也只有和他汇报，获得他的理解，我想这是很多技术人员经常碰到的问题。
软件研发的敏捷文化其实更强调一种包容与和谐的文化。敏捷并不是要把不参与技术工作的人，不能立马增值、兑现和提升生产率的东西，统统都看成自己的对立面和敌人。眼里只有“代码”，而没有“人”，我想这是很多一些技术人员经常容易犯的错误。 太极敏捷派掌门 张恂 www.zhangxun.com -
作者答疑， 之所以用敏捷，我对这件事情的处理是有一个比较的，"A"在八个月内没有做任何正事，除了把手上的活分配给他人，自己就是关在办公室里没做一点事情。我在三个星期内，收集了证据，暴露了他的不作为给我们的直系上司，并将他调离我们组，解决了这个问题。这里就有一个比较，八个月很多人对他的容忍，让他白拿八个月的工资。和三个星期，给他一次次机会，没有效果，最后让上司出面解决。这就是敏捷了。 我记得我接受的训练，流程必须是流畅的，象生产线，没有失误阻止产品流过生产线，任何阻止生产流程的失误必须从根源解决。只有这样才能完全根除浪费，达到敏捷。我正是运用了我接受过的训练，解决了问题。不仅解决了我的问题，还帮助我的同事"B"解决了同样的问题。“A”不在我的组里破，也调离了B的组。 对我写的有疑问的朋友，我可以保证，我是一个很容易让人喜欢的人物，我很单纯，很直板，有时过于爱憎分明，我是个Team Player。我不能说是我是一个优秀的Scrum Master，但是让我进入一个Agile team，你肯定会喜欢我的配合，我对事情的判断，我能够提问，我能够把事情做完做好等等品质。说不定你会有机会和我合作，那时你就知道我这个人是多么可爱
-
> 软件研发的敏捷文化其实更强调一种包容与和谐的文化。敏捷并不是要把不参与技术工作的人，不能立马增值、兑现和提升生产率的东西，统统都看成自己的对立面和敌人。 不能立即兑现不等于没有未来的预期收益，消除浪费不等于不做远期投资。远期投资是否值得做，往简单了说，用财务技术就可以算出来。这都纯粹是技术活，别动不动的就扯什么文化的淡。首先把“把浪费看成对立面和敌人”曲解为“把不能立马兑现的东西统统看成对立面和敌人”，然后拿这个自己立起来的靶子来炮轰“很多一些技术人员”，最后说自己掌握了“包容与和谐的文化”，整就是一个扯淡的套路。打住吧。
-
熊节胡扯敏捷 XP 如上。
-
Kent Beck在极限编程第二版中，引用了约束理论，我觉得不妨适用在这里。无论是人，还是流程，只要构成了对当前项目影响最大、产生浪费最多的阻碍因素，也就是瓶颈，就应该尽量移除之。从这个角度来看，如果一开始A没有构成最大的瓶颈，暂时放着问题也不大，随着项目的进程，他成了瓶颈，那就搬走吧。 ps：约束理论
-
约束理论链接：http://www.chinamcn.com/zsk/glgj/zhil007.htm
-
这个～～熊节楼上的话是在就事论事啊～～
-
我现在对"敏捷"这个词有点过敏。前几个月，有一期《程序员》的标题叫“敏捷的三重境界”。看得我只起鸡皮疙瘩。 呵呵。打住！
-
文章的题目改为：一个敏捷初哥放任越轨列车的故事。这样更符合文章的内容。同学们以批判断的眼光来看作者对项目中问题的反应，作为教训，不要再犯类似作者的错误。
-
你们对于 A 的处理，大体上是对的。如果我遇到和你类似的情况，我想，我也会采取类似的做法，收集证据，让事实说话，这是很自然的科学的工程师们的做法。而且你们已经做到了仁至义尽，给了他一次次机会。 值得思考的是，谁都知道，这样的人对于软件研发没有价值，但问题是你们公司什么还会留他？是关系户，亲眷，公司政治，文化，还是其他什么原因？为什么 A 不能像一个新人，从零开始，被你们公司改造，真的无可救药了吗？我想，这些围绕 A 事件的因素和现象暴露了你们公司文化、管理上的缺陷，或将成为你们后续实施敏捷过程的障碍。 我想，你们团队可能做到了一些部分的敏捷实践，但在公司层面、组织层面，离敏捷可能还很远。 下一个艰巨的任务是：如何让你的老板 D 和 H 参与到这种敏捷变革中，你总不至于把自己的上司也炒了吧。那就不是敏捷了，是政变。 现在我们也知道你心中的敏捷，你说“这就是敏捷了”。我喜欢，也很理解你的单纯、直板、坦率和爱憎分明，这些都是技术人员的优良品质（我也是一名 14y+ 技术人员）。但坦率地讲，你说的这还不是敏捷，传统公司遇到此类问题，也应该这么做，这是任何一个具有科学逻辑思维的管理者应该想到和做到的。 然而，敏捷比这个，要求更多，更高。敏捷，首先是一种进步的开发哲学、价值观、原则、境界和思想，在很多情况下，并不是那些具体的时髦做法，你做到了那些实践，也未必能达到敏捷态。你们团队似乎采用了一些 Scrum 的做法，但显然离敏捷的真实态还较远。 掌握和吃透敏捷的关键在于，理解敏捷方法 XP、Scrum、AUP、Crystal、Lean、FDD、ASD、APM ... 的创始人为什么要这么做，他们的真实目标到底是什么？千万不要像某些明星那样（诸如 Jeff Xiong）机械、刻板地去理解。 太极敏捷派掌门 张恂 www.zhangxun.com
-
why?
-
>why? 掌门这话是跟谁说呢？
-
呵呵，不用客气。
>why? 掌门这话是跟谁说呢？
-
有感而发，凉粉，thanks!
-
从 1 万元的，到 20 万元的都有，您要哪一款？ 有感而发。
-
从 1 万元的，到 20 万元的，都有，您要哪一款？ 有感而发 ...
我现在对"敏捷"这个词有点过敏。前几个月，有一期《程序员》的标题叫“敏捷的三重境界”。看得我只起鸡皮疙瘩。 呵呵。打住！
-
“那个时候我就已经预见了今天我不得不作出的处理。” 实际上从一开始作者就知道A的情况，A的弱点。 “我知道，这样的人不能重用，我对他没有信任感。” 在这样的认识前提下，作者应该作出的反应是什么呢？我觉得应该是细粒度的监控，充分的沟通，每天早上和A来个2分钟的meeting，每周起码两次小组scrum meeting。但是作者没有做这些，“我在周一分配了任务让他阅读文档，我给了他一个星期。” 对于一个你不信任的人，你知道弱点的人，为什么会放任他自己干一个星期而不管不问？整个火车越轨的过程长达3个月，太长了！作者的反应太不敏捷了。 抛开敏捷不谈，任何管理者，对于同事在3个月的时间里“不出活”的现象也无法容忍，绝对不能坐视事态发展3个月。实际上最多一个月，作者就应该解决问题，3个月才解决已经失职了。
-
有人身攻击的倾向了，建议打住
-
72 条回复
回复