scrum项目管理_Scrum，用于初创企业（或针对该项目的任何项目）

scrum项目管理

Scrum is a lightweight framework designed to help small, close-knit teams of people develop complex products.

Scrum是一个轻量级框架，旨在帮助紧密联系的小型团队开发复杂的产品。

Of course, Scrum isn’t just applicable to software projects as you can use it to build a better mousetrap or really anything for that matter. I’ve seen it used in every single part of an organization, even legal and finance.

当然，Scrum不仅适用于软件项目，因为您可以使用它来构建更好的捕鼠器或其他任何东西。 我已经看到它在组织的每个部分都使用过，甚至在法律和财务方面也是如此。

Typically, a Scrum Team is about 7 folks, plus or minus 2. So, the most that you’d have is 9 and the smaller teams have about 5 team members. This, of course, doesn’t really work for early-stage startups where the founding team might be just 2 or 3 folks. Heck, it might just be you.

通常，一个Scrum团队大约有7个人(正负2)。因此，您最多拥有9个人，而较小的团队则有大约5个人。 当然，这对于开创团队可能只有2到3个人的早期初创公司并没有真正的作用。 哎呀，可能就是你。

There are 3 roles:

有3个角色：

1. Product Owner
   产品拥有者
2. Scrum Master
   Scrum大师
3. Team Member
   队员

The Product Owner represents the business and handles the relationship between the product and the investment of time, resources, and energy that the business is incurring. The PO ensure that maximum ROI is achieved.

产品负责人代表业务，并处理产品与业务所花费的时间，资源和精力之间的关系。 采购订单可确保实现最大的投资回报率。

Tactically, they help the team understand what is higher priority and what is lower priority, what might be more valuable to work on and less valuable to work on. Their role is to help shift resources and time and attention. Sometimes, but not always, they may prioritize things on the backlog but they are the only ones who can ask the team to work and who can change the order of the backlog.

从战术上讲，它们帮助团队了解什么是更高的优先级，什么是更低的优先级，哪些可能更有价值，而哪些更不重要。 他们的作用是帮助转移资源，时间和注意力。 有时但并非总是如此，他们可以将待办事项列为优先事项，但他们是唯一可以要求团队工作并可以更改待办事项顺序的人。

Finally, they help the team understand the requirements so as to maximize time and resources to produce higher efficiency and effectiveness (thus boosting ROI). They do this by creating user stories that generally look like this:

最后，它们帮助团队理解需求，从而最大化时间和资源以产生更高的效率和效果(从而提高ROI)。 他们通过创建通常如下的用户故事来做到这一点：

As a <type of user>, I want to <do something>, so that <some value is created>.

作为<用户类型>，我想<执行某些操作>，以便创建<某些值>。

A Product Owner:

产品负责人：

• Holds and maintains vision for the product
  保持并保持产品愿景
• Represents the interests of the business
  代表企业的利益
• Represents the customer(s)
  代表客户
• Owns the backlog
  拥有积压
• Orders and priorities the product backlog
  订单和优先产品积压
• Creates acceptance criteria for the items in backlog
  为待办事项中的项目创建验收标准
• Is available to assist and answer team’s questions
  可用于协助和回答团队的问题

The Scrum Master plays the role of coach and helps guide the team to better self-organization, performance, and decision making. While the team focuses on building the best product, the SM focuses on building a high-performance team.

Scrum Master扮演教练的角色，并帮助指导团队改善自我组织，绩效和决策能力。 团队专注于打造最佳产品，而SM则专注于打造一支高性能团队。

Good SMs are one part coach, one part champion, one part guardian, one part facilitator, and, of course, an expert at Scrum mechanics. They equally champion the product, the team, and the individuals on the team.

优秀的SM是教练，一份冠军，一名监护人，一名辅导员，当然，还有Scrum力学专家。 他们平等地支持产品，团队和团队中的个人。

They are not anyone’s boss, mind you, but rather a peer, on the team with a very distinct role. In summary, they:

请注意，他们不是任何人的老板，而是团队中非常重要的同龄人。 总之，他们：

• The resident Scrum expert and advisor
  常驻Scrum专家和顾问
• A coach for the team
  团队教练
• The remove blockers, impediments, and help the team continue to move forward
  消除障碍，障碍并帮助团队继续前进
• The facilitate the backlog and the other parts of Scrum
  方便积压和Scrum的其他部分

