我们需要敏捷，每个程序员都需要敏捷
题记：
直到现在我才清清楚楚的明白：我们需要敏捷，他可以让整个团队凝聚起来去解决问题，而不是你欺负欺负我，我欺负欺负你。因为当我们选择拥抱变化的时候，变化也就变化的越慢。而项目里面的变化每时每刻在发生的，你怎么可能拒绝变化呢？敏捷不仅仅是对公司有利，对每个开发人员来说也是把有力的保护伞，至少可以让你一次把事情做对，不会因为把a做成b，再从b做成a,而郁闷，至少我不想以为改需求去加班，所以我们需要敏捷，每个程序员都需要敏捷。
这是发生在我身边的故事：
情景1：1个月以前:一次饭局上一个产品经理突然提到敏捷，然后我很感兴趣的说，你们现在做的怎么样了，然后他含含糊糊的说：我们现在不做了，我们团队队员还没到那个意境，然后我诺诺的说，有些团队也许不适合敏捷，他们也许更适合别的一些方式。
情景2：2个月前:在偶尔一次谈话中，又一个产品经理跟我说：敏捷在短期项目里面比较适合，在我们这种平台产品级的不太适合，因为没有在这种需要长期平台实践过敏捷，我也含含糊糊的说：也许吧。
情景3：1年前：一个曾经跟我在不同做项目的一个姑娘，我们在一起聊天的时候，每每提到敏捷，就很厌恶的说：你们项目现在比较稳定比较适合敏捷，像我这种随时都可能出现问题的事情，根本就没法去敏捷，所谓的敏捷不就是把任务放到墙上呀，我也会呀，我们不屑去做，我们感觉这些更浪费我们时间，在做这些事情的时候，也许我早就把我手里面的任务解决掉了，何必浪费这么长时间去做这种事情呢？浪费时间，接着就是莫名的一些抱怨。
突然有一天，你花了好大的力气跟你的老大谈话，说敏捷如何如何好，如何如何能提高我们的生产效率，然后老大说：你来做这件事情吧，在一个项目组先推广看看。
可是当你做的时候你会发现：
阻碍你的力量：当一种新的规则进一个项目组里面的，团队几乎有一半以上的人在抱怨，为什么我好好的工作做的很好，又让我去做这些跟工作不相关的事情？ 还让我去承诺？还让我去做评估，我做有用吗？ 最后还不是项目经理说了算？你们这些无聊的人就喜欢学点西方人的思想，我只做我分内事情就好了，没必要，也不想花这个时间去学这个无聊的东西…….。大家虽不挂在嘴边，但是心里早已盘算好，你让我干什么我就干，大家干什么我就干什么，反正新规则不是我推进来的，我不反对也不支持。
推动你的力量：当然也有比较喜欢“新鲜空气”的人，他们在团队里面尽自己最大努力去推广敏捷，改变原来那种死板的，甚至阻止“邮件大战”试图通过敏捷最简单的沟通方式去让敏捷遍地生花。
总之，做敏捷很难，要得罪很多人，要让大家理解一种思想很难，有些确实不适合，有些连了解都没了解就盲目下结论，我不适合。
我最近在思考这个问题：敏捷究竟能给我们带来什么？我们真需要敏捷吗？
想到敏捷的核心思想是拥抱变化，拥抱变化是什么呢？他是给整个团队灌输一种力量，这个力量就是，我们整个团队通过各种方式去满足用户需求，去理解用户需求，去想各种办法去做出客户想要的东西。
突然想到一年前同样一个夏天，我们开的一次草坪会议，只是一个会议，就让整个团队凝聚起来，每个人都想方设法去把他做好。
关于草坪会议：
去年自己在一个项目组里面，由于各种原因，需求换了2拨，测试的介入项目组较晚，新的技术，新的平台，新的项目组，造成项目风险越做越大，在离交付还有一个月的时候，我们开了一次草坪会议,目的是解决如何完成交付。20多个人，在园区的一块草坪上席地而坐。
1.我清楚的记得开发经理说的一句话：在项目开始的时候，项目经理让我制定计划，我就感觉他是一份根本完成不了的清单，他太疯狂了，根本没法控制。
2.“你给我的需求是这样的，你跟客户碰了一次头，回来全部改掉了？你需求怎么做的呀？”
3.“当然，主要是框架老是变变变，尤其是工作流，我快受不了了。。。。等等。”
我们也找了自己身上的一些毛病，必须技术不行呀，自己学习能力差呀，等等。
当大家抱怨完之后，最后部门经理直接说，我们如何完成交？这是我们第一个项目，如果完不成，全国的市场我们根本打不开？ 大家谁也不希望以后一说这个失败项目是自己做的吧？最后，当我们沉默几分钟之后，我记得是xw说“开始干吧，干了才知道我们能不能完成交付”我们开始试着找方案，大家轮流开始想各种方案，接着大家轮流承诺，最后当伦到我承诺的时候，我说：我会在这一个月内，尽自己最大努力，去做这件事情。虽然有个别人说自己也许加不了班，但是 xw 说：就算你不跑，我们也会带着你跑的。
就这样你一句，我一句，我们在之后的一个月内一直持续的加班，在找各种方法来稳定需求，甚至把上海的架构师搬到北京跟我们一起开发，当然，我们在这段时间内，也有争吵，也有嘻嘻哈哈的时候，甚至还有各种额外的小故事，比如集体刷夜，当然，交付要比我们预期好很多，虽然现在仍然有人在做维护。当离开团队的时候我在自己qq上写了一句话：我离开了，你们会想我吗？其实是我想念我的那个团队了。
我们团队里面之前有一部分人在做敏捷开发，面对这个项目我们真的尽力了，我们尽可能的去想各种办法去稳定这个这个需求，确保开发出来的东西是用户想要的东西。
拒绝变化：找各种理由去拒绝客户的要求，甚至搞个“邮件大战”，在或者你推推责任，我推推责任，反正责任不是我。
场景1：两个星期以前：我在拼命的加班，我在自己微博里面写了一句话：”早晨说让我造只猫，晚上变成了老虎，明天早晨呢？“我在拼命的改需求，我做的板块，由于各种原因变变变，当我试图去改变这种状况的时候，我发现我根本改变不了现在的环境。我清清楚楚记得：老大，给我个稳定点的需求吧？他笑眯眯的说：我们这哪有稳定的需求呀。我弱弱的说那好吧，那就相对稳定的需求吧。就这样需求变呀，变呀，刚开始的时候用户让我们怎么改，我们怎么改，从猫变成老虎，又从老虎变成猫，最后要交付没东西了，那怎么办呀？加班吧？为什么我们一直在变，确始终不是用户想要的呢？最后大家都崩溃了，这个项目已经面目全非。。。。。
-----想到敏捷的计划会议，能解决掉这个问题
场景2：一个星期以前：我在跟同事咨询问题的时候，被吓了一跳，客户经理跟开发经理在办公区吵起来了，我很惊讶，这是第一次感触最大的，我听到唯一的信息是他们在推责任，你想想看，这样信息对整个团队是什么影响呀。当我们完成不了交付的时候，就会各种各样的噪音
场景3：当我加班加到半夜回家打车打不到走在路边的时候，看着圆明园墙那边的绿树的时候，我常常在想，我们项目主要是需求在变，而我们也没在考虑为什么用户要变？变了那些？下次再变我怎么办？如果我们项目组用敏捷去管理，需求也许不会变化这么快，因为我们在做每个东西之前都会问为什么，为什么这么做，这么做的意义是什么？这样做能满足客户什么需求？因为当我们选择拥抱变化的时候，变化也就变化的越慢。
直现在我才清清楚楚的明白：我们需要敏捷，他可以让整个团队凝聚起来去解决问题，而不是你欺负欺负我，我欺负欺负你。因为当我们选择拥抱变化的时候，变化也就变化的越慢。而项目里面的变化每时每刻在发生的，你怎么可能拒绝变化呢？敏捷不仅仅是对公司有利，对每个开发人员来说也是把有力的保护伞，至少可以让你一次把事情做对，不会因为把a做成b，再从b做成a,而郁闷，至少我不想以为改需求去加班，所以我们需要敏捷，每个程序员都需要敏捷。
希望每个程序人员在公司内部推敏捷的时候，自己可以跳进去，项目的执行本来就是程序员来干的，敏捷的产生一部分是用来保护程序员的，因为他也是你的保护伞。
当你真正喜欢上敏捷的时候，一定要在项目组推广敏捷，这样，这样，你的团队成员，才不会有像我们一样郁闷。
