可能很多人觉得奇怪，我拉开了架势，整了那么足的气氛，最后的收兵却那么显得匆忙，为啥呢？
原因很简单，因为我就是觉得现在敏捷在中国，就是如同我的这个系列一样，嗓音高，动静大，但是内在的实质太少了。因此我才把这个系列叫《敏捷在今日之中国》。
当然从前我也曾经专心致力于搞声浪，造气势，拉眼球。不过现今的情况已经变化了，敏捷已经不是一种歪门邪道，已经不需要我们去做很多事情了。现在这个阶段，最应该做的事是踏踏实实的把敏捷的思想贯穿下去，把敏捷的方法踏踏实实的掌握好精髓，把敏捷的技巧融入我们的具体工作中。这三点缺一不可，必须从思想到方法到技巧都踏踏实实的去做。
我这个人头脑简单（当然没有四肢发达），所以总是希望把事情向简单里面想。这个例子按照我的理解，就是一个人互相觉得自己的劳累过度了，完成不了工作了，需要补充人手了。于是上级安排来了一个人，结果这个新人的添加失败了，经过一番折腾，之后这个人又被安排走了。你也许和我一样看过一本小书——《官场病——帕金森定律》，对这个事情一点也不感觉到奇怪。细节我就不分析了，其实本就简单的不能再简单。
我努力使我的总结长一点，但是实在找不出还有啥需要说的。而分析张导师，我实在是绝对无趣。本来想和他搞个分析，最后再抛出我的看法，结果看是不可能了。
相信我，这里没有啥虎头蛇尾，以为我本来就觉得既没老虎（我家没有年画），也没 ...
软件工程的研究核心是什么，是人。可以说一切工程方面的研究核心都是人。这一点我早几年在平cmm的时候就说过，这不是我的发明创造，也算不上我的总结和分析，仅仅就是我一个直白的转述。而在今天包括张导师这样的人都承认了，《人》才是问题的关键，我想这一点很说明问题。当然我们不可能不去研究其他的问题，比如模式、设计、需求、语言、过程、方法等等。但是这些研究背后有一个前提，那就是人。
而敏捷现在很多人都在打这面旗帜，但是敏捷究竟是什么呢？速度快？感应和反映迅速？以至于最后就是我比你快，我就敏捷；我更迅速，我就更敏捷？如果这个《敏捷》仅仅是普通意义上的敏捷，当然可以这样说。但是我们知道《敏捷方法》当初曾经差点 ...
我已经在infoq那里向导师提出共同讨论的建议，如果他肯于平心静气的和我讨论，那么这个系列就不需要继续下去。
如果他不同意，我有两个选择。一个是不厚道的，将他所有的评论都一一进行点评。一个是厚道的，先对此案例进行我的分析，并在中间穿插对他的评论的点评——只要不是原则和根本错误，就不指出，而即便是大的错误也仅仅点到即止。也就是说一个是充满火药味和攻击性的，一个是平和而非攻击性的。
当然如果从可看性上来说，火药味和攻击性无疑是绝大多数人希望看到的。不过我的blog本身就没有多少人关注，而我自己也恰恰不喜欢别人关注，因此我不会考虑这个问题。
这位导师在写他的新书吗，我觉得这个也是个我点评的好机会。而 ...
导师觉得应该给大家补课，于是出来教大家如何学习。
引用 1）采用“结构化”的案例分析，尽量不要记流水账。
也就是要概括、提炼，屏蔽掉无关和琐碎的细节，做到结构分明，条理清晰，重点突出，让人一目了然。
本案的流水记账方式让人感觉有点发牢骚，怨情满腹，可读性较差。
可能的话，还可以分门别类地介绍一下项目地域、规模、应用特点、来龙去脉等背景信息。
2）如果人物众多，应该排一个人物表，比如：
A 高级工程师，麻烦制造者，作者的下属（同级？）
B Team Lead，与作者共事的管理者和支持者
D 作者的上司，不作技术性工作的经理
H 开发组的上司（大部门领导？）
J 前任 QA Lead，德高望重的老 ...
这个时候另外有一个cao yufei出来发言
引用 文章的题目改为：一个敏捷初哥放任越轨列车的故事。这样更符合文章的内容。同学们以批判断的眼光来看作者对项目中问题的反应，作为教训，不要再犯类似作者的错误。
导师马上追问：why？
可惜为何不与gigix继续进行下去呢？那个议论显然比这个深入，而且有实际的意义。
于是得到一个回答：引用那个时候我就已经预见了今天我不得不作出的处理。”
实际上从一开始作者就知道A的情况，A的弱点。
“我知道，这样的人不能重用，我对他没有信任感。”
在这样的认识前提下，作者应该作出的反应是什么呢？我觉得应该是细粒度的监控，充分的沟通，每天早上和A来个2分钟的meeti ...
其实导师早就对作者的做法有了疑问
引用 看完整篇故事，总体上我赞成作者和 B 的作法，A 的工作态度有问题，不适合留在项目组里。
但我同时也看到了一种可能不太好的情绪，作者为什么连自己的上司 D 也讨厌？牛到不把自己的上司甚至老板都放在眼里，恐怕不是一个好苗头。
引用 D 只是个经理，他不做技术性的工作，是无法了解下属的真实情况。这是一个典型的例子，不懂技术也不懂下属能力的经理会误判下属的真实情况。或多或少的蛮横安排资源，不接受团队回馈也是 D 所犯的错误。敏捷开发的一个重要手段是团队自我管理，也就是在阵地上的士兵比在指挥所的军官更了解战场战况，有时将在外，必须拥有“君命有所不受” ...
作者真的有点难受了
引用 作者答疑，
之所以用敏捷，我对这件事情的处理是有一个比较的，"A"在八个月内没有做任何正事，除了把手上的活分配给他人，自己就是关在办公室里没做一点事情。我在三个星期内，收集了证据，暴露了他的不作为给我们的直系上司，并将他调离我们组，解决了这个问题。这里就有一个比较，八个月很多人对他的容忍，让他白拿八个月的工资。和三个星期，给他一次次机会，没有效果，最后让上司出面解决。这就是敏捷了。
我记得我接受的训练，流程必须是流畅的，象生产线，没有失误阻止产品流过生产线，任何阻止生产流程的失误必须从根源解决。只有这样才能完全根除浪费，达到敏捷。我正是运用了我接受过的训练，解决了 ...
真正的好戏这个时候才刚刚开始，因为某个人这个时候才出场。
作者有点坐不住了，出来解释了。引用 我是作者，进行更进一步的答疑。
首先，这个"A"一上岗我就知道他有点不对头。当时他的工作和我的不冲突，所以我也没有仔细观察他的工作行为。当"D"我的直系上司把他分配给我时，我就知道这人会出问题，有读者问得好，既然知道"A"不行，为什么不直接就处理掉。这就是敏捷有时无法做到的--我要合理安排我和直系上司的关系，我不能直接反对他的决定，当时我没有直接的理由回绝，而且我应该给我的上司"The benefit of the doubts"。所以我没有直接回绝。
"A"加盟以后，我确实存在幻想说，疏导一下 ...
小刀的话显然让作者感到不舒服，于是出来做了解释
引用我是本文作者，之所以写这篇文章的目的是，敏捷开发中很重要的一个环节是发现问题，从根源上解决这个问题。很多读者对事实的实际发生根本不了解，所以会误解为我给这个开发者穿小鞋。事实上，这个开发者"A"从一开始就说“我会帮助你完成该完成的。”暗地里，他在三个星期中什么都没有做。我和他沟通无数次说，你要专心把一件工作做完再转到另一工作上，而不是这里忙一点，那里忙一点，最后什么都没有做完。我把自己的想法很清楚地传达给他 -- 我想看到实质性的工作进展。敏捷需要清晰的交流，我觉得我做得很好了。和我一起工作的"B"同样做了口头，文字上的交流。我和"B"在三个 ...
刚才出场的凉粉 小刀其实在此之前，已经发表过看法
引用 我在http://www.infoq.com/cn/news/2007/07/cultivating-agile-attitude一文中曾经说过，“我们会无缘无故的讨厌一件事情，会因为看一个人不顺眼而敌视他所说的一切，会骄傲自满，会自私自利，会固步自封，会讳疾忌医。也许，我们并不会因为知道敏捷可以帮助我们为客户交付最大的价值而轻易接受它，在实践中改变认知。”
我们不能空喊着“个体与交互胜过过程与工具”，而不去思考如何塑造有利于个体与交互的环境，解决对个体与交互造成制约的种种问题。从这一点上来看，作者的故事还是很有启发性的。
但是，我感 ...
马上Alex Xu就说
引用 其实这和Scrum没什么关系。放在一般的项目里同样有这种问题。这是项目组人员管理的问题。通常好的做法是先任命Team Leader，然后由HR提供人员来供TL挑选。当然现实中未必有这么理想。但是至少TL应该具有拒绝不合适的人员加入的权利。
在Scrum 的实践中，现在推荐的一种做法是签合同（申明）。有两种合同，一个是TM和Scrum Master，Product Owner签的，大家明确一下职责并发誓遵守，每个TM加入的时候都要签字。另一个是scrum master和公司管理层签的，确保整个项目的执行能够有相对独立的空间，尽量少的受到管理层的骚扰。当然Scrum ...
真正的高潮到来了，而且新的角色出场了。
引用于是我和B又找了我们前任QA Lead —— J。J是个德高望重的人，A之前的QA Lead，给了我们的建议是，直接找上司D。
于是作者和B共同行动起来
引用于是我和B起草了一封信说A一个星期下来没有实质性进展，反而有负进展。他的态度是我们不能容忍的。希望D能替我们安排一个好的解决方案，我们对事情发展到这个状态已经无能为力了。
此时大概是周末，作者可以有时间思考一下。于是他说
引用周末，我仔细想了一下，和D见面时不能透露无望的神情。读者如果看过《教父》，知道Don Corleone在电影一开始接见好莱坞大明星Johnny Fontane，Johnny ...
事情似乎一开始在朝好的方向发展了。
一个星期之后，作者认为A有所改变。因为事态发展了，开发组的领导H参与进来，督促A“要把工作重心转移到”作者“分配的事务上”。同时D也对A做了安排，并且是“特别安排”
引用让他全力帮助我。
于是他们就开始真正的运转起来引用我仗着我有令箭和A的态度转变，就开始给他分配任务，每天和他进行2分钟的Scrum。同时也帮他开始建立开发环境，我花费了三天，才把他的开发环境整理清除，此处应该是笔误，“清除”应该是“清楚”。
作者还及时加了个点评
引用他被聘开始工作到现在，对自己的开发环境维护什么都没有做，一切都是乱七八糟，然后自己还不懂到我们的开发测试Wiki上找答案。让我 ...
A以来就干了一件很让作者恼火的事情。他写了一封信给作者的领导D，列出了他认为2008年他所在小组“应尽的义务”。而作者马上就声称A引用他自己承担的任务里，没有一项是和他新工作相关的，而且每个都要花费不少时间操作。
这里不好说，作者究竟是因为在他看来A是以领导名义发的这个信给作者的领导D，还是因为A又是在推卸责任。引用这不是明摆着要消极处理他的新工作吗
不过不管如何，其马上给A回信（其实严格意义上不能叫回信，因为A的信是给D的，而不是给作者），并且也抄送了一封给D。这里似乎是在暗示，是由D在这中间也做了些什么。
而下面的情况就愈发微妙起来——作者马上
引用当时我的感觉是这个人不适合在我的组里做事 ...
文章我本想先放一放，因为就如同经常发生的情况一样，评论往往比原文更加精彩。不过即便如此，我还是有必要叙述一下这个文章的内容。而具体分析和我建议的应对，则会在对评论进行分析之中和之后给出。
首先作者一开始就声称自己没有管理经验，并且认为这个事情是公司政治。并且声明：
引用让我认识到如何使用敏捷教条对管理方面的问题进行分析，如何采取合适策略来解决此类问题。
事情的经过时这样的——在2007年6月前，作者被派往一个团队做QA。用作者的话来说是引用我被分派到一个新成立的小组做QA Lead
不过随后他又说，自己是单枪匹马，而随着工作的进行，感觉一个人不能应付。于是提出需要增派人手。不过由于人员紧张， ...
今天敏捷已经从非主流成为主流，从邪门外道成为了名门正派。基于此现实，情况于是同数年前，发生了根本性的变化。
当几年前，我们几个人在chinauml、csdn介绍敏捷，并且经常为了敏捷同别人争吵的时候，我们的力量是那么渺小。而今日情况发生了根本性的转变，一大批人蜂拥的声称自己是敏捷的追随者。而在这一片敏捷的嘈杂声中，原来的目标以及信念却逐渐被人们忘记，敏捷已经从一种思想指导下的实践，形成了一些“成熟”的过程与最佳实践。
早就想对现状作个反思与总结，但是自己太懒，而水平也烂，一直没有动手。不过最近infoq中国上发表的一篇文章，及其随后开展的讨论，让我有了写些什么的想法。
文章链接如下，http: ...
ozzzzzz
- 浏览: 81912 次
- 性别:
- 详细资料
搜索本博客
最近加入圈子
最新评论
-
FDD方法讲座普及篇完成
:idea: 好东西，快快开讲吧
-- by 憨老汉 -
几个主题的准备
一直想看FDD的实例
-- by 憨老汉 -
几个主题的准备
o6z啊，这个什么时候出来呀，我都等你好几年了
-- by 憨老汉 -
《JAVA将死？》之后续
别忘了java还有个script，星星之火可以燎原
-- by KKFC -
送一句话
嗯，说的通俗些，就是要多实践：）上面说的那个“五不”人员应该再加一条——“不世出 ...
-- by springhill
评论排行榜