每日scrum站会的时间_Scrum仪式：每日站立

每日scrum站会的时间

The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.

以下是摘自M. David Green的《 Scrum：Ninja的新手》一书的摘录。 副本在世界各地的商店中都有出售，或者您可以在此处以电子书形式购买 。

每日站立 (Daily Standup)

The daily standup is probably the first ritual that comes to mind when people think of scrum. The daily standup provides a heartbeat for the team, giving everybody a regular opportunity to get a clear picture of what other people on the team are working on, and what the status of the project as a whole is.

当人们想到Scrum时，每天的站起来可能是第一个仪式。 日常站立为团队提供了心跳，使每个人都有定期的机会清楚地了解团队中其他人正在从事的工作以及整个项目的状况。

目的 (Objective)

The purpose of the daily standup is to give everybody on the team an opportunity to share the status of the work they’re doing, and get help if anything is blocking their progress. Everyone on the team should pay attention as their teammates report, so they can have a clear picture of the status of the complete iteration they’re all working on.

日常站立的目的是使团队中的每个人都有机会分享他们正在做的工作的状态，并在遇到任何阻碍他们进步的情况时获得帮助。 团队中的每个人都应在队友报告时注意，以便他们可以清楚地了解他们正在进行的完整迭代的状态。

This is also an opportunity for anybody outside the team who’s interested in knowing what the team is working on to find out how stories are progressing, and what’s likely to be worked on next. Only team members are allowed to present at the daily standup, but anybody in the company may attend, and visitors should be invited to participate as silent observers.

这对于团队之外的任何人来说都是一个机会，他们有兴趣知道团队在做什么，以了解故事的进展情况，以及下一步可能会做什么。 每天只允许团队成员出席站立会议，但公司中的任何人都可以参加，并且应邀请访客以沉默的观察者身份参加。

传统上，每日站立时间限制为15分钟。 这是一个简短的仪式，并且保持简短且尽可能方便，以便每个人都可以承诺在场，积极参与并在其他人讲话时留神。 希望每个人都站起来，既要引起他们的注意，又要鼓励所有参与者发挥作用，使仪式简短而集中。 大多数团队都试图将站立的姿势从办公桌前移开，并劝阻人们在仪式期间使用笔记本电脑和其他设备。

注意：保持站立状态

Scrum负责人将每日站立的时间保持在15分钟的时间范围内，但是团队中的每个人都应该感到有能力执行站立的规则，因此时间框不会被打破。 这包括确保每个人都准时开始，专心，不允许客人打扰。

不同的团队会选择一天中的不同时间来站起来。 通常，早上或午餐前的第一件事可能是个好时机。 这些是一天中的自然休息，通常对于团队中的大多数人来说都是常见的，因此15分钟的站立时间不会中断更长的编程时间所需的焦点。

对于不在同一地点的团队，找到适合每个人的时间可能是一个挑战，尤其是当团队中的某些成员位于不同时区时。 任何人都不应定期错过站立比赛，但只要满足日常站立比赛的目标，总会有灵活性的余地。 即使不是每个人都可以站起来，Scrum主管也应该为在那里的任何人保留仪式。

有时，团队可能需要提出自己的系统，并从sprint到sprint进行反射式迭代。 重点应该放在保持简短的仪式上，可靠地进行维护，并确保它们提供预期的价值而不会造成不必要的干扰。

站立时，每个团队成员都应该在场并可以使用。 唯一必要的准备工作是让每个团队成员考虑如何以一种对所有人都清晰易懂的方式介绍当前正在完成的工作。 如果团队成员有与团队之外的人相关的阻碍因素，那么让这些人知道准备好在站起来之后立即讨论问题是合理的。

站起来之前，Scrum管理员无需进行任何特殊准备。 一个好的Scrum管理员可以在站立之前检查正在处理的故事的状态，以查看是否有任何更改待解决，或者可以安排将Scrum管理员认为通常不应该参加的任何客人聚集起来。

三个问题

日常站立的核心包括Scrum主管围绕团队并向每个人询问三个问题：

• 自上次站起来以来，你做了什么？

• 在下一次站起来之前，您打算做什么？

• 有什么阻碍您前进的吗？

