Scrum开发的失败经历及心得

产品小白专属,10周线上特训,测、练、实战,22位导师全程带班,11项求职服务,保障就业!了解一下

本文作者回顾了自己一次失败的Scrum开发经历,总结了如下问题及改进方法,望对后来者有帮助。

背景

公司是一家初创公司,因为新业务需求:另外两个部门需要开发互联网产品,于是成立了IT研发部。我的岗位是产品,另还有前端3枚、后端1枚、UI1枚、产品总监1枚。除产品总监外,其余都是萌新。

IT技术总监决定以Scrum敏捷开发来进行日常开发,由于其比较忙,暂由我担任敏捷教练,带着从没接触过敏捷开发的大家,一起尝试。

到目前,大家已有1年的磨合了,开发完了两个线上产品。然而,对于团队的战斗力(一个产品需要多久开发完?大概几个sprint完成?每个sprint能做多少个任务?)还是模糊不清的,可以说scrum开发实践的蛮糟糕的。下面就与大家分享下,希望后来者能避开我走过的坑。

Sprint1:估算埋的坑

我是运营转的产品,对技术上可以说是比较白的,只能边学边摸索着推进团队Scrum开发的进程。技术总监传授了一些技巧让我组织切割故事点,和程序一起估算开发任务,并组织开站会。一开始真的是一个头两个大,我对如何切割故事点?怎么估算开发周期?晨会每个人说完三个问题后又应该如何?这些都都很模糊,随着业务的进展,只能硬着头皮干了。

准备阶段,我把需求和故事点迷迷糊糊屡出来后,和程序开会,让他们了解产品的需求。关于估算,我们采取了每个程序各自估算的方法。前端负责做前端页面和管理后台,后端一个人做所有的业务。需求列表里属于谁的故事,就各自估算,以人天为单位,放到teambition(协作工具)里。

到了开发阶段,每天早晨会有站会,我们各自在座位上走一轮。期间,越往后感觉大家越不上心,有点应付。我做是主持角色,每天记录成员工作完成情况。

结束总结时,我们发现了两个问题:

  1. 前端页面两个人写的,各自有分配到页面,但后期发现其中有个页面是几乎一样的,这个而我切割故事的时候也没有注意,他们各自重复的写了,浪费了时间。
  2. 延期了。我注意到,刚开始他们一天甚至可以完成估算的3天的工作量,但最终结果延期了3天(前期估算其实很不合理)。排除程序请假的因素,原因是有些任务程序不熟悉或开发期间遇到麻烦了,导致估算1天可以解决的任务,却做了好多天。站会也询问对方能不能解决,有没有啥困难,都口头上说没问题很快能解决,可实际结果不是这样。

失败分析:

  1. 没有大家一起打扑克估算,讨论矫正,而是各自单独估算,估算的不准确。
  2. 需求会没有沟通到位,成员没有对整体产品做全面的了解,产品也没点出不同模块的相同页面,减少开发的浪费。
  3. 站会沟通不够,成员遇到问题没有足够重视,没有延期发生时的解决方案。

Sprint2:沟而不通,有形无神

到了第二个sprint的,遇到了一个极其严重的问题:由于前期后端接口的任务没有估算和切割(我当时也不懂,主要是引导者前端把故事做切割),然后,程序采取的是先写页面后调联的方式(该方式也导致了后面前端程序回过头调试时,有些功能都已经遗忘了,开发效率下降),导致前端页面样式都写完了,却没有接口调试,只能停下来等后端写接口。

此外,期间还暴露了很多其他问题,值得引起重视。如:

  1. 后端程序不太乐于沟通,数据库进度卡在了那里,没有追踪;
  2. 前期切割任务没有列入后端的任务,完全没有发现这个问题,期间站会后端的汇报总是帮助前端调接口之类的,就略过了;
  3. 另,我作为Scrum master脸皮比较薄也没有寻求技术总监帮助,一般催程序一次两次,对方还没结束,只能继续等着。

各种因素一起,导致了这个尴尬的局面。

失败分析:

  1. 前后端没有独立开,前端实现依赖后端的接口来完成工作。
  2. 前期估算任务,忽略了后端的工作,写接口写数据库表等都应该纳入。
  3. 前端采取先写所有页面样式,再全部统一调联的开发模式,导致后期接口压力巨大,回过头调联可能已经忘记前面页面的需求。应该采取边写样式边调联的开发节奏。

Sprint3:士气低迷得结束

受前一个sprint的影响,后面只能让后端穿插着配合前端写接口,前端等待的状况无法避免,肯定延期了,大家的目标就是尽快交付。

由于前面页面与调试的分离,导致每个阶段都没法进行测试,后面我测试发现很多问题,只能又退回去返工,导致延期时间延长,拖了快1个月才上线。

此外,有个前端是新手,期间也没代码检验的步骤,导致有些页面用不了,重新返工。

延期期间每天加班,大家士气更加低落,协作得非常糟糕。

