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

Posted 2021-04-25 展播

  这篇文章和《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. 开发人员轮换完成任务。

 

总结

---

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

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

 

欢迎转载，转载请注明：

转载自 胡庆访[ http://zgynhqf.cnblogs.com/ ]

最后，您想和老五面对面聊敏捷吗？

那么，动动你的手指，扫一扫就能实现奥！

上海展播信息科技有限公司是一家专业化、国际化管理与技术咨询机构。主要面向互联网、软件和信息服务业，以及通信、能源、交通、金融等行业企业，为其提供推Scrum,CMMI,IPD有关的过程改进、技术方案和成熟度能力提升，以及标准、模型、技术、工具的培训、咨询、评估、认证和推广服务。

展播科技秉承"专业、高效、高性价比、高客户满意度"的服务理念，汇集了由多位国内外具有丰富研发管理实践的咨询顾问。

展播科技坚持以客户服务为中心，依据具体的公司实际情况、针对客户的具体差距分析报告，有针对性、有选择性地量身定做解决方案，安排相应的专题培训，为客户建立属于自己的研发与工程及管理体系。