敏捷的前世来生

一， 敏捷的“官方”定义

二， 敏捷流程框架及敏捷实践一览

三， 敏捷在中国的水土不服

四， 敏捷不能当饭吃

一， 敏捷的“官方”定义

 

1.从“打针”说起

 

互联网中有一张关于敏捷的“神图”，请仔细品味一下：

图1.1 打针与敏捷的关系

 

在敏捷面前我们都是“小朋友”，小朋友要打的这个针叫“敏捷”！

A）最左边的小胖帅哥，正在打针（正在实施敏捷），你看到他的“精彩”表情了吧！

B）中级的戴眼镜的小帅哥，马上就要到他打针了（即将实施敏捷），他见到小胖哥的夸张表情，整理犹豫和忐忑当中……

C）右边一堆暂时还不需要打针（敏捷“围观”群众）的小朋友，他们是不明“敏捷”真相的围观群众。所谓针不到肉不知道疼，先围观乐着呗……

这个图实在太神了！你属于哪种情况呢？正在实施敏捷？即将实施敏捷？还是围观当中？

 

2.敏捷的各大门派

2000年初我听说的一种敏捷叫做“XP”，当时还以为这个“XP”与 WindowsXP 有关系呢！长时间的工作积累，让我认识和实践了多种敏捷，以下的敏捷门派，你听说过吗？

1）OpenUP（RUP敏捷版）
2）精益开发
3）极限编程（Extreme Programming,简称：XP）
4）SCRUM
5）MSF（英文：Microsoft Solution Framework，中文直译：微软解决方案框架，可以理解为：微软研发的最佳实践）
6）水晶方法
7）特性驱动开发

有一本书叫《敏捷开发知识体系》对上述提到的大部分敏捷门派都有所介绍，可以考虑入手一本看看。我还是这本书的编委之一呢，不过实在惭愧，我对本书贡献很小，不过我会通过博客和网站陆续为大家分享敏捷方面的文章。

当我提到MSF也算敏捷门派一种时，可能会有朋友会说：不是吧？且听我逐一道来……

MSF是我第一次全面学习和实践的软件研发方法论，后续我又学习和实践了XP和SCRUM，我觉得无论是哪一种都具备敏捷的特点，并且我认为MSF是最全面、严谨和有效的一种。关于MSF，我曾经分享了一个视频课程“微软研发那些事儿”，欢迎看看：http://www.umlonline.org/school/viewthread.php?tid=2491

本系列文章并不会深入讨论MSF，MSF似乎已经“廉颇老矣”，我会分享SCRUM及极限编程方面的敏捷实践为主，将来有机会再详细分享MSF。这里也需要稍微啰嗦一下，我其实并不熟悉全部的敏捷门派，仅仅是对MSF、XP和SCRUM都比较熟，积累了一些实践经验，并且有自己的想法和体会。

 

3.敏捷四大宣言

敏捷其实无所谓“官方”，你只要足够牛B，你自己都可以建立自己的门派，用你喜欢的名字来命名你的门派！但问题来了，如果这么多门派都说自己才是正宗的敏捷，咋办？

那简单，开一个武林大会决一胜负就是了，谁赢就是正宗滴！所以美国各大敏捷门派开了一个敏捷大会，各大门派血战九九八十一天，决不出胜负，干脆成立了一个敏捷联盟，达成了一个重要的一致决定，那就是：敏捷的四大宣言和十二准则，要满足这四大宣言和十二准则才能叫敏捷！这下好了，决不出胜负，他们干脆抱团结盟，为敏捷立下了门槛了。

哈哈，上述一段是戏说，当家不要完全当真。其实事实真相是：美国各大敏捷流派经过讨论协商后，提炼出各大门派的共性，这就是四大宣言和十二准则。当然可能有人会跳起来说：干嘛是美国？不能是中国吗？我也很想是中国啊，可惜我们在这方面是落后于人家滴，所以只能说人家制定标准，我们学习罗！有朝一日，希望我们能超过美国吧！

我们用一个图看看敏捷四大宣言吧：

图1.2 敏捷四大宣言

 

看这个图是需要一点“学问”滴，这个图要点是：敏捷是一个相对的词汇，敏捷代表左边比右边更好一点。于是这个图可以用以下四句话来表达：

1）“个体和互动”更优于“流程和工具”；

2）“工作的软件”更优于“详尽的文档”；

3）“客户合作”更优于“合同谈判”；

