9个月,回顾一下敏捷开发的得失

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解详情

其实人脑远没有我们自认为的那么强大,我们的“系统1”(可以简单理解为直觉系统)可以同时做几件事情,但是我们的“系统2”(可以简单理解为思维系统),它在一个时间内其实只能做一件事情,而且它很懒。

mignjiekaifadsfds

敏捷开发在今年已经经历了9个月的风雨。在部门内,敏捷开发已基本成型,在公司内,也有进一步发展推广的趋势,在世界上,好像人人都在谈论敏捷。因此,有必要在这个时候回顾一下这9个月的得失,毕竟方向比努力更重要。

1.收获

1.1.全功能型团队

一个团队,拥有策划、交互、视觉、软件、测试、运营各个领域的人员,有足够的能力实施任何软件功能从无到有,从有到优的过程。他们是一个整体,有着共同的目标,能够充分的交流,互相信任。他们是一只能真正打仗的团队。

1.2.有条不紊的流程

没有红绿灯,交通会堵塞,会出事故。同样,没有敏捷流程,项目进度会堵塞,项目下单会出事故。敏捷项目中的每一个人就是行驶在公路上的一辆辆车辆,他们既有自主的意识,也受制于交通规则的约束,他们合二为一成为一个整体,相铺相成。敏捷流程,将大家串在了一起,使大家步调一致,更高效的工作。

1.3.更快的发布与反馈

在敏捷的世界,发布速度更快那是基本,不能快速发布就谈不上什么敏捷了。目前,我们做到了每半个月对外发布一个版本,相比于之前的一个月甚至几个月,在发布效率上有了成倍的提升。这样,我们能更快速的验证我们的功能,更快速的修复问题,结合大数据和线上问题反馈,形成闭环,不断迭代,这才是敏捷的意义。

1.4.稳定的开发节奏

在今天,需求再也不是像以前那样一波一波的来,软件一波一波的忙。需求池不再是一个名词,它起到了应有的作用,需求也不在是高,很高,没有低,而是一个合理的高中低分布。就这样,稳定的需求决定了后端稳定的开发节奏,持续的功能迭代已经步入正轨。

1.5.可控的项目进度

在以前,我们会定一个某个不靠谱的月份下单,然后延后一个月,甚至两个月。渐渐的,大家习以为常,大家觉得项目延期理所当然。而现在,迭代的功能的项目进度完全可控,说哪天下单,基本上就在哪天下单。这样,项目组成员更有目标,也更有成就感,对功能进度关注的非项目组成员也能提前心里有数。

2.损失

2.1.满载的会议

为了有效的促进团队信息的流通,保障信息对称,敏捷采用晨会、需求评审会、用例评审会、迭代总结与计划会、版本发布会议等会议,在敏捷的世界里,他们都有其存在的必要性,甚至可以说,没有了他们敏捷寸步难行,但是带了一系列副作用,会议占用了团队成员的较多时间,如果某个成员不幸身处于多个项目中,那简直是一个噩梦。有得必有失,我们只能直面敏捷的会议消耗,因此,提高会议效率,是一项十分重要的工作。

2.2.超过强度的迭代

持续迭代,十分美好,但是长时间超过正常强度的迭代,对于团队来说那就是一种伤害。在这样的迭代环境中,团队成员因为疲惫,更容易暴躁,更难以沟通,大家疲于奔命,没有时间停下来思考,大家总日忙碌,渐渐的忘记了为什么要做这些事情,渐渐的,团队少了几分思想,只剩下执行。既然敏捷是持续迭代,那它就属于长跑,我们不能让一个人总是以短跑的速度去完成长跑。

2.3.误解带来的失落

当大家看到版本每半个月发布一次时,觉得我们任何一个新功能都能快速的上线,这往往是大家一厢情愿,大家的错觉。也因为有了这种错觉,对敏捷团队产生了很多误解,带来了打击,而不是肯定。

一个软件正常的生命周期包括以下:需求提出、交互设计、视觉设计、测试用例,软件开发、测试、发布上线、线上维护。

这里客观的举一个需要开发一周的功能:从需求提出到交互完成一周,软件开发一周,单模块测试一周,集成测试两周,因此在一切顺利的情况下,一个需要开发一周的功能,至少需要5周左右的时间才能上线。这就是我们目前的实际开发能力,我们要客观面对事实。

这里很多人会说,测试花了三周时间,太长了,交互也许也用不了一周,但是这就是我们的能力,或许这里有提升空间,但是这大半年的实际经验告诉我们,这是目前保持稳定的节奏的最佳方式,鼓励大家提供更好的方案,但不要仅仅只看到问题的一部分,我们是要解决的是产品整个生命周期的问题。

2.4.缺乏激情的目标

