敏捷史诗故事是什么
Running a team of developers is hard. Trying to coordinate a mountain of work while keeping everyone productive is a challenge itself. But on top of that, you have to keep open communications with a client. How can we use agile to relieve some of those pain points?
运营一个开发团队很难。 在保持每个人的生产力的同时，努力协调工作量本身就是一个挑战。 但最重要的是，您必须与客户保持开放的沟通。 我们如何使用敏捷来缓解其中一些痛点？
什么是敏捷？ (What is agile?)
Agile is a software development methodology that stems from the idea of breaking up large amounts of work into smaller pieces. This gives product managers, developers, and any stakeholder a better understanding of the work.
敏捷是一种软件开发方法，其源于将大量工作分解为较小的部分的想法。 这使产品经理，开发人员和所有利益相关者对工作有更好的了解。
Historically, software development was a slow process where major changes to requirements could put large strains on teams.
从历史上看，软件开发是一个缓慢的过程，其中对需求的重大更改可能会对团队造成很大的压力。
When following the agile methodology, the smaller chunks of work help teams become more flexible, and dare I say agile. And in the process it helps them deliver features faster and respond to changes quicker.
当遵循敏捷方法论时，较小的工作帮助团队会变得更加灵活，我敢说敏捷 。 在此过程中，它可以帮助他们更快地交付功能并更快地响应更改。
These ideas have been broken up into different frameworks of approaching this methodology. Two of the common ones are Scrum and Kanban.
这些想法已分解为采用这种方法的不同框架。 常见的两种是Scrum和看板 。
For this walkthrough, most of these concepts follow along the Scrum framework, but there are certainly concepts that apply to both and others.
在本演练中，大多数概念都遵循Scrum框架，但是肯定有一些概念适用于所有其他概念。
您应该了解哪些概念？ (What are some concepts you should know?)
I'd argue half of being productive as a developer in an agile world is simply understanding the terms. Typically the project manager runs the show, so if you can be on the same page with what they're talking about, it will make the process a lot easier.
我认为，在敏捷世界中作为开发人员富有成效的一半只是在理解术语。 通常情况下，项目经理负责表演，因此，如果您可以将他们所谈论的内容放在同一个页面上，它将使整个过程变得容易得多。
There are books, courses, and certifications based around learning the nuances of the agile methodology. I'm not going to go deep into some of the philosophical aspects or some of the deeper parts, but I'm going to cover a good set of key concepts that will help you hit the ground running when you start your new job with an agile team.
有一些书籍，课程和认证都是基于学习敏捷方法的细微差别而制定的。 我不会深入探讨某些哲学方面或某些更深层次的内容，但是我将介绍一组很好的关键概念，这些概念将帮助您在开始新工作时从头开始。敏捷团队。
故事 (Stories)
A story is typically the smallest defined piece of work. This usually comes in the form of a new ticket that you create in the project tool you're using whether it's Jira or even Github Issues.
故事通常是定义的最小的作品。 这通常以您在使用的项目工具中创建的新票证的形式出现，无论是Jira还是Github Issues 。
表达故事 (Expressing stories)
When working on a project, you'll probably run into a variety of ways people express stories. But a good guideline is to work through the concept of the word "story" itself and explain the work that needs to be done in that way.
在进行项目时，您可能会遇到人们表达故事的各种方式。 但是，一个好的指南是通读“故事”一词本身的概念，并解释需要以此方式完成的工作。
For instance, if you would like to provide the ability for the people who use your website to share a blog post on Twitter, you may want to write the story as: As a reader, I want to share the post I just read to Twitter.
例如，如果您希望向使用您的网站的人提供在Twitter上分享博客帖子的功能，则您可能希望将故事写成：作为读者，我想分享我刚刚在Twitter上阅读的帖子。
Using that pattern of "as a [person], I want to [action]" helps provide context as what state somebody may be in when visiting their site and what they're trying to achieve. This can be particularly helpful if you're developing features for people who are logged in that are different from guests.
使用“作为[人]，我想[行动]”这种模式有助于提供上下文，作为某人在访问其站点时可能处于的状态以及他们试图实现的目标。 如果您要为已登录的访客开发与访客不同的功能，这将特别有用。
细节和要求 (Details and requirements)
While the title of a story is an important representation of the work, you'll also want to provide additional specifics.
虽然故事的标题是作品的重要代表，但您还需要提供其他细节。
At a minimum, that should be done by adding a thorough description and a set of acceptance criteria that can help give the developer context and requirements. Depending on the team, this can also include tools like tags or categorizations that make it easier for the team to visualize groups of work.
至少应通过添加详尽的描述和一组可接受的准则来完成，以帮助提供开发人员上下文和要求。 根据团队的不同，它还可以包括标签或分类之类的工具，使团队更容易可视化工作组。
Providing a strong set of requirements helps both the developer working on the story and the person reviewing it have a measurement to determine if it's actually complete. Without it, everyone's just guessing.
提供强大的需求集有助于开发故事的开发人员和审阅该故事的人员进行衡量，以确定故事是否真正完成。 没有它，每个人都只能猜测。
A good way to phrase these are: verify [requirement]. Back to my example of sharing a post on Twitter, maybe some of the requirements to that story would be:
短语的一个好方法是：验证[要求]。 回到我在Twitter上分享帖子的示例，该故事的某些要求可能是：
- Verify when clicking the share button a new tweet is created 验证单击共享按钮时，是否创建了新的tweet
- Verify the tweet includes a link to the current blog post 验证推文是否包含指向当前博客文章的链接
工作量或难度 (Amount of work or level of difficulty)
Each story is represented by a number of points. Those points are a way to express how much effort a team of developers expects one story to be. That effort can mean a variety of things though whether it's simply how difficult the team expects the work to be or the amount of risk or uncertainty a particular story has.
每个故事都由许多观点来代表。 这些观点是表达开发人员团队期望一个故事付出多少努力的一种方式。 这种努力可能意味着各种各样的事情，尽管仅仅是团队期望工作的难度，还是某个特定故事所具有的风险或不确定性的数量。
One way teams represent this is with the fibonacci sequence, where the amount of points can be 1, 2, 3, 5, 8, etc. Where a negligible text update might be 1 point, adding a new form to a page could be 3 points.
团队用斐波那契数列表示这种情况的一种方法，其中点的数量可以是1、2、3、5、8等。如果忽略不计的文本更新可能是1点，则向页面添加新表单可能是3点。
Typically you'll want to avoid pointing stories too high, as you get above 5 points, there's more than likely a way you can break up the work to make it more manageable. While you could easily create a massive 13 point story to accomplish all aspects of a feature, it usually makes sense to tackle the work in smaller, more focused chunks.
通常，您会希望避免将故事指向太高，因为当您获得高于5分的分数时，您更有可能分解工作以使其更易于管理。 尽管您可以轻松地创建一个庞大的13点故事来完成某项功能的所有方面，但通常以较小，重点突出的部分来处理工作是有意义的。
Either way, these points all add up together to give your team a rough estimate of how much work a group of stories would take to complete.
无论哪种方式，这些点都将加在一起，以使您的团队可以粗略估计一组故事需要完成多少工作。
史诗 (Epics)
While stories have a goal of defining a bite-sized piece of work, epics are a way to group those pieces of work together to represent a feature.
故事的目标是定义一口大小的作品，而史诗则是将这些作品组合在一起以代表功能的一种方式。
将故事定义为功能 (Defining stories as a feature)
A good way to explain this is with another example. If you're working on an application that requires the integration of authentication, you may want to create a new epic simply called "Authentication".
另一个例子是一个很好的解释方法。 如果您正在处理需要集成身份验证的应用程序，则可能需要创建一个新的史诗，简称为“身份验证”。
Inside that epic, you could find stories like:
在该史诗中，您可以找到类似的故事：
- As a guest, I want to sign into the application with my email address 作为来宾，我想用我的电子邮件地址登录该应用程序
- As an authenticated user, I want to change my password 作为经过身份验证的用户，我想更改密码
- As the security team, I want to prevent spam and abuse of user authentication 作为安全团队，我想防止垃圾邮件和滥用用户身份验证
With your epic defined, you're giving your team a path to calling a feature complete while also understanding the entire scope of that work. This is important when it comes to planning out the work to be done.
定义好史诗之后，您可以为团队提供一条调用功能完整的途径，同时还可以理解整个工作范围。 当计划要完成的工作时，这一点很重要。
Defining your stories in your epic gives you a sense of how much work something takes, but it doesn't help you figure out how long it would take, which is where sprints come in.
在史诗中定义您的故事可以使您了解某件事情需要多少工作，但并不能帮助您确定要花多长时间，这就是冲刺的目的。
冲刺 (Sprints)
Sprints are a way of planning out how the work will actually get done. While similar to epics in that they are a way to group chunks of work, sprints typically represent a period of time in which a particular chunk of work will be done.
冲刺是一种计划工作实际完成方式的方式。 虽然与史诗相似，因为它们是一种将工作块分组的方式，但sprint通常代表一段时间，在此期间将完成特定的工作块。
每个冲刺时间 (Time per sprint)
A common way of defining a sprint is two weeks of work. During those two weeks, your team will have a particular velocity, or average amount of work you can complete, for an individual sprint. This velocity is represented by a number of points that is a sum of the average velocity of each of the developers working on that sprint.
定义冲刺的一种常见方法是两个星期的工作。 在这两个星期中，您的团队将为单个冲刺设置特定的速度或平均可以完成的工作量。 该速度由许多点表示，这些点是在该sprint上工作的每个开发人员的平均速度之和。
每个冲刺点数 (Points per sprint)
Though many fiercely argue you shouldn't use time to represent that velocity, points will roughly translates to an average amount of time of work for each developer. While 1 point for an experienced developer could be 1 hour, that same 1 point could mean 3 hours for a less experienced developer.
尽管许多人激烈地争辩说您不应该使用时间来表示这种速度，但是积分将大致转化为每个开发人员的平均工作时间。 对于有经验的开发人员来说1分可能是1个小时，而对于没有经验的开发人员来说，同样的1分可能意味着3个小时。
But once you have this number of points that your team averages in a sprint, you'll know how many story points you can expect to plan to be completed. This planning goes sprint to sprint as you spread out a group of stories or an epic so you can predict when a feature will be complete.
但是，一旦您拥有团队在冲刺中平均的分数，您就会知道可以预期完成多少故事点。 当您散布一组故事或史诗时，此计划会不断进行，因此您可以预测功能何时完成。
敏捷如何适合您的团队 (How agile fits with your team)
Try to remember that the Agile methodology through Scrum, Kanban, or any other framework is just that – a framework. While it's probably a good idea to follow the process when you first start out, listen to your team and try to mold it to your own experiences.
尝试记住，通过Scrum，看板或任何其他框架进行的敏捷方法论只是一个框架。 刚开始时遵循该过程可能是一个好主意，请听取您的团队意见，并尝试根据自己的经验来塑造它。
Each team works a little bit differently and forcing a process onto that team can cause more harm than good, but there will always be a learning curve for any process. Fight the eye rolls until everyone gets the hang of it and have frequent retrospectives to see what works and what doesn't.
每个团队的工作方式略有不同，强加于该团队的过程可能弊大于利，但任何过程始终存在学习曲线。 努力奋斗，直到所有人都掌握了眼力，并经常进行回顾，以查看有效的方法和无效的方法。
At the end of the day, the processes your team follows should mostly be invisible, working for you instead of against you. Find what works best for your team and share your experiences for others to learn!
归根结底，团队所遵循的流程大部分应该是不可见的，为您服务而不是不利于您。 找到最适合您的团队的经验，并分享您的经验供他人学习！
您的团队正在处理什么？ (What's your teams process?)
翻译自: https://www.freecodecamp.org/news/what-is-agile-and-how-youcan-become-an-epic-storyteller/
敏捷史诗故事是什么
3455
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