4）“相应变化”更优于“遵循计划”。

这四句话怎样理解呢？我们先通过几个简单例子来体会一下吧，后面再为大家分享更多文章。

例1：有人说做CMMI就是用一套流程和文档将事情复杂化，然后为了管理这一套流程和文档，再用一套流程和文档来管理前面的这一套流程和文档。这样是相当悲催的事情，说它是反敏捷已经轻了，我觉得是反人类！这样的做法明显就是违背了敏捷宣言的第1、2句话。

例2：某公司过了CMMI3级，过程要求必须产生一系列的文档，结果文档有了，但软件不能工作。这样做明显违背了敏捷宣言的第2句话。实践敏捷的你觉得爽了，这下可以“打正旗号”地不写文档了，但问题哪怕文档不用写，你能保证软件是可以工作的吗？你能做到“持续集成”和“测试先行”吗？“持续集成”和“测试先行”其实就是第2句话所演化出来的最佳实践。（后续文章再为详细大家分享“持续集成”和“测试先行”）

例3：某软件公司为了让客户“高兴”，一直满足客户的“无理”要求，但客户最后还是将软件公司告上法庭，于是双方在法庭上引用合同条款互殴。软件公司律师辩护的理据：一直按照客户的要求来做出软件，软件公司没有过失。客户律师的理据：软件公司没有提供专业服务，没有能满足客户的真正需要。最后法庭判客户胜诉！遇到强势的客户，可能你会觉得难以做到“客户合作”，但如果你一味奉承客户，而不想办法和客户好好沟通，达至双方合作和双赢，最后如果要闹上法庭，我们软件公司败诉的机会是很大的。因为软件是一项专业的服务，客户并不是专业人士，我们要承担更多的过失责任。这个案例体现了“客户合作”更优于“合同谈判”。

例4：为了更好实践敏捷宣言第4句话，我们的项目干脆就不需要计划了，因为计划赶不上变化！请问这是在敏捷吗？恰恰相反，计划正是应对变化的最好办法，但我们的计划需要及时响应变化。“敏捷”常常成为“伪敏捷”外壳，或者成为“手工作坊”模式的遮丑布，这些都是我们需要注意的。

上述4个例子还不能充分说明这四句话的内涵，先简单体会一下吧，我们还需要在实践中反复体会这四句话。

 

4.敏捷的十二个准则

四大宣言可能有点粗，所以美国敏捷联盟还弄了12个准则，这12个准则可以看成是这四大宣言的细化。

12准则如下：

1）我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
2）欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
3）要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
4）项目过程中，业务人员与开发人员必须在一起工作。
5）要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
6）无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7）可用的软件是衡量进度的主要指标。
8）敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9）对技术的精益求精以及对设计的不断完善将提升敏捷性。
10）要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11）最佳的架构、需求和设计出自于自组织的团队。
12）团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

这12个准则比四大宣言多了不少字，是不是已经可以帮助你精准理解敏捷了？

如果你回答是，恭喜你，你是超级小神童！如果你的回答是否，那我们要握一下爪了，伙计，我终于找到一个和我一样的正常人了！

12个准则只能帮助我们稍微了解更多，但可能会带给我们更多的疑问。上述这12个准则，无论你现在理解成怎样，我强烈建议你和你目前的实际工作联系起来，对上述12条准则逐条打分。如果你觉得你目前工作能完全实践这条准则可打10分，如果完全没有实践可打1分，根据你的感觉打1-10分。如果部分准则你完全理解不了，那先不要打分，带着疑问看我后面的文章。

敏捷四大宣言和十二准则，需要不断地通过实际工作来理解和体会！

 

5.敏捷的“官方”定义

那次年会被人措手不及的问了这个问题：什么是敏捷？

当时我招架不了，回答了：敏捷就是用“简单有效”的原则做事情。

到现在我还死要面子，坚持这个回答是正确的。好吧，我承认我不是什么名人，我说什么是敏捷不算数，那么就来个“官方”定义吧：

那就是“符合敏捷四大宣言和十二个准则的做法，都是敏捷！”

这可不是我说的，是美国敏捷联盟达成一致的结果。但这句话说得轻巧，要理解敏捷四大宣言和十二个准则，需要花多长的时间去实践和体会啊。

作为敏捷入门者来说，先简单了解到这里就可以了；作为敏捷实践资深人士来说，也没有必要就纠结“敏捷”这个概念，有用就行了管他是不是敏捷，敏捷只是个说法而已。

 

