解读敏捷2 - 敏捷实施的六个陷阱

随着敏捷日益成为主流,各种各样的敏捷会议召开,一本又一本的敏捷图书出版,一个又一个的公司前赴后继的迈向敏捷,好一番火热景象。这让我回忆起了当年看报时的一个感受,当时每张报纸的显眼处都能看到牛皮癣和肝病的广告,咋一看感觉会治病的人很多,仔细思考下才发觉是根本原因是能治好病的人很少,否则市场上不会那么热闹。敏捷的现状是不是也是如此呢?

“与其做敏捷,不如变敏捷!Be agile rather than do agile.”但对于大多数公司来讲,如果没做过敏捷,怎么知道如何变敏捷。而且做敏捷可以检查和测量,变敏捷则不能,这违背了“不能被测量则不能被管理”的管理定律。但大多数敏捷实施会失败!那些被敏捷后的美好前景吸引、前赴后继奔向敏捷的公司基本上是在自寻烦恼,“苦逼敏捷”开始盛行。

窃以为要想成功实施敏捷必须先解决下面六个问题:

1. 没有目标,为敏捷而敏捷

为敏捷而敏捷,并不是为了解决真正的问题,把手段当做目标。不少公司简单的被市场宣传打动,认为敏捷就代表着好,不敏捷就不好。这些公司往往会被轻易的忽悠,高估敏捷实施的效果,希望通过简单的敏捷实施就能解决面临的很多问题。因为没有目标,他们在实施的时候只能力求规范。这是一种符合国情的管理方式,俗称运动式管理。运动式管理的目标仅仅是为了运动,运动之后才知道自己在裸泳

贵公司当前的主要问题是什么?实施敏捷要解决哪些问题?哪些问题是不能通过实施敏捷解决的?

2. 没搞懂敏捷

不想变敏捷,只想做敏捷。没有真正投入成本研究敏捷的公司并不知道敏捷因何生效。当然,他们也有研究,例如派人参加两天的CSM培训,拿到证书;或者买进两本敏捷的书籍,看看红绿模式或者知道每天早上要回答三个问题。这种肤浅的研究把敏捷看做过程,而且是非常简单的过程。他们往往会低估敏捷实施的难度,高估敏捷实施的效果,结果在真正实施的时候碰的头破血流。在这种情况下实施敏捷就是一个悲剧。“我遵守所有的规则,人的和神的。而你不遵守规则,但他们爱你胜过爱我。“——《燃情岁月》

敏捷是什么?敏捷到底是怎样发挥作用的?需要多长时间?敏捷对什么没用?

They told me that the world would be changed if I could answer three questions every morning. Now I’ve answered them for a month, why hasn’t the world been changed?

3. 错误的方法:套装癖

套装癖是指人们更喜欢看起来完整的东西来满足他们的心理愿望,以逃避独立思考和解决问题的真正困难。套装癖现象不仅仅发生在敏捷软件开发,它体现了人们对解决方案而不是解决问题的热爱。瀑布模型并不是瀑布模型提出者的本意,但它被曲解成了瀑布模型这样一个软件开发解决方案;之所以提出CMM是为了衡量过程中的质量,但它变成了解决软件开发企业管理问题的解决方案;Scrum不是解决方案,但人们或者是抱怨Scrum解决方案没有提供足够的实践,或者是自己为它加上用户故事、计划扑克和其他实践,一定要把它变成解决方案。人们一边在市场上追逐套装,一边在抱怨套装原来是中看不中用啊。的确,实施一个套装比实施一个实践难多了,但套装癖们还是乐此不疲。

实施敏捷就是实施Scrum吗?真的需要所有的实践吗?有没有哪一个实践做好了,真的有效了?

4. 基础不行

敏捷软件开发还是软件开发,不会因为实施了敏捷,就可以招聘技能更低的人完成工作了。以Scrum为例,Scrum是暴露问题而不是解决问题,解决问题还是要靠人。人与人之间的冲突需要冲突解决能力,团队建设需要领导能力,对业务的深入理解需要对业务的掌握和分析能力,开发人员的设计编码能力更别说。Scrum的创始人说过,白痴也可以用Scrum,然后他又补充了一句,当然,他们只能产出垃圾而已。你们公司需要垃圾吗?

贵公司现在的软件开发能力如何?经过6-12月后,代码的质量能保障吗?开发人员理解业务吗?架构是不是让人很崩溃?

5. 环境冲突

要实施敏捷,却没有实施敏捷所需的环境、人和文化。大多数的公司无法包容为了解决问题突破公司规定,敢指出领导问题的人,在这种公司大规模实施敏捷,纯属找抽。这也是很多人谈到敏捷都会说,敏捷很好,但是在我们公司不适合的原因所在。而且实施敏捷带来的透明性会让坏消息在开始的时候满天飞,能否容忍坏消息?能否正确引导团队的认识?对管理层是极大的考验,其实坏消息一直存在,只是以前被捂住了而已。“贪官奸,清官要更奸。”——来自周星驰《九品芝麻官》

贵公司有没有更奸的清官?能不能容忍坏消息?能容忍多久?鼓励尝试吗?还是对任何“错误”都要惩罚?

6. 高估研发管理能力

软件研发管理能力是被软件开发公司忽视的癌症。有一个非常简单的问题来考察软件研发管理能力,“请问贵公司Code review做的怎么样?”看看管理层如何回答这个问题,到几个项目团队去看看实际做的怎么样,问问开发人员对Code review的感受。Code review是搞软件的人都懂的实践,人人都知道应该做,但是大多数公司在这一点上都不合格。

贵公司有没有一个软件开发实践是真正推下去了,没有应付了事的?哪一个敏捷实践是贵公司准备实施的?怎么真正推下去?

 

解读敏捷

这就是解读敏捷这个系列的目的了,希望通过这个系列达到如下目的:1)展示我对敏捷的理解,以帮助更多的人真正了解敏捷;2)对实施敏捷提出想法和建议;3)提供一些实例供参考。

虽然看起来很容易,但是敏捷真的很难,需要多年的学习和实践。只想按葫芦画瓢,结果就会是按下葫芦浮起瓢。我的格言是:简简单单就能做好的事不值得付出努力。就是因为难,所以做好了才能成为竞争力,才能与众不同,是这个道理吧。

后续的内容还没有全部构思好,但考虑中的内容包括:

1)实践与理论解析

敏捷有多难?从细节看全局,如何将细节做到极致,从细节理解敏捷。请看后续:解读敏捷实践之结对Review,解读敏捷实践之每日立会。怎么理解套装的Scrum、XP等等。

敏捷背后的理论解析,排队论,博弈等等。

2)实施方法与样例

你想解决什么问题?采用什么方法?问题域分析与道法术器。

3)杂谈

一些相关的事例与感悟。

 

PS:@larrycaiyu 建议我把名字从《大多数敏捷实施会失败》改成《敏捷实施的六个陷阱》,欣然改之。

posted on 2011-12-14 12:51  大卫张  阅读(2143)  评论(3编辑  收藏  举报

导航