A Team Member has the most authority in the Scrum system as they are part of a self-organized body of folks who are committed to building kickass products. They have the authority to decide how the work gets done, what tools they should use, what techniques should be deployed, and the associated costs of those decisions.

团队成员是Scrum系统中拥有最大权限的成员，因为他们是致力于开发kickass产品的自组织成员的一部分。 他们有权决定工作的完成方式，应使用的工具，应采用的技术以及这些决定的相关费用。

The prevailing wisdom is that people who do the work are also the best authority on how to best said work.

普遍的看法是，从事工作的人也是如何最好地说出工作的最好权威。

A fully functional Scrum team should have all of the relevant skills necessary to build the product which means that most, if not all, of the team members are specialists in their own right. But this doesn’t mean that they silo their effort as the uniform goal is to deliver a working product to the business and customer. This means that team members will often times work in other areas that may be outside of their speciality to get the job done.

一个功能齐全的Scrum团队应该具备构建产品所需的所有相关技能，这意味着，即使不是全部，大多数团队成员本身就是专家。 但这并不意味着他们会孤军奋战，因为统一的目标是向企业和客户交付有效的产品。 这意味着团队成员经常会在他们专业以外的其他领域工作，以完成工作。

High-performance teams share the load, always.

高绩效团队始终担负着责任。

Team Members:

团队成员：

• Responsible for completing user stories to incrementally increase the value of the product
  负责完成用户案例，以逐步增加产品的价值
• Self-organize to get all of the work done
  自组织以完成所有工作
• Owns and creates the estimates for the work
  拥有并创建工作估算
• Owns the “how to do the work” decisions
  拥有“如何做工作”的决定
• Avoids single-minded, specialist-thinking and instead considers the team’s performance in aggregate above their own
  避免专一，专心的想法，而是将团队的绩效综合考虑

Scrum Artifacts are essentially the tools that practitioners of Scrum use to make great products and to increase visibility and communication effectiveness.

Scrum Artifacts本质上是Scrum的从业人员用来制作优质产品并提高可见度和沟通效率的工具。

The Product Backlog is the master list of all of the planned and desired deliverables for the product. This can (and should) include features, bugs, documentation, Q/A, and more, essentially including anything that is meaningful and important to create for the product as a whole.

产品待办事项列表是该产品所有计划的和期望的可交付成果的主列表。 它可以(并且应该)包括功能，错误，文档，Q / A等，基本上包括对于整个产品而言有意义且重要的任何内容。

Some call items within the backlog just “backlog items” while other teams might call them user stories. This is preferential and the team can decide what specific terms they want to use.

待办事项列表中的某些呼叫项只是“待办事项项”，而其他团队可能将其称为用户案例。 这是优先选择，团队可以决定要使用哪些特定术语。

The list of backlog items or user stories is prioritized and ordered from the most important to the least important. The items at the top are also specific, well understood, and can be executed against quickly and efficiently. This means that they are also generally small tasks. Items further down the list are more ambiguous, less defined, and larger in scope and scale.

待办事项或用户故事的列表按优先顺序排列，从最重要到最不重要。 顶部的项目也是特定的，易于理解的，可以快速有效地执行。 这意味着它们通常也是小任务。 列表后面的项目更加含糊，定义不清，范围和规模更大。

Each item in the backlog should generally have the following:

待办事项中的每个项目通常应具有以下内容：

• Which users the story will benefit (who is it for)
  故事将使哪些用户受益(针对谁)
• A brief description of the desired functionality (what needs to be built)
  所需功能的简要说明(需要构建的内容)
• The reason that this story is valuable (why we should do it)
  这个故事很有价值的原因(为什么要这么做)
• An estimate as to how much work the story requires to implement
  对故事需要执行多少工作的估计
• Acceptance criteria that will help the team know when it has been implemented correctly
  验收标准将帮助团队了解何时正确实施

The Sprint Backlog is the team’s to do list for the sprint. Unlike The Product Backlog, it has a finite life-span: The length of the agreed upon sprint. It includes all the stories that the team has committed to delivering in the sprint and the associated tasks. Stories are deliverables and can be thought of as units of value.

Sprint待办事项列表是团队的Sprint待办事项列表。 与产品待办事项列表不同，它具有有限的寿命：同意的sprint的长度。 它包括团队已承诺在sprint中交付的所有故事以及相关任务。 故事是可交付的，可以认为是价值单位。