失败分析:

  1. 没有阶段性的测试及验收标准,开发模式不规范,应前期约定好并找专家确认。
  2. 团队氛围不理想,没有重视并调整。
  3. 产品与程序沟通不到位,对需求理解不一致。

总结

最近一段时间,大家除了日常的开发,还有各种bug修改任务穿插,Scrum的实践处于半停滞状态,只有站会跟踪在延续了。期间遇到的问题还是老问题,尤其是上线后爆发的问题,大领导责问技术总监,技术总监追责我,我看着程序无辜的眼神和忙碌的身影,也特别委屈无奈,有决心改但不知道从何开始。

有时候很迷茫,觉得自己不是在做产品的工作,除了调研产品、设计原型、沟通需求、上线前测试外,还要兼职生活委员,注册各种账号、走款审批、整理密码。最难的就是要做Scrum master,很吃力,对外沟通难对内催进度难,出了事还要背锅。自己觉得做的不好,估计领导和团队成员也觉得我工作的不好吧,心累。期间至少有两次,我感觉自己的自我被击碎了。

但又很不甘心,从哪里失败了,就想从哪里爬起来,或许没有我想象中那么难,只要再改进一点就接近成功了。就像罗胖说的,摔倒了并没有什么大不了的,爬起来,用簸箕把自己的碎片扫一扫,回头再拼回去。

改进思路

针对这段经历,我有一些改进思路想法,也希望过来人给我提提意见,帮助成长,感恩。

  1. 先开一次轻松的会,团队成员集思广益,说说自己的改善意见,保持公开透明,下次开发时调整。
  2. 规范任务开发估算的步骤,以故事点+打扑克牌来一起打个样,看看每次大家能完成多少个故事点,慢慢提升效率。
  3. 高效沟通,适当拍拍程序马屁,他们也辛苦的,偶尔下午茶激励大家。
  4. 脸皮再厚点,只要发现延期的苗头,放下手头的工作,间隔性询问追踪,若超过一定时间则邀请专家帮助解决。
  5. 确立验收标准,每个sprint结束了,进行阶段性测试,条件合适另邀请外部同事参与演示会。
  6. 燃尽图跟进进度,发现问题,及时发现并针对性改进。
  7. 把线上的互动,全部转移到线下来(白板、估算扑克),增加参与感与仪式感。

实践结果怎么样?暂时未知,有结果会与大家分享。

 

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

题图来自 pexels,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
5人打赏
评论
欢迎留言讨论~!
  1. Scrum,首先要求SM对每个sprint进行跟踪和验收,我们做的时候严格要求前端和后端分开,各自估算时间,边做边调接口的这种模式,这里面对开发的配合和要求稍微高那么一丢丢,这里面首先对前端和后端的负责人要求高,对故事的拆分,分配等等相关要做到心中有数,不能稀里糊涂,delay的原因有很多,不光是程序员对任务估算不足,如果估算不足,那就是对需求评审的时候么有做好相关的流程和系统的理解,产品应该是管事不管人,这样才能很好沟通,尤其不懂技术的产品,万一流程规划的不清晰,那就真的…

    回复
    1. 嗯,后面尽量拖技术总监和我一起把前期工作做到位,只要能合理分配好,成员不拖延(拖延了,能看出是谁导致的,及时让其调整),到我能掌控的产品功能要求及验收标准阶段,我能很好的把控住

      回复
  2. 敏捷不是没有要求和过程管理,只是这些事情是需要SM进行把控,什么做什么不做,所以敏捷的快体现在不做那么多的限制,但是SM本身就是裁判,团队做的不好的时候要及时喊停,但是楼主是萌新,也没有项目管理经验和技术背景,在判断规则和做法的时候缺少必要的技能和背景的支撑,有些缩手缩脚,不能起到很好的团队引领作用,失败在所难免,其实看了您的文章感觉这是软件研发过程管理的常见问题,也起不到太多的借鉴意义,唯一值得警醒的是问题就是贵公司对敏捷和SM的选择上稍显草率

    回复
    1. 感谢,确实存在这些问题,后面还是希望能通过我的协调和把控,让流程高效运作,没技术背景和经验支撑,在边做边学,最近在研究敏捷开发的书籍

      回复
  3. 敏捷开发的核心就是“人”啊,对个人能力要求会很高

    回复
  4. 感觉延期的主要原因,是程序碰到难题,过不了关,导致拖期,一是请外部专家协助解决,另一个要让程序知道是他的原因导致拖期。
    萌新通常都会这样,如果有人偷懒耍滑,坚决毙之,不然真整个团队都会。。。

    回复
    1. 是的,就是实行起来为难的,大家都是每天见的同事,哎

      回复
  5. scrum,Master是关键啊,需要有团队中的Keyman都具备足够的能力才行。如果团队成员大多是弱鸡,建议不要轻易尝试

    回复
    1. :sad:

      回复
  6. 港真,scrum对开发的综合能力(技术,大局观等)要求非常高

    回复
    1. 所以小团队采用啥方法合适?

      回复