我们需要敏捷,每个程序员都需要敏捷

nd | | 访问(137)

  题记:

  直到现在我才清清楚楚的明白:我们需要敏捷,他可以让整个团队凝聚起来去解决问题,而不是你欺负欺负我,我欺负欺负你。因为当我们选择拥抱变化的时候,变化也就变化的越慢。而项目里面的变化每时每刻在发生的,你怎么可能拒绝变化呢?敏捷不仅仅是对公司有利,对每个开发人员来说也是把有力的保护伞,至少可以让你一次把事情做对,不会因为把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,而郁闷,至少我不想以为改需求去加班,所以我们需要敏捷,每个程序员都需要敏捷。

  希望每个程序人员在公司内部推敏捷的时候,自己可以跳进去,项目的执行本来就是程序员来干的,敏捷的产生一部分是用来保护程序员的,因为他也是你的保护伞。

  当你真正喜欢上敏捷的时候,一定要在项目组推广敏捷,这样,这样,你的团队成员,才不会有像我们一样郁闷。

  文章来源:http://www.cnblogs.com/muer/p/RequiresAgility.html