摘要：
实践过敏捷的朋友可能会有这样的感概：“敏捷太理想了！敏捷对人的要求太高了！”说得太对了！！我们不能照搬敏捷，要实践敏捷，首先需要直接面对和解决敏捷在中国的水土不服问题！
本文大纲：
1.鬼佬讲敏捷——神仙谈理想
2.中国项目的超典型案例：打折信息网
3.两大限死，两不确定
4.如何应对“两大限死，两不确定”？
5.中国软件研发人员的“可爱”特点
本文是系列文章的第3篇，如果还没有看过前面的文章，建议先看看！
第一篇：敏捷的“官方”定义
链接：http://www.cnblogs.com/umlonline/p/3450032.html
第二篇：敏捷流程框架及敏捷实践一览
链接：http://www.cnblogs.com/umlonline/p/3450428.html
1.鬼佬讲敏捷——神仙谈理想
中国很多年度大会都会请一些国外敏捷大师来分享，有朋自远方来不亦乐乎！鬼佬大师是敏捷的前辈，在国外有多年的敏捷实践经验，能听到他的分享简直是“三生有幸”（这样说好像有点夸张噢）！于是你终于听了某大师的分享，你可能会出现以下几种状况：
1）上课过程中进入“某种仙境”，心中澎拜，但回头才发现无法落地。
2）你可能上课途中就发现一些难以落地的问题，向鬼佬大师提问，但因为鬼佬大师不懂中国国情，又加上双方语言不通（需要通过翻译），最后问题只能不了了之。
3）你已经实践了一段时间的敏捷，鬼佬大师一边讲课，你一边摇头叹气（或者是在心中摇头叹气），你可能会得到这样一个结论：鬼佬讲敏捷 = 神仙谈理想！
我不是在鄙视鬼佬大师，鬼佬大师的实践经验在国外绝对是可行和成功滴，但在中国，鬼佬大师们可能就不懂了……
我有以下几个关于敏捷的重要观点：
1）不能照搬敏捷的一套，敏捷只是我们可以借鉴的一种方案，只要有用管他是不是敏捷都可以用上。
2）我们必须分析出敏捷在中国“水土不服”问题所在，想方法解决这些问题。
下面为你分享敏捷如何在中国水土不服？
2.中国项目的超典型案例：打折信息网
若干年前，当时团购类的网站很少、也不流行。某一非IT行业的土豪老板，想花10万元（人民币）做这个的一个网站：
1）网站能自动抓取各大厂商的官网网站的商品信息及打折信息。
2）网站能分类及友好展示各种最新的商品打折信息，网民能通过这些信息找到实惠的商品及购买方法。
3）网站火起来后，可以向这些商家收取费用（比方说年费之类的）。商家愿意付费，因为有利于他们的商品销售，而网站实现了盈利，消费者也可以买到实惠商品，实现三赢！
愿望很美好，现实很骨感！
你不是神仙，你是是现实中人，你的老板觉得要做这个项目，并且任命你为项目经理，你能完成这个项目吗？你觉得你能“敏捷”地完成这个项目吗？
你可能会觉得很悲剧，但更悲剧的事情还在后面！跟你再进一步说说这个项目的其他情况：
1）你的老板想跟客户签的合同金额是10万，但老板只给你5万的预算来完成项目。老板果然是老板，够狠！他要赚5万！！
2）老板不是真的给你现金5万，然后你开始干活。5万是人工成本，按每人月1万来计算，也就是说你最多只能花5人月来完成项目。（后面再详细介绍人工成本和人月）
3）尽管你有多年的研发及项目管理经验，但类似的网站你还没有做过。
4）你的团队除了你以外，你还有两名程序员（还没有毕业的应届毕业生），还有一名不懂研发的美工（美工经验很丰富）。
5）项目是有工期限制的，你这么牛B，而客户又比较急，给你一个半月吧。
下面说明一下人工成本和人月的概念，已经懂的可以直接略过这段。
人工成本：软件研发的成本主要在于人工成本，我们当时算了一个指标，叫做“人工综合单价”。简单说就是将公司运营的所有成本平均摊到每一位研发人员上，几年前在广州这个人工综合单价大概是1-2万/人月（现在当然是不止这个价钱滴）。如果你仅仅是初级的岗位，你的薪金可能只有这个人工综合单价的1/3甚至不到，这是很正常的。
人月：两个人做一个月的工作，工作量叫两人月；一个人干两个月，工作量也是两人月；5个人干3个月，就是15人月。人月乘以人工综合单价，就可以得到项目的总成本。通过人月还不能直接得到工期，这个项目总成本是用5人月来控制的，不是说你投入10个人半个月就可以搞定的，就好像不是10个女人就可以1个月生出孩子的！
可能你不会经历这样悲剧的事情，但这是我的一段悲剧经历，这是我经历过的一个超级极端的典型中国CASE！
3.两大限死，两不确定
中国软件项目的一个大特点，就是“两大限死，两不确定”！
限死1：预算限死。（本项目只给你5万预算）
限死2：工期限死。（1.5个月工期）
不确定1：需求不确定。（在互联网抓取各种打折商品信息，天啊，要抓取的网站和商品信息可能是无穷无尽啊！）
不确定2：技术不确定。（网页信息抓取？没做过！但我知道这些HTML每个网站都不一样，并不是这么简单抓取文本就OK了，还要分析出商品名称、种类、价格、所属商家等信息，并保存在数据库相应的表和字段中。）
你当我是超人，带领两个还没有毕业的应届毕业生，加一个不懂研发的熟练美工，就算我RP大爆发，也不可能完成这个“impossible mission”。如果我能搞定，下一部“Mission Impossible”（电影：谍中谍）找我演算了！
这个项目如果要做，注定就是失败的，失败原因之一就是我没有这么大本事搞定这个项目，但最根本的原因是：客户认为10万元就可以做出这个网站，通过网站的“自动抓取”功能就可以丰富网站的打折商品数据，然后网站就会自然而火起来吗？假设10万真的可以做出这个网站，如果你不砸100万以上的资金去推广和运营，这个网站只能一直是默默无闻。
以上分析暴露了中国软件项目的一个深层次的根本问题，就是“拍脑袋”项目！
现在可以小结一下了，我想说明的是：
1）如果这个项目是“拍脑袋”拍出来的，运气好这个项目仍然有戏，但大部分情况是这个项目战略上可能就是失败的，神仙都可能无法搭救这个项目，更加不要谈敏捷可以改变什么了。
2）如果这个项目不是“拍脑袋”拍出来，你还需要面对“两大限死，两不确定”的困境。中国软件项目基本上都有这样的特点，合同中合同金额和工期是写死的，但需求很粗，可能是不到一页纸的需求，有些更悲剧，只有几句话。而项目中可能需要用到的技术，我们基本上不太可能全部都掌握。
这个时候，我们是不是死定了呢？敏捷还有戏吗？
4.如何应对“两大限死，两不确定”？
1）“两大限死”我们基本无法改变，我们只有接受！
在中国我们不可能跟客户这样谈：这个项目我们打算采用现在世界上最先进的SCRUM敏捷开发方法，我们将会通过多个冲刺来完成，一个月一个冲刺，我们按冲刺来收费吧！
你敢这样跟客户说，客户要不当你是外星人，要么就是马上换另外一家软件公司不鸟你。
2）“两不确定”是转机，我们有机会力挽狂澜！
“需求不确定”看上去是一种危机，但危机也是机会！需求可以往很多很不确定的方向继续发展，但我们也可以抓住客户真正的需要，调研、分析和整理出客户可以接受的需求，将需求控制在合理的范围内。当然要做到这样很难，这样就需要我们提升需求分析的能力，敏捷的“用户故事”能帮助我们，当然也不能仅靠“用户故事”。
“技术不确定”也会为我们提供机会，如果能找到合适的技术和实现方法，我们是有机会用比较少的工作量和代价来完成项目的。敏捷12准则之一“对技术的精益求精以及对设计的不断完善将提升敏捷性”，在这里就充分体现出来了。
需求决定了软件的价值，技术（设计）决定了软件的工作量，也就是软件的生产成本，如果我们能控制这两方面，项目成功机会就很高了。
国外的客户和中国的客户是没得比的，国外的客户是知道以下几个基本道理的：
1）做软件之前是需要先确定需求的。（国内客户喜欢让你先做出来看看。）
2）需求变更是要收费的。（国内客户认为需求变更是很正常的事情，但收费就不正常了。）
3）计算机不是强大到什么事情都能干的。（国内客户会认为计算机很强大，甚至可以干掉外星人！）
所以我们要谈敏捷，先要面对这个国情！
当然如果你从事的是互联网行业，或者是自主研发产品，那么“两大限死”的情况就会没有了，“两大不确定”的情况仍然存在，但已经比较容易实践一些敏捷实践（如：冲刺）了。在中国，如果你是做项目，实践敏捷难度很高；如果你是做互联网或做产品，实践敏捷的难度将会降低不少。但无论是你哪种情况，你还需要面对下面这个挑战！
5.中国软件研发人员的“可爱”特点
先上一张图：
这张图不用我解释，你基本就可以懂了……
不少敏捷实践者抱怨：敏捷对人的要求太高了！上图就是我们的现状！
我是70后，刚开始工作那两三年，身边的同事基本都是70后；
过了几年，来了一些80后，于是我们这些70后就抱怨：这些80后啊……
又过了若干年，80后成为管理层了，开始招聘一些90后，然后抱怨：这些90后啊……
于是我们可以推测，不久的将来，90后将会抱怨：这些00后啊……
天啊，为什么会这样？这是社会的错？这是中国教育的错？难道我们的教育真的让我们一代不如一代？（重要说明：你千万不要对号入座噢，不是说70后一定比80后优秀，也不是80后比90后优秀，这只是某种现象。）
说起IT人，特别是说起程序员，我们就会想到两个字——闷骚！（重要说明：你也不要对号入座噢！）
曾经有某位敏捷教练跟我抱怨，他天天做“求沟通”的事情，那些人就是一堆木头，踢几下才动一点点。
我听了后表示淡定：这种“求沟通”的事情我以前天天干，不亦乐乎。我只能通过这样的行动，希望潜移默化慢慢地让木头变得更加主动。
我们有什么办法改变这种情况呢？难道要等中国教育的改革吗？那要等到哪年哪月啊啊啊啊啊啊啊？
方法还是有滴，不过我要先告诉你：其实程序员只是表面“闷骚”而已，他们其实内心是“狂野”的，我们要想办法将程序员内心中的“野性”释放出来！
我举两个程序员其实是内心“狂野”的例子：
1）如果你敢当面和当众说某程序员他写的某段代码不好，他一定会跟你据理力争，平时闷骚的他有可能激动得拍桌子。
2）某程序员想和女朋友证明，程序员在技术上是争抢好胜的。于是在某论坛发了一个贴，主题“PHP是最好的开发语言”，结果你可以预测了…… 女朋友说：“我知道了，我们去吃饭吧！”程序员说：“不行，我还要说服他们PHP是最好的开发语言！”
多年的不合适的中国教育，可能让程序员内敛起来，但大部分程序员是追求进步的，也是不服输的，如果我们能用合适的管理方式、激励方法、团队建设方法，就可以释放大家的主动性，打造出“自组织”的开发团队。将来我会为大家分享更多的敏捷团队建设方法。
请看下一文！
下一篇将为你分享：神马是敏捷？（4）——敏捷不能当饭吃
摘要：我们将会谈谈敏捷对组织架构、团队文化的要求，特别是对薪金待遇的要求！
作者：张传波
创新工场创业课堂（敏捷课程）讲师
软件研发管理资深顾问
CMMI首席专家
《火球——UML大战需求分析》作者
软件知识原创基地创办人
相关文章