Burn Charts help the team understand the relationship between time and scope. Points are on the y-axis while sprints are on the x-axis. As time progresses, one can see how many points are remaining in the overall product and the relative speed and pace at which the team is working through the points and the sprints. A Burn Down chart shows what is left to do while a Burn Up chart shows how much scope the team has got done over a select period of time.

烧伤图可以帮助团队了解时间与范围之间的关系。 点在y轴上，而冲刺在x轴上。 随着时间的流逝，人们可以看到整个产品中还剩下多少点，以及团队通过这些点和冲刺的相对速度和进度。 燃尽图显示剩余的工作量，燃尽图显示团队在选定时间段内完成的工作量。

When more items are added to the backlog one can see the number of points increase through a vertical line up and when things are removed it’s a vertical line down.

当有更多项目添加到待办事项列表中时，可以看到点数通过垂直线向上增加，而删除内容时则是垂直线向下。

The Task Board represents all the team’s tasks visibly so that everyone knows what is being worked on and by whom. The more simple of task boards have three columns:

任务委员会明显地代表了团队的所有任务，因此每个人都知道正在做什么以及由谁来进行。 任务板较为简单，包含三列：

• To Do
  去做
• Doing
  在做
• Done
  完成了

Tasks are simply moved from left to right as they are worked on and progress is made. The Task Board is a visible reminder of the team dynamics and mechanics in play: We are all in this together and we sink or swim as a team. It allows the team to inspect the work and then adapt as necessary. Other stakeholders can also see the progress and provide value as well.

在处理任务并取得进展时，只需简单地从左向右移动任务即可。 任务板明显提醒了团队的动态和机制：我们都在一起，我们作为一个团队沉没或游泳。 它使团队可以检查工作，然后根据需要进行调整。 其他利益相关者也可以看到进度并提供价值。

How the team defines “Done” is also very important because it will be different for different teams. Also, if it is not clearly defined then it will create confusion among different team members and stakeholders as they will have their own interpretation as to what “done” really means.

团队如何定义“完成”也非常重要，因为不同的团队会有所不同。 另外，如果没有明确定义，则会在不同的团队成员和利益相关者之间造成混淆，因为他们将对“完成”的真正含义有自己的解释。

For instance, a software developer might consider “done” when they have finished writing their code while a business person may consider the task “done” when it is ready to sell to customers. Clearly, these are two very different interpretations of “done”!

例如，软件开发人员在完成编写代码后可能会考虑“完成”，而业务人员在准备将其出售给客户时可能会认为任务“完成”。 显然，这是对“完成”的两种截然不同的解释！

Effective Scrum Teams define what “done” means and then apply it to their Task Board and user stories. This is what is often described as the “Definition of Done” and may be singular in nature or a combination of elements. Printing the definition out and putting it alongside the Task Board is an often used tactic as well so as to remind the team what it really means.

有效的Scrum团队定义“完成”的含义，然后将其应用于任务板和用户案例。 这通常被称为“完成的定义”，并且本质上可以是单数或元素的组合。 打印定义并将其放置在任务委员会旁边是一种常用的策略，也是为了提醒团队真正的含义。

The Sprint Cycle consists of several meetings, often called “ceremonies”:

冲刺周期包括几次会议，通常称为“仪式”：

• Sprint Planning
  冲刺计划
• Daily Scrum
  每日Scrum
• Story Time
  讲故事的时间
• Sprint Review
  冲刺回顾
• Retrospective
  回顾性

The Sprint Cycle (or “Sprint” or “Iteration”) is how you get work done: A fixed period of time where you work on small parts of the larger product. The goal after each sprint is the same: A demonstrable working piece of software.

Sprint周期(或“ Sprint”或“迭代”)是完成工作的方式：在固定时间段内，您可以处理较大产品的一小部分。 每次冲刺之后的目标是相同的：可演示的软件。

The more effectively a team completes their sprints the faster the product is built and the faster the business realizes a high return on investment. The team will decide, after each sprint, whether the product is shippable (i.e. can be sold to customers).

团队完成冲刺的效率越高，产品构建速度越快，企业实现高投资回报的速度就越快。 在每次冲刺之后，团队将决定产品是否可运输(即可以出售给客户)。

In general, the shorter the sprint cycle is the faster they can get feedback which helps make subsequent sprints even more effective. This cumulative effect is not to be taken lightly, by the team or the larger business.

通常，冲刺周期越短，他们可以获得反馈的速度就越快，这有助于使后续的冲刺更加有效。 团队或大型企业不应轻视这种累积效应。

