欢迎来到分享几个团队敏捷转型过程中的故事
发布于 2024-02-22
1722
版权声明
我们非常重视原创文章，为尊重知识产权并避免潜在的版权问题，我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容，访问作者的公众号页面获取完整文章。
查看原文：分享几个团队敏捷转型过程中的故事
文章来源：
Bruce Talk
扫码关注公众号
扫码阅读
手机扫码阅读
ScrumMaster团队转型经验分享摘要
ScrumMaster在帮助团队从传统工作方式向敏捷开发方式转型的过程中，常会遇到一些相似问题。以下是几个在多个团队转型中常见的问题及反思。
故事1: 单件流与并行工作
在敏捷转型初期，一个团队的开发状态显示，Dev1同时处理多个User Story，而Dev2仅处理一个。Scrum强调聚焦单个任务以减少上下文切换带来的效率损失。Dev1的多任务处理并不理想，因为真正的并行是不可能的。Dev2虽然聚焦但无法启动测试。建议对大的User Story进行合理拆分，并尽早完成以形成反馈闭环。
故事2: Sprint Backlog Item与Bug
一个团队在Sprint中同时处理Bug和Sprint Backlog Item时，存在Bug堆积的问题。团队普遍认为Sprint Backlog Item比Bug更重要，但这种做法可能导致Sprint目标无法实现。Scrum要求每个Sprint Backlog在开始新任务前都应该通过验收标准的测试并达到完成标准。如果Bug无法在当前Sprint解决，应该重新排序并考虑在后续Sprint中处理。同时，应优先处理最重要的任务，以最小化对Sprint目标的影响。
故事3: Sprint中的改进项处理
对于Sprint中发现的改进项，应根据其性质做决定。如果改进项与当前Sprint目标相关，且时间允许，应在当前Sprint内完成。如果与Sprint目标无关，则应从产品目标的角度考虑优先级，并决定在后续哪个Sprint中处理。
Bruce Talk
查看原文：分享几个团队敏捷转型过程中的故事
文章来源：
Bruce Talk
扫码关注公众号
相关推荐
840配置审计是配置管理中的一个重要概念，在CMMI标准中划分了3种，如果再加上PPQA对配置管理过程的审计，累计为4种。在很多图书、资料中对这四种审计言之不详，因而也就造成了理解的偏差。故而我整理了如下的表格，进行了澄清。需要说明的是在很多企业中实际也做了这4种审计，只是没有清楚的认识这4个概念而已。
还在用多套工具管项目？
一个平台搞定产品、项目、质量与效能，告别整合之苦，实现全流程闭环。
查看方案
Bruce Talk的其他文章
我们需要软件工艺
软件开发并不是一项简单机械的活动，将其看作一种工程学实践是不恰当的。因此，我们需要给软件开发一个更好的隐喻：软件工艺。
程序员如何保证自己开发的正确性——测试开发有感
测试开发，开发测试，终极问题都是如何才能知道我们开发的内容是正确的呢？分享一下我的AHA时刻吧。
从一个乙方视角聊聊敏捷项目
敏捷开发是否适合软件项目？还是只能在产品研发中发挥作用？让我从乙方的视角聊聊感受。他们之间确实有不同的地方，但也有相似的方面。
SM和PO如何参与Daily Scrum——《Scrum指南》重读有感(3)
如果 Product Owner 或 Scrum Master 正在积极处理 Sprint Backlog 条目，那么他们将作为 Developers 参与其中。
头脑风暴小工具-影响地图
正文本周在和一个团队探索一个实验型项目的时候，影响地图发挥了很大的作用。这里和大家分享一下。 如果你不熟悉影
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线
-
联系我们
电话：4006 8899 23 邮箱：beining@chandao.com -
融实践库
关于我们 加入我们立即学习
微信号：rongpmcom
-
微信公众号
-
微信视频号
-
社区微信群
