哥们，你吹牛吧？ 自我标榜吧？  美化吧？ 

  OK,我承认，有一点点美化，但95%的现状描述确实如此。 OK,我承认，当我把队伍交给一个不理解敏捷的项目经理，又不愿意学习的项目经理，他确实会搞砸一些东西。 

  但，确实，我说的基本上是事实。

  那我怎么做到的？

  我做了如下几件事情：

1. 先Show技能：一个现实项目代码结构非常差的例子，或者是我常用的打折策略例子，先Show无单元测试重构，再show有单元测试重构，重构的目标---》OO。让人们看看什么是OO，OO的诱惑在哪里？燃起大部分程序员心中的那把火，那把追求完美的火。
2. 让重构和单元测试为大家认可后，大家一起玩，一起玩的基础是什么？一致的代码规则，一起玩玩并交流心得
3. 然后，你就可以推广持续集成了.....
4. 接着你可以推广晨会了.......
5. 至关重要的一关：将需求管理起来，这主要不是说服程序员，而是需求部门，请不要给我混乱的设计和需求，请规范。这个工作需要一点点技巧，一点点强势，一点点能力，一点点帮助。
6. 玩起发布计划，玩起迭代游戏，玩起燃烧图，让大家一起玩
7. 一步步来，推广敏捷过程本身就是敏捷管理过程。
8. 基本游戏规则建立后，再新的一轮深化敏捷过程

    轻松吧？ 其实你错了，不轻松，真的不轻松。

     不同的企业和团队有其不同特点，企业又会处于不同的发展阶段，你要掌握好节奏，掌握好推进过程，掌握好和固有模式冲突的协调方式，一步步来。

      其中，必不可缺的，让其中一部分人先富起来，让那些积极进取，积极学习的人，先掌握了敏捷的实践，这样你又添了几个布道士，事半功倍。我在某楼企业，就曾经因为没处理好某老员工的步道事宜，造成了较大的困扰。

      补充一下，这2家企业，无论高层还是基层，最初对我的能力都是顾虑重重的，担心偶是个“理论份子”

我也在某楼企业，被 @kent 敏捷过。

“show技能”确实比较高效。被show的人只要看着，再对比自己之前旧的经验，就经历了一场自己做不出来的实践，能快速从中学到东西。

我在被敏捷的过程中，整个项目三四个月下来，都比较忙，所以熟悉了是怎么操作，但要问为什么，说不出很深刻的见解。原因很多，主要是因为自己不够进取。所以当时我可以说是会了敏捷的实践，但要主动成为布道者，还需要对这些实践的一些沉淀。所以我认为，在推广敏捷的过程中，实践肯定是第一位的，但是推进对这些实践的总结以及理论知识的补充也很重要，特别是对懒的、内向的成员。

很认同“推广敏捷过程本身就是敏捷管理过程”（当然还是不深刻的），但对推广者的信心和能力是个考验。理论知识是最基本的，加上实践经验就更好了，但是最重要的，如 @kent 所说“不同的企业和团队有其不同特点，企业又会处于不同的发展阶段”，要因地制宜（否则就真是“理论份子”了），但这块需要很多经验积累，我觉得这些经验也可以分享下。

以我的理解，敏捷推广者应该对要推广的实践都有深刻理解，积极投入实践，过程必须经常的总结，结合当前情况进行调整；还有，技术水平也得不断提高。说到这，我想问下，技术和敏捷是什么关系？我觉得是技术服务于敏捷管理的。

推广和实践过程中，心态也确实重要，baby steps是可以参考的实践。

问个问题，这是我在某开源bbs公司遇到的。

我的领导和他上面的CTO基本只在他们自己的公司工作过，都是php程序员，对OO只是知道个大概，对敏捷更没怎么听过，整个团队当时大概10人，水平也都差不多。这种情况下，你会怎么去推广敏捷呢？

我一直在尝试，不过失败了，想看看大家的想法。

