本文作者回顾了自己一次失败的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协议