It is very common for teams to have sprint cycles that last 2 weeks, although in early-stage ventures the cycle times might be as small as 1 week. When Scrum was first introduced the cycles were around 4 weeks or one month.

对于团队来说，短跑周期持续2周是很常见的，尽管在早期阶段，周期时间可能只有1周。 首次引入Scrum时，周期约为4周或一个月。

For a one week sprint, you’ll usually have the following with time breakdowns:

对于一个星期的冲刺，通常会有以下时间细分：

• Monday: Sprint Planning (1–2 hours)
  星期一：Sprint计划(1-2小时)
• Tuesday: Daily Standup (15 minutes)
  星期二：每日站立(15分钟)
• Wednesday: Daily Standup (15 minutes), Story Time (1 hour)
  星期三：每日站立(15分钟)，故事时间(1小时)
• Thursday: Daily Standup (15 minutes)
  星期四：每日站立(15分钟)
• Friday: Daily Standup (15 minutes), Sprint Review (30 minutes), Retrospective (1–2 hours)
  星期五：每日站立(15分钟)，Sprint审查(30分钟)，回顾(1-2小时)

For Sprint Planning the goal is for the team to commit to a set of deliverables for the sprint and to also identify the tasks required to deliver upon the agreed user stories or backlog items. With the team, the Product Owner presents the suggested stories to prioritize and the team discusses, sometimes vigorously, their position and priority.

对于Sprint计划，目标是团队致力于为sprint交付一组交付成果，并确定交付商定的用户案例或积压项目所需的任务。 产品负责人会与团队一起提出建议的故事以进行优先排序，并且团队有时会激烈地讨论其立场和优先级。

It’s worth noting the delineation of role and responsibility and authority between the PO and the TM: The Product Owner decides which stories are going to be considered for the sprint while the team members doing the work are the ones who decide how much work they can reasonably take on.

值得注意的是，采购订单和TM之间的角色，责任和权限的划分：产品负责人决定将要针对sprint考虑的故事，而团队成员则是负责合理完成多少工作的人承担。

In the second part of the meeting the team then decides how the work will be done, decomposing the agreed stories into tasks. As tasks are defined the resulting stories on the backlog may change as well as more information become apparent and usable. It is not uncommon for a team to over-commit to the number of user stories in the beginning and then have to remove some as more details emerge.

在会议的第二部分中，团队将决定如何完成工作，将商定的故事分解为任务。 定义任务后，待办事项列表上的结果可能会更改，并且更多信息变得明显且可用。 对于团队来说，一开始就过多地承担用户故事的数量，然后随着更多细节的出现而不得不删除一些故事，这种情况并不少见。

The result of this planning session is the Sprint Backlog which consists of the aforementioned user stories and the resulting associated tasks. The Product Owner can give more user stories if the team requests them or has room but should be wary of overcommitting the team.

该计划会议的结果是Sprint Backlog，该Sprint Backlog由上述用户案例和相关的任务组成。 如果团队要求他们或有足够的空间，产品负责人可以提供更多用户故事，但应提防过度使用团队。

The Daily Scrum, or Daily Standup, is when most teams hold a quick meeting near the beginning of the day to share the following:

每日Scrum或每日站立，是大多数团队在一天开始时举行一次快速会议以分享以下内容的时候：

• What tasks have been completed since the last Daily Scrum
  自上次Daily Scrum以来完成了哪些任务
• What tasks are to be completed by the next Daily Scrum
  下一个每日Scrum将完成哪些任务
• What obstacles are slowing the team down
  哪些障碍正在拖慢团队速度

Each member of the team participates and the meeting should be pointed, specific, and brief. The point is for everyone to get an idea of global progress and to identify issues before they become larger ones. This allows the team to actively inspect and adapt to changes in near real-time. Surfacing issues is the goal but creating solutions during the Daily Scrum is not.

团队中的每个成员都应参加，并且会议应该有针对性，具体且简短。 关键是让每个人都有全球进步的想法，并在问题变得更大之前就确定问题。 这使团队能够主动检查并适应近实时变化。 解决问题是目标，但不是在每日Scrum期间创建解决方案。

Story Time happens mid-week or mid-Sprint to discuss how the team can improve on the stories in the product backlog which are user stories for future sprints. These are not user stories in the current sprint.

故事时间发生在周中或Sprint中期，讨论团队如何改进产品待办事项中的故事，这些故事是未来Sprint的用户故事。 这些不是当前sprint中的用户案例。