6.敏捷相关学习资料

体验最火的敏捷——SCRUM（视频课程）：http://www.umlonline.org/school/viewthread.php?tid=2524

超越极限编程（视频课程）： http://www.umlonline.org/school/viewthread.php?tid=321

每日例会 = 僵尸大会？（视频课程）：http://www.umlonline.org/school/thread-2602-1-1.html

二， 敏捷流程框架及敏捷实践一览

1.神马是SCRUM？

问：“SCRUM”是什么意思？

答：橄榄球呗！

继续问：老兄，我问的是敏捷的SCRUM！

答：哦！嗯……（停顿几秒）这是因为这种敏捷方法论和橄榄球比赛的特点有点类似，所以才叫SCRUM。

橄榄球比赛双方对攻，每一次进攻叫做SPRINT（冲刺），橄榄球比赛也非常注重团队合作，这些都符合这种敏捷方法的特点，所以引用了“SCRUM”这个名称来命名这个敏捷的方法论。另外“SCRUM”这个名字很形象、响亮、容易记忆，有噱头利于宣传。那天你也可以独创一种神秘的敏捷方法论，然后配上一个很酷的名称，说不定会把SCRUM的风头盖过去呢！SCRUM可能是近年来最火的一种敏捷，适用于大中小型项目，也适用于分布式的团队。

美国有敏捷SCRUM联盟，可以认为这就是SCRUM官方机构，搞了一个SCRUM认证培训。中国有一家SCRUM中文网网站，她是中国领先的Scrum认证及敏捷培训授权服务机构，我还是SCRUM中文网的顾问！在中国如果你想搞一个SCRUM相关的认证证书，你需要参加官方授权老师讲授的相关课程，例如：SCRUM Master的课程，好像是7000大元（人民币）/人（最近不知道涨价木有），国外的老师来中国授课，配上中文助教。这个课程相当贵，其中一个原因是因为这是官方授权的课程，需要颁授官方认可的证书，官方其实是要收取费用的，所以价钱就上去了。

SCRUM这么火其实可能并不是因为她真的比其他敏捷方法优秀很多，而是一种商业操作模式，有利益驱动，背后自然就有很多推手。这个国外的SCRUM联盟很会赚钱，设立标准，然后授权给不同的敏捷培训及服务机构，只要你做官方发证的培训，我就会赚到钱。SCRUM越火，认知度越高，越容易赚到钱。这道理和PMP证书、CMMI认证、ISO认证等的商业模式是一致的。证书在我们中国，你懂滴，总会有人前赴后继地去花钱搞证！

上面一段话说了SCRUM的商业模式，我并不是为了说明SCRUM商业模式很浓，纯粹为了赚钱，而是让你知道是怎么一回事。其实SCRUM还是不错滴，很多最佳实践相当有用，不过需要结合中国国情来处理。如果你能让公司报销，或者你是土豪，那么花7000大元去参加培训得到一个证书，这也是相当不错的事情。如果你和我一样是土鳖，没有这么多银两，也没有关系，证书什么滴其实是浮云，关键是你还可以通过很多途径和实践来学习和体会SCRUM。

另外需要说明，不要尽信敏捷，也不要尽信SCRUM，无论是什么知识，我们都需要用“拿来主义”的心态来处理。

 

2.SCRUM 的流程框架

SCRUM的内涵到底是怎样的？一个图就可以搞定！

图2.1 SCRUM一张图搞定

 

这张图展示了SCRUM的流程框架及团队架构，我们先看流程框架部分，下小节才说团队架构部分。

你可以由左到右看这张图：

1）左边部分是需要完成的工作，由左到右分别是：产品代办列表（Product Backlog）、冲刺代办列表（Sprint Backlog）、工作项分解。

通常通过“用户故事”的方式来表示产品代办列表、冲刺代办列表，产品代办列表的用户故事可能比较大，需要进一步细分为比较细的用户故事，然后放入不同的Sprint中，作为不同Sprint的代办事项，而Sprint中的用户故事，还可以继续拆分成更细的工作项分解。这段内容先大致这样理解就可以后，以后再会为大家详细分享需求拆解方面的文章。

2）右边部分说明了：这些需要完成的工作，需要通过大小迭代来完成。

