我们是一家中等规模的公司,有一个由五名成员组成的开发团队。最近,我们开始在研发部门学习/使用Scrum方法。
我们的核心团队有一个项目,而每个员工都有单独的任务和项目。其中有些项目的规模仅够单个开发人员完成。
此外,单个开发人员可能支持他们单独发布的产品。
此外,我们目前使用JIRA Scrum板来跟踪我们在核心团队项目中的进度,而我们每个人都使用单独的JIRA看板来处理我们的单个任务/项目。
我们发现在sprint评审期间很容易检查核心团队的项目,但是很难了解我们的日常任务和与核心项目无关的项目。
我们是否应该使用单一的看板来解决所有核心团队的Scrum板问题,以及所有其他非核心团队任务/项目?
那么,在我们的冲刺审查会议期间,我们会详细讨论所有包容性看板中的所有问题吗?如果是这样,我们应该如何过滤我们的看板?在一定的时间范围内更新,标签等?
还是我们应该使用单一的Scrum板,并强制整个团队规划和评估核心团队的项目和所有单独的任务/项目?当新的支持问题在sprint过程中出现时会发生什么?我们是否调整了冲刺范围,中间冲刺?
在保持Scrum评估和计划的同时,我们应该使用什么分组方法来展示我们核心团队的共享项目,以及每个开发人员的单个任务/项目?
发布于 2018-01-29 09:50:02
scrum团队应该为冲刺设定一个固定的目标,这是每个人都在为之贡献的。构建这个特性完成这个版本..。因为这是现实生活中的团队成员对业务有其他的承诺,这没什么--但是每个人都需要判断他们能为scrum团队投入多少时间/精力,每次冲刺。听起来,你可以很好地处理这件事,把这些额外的工作分开处理。
然而,下一个合乎逻辑的结论是,只有属于scrum团队项目的工作才应该在scrum板上进行跟踪,并在日常的停顿中讨论。在您的团队中,绝对没有必要谈论面试,或者您的基础设施人员每天都在为一个专注于完成下一个功能的团队讨论服务器。
这并不是说这份工作不应该被跟踪。但是,这应该在不同的团队僵局或1:1与项目经理/线经理之间进行,并且可以通过聊天、小道消息和官方交流而不占用宝贵的15分钟而带给团队成员。
看板可以使用(如果你愿意的话),但不要把它们放在主板上,在JIRA中创建另一个板,甚至可以旋转几个trello页面。
我们最近使用的东西是在站立过程中使用监视器,显示显示scrum板,如果它不在面板上,则不会讨论(显然是合理的)。这有助于会议的重点,并保持每天简短和简明扼要。
发布于 2018-01-29 03:21:07
尝试一个基于Scrum的Scrum/Kanban组合板:
策略是在团队的墙上同时使用Scrum板和看板。这可能是怎么回事。让产品负责人通过正常的Scrum过程和板或墙来操作计划中的Sprint预测承诺。现在,通过另一个简短的工作流程控制来传递不断涌现的蜂蜜的需求:( a)在日常活动中或在单独的聚会中,与separate和团队就“故事”进行简短的讨论;( b)对产品所有者带来的项目(S)做一个故事点评估。然后把这些放在看板上的墙上或木板上。
或者是基于看板的ScrumBan板:
从看板开始,并将产品待办事项添加到其中。通过一个小的计划会话将转换为TODO列表。当TODO列表变为空时,请进行计划。
https://softwareengineering.stackexchange.com/questions/355707
复制相似问题