Did you meet this?

http://www.infoq.com/cn/articles/stop-aberrant-train

这关敏捷鸟事？啥事都往"敏捷"靠，现在不流行了。
这年头讲的是harmonious programming:
[img]  http://readonly.iteye.com/upload/picture/pic/6329/54c8d247-858d-4dc9-8c4d-e788b889ae46.jpg[/img]

作者厌恶 A 合理，但为什么连自己的上司 D 也讨厌？
2007年11月20日 上午1时48分 发表人 Charlie Zhang

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

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

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

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


---- 这个人的评论比较敏锐。

敏捷这东西到底是管理还是技术？作者到底是Tech Lead还是people lead?

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

-----这感觉就象一个丈夫讲妻子有外遇一样，颇有为厌恶而厌恶的感觉。

此外文中也未感觉作者如何去帮助A实施转型的具体措施和跟进计划，更多的好像是一个圈套：嗨，我不是和你说过么？你还不改？我给你机会了，是你自己不好。

支持ray_linn

这个就死张询大师的回答，本来我想出手做点评，不过既然大师说的高兴，而其他人听不出逻辑混乱，我也就算了。

这么长的辩论要保持逻辑清晰也不容易，我只稍微看了一下，这段是我比较认同的。

说太多别人的长处或者短处（文中反复编排了A的不是），只是某种心理暗示，想巩固自己心中不那么牢靠的理由，就好象一个女人在说某个男人怎么怎么爱他。


我不懂啥敏捷，也只略懂管理，我想管理的目的之一应该是敏捷（高效，简练），但敏捷不是管理的唯一目的，这是作者的所混淆的地方。

作者是不是太自我了...

我已经在对这个事件做个评点，因为他很好的说明了国内敏捷发展的现状——一下在忽然所有的人都开始声称自己是敏捷的。而这其中必然有很多滥竽充数和误解，也有很多添油加醋的敏捷混合体。虽然声势有了，但是情况却复杂了，这不能不引起我们的注意。
比如你说管理额目的之一是敏捷（高效，简练），这个当然是我们一般层面上正确的看法。但是方法论层面的敏捷，却又其专属的意义，我们并不能说高效、简练就是敏捷。这里的敏捷应该是敏捷宣言上明确宣扬的敏捷，而不是我们普遍认为的敏捷。而当初如果敏捷方法不以敏捷而命名，是以轻型方法命名就不会有此种情况发生。

事实上，公司正在提倡lean管理的概念，翻译过来轻型，瘦型管理，似乎颇有借鉴意义。

一直觉得敏捷方法和项目管理方法是一样的道理，是execution的科学，读一肚子PMP的人不一定是好的项目经理，同样读一肚子敏捷方法的人也不一定能敏捷。

所以好的项目经理都是从实践中长出来的。