Scrum 流程应用反思 - 我们的团队

    这篇文章和《PDA感悟》一样,是对一年前学习到的相关知识的一个应用反思

    写它,是为了完成每月反思,也是为了完成我这个月的目标,更是为了积累项目流程经验。

    之前已经看过刚进公司的时候,由于项目组需要使用 Scrum 作为流程来进行软件开发,所以当时看了一遍《Scrum and xp from the trenches》,主要目的是了解 scrum 中的主要内容,以促进早日融入项目组,并写了一篇介绍 Scrum 的入门级别的文章:《Scrum 大白话总结》。

    至今,时间过去了也有一年多了。在这一年多里,项目组不断使用 Scrum 进行开发,但是总是感觉有些地方不太对,没有想象中的“敏捷”。直到最近两个月,问题慢慢地突显出来了,“需求不确定”,“估时无章法”,“辛苦回顾的结果不落地”,“会议常延时”,“计划会议难以把握个人重点”……等。

    敏捷的团队,需要敏捷个人,身为团队的一份子,有责任去不断反思敏捷团队中所存在的问题,并提出自己的书面建议。这些流程反思不只是PM的责任,更是身处一线的开发人员的责任,否则,被动等待的团队如何能做到敏捷?所以,我决定对项目组中目前所遇到的问题进行归纳总结,并提出个人的相关建议,希望会对项目组有所帮助。在这之前,我不得不先再次重温《Scrum and xp from the trenches》一书中的知识,整理别人为什么能做成功,而我们的流程却有许多问题。

书籍知识整理

    由于该书90%的内容都在讲他们的团队是如何实践 Scrum。所以,这些内容都是来自他们的亲身实践经验,有很大的参考价值。

    另外,基于对项目组有帮助的目标下,我只从原书中摘抄出了部分相关的理论方案。这些方案并不一定适用每一个团队,但是它们一定有它们成功的道理。

  1. 关于 计划会议: 会议开始前,PO要准备好接受各式各样问题的挑战。 计划会议开始时,应该宣读本次会议议程,并强调 Sprint 目标。
  2. 关于 Sprint 目标:强调商业价值。
  3. 关于 团队成员:一个敏捷团队,人数最好在3-5人。
  4. 关于 Sprint 长度:短迭代,意味着敏捷、更多的反馈、更少的错误。理论上,开发人员喜欢长迭代,而 PO 喜欢短迭代。
  5. 关于 Sprint 故事列表: 团队成员定夺最终的故事列表,不是PO,更不是SM。 那么,PO 如何影响故事列表?“重新排列优先级”,“划分大故事为小故事”,“缩小故事的范围”。 团队如何确定 Sprint 中的任务数?两个方案:“敏捷团队自身感觉”、“计算团队速度”。
  6. 关于 速度计算:分析历史完成量,计算出团队的专注度;计算迭代中的可用人天;相乘,得出最终速度。
  7. 关于 index card:好处有两点:每个人都能保持高度的参与程度,而不再只是掌握键盘的人;多个任务可以被同时编辑。
  8. 关于 Sprint Backlog:自行定义合适的格式,建议 Excel。
  9. 关于 Sprint 回顾会议:目标在于反思!在于长进!找到本期重点不足,并予以改正。
  10. 关于 测试阶段: 最小化测试阶段的时间。 开发完成任务之前的时间可以做的事:测试人员需要为接下来的测试做准备;编写测试代码;与开发结队;其它辅助达到 sprint 目标的事(这些事最好在计划会议中定义)。

我们的团队 现象与建议

    流程是优化出来的。发现问题,思考方案,解决问题。

    第一步就是发现问题。这要求有人关注流程,在流程进行时,思考并记录流程中存在的问题。虽然听上去很简单,但是仔细一反思,就会发现,除非有专门的人来做这个事,否则很少会有人不断记录流程中的问题。可能大家都发现了一些问题,聊一聊,不管当时出不出结果,过段时间就忘记了。最近几个 sprint,公司派了PMO部门的周姐过来监督团队流程。但是,我个人认为,这些事情是敏捷团队成员自己的职责。所以在最近的几个 sprint 开始,我开始使用PDA随时记录存在的问题。

    以下,我提出我记录到的一些大大小小的问题。

注意,这些问题及方案是基于我作为一个开发人员的角度提出的,但是从不同的角度和立场来看,它们很可能也不是一个问题。另外,一些问题跟我们项目的性质有关,我们部门属于新产品研发部门。

需求方面

现象:

  1. 计划会议中,PO提出的需求不断受到开发人员的质疑。计划会议一度变为业务研讨会议,一些需求经过临时的讨论,发现有问题,被“丢弃”了,被“打回”了。
  2. 几位需求人员,在计划会议中,一些需求没有达成共识。
  3. 疾跑过程中,有时会发生临时需求更改的情况。本期迭代中的原型也在迭代中不断被修改。

