敏捷？试错啊！玩不起！

“别跟我谈敏捷！我们部门是做和人民生命财产相关的软件，我们不能试错，不容许一丝一毫的问题！在这个问题上，绝对不能儿戏！做敏捷还是找别的部门吧！”

这句话听起来耳熟是吗？来来来，我们坐下来好好聊！

试错是不管对不对，先上线看效果再说？

试错是不管质量好不好，用户用了再说？

试错是不用操那么多心，用户提了再改呗？

大写的NO!

如果真是这样，那可真叫儿戏了！

其实我们在实现“试错”的功能前就已经认真做过研究，这个功能应该是到目前为止最有可能解决问题的东东。当然，这也只是一个“假设”，有待验证！

因此，在大规模开发和大面积使用之前，我们做一个MVP，并配合合适的发布策略，快速得到小部分真实用户的反馈（相当多的情况是通过埋点采集的数据分析而得），从而判断我们前面的“假设”是否得到验证，符合预期。如果与预期不符（即所谓的“错”，方向性错误，或者说仅仅是有点儿偏差），我们需要根据反馈进行调整。

这就是试错的玩法！

敏捷只是为试错提供了非常棒的条件！传统的开发方式可干不了这个！

不过，实施了敏捷，你不想发的功能，我们也不会哭着喊着求你发！敏捷改变和优化的是咱们的工作方式，至于哪个功能你敢发，哪个你不敢发我们可不管！以你最舒服的标准来发就OK！

所以，无论你是做和生命相关的软件，还是和财产相关的软件，因为恐惧“试错”而拒绝敏捷，通通滴不是理由！

有人说了，我们公司不适合做敏捷，我们项目不适合做敏捷！你能说清楚什么样子才算是做了敏捷吗？

敏捷原则有12条呢，你在其中一条上有所进步，我是不是可以说你们比以前更加敏捷了呢？比如你是否可以减少写邮件、减少打电话，走到对方的工位旁面对面聊几句把事情搞定？

在实践上，不管你在做什么项目，无论你现在用的是瀑布还是其他，你是否可以把所有工作可视化到墙上，你是否可以开每日站会，你是否可以开双周回顾会？我相信你能！这几点不会给你带来太多的负担，相反，会给你带来巨大的正面效应！不信你可以试试看！

所以敏捷不是0或1的玩法，大家都可以走在敏捷的路上，只是程度不同罢了！

所以呢，大家都敏捷起来吧！没有最敏捷，只有更敏捷！