它应该就这么简单。 团队中的每个成员都会回答这些问题中的每一个，最后一个人完成报告后，双方的立场就结束了。 除非Scrum主管需要为整个团队发布紧急公告，否则与参与站立的其他人没有特定业务的所有人都应该可以自由地重新开始工作。

警告：当心站立的客人

人们经常以脱口秀的形式作为客人来提问，介绍新信息或发起与整个团队无关的讨论。 不是开发团队成员的任何人都不应在站立时讲话。 Scrum管理员需要坚决抑制这种行为。 在这方面，组织等级较高的人员不会得到特殊待遇。 每个人都需要尊重工程师的时间和精力，并让他们尽快恢复工作。

在回答站立问题时，每个工程师都需要准备简洁的说明，说明他们的工作，下一步计划进行的工作以及是否有障碍物。 这是一项需要练习的技能，Scrum主管应准备好指导每个团队成员如何以最佳方式利用这些时间来回答这些问题。

如果一个人的报告引起了一些来回讨论，并且对话与整个团队都息息相关，那么Scrum管理员可以允许它。 但是必须限制这种类型的交互，以尊重站立的时间。 如果对话超出几句话，Scrum主管应介入并建议将对话脱机。 优秀的Scrum管理员将在站立会议结束时跟踪需要进行哪些对话，并随后跟踪他们的状态。

其他状态更新

一些团队选择在每日站立时在团队共享的Scrum板上更新其故事的状态，而另一些团队则喜欢在故事完成后单独进行操作。 无论哪种情况，站起来都应该是一个机会，以确保每个人都更新了他们正在处理的所有东西的状态，并且团队中的每个人都知道其他人正在做什么。

对于正在进行结对编程的团队来说，站起来可以是切换结对或交换故事的机会。 一些配对的团队更喜欢每个故事都有一个工程师从头到尾地进行观察。 允许团队中的多个人结对同一个故事对团队的灵活性可能是有益的，尤其是在涉及到一些值得共享信息的核心功能的情况下。 不同的团队会提出不同的方法，但是站起来是每天进行更改的好地方。

站起来也是团队成员相互交流的良机，他们是否希望在下一次站起来之前完成一个故事，以及他们是否有休假时间。 知道团队中其他人的可用性可以激发队友围绕即将发生的故事计划他们的工作，并安排换对或适当分配资源。

注意：下一步要做什么？

如果工程师不清楚下一步应该做什么，则sprint待办事项的优先级应指导这些决策。 产品负责人负责整理整个sprint中的sprint积压，并确保它始终代表应处理故事的优先级。

除非有令人信服的技术原因，否则任何没有当前故事的工程师都应开始处理积压的故事，无论其专业化程度如何，都将其放在第二位。 遵循这种模式可以为工程师提供一个机会，让他们与经验较少的领域的人员结对，并帮助在整个团队中传播有关整个代码库的知识。

最后，Scrum主管可以在站立会议结束时发布与整个团队相关的公告，前提是每个人都有机会举报，前提是还有时间。 这不能替代任何可能由公司会议，团队午餐和其他聚会而来的组织团队建设。