问题分析:

    主要原因在于计划会议中给所有人员展示的需求,基本都是上一期sprint中制定的,并没有一个较长期的思考。一个短期思考的产物,很难做到合理、全面、系统、无懈可击,所以会议中一些需求会经不住拷问。

建议:

  1. 需求先行,先做两到三期的Sprint Backlog。
  2. 需求组本身先开展需求评审会议。在计划会议前,完成一个较稳定的列表,其中包含 1.5-2 个 sprint 任务的 backlog,用于计划会议给开发人员讲解。
  3. 迭代中严禁需求变更。哪怕做错了,继续做下去!
  4. 不超过2周的短迭代,降低可能的需求变更。

会议时间拖延

现象:

  1. 计划会议较多时间讨论业务。
  2. 各种会议思绪乱飞,进入无关话题。
  3. 最近几个 Sprint,各种会议超时过多。

建议:

  1. 会议开始时,主持人说明会议的目标,并适当控制会议内容和时间。
  2. 多余的话题,记录下来,另起讨论。
  3. 相信需求团队,不轻易质疑。

回顾

现象:

  1. 回顾项没有落地。
  2. 过于遵循“章法”,好的、不好的、改进项都列满了。

建议:

  1. 目标:表扬、改进。
  2. 会议开始,强调回顾目标。继续使用原来的“回顾原则”。
  3. 挑重点回顾。少来几项,指定改进责任人。
  4. 回顾上期改进项的执行。
  5. 回顾项进入 backlog。
  6. 没有什么好回顾?散会!

    最近,大家都发现,回顾会议的质量并不高。上次回顾会议,周哥 组织更换了形式,没有按照表格进行,而是大家积极讨论,感觉明显“敏捷”了许多。

估时

现象:

  1. 不知道怎么估。
  2. 好久没用任务拆分墙了……直接分了用户故事,回去自己贴吧。
  3. 最近的需求文档中说的是用户故事?这种故事比任务还小,没法拆啦~
  4. 好吧,好吧,一个模块一个模块估吧。
  5. 勇刚说,这种估时太扯了。
  6. 没法估,有需求的不确定性,有技术的不确定性。
  7. 果然,估时不准。
  8. 说不出我们每个Sprint的速度。

分析:

    今年,部门开始使用新的 Sprint Backlog 格式,中途也发现了很多的问题。例如,整个 backlog 完全面向产品架构,与开发人员没啥关系,这怎么可能会有指导性。问题提出后,做了一些改进,但是还是对于开发人员来说,还是没有指导性。开发人员面向这个 Backlog 进行估时,无疑寸步难行。再加上任务板不再在任务拆分时使用,大家都无法把任务细化,直接一项一项backlog估时,要么大了,要么小了。

建议:

  1. 要拆!面向逻辑任务进行拆分。任务项要可大可小,目标是开发人员能真正地在心中认可估出的时间。 (要是有公式就最好了,例如:我做这个模块都是体力活,20个类,一个应该是20分钟,那么一共是……)
  2. 不确定性: 这个 Sprint 先出设计方案,下个迭代再实现代码。 大改动需要提前两三个 Sprint 进行准备,所以,需求当然也要先行! 这样同时解决了当期任务依赖性的问题。
  3. 逻辑任务划分完成后,不要忘记于对应的 backlog 项进行关联,以防止断环。
  4. 做几个稳定的 Sprint 之后,开始计算专注度和速度。

    最近一次的估时会议,我们使用了基于 OEA 框架开发的新工具 GPM 来进行任务估时。个人感觉效果不错:当次 sprint 估时大概使用了两个小时,估时的时候能做到尽量拆分到开发人员心中的粒度,并进行时间汇总。但是,测试人员反馈无法出日报了,逻辑任务没有和 backlog 进行关联。所以我们又在任务上添加了“关联 backlog 项”及“实际完成时间”。以下是软件截图:

(这里也体现了 OEA 框架的威力,这个工具的开发时间一共1小时。相关内容,园友可以看这里:《OEA 框架演示 - 快过原型的开发》)

计划会议抓不住个人重点

现象:

  1. 增加了两名开发人员,我们没有对过程进行任何改进。
  2. “这块需求应该不是我的,我没必要听得那么仔细”。
  3. 我在看PDA……我在打嗑睡……我不参与这一块的讨论……
  4. 讲估算,除了智哥,大家都闲着。
  5. 需求宣贯完毕,开始拆分任务。任务分配到开发人员头上,开发人员还是不知道具体要做什么。“明佳,这块再给我说一遍吧”“明佳,这块是不是这样……”
  6. 我个人感觉太不“敏捷”了,慢死了……

