Scrum开发的失败经历及心得

代码笔记   2018-05-25 09:21:36

本文作者回顾了自己一次失败的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. 把线上的互动,全部转移到线下来(白板、估算扑克),增加参与感与仪式感。

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

打赏