大迭代是指：Sprint（冲刺，也就是小版本），通常是30天的时间，每30天增量式的交付“可运行的软件”。“可运行的软件”这个说法还不太好，应该是“可工作的软件”，否则你可能认为编译通过程序能跑就是“可运行”了，而“可工作”才是重要指标，不仅仅能运行，还能为客户带来实在价值，才叫“可工作”。

小迭代是指：每天的项目会议，通常是15分钟内。其实“站立”开会不是必须的，你可以“坐”着开，甚至“躺”着开。开会时间可以是早上、中午或下班前。形式和时间都不是关键，关键是要有效，要领会24小时开一次会议的核心思路！我们都知道问题越早发现越早处理，处理成本越低，24小时开会让问题被发现时间不会超过24小时，将问题消灭萌杀状态，同时每天修正项目的方向，保证我们一直在做正确的事情。

 

3.SCRUM 的团队角色

图2.1右下方有三种角色：产品负责人、Scrum Master、开发团队，下面分别介绍。

 

产品负责人（Product Owner）

这个角色负责的事情主要是：

1）提供远景；
2）提供边界；
3）提供用户故事的优先级。

该角色和产品经理是不是类似甚至一样呢？

某些公司的产品经理很强势（特别是互联网公司），开发团队经常会这样抱怨产品经理：

1）上午提要求，下午就要交付。
2）需求经常变！
3）需求解释不清楚，想找你澄清需求的时候，找不到你！
4）人仰马翻好不容易做出来了，但这些功能基本没有人用。

SCRUM中的产品负责人还需要注意做到以下两点：

1）要和开发团队沟通需求。
2）要尊重开发团队的研发能力。

也就是说如果产品负责人不能让开发团队理解好需求，这是某种失职；如果开发团队总是疲于奔命经常加班来完成工作，那就是不尊重开发团队的研发能力，不尊重软件研发工作的客观规律。

 

Scrum Master

这个中文不知道怎样翻译好，翻译成“橄榄球教练”，这不太好吧？于是有人翻译成：SCRUM教练、敏捷教练。

这个角色要做的主要事情：

1）训练团队用正确的方法做事，遵循SCRUM的流程和做事原则。
2）不代替团队做决定。

这其实是一个很爽很舒服的角色，因为他只需要讲道理，不需要做决定！他主要职责是训练大家做事情，而不是亲自负责这个事情，这跟项目经理是很不一样的。

我们的项目经理需要安排很多事情，做很多决定，还需要监督大家。项目经理就是一个大坑，什么都可以放进去！但SM（Scrum Master）就舒服多了……

Scrum Master这个角色，还需要注意以下几点：

1）你没有行政权力。例如：你不能决定项目团队某成员薪金或奖金，你无权说：你被解雇了。
2）你要忍住帮团队做决定的冲动，让团队学会自我成长。
3）不建议你同时兼任产品负责人。产品负责人需要做不少重要的决定，这其实与Scrum Master角色冲突，一个人同时做两种角色的事情，容易搞混了角色，当然你是超人能分得很清楚的话例外。

Scrum Master 这种角色理想很丰满，现实很骨感，实践中会遇到很多问题，后续文章再为大家详细分享。

 

开发团队

这个词前面还需要加上一个词才比较合适，应该叫：“自组织”的开发团队。

这种角色在现实工作中更加“不可思议”，甚至是不可能存在，不过我们还是先看看这个开发团队包含什么角色吧：

1）业务分析师
2）程序员
3）测试人员
4）软件架构师
5）数据库设计师
6）用户体验设计师
……

开发团队虽然有“开发”两个字，不是说仅包含“开发角色”，而不包括“非开发角色”，通常我们所说的“开发角色”就是指程序员，好像测试、实施、配置管理、QA等角色就不是在做开发工作。这个开发团队是指：除了产品负责人和Scrum Master以外的，所有对项目有贡献的角色，这些角色的名字也不是固定的，各公司情况不一样，上面仅是一个例子。

这一波人如果能自我管理、主动沟通、相互协调地完成工作，这样才能叫“自组织的开发团队”，这样才能敏捷。可惜的是我们的开发团队如果没有项目经理这样的角色来协调和指挥，很可能会成为“乌合之众”，无法谈得上敏捷。

如何才能打造“自组织”的团队呢？后面再为你深入分享。

 

4.敏捷最佳实践一览

敏捷最佳实践相当多，我们先来个一览，先让你有个大概认识吧，后续再为你逐一分享。

