-5

在项目中,用户故事的工作流程是 ToDo - In progress - Dev - SIT - UAT 现在我们面临的挑战是计算速度,因为考虑到开发、SIT、UAT 测试所涉及的工作,我们很抱歉。但是在网站上是 sprint,我们只能将我们的用户故事推送给 dev,而不能在 sprint 中完成 SIT 和 UAT。现在计算速度的正确方法是什么?

4

3 回答 3

2

速度是衡量团队在单个 Sprint 中可以处理的工作量的指标,也是 Scrum 中的关键指标。速度是在 Sprint 结束时通过汇总所有完全完成的用户故事的积分来计算的。

https://www.scruminc.com/velocity/

由于您没有完成故事,因此您的速度为零。如果您保持项目燃尽,您可以在完成 SIT/UAT 时看到一些获得的积分。这可以让您了解完成了多少工作以及项目何时完成。

开发团队由专业人员组成,他们负责在每个 Sprint 结束时交付潜在可发布的“完成”产品增量

https://www.scrumguides.org/scrum-guide.html#team-dev

猜猜你需要弄清楚如何在 Sprint 中完成你的工作。这个想法是在一个 Sprint 中真正完成工作,这可能是一个挑战,但是尝试重新组织你的工作以实现它。

如果,一旦你完成了一个故事,你就不必再回头看它,那不是很好吗?这就是“完成”背后的理念。一个完整的故事不是一堆未集成、未经测试的代码。它已准备好部署。

https://www.jamesshore.com/Agile-Book/done_done.html

在下一次回顾中,我会花一些时间讨论如何在 Sprint 中完成故事。需要什么?

我建议在开始下一个用户故事之前先收集一个用户故事并完成它。

注意障碍并修复它们以更快地交付:

  • 如果您无法在 sprint 期间执行系统集成测试,请花时间使其更容易部署到测试/暂存系统。
  • 安排用户定期进行用户验收测试,或邀请他们参加 Sprint 审查并让他们玩弄它。为他们发现的事物创建新故事。
  • 尝试拆分故事以使它们更小,这样更容易真正完成。
于 2018-09-03T09:57:48.583 回答
-1

如果:

  • 集成测试是完全自动化的

  • 如果没有,您的团队中有一名全职测试员,一旦故事部署在 SIT 服务器上,他就会进行测试(由 Jenkins 等持续交付工具自动部署)

  • 一旦开发人员说“看看它”,某人就会接受一个故事(甚至可以在你的笔记本电脑上完成)

  • 产品负责人是接受故事的人

  • 在 Sprint Review(“演示”)中,您向用户展示新的 Produxt 增量并请求反馈

......然后你得到流程,你只有三个状态:待办 - 做 - 完成。发布/部署到生产只是冲刺中的另一个故事。

...然后 Jira 会告诉您您的速度,您可以在 Jira 中使用所有其他非常有用的报告 :-)

......团队中的每个人都很高兴,因为有流动。并且功能可以快速交付给最终用户。

于 2018-09-19T06:27:13.063 回答
-1

我的建议是测量在给定时间段(天、周、月等)内从工作流程开始到工作流程结束所采取的故事点数量,这将为您提供团队在故事点方面的速度。

于 2018-09-03T08:52:14.507 回答