分析:

    我是这样想的:

  1. 没有必要每个人把所有的需求都完全吃透。
  2. 指定任务被放在了需求宣贯之后,导致所有开发人员在需求宣贯时,都不知道自己要做的是哪一部分内容。一天计划会议下来,很难保证持续不断的集中精力在每一个需求上。导致一些问题,例如:想着这个模块可能与我无关,我不需要那么关注,那么就经常会开小差,不参与讨论。最重要的一点是,需求的把握没有重点,分不清主次。到任务划分时,真正分派到自己头上的任务,还是不能彻底理解需求,问一些其实已经讨论过的问题。 团队人员越多,这个问题就越会显露出来。
  3. 一个问题参与讨论的人多了,反而更闹。
  4. 多个CPU(人脑),线性地完成一个任务(理解所有需求);当然不如并发,让各CPU进行并发计算,只需要加个管理程序(促进沟通的方案)就好了。

    这个问题和周哥讨论了蛮久。

    周哥的意思是,这是每个开发人员的职责,如果同组的其它人在开发什么都不知道,那么肯定是不行的。

    后来和勇刚进行了沟通,他说GEPS项目组使用的方案是开发人员轮换人员开发各自的任务。

建议:

  1. 人员多了,形式上,可以考虑分更小的组。
  2. 先以团队协商的形式,分好故事点,再为开发人员进行需求宣贯。
  3. 必须有个总体的需求宣贯会,保证所有人员都浅层次地理解其他人的需求及任务。
  4. 敏捷个人,把握好自己的需求。心中可以做好任务拆分。最后直接录入GPM中。
  5. 开发人员轮换完成任务。

总结

    今年的目标中,有一部分是自己要学习管理,而学管理的目标是优化小项目组的流程,如何能优化好一个小项目组的流程,为以后的个人发展做准备。

    这次的反思是我第一次反思整个项目组的流程,当然,这些也都是从一个开发人员的角度来提出的。这些思想和建议并不一定正确。但是,我相信,只要我们每个人不断地进行反思,并发挥好回顾会议的作用,提出自己的建议,我们团队的流程必然会越来越高效,越来越敏捷!

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CDA数据分析师

数据科学家VS数据工程师,真的是一山不容二虎?

原作者 Karlijn Willems 编译 CDA 编译团队 本文为 CDA 数据分析师原创作品,转载需授权 数据科学是一个蓬勃发展的产业,相关大数据的职业也...

2426
来自专栏无原型不设计

UI设计:掌握这6点,轻松0到1

非科班出身能成为UI设计师吗? 答案是肯定的。世上无难事,只怕有心人。只要找对方法、坚持不懈,即便是零基础也能学好UI设计。 那么零基础学习UI设计,需要...

2655
来自专栏CSDN技术头条

写给技术:简历迈对一小步,跳槽前进一大步

在找工作时,有人投递上百份简历才收到一两个要约电话,有人一投一个准。这其中的差异在哪里? 屡投屡败的小伙伴,往往是一份通用简历投 N 家公司,这样的简历看起来和...

4584
来自专栏智能计算时代

个性化推荐最佳实践

image.png 个性化推荐最佳实践 一、基本概念 网络营销解决方案提供商Questus公司的调查显示,在选择网络购物的消费者中,32%的人认为浏览体验非常...

3366
来自专栏DevOps时代的专栏

案例 | 可视化的方式解决 Dev 和 Ops 的相爱相杀(下)

上篇文章链接:案例 | 可视化的方式解决 Dev 和 Ops 的相爱相杀(上) 5.“看见”DevOps的价值流上下文 ? 我们来看一下看见 DevOps 的价...

2565
来自专栏专知

想成为大牛?从写博客开始

The most importantpart of a data science project is writing a blog post

1256
来自专栏互联网杂技

Airbnb团队负责人:硅谷新兴的产品内容策略分析师是什么

Marissa Phillips 是 Airbnb 产品内容策略(Product Content Strategy)团队负责人,就职于旧金山总部。2016 年加...

1153
来自专栏Java帮帮-微信公众号-技术文章全总结

项目管理——如何有效的沟通

项目管理——如何有效的沟通 团队之所以成为团队,是因为团队会相互的协作去完成一个共同的目标。在完成这个目标的过程中就缺不了团队成员间的交流和沟通。如果团队有n个...

3566
来自专栏张善友的专栏

培养敏捷态度

关于敏捷方法论的文章已经很多了。其中,相当一部分文章讲述了敏捷方法技术方面的问题,比如测试驱动开发和持续集成。同样,还有相当一部分文章讨论了敏捷 方法论的应用问...

1996
来自专栏Albert陈凯

大数据方向的十个岗位

随着大数据的趋势引起的越来越多的重视,各大企业对与大数据相关高端人才的需求也越来越紧迫。这一趋势,也给想要从事大数据方面工作的人员提供了难得的职业发展机遇。 ...

3726

扫码关注云+社区

领取腾讯云代金券