这里列出来的敏捷实践并不限于SCRUM范围内的，我尽量将所有流派的敏捷实践来了一个小小的总结。 

需求方面最佳实践：
1）User Story（客户故事）
2）客户全程参与

设计方面的最佳实践：
3）简单设计

测试方面最佳实践：
4）测试驱动开发（TDD）
5）自动化测试

编码方面最佳实践：
6）重构
7）结对编程
8）代码共有
9）强调编码规范
10）持续集成（每日构建）

项目管理方面最佳实践：
11）Sprint（冲刺）、小版本发布
12）每日站立会议、每日晨会
13）每周工作40小时
14）Burn Down Chart（燃尽图）
15）Lesson Learned
16）隐喻

 

三， 敏捷在中国的水土不服

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是最好的开发语言！”

多年的不合适的中国教育，可能让程序员内敛起来，但大部分程序员是追求进步的，也是不服输的，如果我们能用合适的管理方式、激励方法、团队建设方法，就可以释放大家的主动性，打造出“自组织”的开发团队。将来我会为大家分享更多的敏捷团队建设方法。

四， 敏捷不能当饭吃

1）部门设置惹的祸？
下面我将会列举三个例子，前面两个是“杯具”，后面一个是“洗具”。

案例1：需求设计部 PK 编码及实施部
先上图：
 

图4.1 部门之间的PK

某软件公司设立了两大部门：
需求及设计部：顾名思义，就是负责软件需求分析及设计工作。（后面简称“A部门”）
实施部：负责编码实现，负责软件的安装、部署、上线、培训客户等工作。（后面简称“B部门”）

公司内部有一个任务管理系统：A部门经过需求分析及软件设计后，通过该系统分派编码等任务给B部门，这个任务叫“工单”，而分派任务的工作叫“下单”。B部门需要完成这些任务，并接受A部门的检查。B部门如果不能按时按质量要求完成任务，B部门的绩效考核就会差；而B部门如果认为A部门分派的任务不合理、描述不清，可以拒绝该任务，称之为“踢单”，“踢单”越多，A部门的绩效考核就越差。
没有这样的部门设置和考核机制之前，两个部门的人可以无分彼此地一起商量事情，共同解决问题，而这样的部门设置及考核机制建立后，两个部门的人经常为了一个“工单”而扯皮，工作的焦点变成不是如何让项目成功，而是如何界定两个部门的工作边界以及想办法推卸责任。
这样的情况，如何敏捷？

案例2：客服部 PK 开发部
某网站有大量的用户访问，用户可以向客服部投诉问题，客服部记录问题后移交个开发部处理。用户向客服部描述问题的时候，往往是描述不清的，往往只有“大概”的说法，而客服部往往也不能进一步向用户问清楚情况，往往只能记录问题而已。于是这样的问题移交到开发部时，开发部就会说：记录不清楚，无法定位问题所在，无法重现问题。开发部将问题踢回去，要求客服部进一步了解清楚情况。而客服部认为这些问题应该由开发进一步去搞清楚细节，毕竟客服不懂技术，可能无法跟用户了解清楚情况。于是有些用户提出来的问题因为客服部和开发部的扯皮，一直悬而未解，直到不了了之……
这样的情况如何处理？又如何敏捷呢？！

案例3：服务部与开发部的协作
我曾经在某公司的开发部工作，公司也有服务部等其他部门，我们公司当时销售产品为主，客户数量有几千甚至上万。客户使用软件过程当中，自然会遇到很多问题，就会求助于服务部，服务部能解决很多问题，但有时候遇到一些复杂的问题或者程序出错可能就无法处理，就会转给开发部处理。
我负责其中一个产品，我是这个产品的开发者。服务部转发过来的问题通常也是记录不清的，有时候服务部的同事会直接将用户的电话转过来。我不会厌烦这样的事情，反而是非常喜欢这样，我很关注用户使用我们的产品的感受，我会主动找客户问清楚细节。有时候服务部有一段时间没有意见反馈过来，我会主动问服务部同事：是不是出了什么状况？因为我相信只要软件有人在用，就不可能没有问题，没有问题就意味着没有人用这个软件。每次处理完问题后，我都会向服务部的同事通报处理的情况，并告知服务部的同事下次遇到类似问题应该如何跟用户沟通。开发部不仅仅是我，所有的同事都是这样的态度工作的，开发部和服务部之间的协作是无缝和良好的。
我能这样做是因为我人品好、工作态度好吗？非也，这是因为我有强大的利益驱动，我是按软件的销售额拿提成的！最终用户使用软件的感受，我当然要关注，我要改善软件让软件更加好卖，我好拿更多提成啊！
好的人品和好的工作态度，当然会帮助工作做得更好更主动，但如果有不合理的部门设置和绩效考核办法，就会逐步将这些“好东西”磨掉，甚至让好的员工忍受不了选择离职！合理的部门设置和绩效考核办法，能释放大家的工作积极性，让“懒人”变得更加勤劳和主动，同时淘汰掉不合适的员工。