敏捷的持续进行,也是对团队成员的持续打击,时间越长,打击越强,因为随着时间的推移,按照现有的评价体系,大家会越来越没有成就感,缺乏创业般的动力。

为什么?人都是有思想的,不是机器,工作总会有点追求,工资是最基础的,一个有梦想有追求的人,或许是追求自身技术的进步,或许是追求自己做的产品的成功,或许追求事业的发展,或许追求家庭的幸福,但是绝不是追求没有任何成就感的迭代。这样的工作,我们有什么理由要求大家时刻保持创业的精神工作?

2.5.弱凝聚力的团队

虽然我们拥有了一个全功能型团队,但是这个团队的凝聚力却很弱,但是身处于这个团队不是为了创造激动人心的产品,而是为了完成迭代任务,因为只有这样才能较好的协作,如果可以,也许他们更愿意自娱自乐,而不是围着这个团队打转。因此,当有别的地方需要他们时,他们不会对现在这个团队有任何留念,因为哪里都一样。

3.敏捷接下来怎么走?

这个问题很复杂,因为我自身也在这个漩涡中难以自拔。但是我还是希望能解决这个问题,因为从长远来看,大家总会在这个漩涡中筋疲力尽。大胆假设,小心求证,我们需要有这样的勇气,就像很多人说传统行业转型是找死,不转是等死一样,找死至少还有一线生机。以下是我的一些方向和设想:

3.1.优化会议效率

会议多难以避免,但是优化会议效率却是我们能做到的事情,这个问题目前普遍存在,但是却没有引起重视,会议效率的提高不是简单的一句话,需要会议主持人和参与人都做好充分的准备,以及具备相应的能力,所以它不是简单的一两个流程和制度,更重要的是对人员的培养以及团队文化的建设,这些都需要时间、资源和精力。过多低效的会议,会让大家更低效的工作,甚至每天一起床就想着各种会议,就等着开会吧,反正中间间隔时间也做不了什么事情。

3.2.长跑式的迭代

有一个理论,当一个人按照正常步伐行走时,我们的大脑还能干点别的事情,如果让一个人保持一个比平时更快的速度行走,大脑就无法干别的事情了,《思考,快与慢》一书中提到的“系统2”需要持续保持快速的行走这个事情,因此如果让一个团队已一个不正常的速度保持迭代时,那么你就别想他们还能干点出乎你意料之外的事情来,因为他们只有能力完成你交代的事情。

其实人脑远没有我们自认为的那么强大,我们的“系统1”(可以简单理解为直觉系统)可以同时做几件事情,但是我们的“系统2”(可以简单理解为思维系统),它在一个时间内其实只能做一件事情,而且它很懒。

这里还有一个简单的实验,大家不妨自己试一试:

一个手保持1秒一下的固定节拍,每隔两个节拍周期性的完成4785每位加1的计算结果,并说出来,例如:4785的计算结果是5896。

3.3.明确敏捷团队的核心业绩

问题由小到大,这是目前面临的最大的问题,也是最难解决的问题,因此,我自身也对此疑惑不解。现在的敏捷团队缺乏明确的目标,一层不变的迭代,周期性的发布在一定意义上更让人感觉自己所做的工作按部就班,缺乏意义,严重缺乏成就感。

如何让团队成员身处于一个敏捷项目组中有所成就,实际操作中确实没有探索到有效的方法,如何明确敏捷团队的核心业绩,也是难以评估和量化,正因为如此,在这个问题上,目前只有方向,没有方法。

个人觉得以上三个方向,是下一阶段值得探索改善的方向,也许我们现在只做到了60分的成绩,但是一个一个问题的解决我们会做到70分、80分,有一天,我们的项目管理能正规化,能与这方面的佼佼者并肩,而不是一直处于这种**“纯工作经验式”**的直觉式管理和补丁式管理。

 

本文由 @空穴来风 原创发布于人人都是产品经理。未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。
6人打赏

评论( 4

登录后参与评论
  1. 一周开发时间的需求,三周测试确实太长,可能是开发时间太少,可能用两周开发,一周测试就够了

    回复
    1. 回复

      嗯,这块后期也许有优化的空间,这个与我们的产品属性也有关系,我们的产品涉及到多个端,为了保障发布的节奏,已经测试的全面性,目前一周基本无法实现。

  2. 可以试试将项目任务和个人GTD管理相结合,将团队分配给你的任务放在一起,能看到每天任务的完成情况,提升成就感,还可以管理私人事务。推荐使用专业的敏捷开发的团队协作工具,比如jira或者teamin,能够帮助你把很多事情捋顺。

    回复
  3. 暑期实习两个月也经历了敏捷开发,发了一版又一版,也改善了一些地方,但是感受不到太大的价值,总觉得为了发版而发版,没有什么指标来衡量更新的功能是好是坏,能促成更多的交易量吗

    回复
加载中