(

Traditionally, the daily standup is limited to 15 minutes. It’s a short ritual, and it’s kept short and made as convenient as possible so that everyone can commit to being present, participating actively, and paying attention while other people are speaking. Everyone is expected to stand, both so that they pay attention, and to encourage all participants to play their part in keeping the ritual short and focused. Most teams try to hold the standup away from their desks, and discourage people from using laptops and other devices during the ritual.

Note: Keeping the Standup to Time

Keeping the daily standup within its 15 minute time box is the responsibility of the scrum master, but everybody on the team should feel empowered to enforce the rules of the standup, so the time box doesn’t get broken. That includes making sure everybody starts on time, pays attention, and doesn’t allow interruptions from guests.

Different teams will choose different times of day to hold the stand up. Often first thing in the morning, or right before lunch, can be good times. These are natural breaks in the day that are usually common to most people on the team, so a 15 minute standup won’t disrupt the focus needed for longer blocks of programming time.

Finding a time that works for everybody can be challenging for teams that aren’t co-located, especially when some members of the team are in different time zones. Nobody should be allowed to miss the standup on a regular basis, but there’s always room for flexibility, as long as the objectives of the daily standup are being met. Even if not everybody can make it to a specific standup, the scrum master should keep the ritual for anyone who is there.

Sometimes teams may need to come up with their own systems, and iterate on these reflectively from sprint to sprint. The priority should be on keeping the rituals brief, maintaining them reliably, and making sure they provide the intended value without creating undue interruption.

Every team member should be present and available at the time of the standup. The only preparation necessary is for each team member to think about how to present the work being done at the moment in such a way that it’ll be clear and understandable to everybody. if a team member is having blockers that relate to people outside the team, it’s reasonable to let those people know to be prepared to discuss the issue immediately after the standup.

There’s no special preparation needed by the scrum master before the standup. A good scrum master may check the status of the stories being worked on before the standup, to see if any changes are pending, or may arrange to round up any guests the scrum master thinks should be there who don’t normally attend.

Three Questions

The core of the daily standup consists of the scrum master going around the team and asking every person three questions:

• What have you done since the last stand up?

• What do you plan to do until the next standup?

• Is there anything blocking your progress?

It should be as simple as that. Every member of the team answers each one of these questions, and once the last person has finished reporting, the standup is over. Unless the scrum master has urgent announcements that need to be made for the entire team, everyone who doesn’t have specific business with another person attending the standup should be free to get back to work.

Warning: Beware Guests at Standups

There’s a strong tendency for people attending standups as guests to ask questions, introduce new information, or start discussions that don’t relate to the entire team. Anyone who isn’t a member of the development team shouldn’t be speaking during standup. The scrum master needs to be strong about suppressing this kind of behavior. People of high rank in the organizational hierarchy don’t get special treatment in this regard. Everyone needs to respect the time and attention of the engineers, and allow them to get back to work as quickly as possible.

In answering the questions of the standup, each engineer needs to be prepared with a succinct description of what they’ve worked on, what they plan to work on next, and whether they have any blockers. This is a skill that takes practice, and the scrum master should be prepared to coach every team member on how to answer these questions in a way that makes the best use of the time available.

If one person’s report invites a little bit of back-and-forth discussion, and the conversation has relevance for the entire team, the scrum master may permit it. But this type of interaction must be limited to respect the time box of the standup. If the conversation gets beyond a few sentences, the scrum master should step in and suggest that the conversation be taken off-line. A good scrum master will keep track of what conversations need to happen at the end of the standup, and follow up on their status afterward.

Other Status Updates

Some teams choose to update the status of their stories on the team’s shared scrum board during the daily standup, while others prefer to do it individually as the stories get completed. In either case, the standup should be an opportunity to make sure everybody has updated the status of everything they’re working on, and that everybody on the team is aware of what everybody else is working on.

For teams that are doing pair programming, the standup can be an opportunity to switch pairs, or switch stories. Some teams that do pairing prefer that every story have one engineer seeing it through from beginning to end. It can be beneficial for the flexibility of the team to allow multiple people to pair on the same story, particularly if it relates to some core functionality that’s worth sharing information about. Different teams will come up with different approaches, but the standup is a good place to make changes on a daily basis.

Standups are also a good opportunity for team members to let each other know if they expect to complete a story before the next standup, and if they have vacation time coming up. Knowing the availability of other people on the team can inspire teammates to plan their work around upcoming stories, and arrange to switch pairs or allocate resources appropriately.

Note: What to work on next?

If an engineer is unclear about what should be worked on next, the priority of the sprint backlog should guide these decisions. The product owner is responsible for grooming the sprint backlog throughout the sprint, and making sure that it always represents the priority in which the stories should be addressed.

Unless there’s a compelling technical reason, any engineer without a current story should start working on the story at the top of the backlog with the next highest priority, regardless of specialization. Following this pattern can provide an opportunity for engineers to pair with somebody in an area where they have less experience, and help spread knowledge about the entire code base throughout the team.

Finally, the scrum master may make announcements that have relevance to the entire team at the end of the standup—once everybody has had a chance to report, and only if there’s time left. This shouldn’t become a replacement for any organizational team building that may come from company meetings, team lunches, and other gatherings.

)

翻译自: https://www.sitepoint.com/scrum-rituals-daily-standup/

每日scrum站会的时间