上述三个例子说明了什么呢？你是属于哪种情况呢？很明显，能不能敏捷与公司的某些机制有关系，下面继续详解……


2）强矩阵还是弱矩阵？
请看图：
 

图4.2 矩阵式管理

软件公司一般会分为若干部门，比方说：行政部、财务部、研发部、质量部、销售部等等。公司越大，有可能部门分得越细，研发类直接相关的部门还可能细分为：项目管理部、需求部、开发部、测试部等。通常部门的划分标准是根据按工作性质，细分部门的目的是希望术业有专攻，公司老板希望各部门能越做越专业，各部门各司其职，共同地完成公司的运作。软件项目需要各类专业人才,包括以下方面的专业人才：需求分析、软件设计、项目管理、程序员、测试工程师、实施工程师、配置管理员、QA等等，这些角色在项目中各司其职，发挥各自的作用，这些角色可能来自不同的部门。对于某位项目成员来说，他又双重领导，分别是他所在部门的部门经理，还有就是项目中的项目经理。

上述部门及项目架构，就是矩阵式架构，基本上大部分公司都是这样运作的，但又会分为弱矩阵和强矩阵。
弱矩阵：各人以部门职责为主，各人做好自己的事情就可以了，各人主要对部门经理负责。
强矩阵：各人以项目利益为主，不仅仅完成本岗位的工作，还需要跨职能地工作，只要对项目成功有意义的事情，都鼓励项目组成员去完成，各人对项目成败直接负责。

如果你们在开展项目工作中需要经常协调各部门，但经常要浪费很多时间和成本，要求其他部门配合就好像求“阿爷”做事情一样；如果你们项目工作中某部门的文档输出是另外一个部门工作的输入，而这个文档经常成为扯皮的载体；如果项目出了问题领导要问责，各部门引用各自部门职责来相互推卸责任，最后可能会变成流程的错、过程的错…… 如果你们有上述情况之一或者是有类似的情况，那么恭喜你，你们是“弱矩阵”！

如果项目小组成员能在项目经理的带领下，无论是来自哪个部门，都能为项目的成功出力，都能自觉地做到“跨职能”地工作；如果项目出了问题，我们会认为这是我们的错，而不是具体某个人或某个部门的错…… 恭喜你，你们是“强矩阵”！

看上去似乎“强矩阵”比“弱矩阵”更好，其实两种模式各有特点和适应面：
弱矩阵：
1）流水线生产，适用于稳定的项目或产品。
2）每个人完成自己的工作职责，对岗位负责。
强矩阵：
1）适用于高难度、高挑战的项目或产品。
2）每个人都对项目成败负责。
3）每个人除了完成本职工作，还需要跨职能地工作。

很多公司规模比较小的时候，一个人需要完成很多种工作，自然而然就是“强矩阵”；公司慢慢做大后会细分部门，但管理者没有用某种考核方式来捆绑各部门的利益，就逐步会变成“弱矩阵”。经历过由小到大的老板可能都会感叹，为什么公司越大效率越低，很可能就是这个原因。
前文的案例1、2，明显就是按“弱矩阵”的思路来管理企业，结果出现了很多问题，这些问题不是部门职责不清的问题，而是体制出了问题；案例3虽然也划分了部门，但一个有效的绩效考核办法将大家的利益捆绑。

我们的软件项目通常都是“高难度”和“高挑战”，基本上不太可能流水线生产，所以我们更加需要“强矩阵”的管理模式，如果要实践敏捷，“强矩阵”的管理模式是必须的。不过我也见过有人分享“弱矩阵”下的敏捷实践，具体我还没有研究过，我觉得“弱矩阵”下部门内可以部分敏捷，但如果项目需要各部门协调时，“弱矩阵”可能真的无法敏捷。


3）敏捷对团队文化的要求
下面分享两个跟团队文化有关的案例。

