扫码阅读
手机扫码阅读
分享几个团队敏捷转型过程中的故事
![](/theme/default/default/images/main/eye-open.png)
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
![](/theme/default/default/images/main/icon-link.png)
![](/theme/default/default/images/main/icon-jing.png)
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中处理。
想要了解更多内容?
![](/theme/default/default/images/main/icon-link.png)
![](/theme/default/default/images/main/icon-jing.png)
Bruce Talk
扫码关注公众号
Bruce Talk的其他文章
头脑风暴小工具-影响地图
正文本周在和一个团队探索一个实验型项目的时候,影响地图发挥了很大的作用。这里和大家分享一下。 如果你不熟悉影
产品团队业务思维的重要性
产品思维对研发团队来说也是必不可少的一个关键要素。作为一项创造性的知识工作,激发团队的主动思考能够事半功倍。
权衡矩阵《敏捷实战-破解敏捷落地的60个难题》读后感
权衡矩阵,让干系人简单直观的了解实际情况。
《看板方法官方指南》中文版发布了!
颜值爆表的《看板方法官方指南》中文版发布了!高速公路的隐喻让看看板方法更加生动立体。看板并不是白板+便签的简单组合。
我们需要软件工艺
软件开发并不是一项简单机械的活动,将其看作一种工程学实践是不恰当的。因此,我们需要给软件开发一个更好的隐喻:软件工艺。
加入社区微信群
与行业大咖零距离交流学习
![](https://cdn.easycorp.cn/rongpm/upload/202312/f_39217d624bb2b42ce8f6322ebd7e573a.png)
![](https://cdn.easycorp.cn/rongpm/upload/202312/f_39217d624bb2b42ce8f6322ebd7e573a.png)
PMO实践白皮书
白皮书上线
白皮书上线