我必须承认，我的管理经验是不足的。最近一次我对下属的工作处理的介入让我学到不少我以前没有经历过的工作经验，在此和大家分享一下我的认识和感悟。这件事情的处理，一般人可能认为这无异于办公室政治风云，对我来说这是一次很好的管理经历。让我认识到如何使用敏捷教条对管理方面的问题进行分析，如何采取合适策略来解决此类问题。

数月前，我被分派到一个新成立的小组做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必须能够对情况和发展作出合理判断，把各种可能发生的事件和后果进行总结归类，再同管理层进行沟通，帮助管理层理解种种处理的不同后果。我列举了几种处理方式：

1、调离A，在分配新的人员给我。后果是要重复一系列培训，开发环境设置等工作。
2、分配新的人员给我，让A和这个新人一起协作相互牵制，如果A合作不顺就要管理。后果是我不需要太多介入培训新人，帮助设置开发环境的问题。而且我可以继续我的测试工作。但是要更多地管理。
3、继续给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不合作，必须让更高管理层替我解决问题的战略。最后是在管理控制的同时收集下属的不当所作所为，作为我的战略资源，同时发动我的同事，我的上司对我进行支持。整个事件从发生到解决，花费了一个多月时间，我用最迅速比较妥帖的方式处理了这件事，而且没有耽误我自己的测试工作。第一次对项目和团队进行管理，我对自己的表现感到十分满意，近几年的敏捷开发实践毕竟是学有所成。但是我也意识到自己要好好学习更好人际沟通，在管理方面更加完善自己的能力。

敏捷开发对开发人员的要求比较高，怎么用人是个很头疼的事！

其实在人员分配方面如果能由你自己去挑选，在配合方面会好很多。

LZ的帖子有标题党的嫌疑，似乎整个过程跟敏捷没多大关系。不管敏捷不敏捷，从一个项目管理者的角度去看，A这个人都不能用，及早的退回所属部门才是明智之举。

在管理和用人的过程中很多很多从基层走上来的管理者很容易犯的一个错误就是：姑息。认为大家都是一起干活的兄弟，只要凑合凑合能用的话就会继续用，这样于项目于个人于公司都没什么好处。

楼主，我觉得问题在你，而文中你自己也提到了，应该一开始就和A做必要有效的沟通才对

干活和用人都不能凑合。不合适的人用在不合适的地方，只会让事情更糟。

弯刀对着瓢切菜。相信有的人是不能通过简单的沟通就能解决问题的。因为需要的是工作能力的提高，工作思路的转变，思想的转变。而这是很难的，也需要时间。