The Product Owner defines and refines the acceptance criteria for user stories in the backlog and also point values for stories that do not yet have an estimate. This is essentially an opportunity for the team to guess at how much work will be required to get the story done.

产品负责人定义并完善了积压的用户故事的接受标准，还为尚未估算的故事指定了点值。 对于团队来说，这实际上是一个机会，可以猜测完成故事需要多少工作。

Not all Scrum Teams have an official Story Time and many teams do this at-will daily. It just depends on the size of the team and their internal culture of decision making.

并非所有Scrum团队都有官方的故事时间，许多团队每天都随意这样做。 这仅取决于团队的规模及其内部的决策文化。

The Sprint Review is a public declaration that the current sprint or cycle is done and it’s time to show the work that’s been completed. Stakeholders from the business are often invited to review progress as well.

Sprint审查是一项公开声明，表明当前的Sprint或周期已完成，现在该展示完成的工作了。 通常也邀请企业的利益相关者审查进度。

It is often the case that not all of the user stories were completed so the audience should be obviously made aware of those details before presenting. The stakeholders, upon review, will undoubtedly have feedback and suggestions and it is the job of the PO primarily to capture these things for review later.

通常情况下，并非所有用户故事都已完成，因此在演示之前，应该使听众明显地意识到这些细节。 利益相关者一经审查无疑将获得反馈和建议，PO的工作主要是捕获这些内容以供以后审查。

No decisions should be made during the review as those are already done in Sprint Planning.

审查期间不应做出任何决定，因为这些决定已在Sprint Planning中完成。

The Retrospective is the final meeting for the team to gather so that they can inspect, adapt, and optimize their ever-improving performance as a team. Unlike the Sprint Review which included outside stakeholders in addition to the Scrum Team, this meeting is just for the team itself.

回顾会议是团队聚会的最后一次会议，以便他们可以检查，调整和优化他们不断提高的团队绩效。 与Sprint评论不同，Sprint评论除了Scrum团队外还包括其他利益相关者，这次会议仅针对团队本身。

The conversations should revolve around what they learned during the sprint and how that learning can be effectively applied to the next sprint so that work can be done more efficiently and more effectively. And, unlike larger “post-mortems,” the idea here is to focus on just a handful of larger strategic changes instead of creating a master list of all of the things that went well or that went poorly.

对话应围绕他们在冲刺期间学到的知识以及如何将学习有效地应用于下一个冲刺进行，以便可以更有效，更有效地完成工作。 而且，与较大的“事后评估”不同，此处的想法是仅关注少数较大的战略变更，而不是创建所有进展良好或进展不佳的总清单。

Inspect and Adapt all the things! The goal of short sprints or cycles is so that continuous improvement happens faster and that any important learnings aren’t lost into the ether. The Scrum process is designed specifically to catch these new and important learnings and then apply them immediately into the system for improvement.

检查并适应所有事物！ 短距离冲刺或周期的目标是使持续改进更快地进行，并且任何重要的学习都不会落入以太坊。 Scrum流程专门用于捕获这些新的重要学习内容，然后将其立即应用到系统中进行改进。

Finally, it’s worth noting that the Agile Manifesto’s values and principles are not directly part of the Scrum Framework but were definitely used to inform the Scrum Process as a whole. It’s worth reviewing them here.

最后，值得注意的是，《敏捷宣言》的价值观和原则并不是Scrum框架的直接组成部分，而是绝对被用来为整个Scrum流程提供信息。 在这里值得对它们进行审查。

Random backstory: I actually wrote this out for a much older startup… 6 years ago! It sat in my drafts for that long.

随机背景故事：我实际上是为6年前的一家更老的创业公司写的！ 它在我的草稿中呆了很长时间。

I finally got around to looking through it and publishing it. I suppose this does prove, to a small degree, the utility of this type of framework or system across multiple projects — it’s relatively timeless! Hopefully it’s useful for you too!

我终于遍历并发布了它。 我想这确实在某种程度上证明了这种类型的框架或系统在多个项目中的实用性-这是相对永恒的！ 希望它对您也有用！

About me: I’m currently leading Product & Engineering at YEN, a Meta Cryptocurrency Exchange and Social Platform, where we’re still applying these ideas liberally.

关于我：我目前是元加密货币交易和社交平台YEN的产品和工程负责人，我们仍然在其中广泛应用这些想法。

翻译自: https://www.freecodecamp.org/news/scrum-for-startups-or-for-any-project-for-that-matter-93ad0db17a84/

scrum项目管理