敏捷能干啥？

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

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

    1. 人 

    2. 管理制度

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

1、人

     不管问题看起来是什么样子，最后一定是人的问题。当然一般情况下，你和老板反映开发中的问题时，如果过度强调这是人的问题，那一般不会有什么好的果子。而且，如果你自己不是老板，一般情况下人的问题你也解决不了。只能是把意见向上反馈。如何找到合适的人，这��️是另外一个话题。真正遇到人的问题，Scrum Master其实是没有太好的办法。我的经验是赶快请这个同学离开团队。

2、管理制度

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

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

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

3、开发方法

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

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

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

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

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

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

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

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

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

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