如何避免Scrum敏捷开发团队反思会形式化,海星法介绍

如何避免Scrum敏捷开发团队反思会形式化?

迭代压力很大,根本没时间,而且,反思会上大家都在互相推脱责任,会议成了“批斗大会”,所以团队的人都觉得这个会很鸡肋。

很多团队在开反思会时是这么干的:产品经理提前做好各种分析和总结,然后召集大家开会一条条过,其他人有一搭没一搭地听,最后反思会就变成“你讲我听”的形式化存在。

因为大家没有什么参与感,更别提对问题有什么共识或者讨论了。

开反思会时应该极力避免这种情况的发生。

反思会目的很简单:1. 让团队每个人都能平等地发表自己的想法;2. 团队对问题要有共识,并能一起探讨解决方案;3. 团队反思氛围比较积极。

要达到这样的效果,需要有一个合适的方法论框架,而我采用的是“海星”法。

这种反思方法是基于“海星”的框架来收集意见并让团队共识问题的,框架结构如下:

【五个角的解释】

不要做(Stop):接下来不能继续的,对团队完全没价值的事;
少做一些(Less):要少做的,对团队价值不高的事;
多做一些(More):要多做的,对团队有意义的事;
继续保持(Keep):团队做的好的,要保持的;
新尝试(Start):以前没做过的,但可能给团队带来高价值的新点子。

在实际操作中,可以这么做:

    在白纸上画出海星,写好各个角的标签,然后把它贴到墙上;
    给团队中的每个人发便签纸,让大家先花2~3分钟的时间写团队应该马上停止做的事(每个人写1~2条);写完的人就把便签贴到白板上。到时间后,再继续花2~3分钟时间写团队要少做些什么,以此类推,直到五个角都写完;
    请团队里的人轮流读一下各个角的便利贴,在读的同时将相似的内容归类到一起;
    大家对问题都有了共识之后,就开始投票。每个人有3票,按投入产出比投出自己认为最重要,最需要解决的条目;
    三个重要的改进项出来后,大家一起讨论,针对每个改进项制定一套可行的解决方案。这个部分非常重要,这部分讨论的时间至少会占到我们团队整个回顾会议时间的25%;
    为了保障解决/行动方案能被执行起来,把方案拆解为任务放到敏捷看板中,避免大家又一头栽到工作中而忽略了调整。

一些建议:

    为了活跃气氛,可以在写便签时播一些音乐;
    让大家轮流读便签很重要,它也是提升参与度的一部分;
    在大家读便签时,我一般会打开团队文档协作工具,在上面做记录,等到投票时,就直接让大家在上面匿名投票(如下图);
    共识优先级最高的3项就好。由于在敏捷中,迭代周期很短(通常是2~4周),所以即使存在很多问题,也无法一一解决,因此,能在短期迭代中解决优先级最高的三个已经很棒了!

海星反思法的好处:

    团队成员被赋予了表达和决策的权利(平等、自组织是敏捷的核心理念,与传统的领导一人拍板相对);
    共同的讨论让团队对问题有更为深刻的共识;
    由于是团队在共同做决定,所以这种方法也提升了团队改进问题的积极性;
    积极活跃的反思氛围。

心得体会:

在实践敏捷的过程中,我开始一点点体会到“参与感”这个词的意义。“海星”法虽然是一个很小的方法,看起来挺简单的,但对我的团队来说,它却起到了很好的反思效果,至少每个成员在开会时都很投入,每个人都愿意表达。

此外,我们会在每个迭代结束后都开一次迭代反思会。这个很重要!

如果开反思会时,采取的是“三天打鱼两天晒网”的态度,想起来就开,太忙就不开,会让团队失去节奏感,而且减少了及时发现问题,解决问题的机会。因为有了这样定期反思的机制,我的团队也在集体反思中不断进步,做出来的东西也越来越好。

推荐大家在工作中定期地用这个方法去做团队反思,及时解决问题。坚持下来,会有意想不到的收获。

如何避免Scrum敏捷开发团队反思会形式化,海星法介绍的相关教程结束。

相关推荐:

Python怎么自动格式化代码_Black工具一键重排代码结构保证团队代码风格统一

Black是Python的强制格式化工具,非美化器而是重写器;它以固定规则一键重排代码结构,几乎无配置选项,确保团队风格绝对统一。 Black是什么,它真能“一键”格式化? Black是Python的代码格式化工具,不是“美化器”而是“重写器”——它不问你意见,直接按固定规则重排结构。所谓“一键”,...

Python 团队代码规范的强制执行

必须将pep8检查嵌入开发流程:本地用pre-commit+black/flake8拦截提交,ci中强制校验并锁死工具版本;明确区分强制项(如行宽88、4空格缩进)与可协商项(如引号风格),杜绝“假装合规”和新人踩坑。 怎么让团队真正在写代码时遵守PEP8 靠文档和口头提醒没用,必须把检查嵌进开发流...

Python 日志规范在团队中的落地方法

日志级别选择需严格匹配场景:debug仅开发测试用且上线必关;info是唯一长期开启级别,记录业务动作;warning表潜在问题但未崩溃;error必须带exc_info=true;格式化须用懒求值参数传递而非拼接或f-string。 日志级别怎么选才不被同事喷 团队里最常吵的不是用不用loggin...

Python trio vs anyio vs asyncio 的团队选择

选asyncio还是trio取决于团队是否愿为结构化并发“多写两行”:asyncio适合已有稳定生态的项目,trio更利于新项目与可维护性,anyio是渐进迁移兼容层,curio仅适用于教学或原理验证。 选asyncio还是Trio,关键看团队是否愿意为结构化并发“多写两行” 如果你的团队已经用as...

Python pyright vs mypy 的团队选型

ci中优先用mypy,因其检查更严格稳定;pyright更适合开发时实时反馈。两者需统一python_version配置,noreturn应显式标注,第三方stub缺失时mypy更敏感,配置应按阶段分离。 pyright和mypy哪个更适合CI流水线 pyright更快,mypy更准——但“快”在C...

Python 测试文化对团队质量的影响

python测试失败主因是环境配置与规范问题:sys.path、包结构、命名规则(test_、test、test_*.py)、mock误用及覆盖率陷阱,非懒惰所致。 测试写不起来,往往不是懒,是环境没配好 Python项目里pytest跑不起来、ImportError找不到模块、conftest.p...

Python SRE 文化在团队中的推广

sre文化在python团队易变“运维背锅会”是因为误将基础监控当sre落地,忽视slo定义、变更风险控制与开发责任;需用pyproject.toml约束、标准化health_check、ci压测等工程实践倒逼sre真正落地。 为什么SRE文化在Python团队里容易变成“运维背锅会” SRE的核心...

Python编码规范实战教程_提升团队协作效率

Python编码规范的核心价值是提升代码可读性、可维护性与协作效率,以PEP8为基础强调一致性而非教条,辅以flake8、black、isort等工具自动检查与格式化,并落实docstring、类型提示及Git协作约定。 Python编码规范不是为了束缚开发者的创造力,而是为了让代码更易读、易维护、...