@HiZhou:问个问题，这是我在某开源bbs公司遇到的。 我的领导和他上面的CTO基本只在他们自己的公司工作过，都...

   首先你站的平台起点较低，这可能是没法选择的。

   换这种情况，我会邀请大家一起玩OO，玩敏捷；质疑什么咱玩什么。 不是一个Leader。

   当然，前提是自己的能力和理论都较高水平，才能够真正的推广。有了能力又促进自信

针对 KENT 提到的这些

1. 对敏捷一无所知,对单元测试、重构、持续集成等实践第一反应是抗拒,接着抗拒，再抗拒。
2. 面向对象编程知识匮乏，仅仅掌握了非常粗浅的封装和继承知识
3. 各个团队的约定规则非常混乱，代码结构更提不上，基本上是填坑式编码
4. 团队成员许多持上班拿工资的心态，缺乏激情； 有激情的也被代码海洋和无尽的加班消磨殆尽
5. 文档和实际产品几乎无法对号入座，队伍越大越混乱
6. 项目计划是用永远也加不完的班来完成的

我也遇到过，这样的队伍很让人头疼和郁闷，我觉得最基本的是身体力行，如果你的水平不是那种天才级别的，身体力行的带动大家一起，如果他们渐渐感觉到你太累了，然后在站立会议上，你每次在不断告诉他们，

代码质量，责任，快速高效，主动性是他们在未来可以出去独挡一面的东西 他们会慢慢来分担你的任务的，我一直记得KENT说过向往 thoughtworks 公司的组织架构，现在想想是有道理的 ，敏捷确实提倡的是精英团队的构成模式，所以在团队稳定后并能主动敏捷的话，希望在每个 招聘人才的时候 都要慎重 ，不要打破原来已经成熟的敏捷团队，敏捷和技术无法分开的，因为本身敏捷就是为技术开发而产生的，测试驱动的方案需要有种非常快速的框架来支撑这种测试先行，面向对象其实就是学会抽象，看你抽象的模式怎样，没有什么诀窍在于多磨练，多思考，多画图，KENT提到有些人只想拿工资混日子，我觉得那就可以严厉地告诉他：如果想混饭吃来伤害团队的，趁早主动离开。项目计划是用永远也加不完的班来完成的，这个一般是在项目型公司会出现，产品型公司基本不会，项目型公司，就看你怎么跟客户敏捷了------这个又跟你公关和外交能力相关了，此问题不好说------

@myth:针对 KENT 提到的这些 对敏捷一无所知,对单元测试、重构、持续集成等实践第一反应是抗拒,接着抗拒...

人员的成长是渐进的，培养一种文化氛围很重要。

@myth 如果他们渐渐感觉到你太累了，然后在站立会议上，你每次在不断告诉他们

这是苦肉计么。。。但确实是一种培养文化氛围的方式。但有时候不是刻意去做的，如果要刻意去做，又觉得无从下手

@HiZhou: @myth 如果他们渐渐感觉到你太累了，然后在站立会议上，你每次在不断告诉他们 这是苦肉计么。。...

谈不上刻意不刻意，如果非要说刻意也是对的。 要给大家树立一种好的、觉得值得学习的目标。对这个目标作为推广的人要有信心，自己不通之处可以学习、或者找人探讨，但是大方向上要给人强烈的信心。 

   试想：你自己都没信心的技能，谁会花时间冒险？

嗯。经过这次讨论，我也更清楚之前失败的原因，信心不足是最大的一点，但是当时没明确意识到，也许当时的心态，还是想偏安一隅，写写代码而已。最终你可以预见，如果团队不一起进步，你代码都写不了。

如果想推广敏捷，先得有信心。信心从哪里来？说的土一点，叫努力学习。

强烈的信心，很多东西也许都应运而生：学习氛围、凝聚力、文化。

@HiZhou:嗯。经过这次讨论，我也更清楚之前失败的原因，信心不足是最大的一点，但是当时没明确意识到，也许当时的心...

除了努力学习，还需要动手能力、良好的沟通能力。敢说也敢做。

@kent:    首先你站的平台起点较低，这可能是没法选择的。    ...

回想起来，是这个道理。

如果没有决策权，推广敏捷的人必须有足够的信心和实力；我当时实力不足，也就支撑不起信心，更没有明确的目标，连失败都谈不上，呵呵。