敏捷能干啥？

    一次和朋友谈起敏捷，朋友说了一句“一切开发方法都是耍流氓，软件做的好不好全看人怎么样”。好吧，我50%的同意这个观点。“只要人足够优秀，流程就是个屁。"纵观人类历史上那些牛叉叉的软件，基本都是最初几个大牛凭借自己的天才才华捣鼓出来的。比如Unix啥的。我相信这些大牛们开发软件时候时候，肯定没有仔细考虑过该采用什么软件开发流程，典型的code and fix。问题在于我们很难保证软件开发队伍里的人都足够优秀。现状是优秀的人都是一小部分。所以我们需要一个好的开发方法帮助团队能够完成软件项目。

我认为一个有战斗力的开发团队，应该具有三个支柱：

    1. 人

    2. 管理制度

    3. 开发方法，这是敏捷能干的事

1、人

     不管问题看起来是什么样子，最后一定是人的问题。当然一般情况下，管理层不会承认这是人的问题。人都是老板们自己招进来的，如果人有问题，那就是自己有问题，谁愿意承认自己有问题。所以，你和老板反映开发中的问题时，如果过度强调这是人的问题，那一般不会有什么好的果子。而且，如果你自己不是老板，一般情况下人的问题你也解决不了。如何找到合适的人，让HR去操心吧，我们在旁边打个酱油就行。

2、管理制度

     这个问题也很操蛋，涉及到公司层面的制度设计，小p职员只能在下面吐吐槽而已。比如外包的问题，公司为了省点钱或人力啥的，雇了一些外包的程序员来参与软件的开发。一般来说，外包开发人员是非常苦逼的，核心的工作公司也不会让外包人员做。干的再累也看不到啥前途。那公司就应该对外包人员有个合理的心理预期，不要期望外包人员天天雄赳赳，气昂昂热情高涨的为你工作。如果有幸聘到了一些有责任心，劳模式的外包人员，那就是公司赚了。赶紧想办法挖过来吧。期望外包团队成为一个自我管理的团队，这个问题实在不是敏捷开发能解决的。又回到了第一个问题。

     现在很多公司采用矩阵式的管理方式，管资源的和管项目的人分开。强矩阵方式开发人员都对项目负责，项目的成败直接关系的开发人员的前途。弱矩阵方式就是项目开发人员都只对自己的直属经理负责，项目经理的评价占的比例太低，这种情况就麻烦了，指望敏捷来解决这个问题，实在是强敏捷所难。

     我之前的公司就是典型的弱矩阵方式。由于项目比较多，一个开发人员往往要参与几个项目。部门领导直接抓一个重点项目，完蛋了，开发人员在做这个重点项目的时候，热情高涨。对于其它项目，就热情一般般了，经常发生项目经理要求开发人员干活，开发人员却不愿意的情况。这个问题，敏捷也没有办法解决。

3、开发方法

     敏捷啥都不能干，我们要敏捷干嘛。好吧，我们谈点敏捷能干的事吧。凡是遵守敏捷价值观的开发方法都可以标榜为敏捷开发方法。既包括技术层面的实践，也包括管理层面的实践。在实际的推广中，往往更重视管理层面的敏捷实践。我想这主要有两个原因：一、管理层面的变化，大家马上就能看的见，立刻就能告诉别人，你看，我们敏捷了；二、老板们没办法度量技术层面的实践。也就是说你做或者没做，老板们没办法直接知道。

    在三个支柱中，如果前两个不能动，那我们只能从第三个上面想办法了。

     说起流程，广大开发人员都是一般辛酸泪啊。这简直就是套在程序员脑袋上的一把枷锁。本来写个代码就完了，现在还有评审，还要让测试帮助验证，每天还有个站立会议。。。。。。。对此，我只能说合理的开发流程能够在的一定程度上保证软件开发的成功率，提高开发效率。注意是合理，不是繁冗。什么叫合理？就是开发人员愿意执行的流程。如果开发人员都在抱怨，就要想一想是不是流程有问题了。

熊孩子：”我什么流程都不想要，我想怎么开发就这么开发“

哥: "别闹了，快回家吃饭去"

敏捷说：个体与交互重于过程和工具

但是敏捷可没说不要流程。

     我见过多次流程制定出来，一段时间后就流于形式的案例。我建议广大制定流程的老板们，最后一段时间后检查一下流程的执行情况，是否达到了预期的效果，是否真的在执行。如果和预期的不一样，又没有新的代替方案，那么最好的方案就是直接取消。

熊老板：”取消，扯淡！ 那不是说我之前决策是错的。不行，不但不能取消，我还要加强监督，必须执行！“

    那怎么判断这个流程是否有效？先严格执行，看看效果，如果过段时间大家还都在抱怨，那么这个流程就应该取消了。Scrum 里面有个回顾会议，就是用来干这些事的，反省一下最近有啥可以改进的。其实还有个简单的方法可以判断这个流程是否合理，就是在会议室宣布新流程时，观察一下广大程序猿们的反应，如果大家都对你笑而不语，或者低头窃窃私语，管理者就应该有点谱，这个流程推行可能会有点麻烦。