什么是用例规范?

很多人混淆了用户案例和故事,但实际上它们是不同的概念。他们可能有一些相似的功能。例如,收集有关用户需求和目标的信息。但它们是为不同的目的而设计的。本文详细讨论了这两个概念以及它们的不同之处。文章中还重点介绍了这两个概念对企业的使用和实用性。本文旨在为读者提供帮助,并帮助他们深入了解该主题。

Continue reading

用户故事和需求之间的差异

虽然大多数新功能都应该从用户的角度来定义,但事实上,当我们定义开发团队需要构建的需求时,我们往往忽略了用户角度的“为什么”。用户故事的重点是体验——使用产品的人希望能够做什么。传统的需求侧重于功能——产品应该做什么。剩下的差异是一个微妙但重要的“谁”  “如何” 和 “何时”列表

Continue reading

敏捷用户故事的验收标准

我们如何才能确保用户故事正确完成并符合客户的需求呢?这就是验收标准发挥作用的地方。验收标准是一份正式的要求列表,可确保完成所有用户故事并考虑所有场景。简而言之,验收标准指定了满足用户故事的条件。简洁的书面标准可帮助开发团队避免对客户需求的含糊不清并防止误解。

Continue reading

什么是敏捷估计?

Agile teams use collective estimation methods to estimate their workload. Group estimation usually uses planning poker as a tool, and teams perform group estimation by playing estimation games. Planning poker is considered to be the most effective and interesting technique for workload estimation in agility. (敏捷团队的估计工作量使用了集体估算方法。集体估算通常使用规划扑克作为工具,团队通过玩估计游戏进行集体估算。规划扑克被认为是在敏捷中进行工作负荷估算的最有效和最有趣的技术。)

Continue reading

S​​crum: 谁创建 Product Backlog项目或用户故事?

The Product Owner (PO) “owns” the product backlog on behalf of the stakeholders, and is primarily responsible for creating it. He or she may instruct the development team and/or the Scrum Master to help him/her in defining the backlog items and in estimating them. (产品所有者(PO)代表利益相关者“拥有”产品积压工作,并主要负责创建积压工作。他或她可以指示开发团队和/或Scrum主控来帮助他/她定义积压项和估计它们。)

Continue reading

什么As / I want / so that 用户故事模板?

The most common technology is the role-feature-reason template, which is used by teams and product owners to start writing user stories in three parts: (1) As a (role); (2) I want (feature); So that (reason). (最常见的技术是角色 – 特征 – 理由模板,用于团队和产品所有者开始编写用户故事,分为三个部分:(1)作为 As a(角色); (2)I What 我想要(特征); So that(理由)。)

Continue reading

如何使用100点方法确定产品待办事项的优先次序?

Your product backlog items need to be structured, organized and prioritized to identify the most important things for your team. In this article, I will introduce 100-point method for product backlog refining activities. (您的待办事项需要进行结构化,组织和优先排序,以确定您的团队最重要的事情。在本文中,我将介绍100点方法为产品积压细化活动。)

Continue reading