案例1：皇帝急太监就是不急！
某项目经理为了项目心急如焚（皇帝急），而其他项目成员表示淡定（太监不急）：你安排任务给我就行了，老子的工作就是完成任务。项目经理很郁闷，为什么大家不能主动一点、多承担一点呢？为什么只有我急，大家不急？

案例2：“木头人”团队
某项目经理和某项目成员一起外出吃午饭，项目经理苦口婆心地跟他说：沟通很重要啊，一个项目的沟通很重要啊，很重要啊…… 如此这般说了很多沟通很重要的大道理，某项目成员一致不吭声，最多只是偶尔“嗯”一下，或者点一点头。项目经理还是私人出钱请项目成员吃饭的呢，他这样做是有原因的！因为他在实际项目中经常问大家有没有问题，大家要么不吭声要么就说没有问题，然后后面项目问题超级多。救命啊，他受不了了，为什么大家都藏着掖着，不沟通不说话呢！于是他才想出请吃饭这招，但你可以看到请吃饭的沟通效果是怎样的？

前文提到中国软件研发人员的几个特点，如：一块木头、机械工人，如果没有合适的管理方式，特别如果是“弱矩阵”的管理模式，那么就会放大这些特点，结果就变成上述两个案例的情况。
敏捷对团队文化是有要求的，就是：我们要在一条船上！

如果只有项目经理在船上，其他人在其他船上或者是脚踏几条船，项目情况跟我无关，出问题我就跳船或者换船！这如何敏捷呢？


4）敏捷对薪金待遇的要求
现在到了本文最高潮的部分了，因为我需要你回到几个“尖锐”的问题，请你根据满意程度用1-10分对以下三个问题打分：
1）你喜欢这份工作吗？
2）你的薪金多少？你满意吗？
3）你满意你的老板吗？
这三个尖锐的问题，我上现场课程的时候也会问大家，但我不需要大家现场打分，大家给个眼神给我就行了。因为学员们身边就是他的同事甚至是老板，他们是不方便当面打分的。但这三个题目，我在网络课程中问出来时，大家打分超级踊跃（因为大家都见不到面，互相不知道是谁），不仅仅是打分，各种抱怨都来了！
欢迎你评论本文时对这三个问题打打分，我们来看看三个尖锐问题会不会炸了锅！

有一次我分享一篇关于敏捷团队建设的文章中提到“能力更高的人更有责任去推动水平低的同事进步”，结果网络上马上有人说：凭什么能力高的要多干活啊！如果你对这份工作不满，一直想跳槽只是暂时实施不了；如果你对薪金不满；如果你对你的老板不满（这里的老板泛指你的上司及上司的上司，不一定是公司老板）…… 你会对知识分享感兴趣吗？你会对敏捷感兴趣吗？
如果你是公司管理层，你想实施敏捷，请先用着三个题目自测一下，看看你们员工估计是怎样的打分（当然你不可能真的让员工去打分的），如果分数很低，你需要检讨问题在哪里，强推敏捷并不能提升分数，反而会让员工更加厌恶公司。

敏捷更多是一种精神层面上的要求，是一种精神文明，但精神文明是建立在一定物质文明的基础上的。员工得不到尊重，员工的生活得不到保障，温饱不解决，你跟我谈敏捷，就是扯淡！
有机会你可以问问国外实践敏捷很成功的大师们，能成功实施敏捷的团队，他们的薪金是怎样的？一般都是高于业界平均水平的。

但这是在中国啊，我们还有很多中小型企业，薪金可能低于业界平均水平，我们岂不是不能玩敏捷呢？
员工对公司的满意度，除了来自于薪金，还来自于对公司对每位员工的成长关怀。如果不能让我们的薪资水平在行业前列，那么我们就更加应该创造一个可以加速员工成长的工作环境，让员工可以学到更多赚钱本领，让员工可以争取到更高的薪酬。


5）敏捷的本质是什么？
本系列文章最开始的时候给出了敏捷的“官方”定义，经过几篇文章铺垫后，现在可以用简单的说话小结一下我对敏捷的理解了。
敏捷的核心基础：我们在一条船上！包括：
1）项目组所有人在一条船上。
2）员工和公司在一条船上。
敏捷的几个重要特征：
1）所有人对项目成功负责。
2）所有人直接需求驱动地工作。
3）所有人都需要跨领域地工作。
4）持续交付、迭代前进。
5）小步前进，持续改进。

6）有效、简单