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的新手》一书的摘录。 副本在世界各地的商店中都有出售，或者您可以在此处以电子书形式购买 。
If you picked up this book to learn about applying scrum to your web or mobile development team, you may already be familiar with the terms scrum and agile. Perhaps you received this book from your company, or maybe you’ve been tasked with implementing an agile process in your own organization. Whatever the reason, it’s always useful to start with a clear, shared definition of the relevant terms.
如果您读了这本书以了解有关将Scrum应用于Web或移动开发团队的信息，则您可能已经熟悉术语Scrum和Agile。 也许您是从公司那里收到这本书的，或者您的任务是在自己的组织中实施敏捷过程。 无论出于何种原因，从清晰，共享的相关术语定义开始总是很有用的。
Scrum is one of several techniques for managing product development organizations, lumped under the broad category of agile software development. Agile approaches are designed to support iterative, flexible, and sustainable methods for running a product engineering organization.
Scrum是管理产品开发组织的几种技术之一，属于敏捷软件开发的大类。 敏捷方法旨在支持运行产品工程组织的迭代，灵活和可持续的方法。
Among the various agile techniques, scrum is particularly well suited to the types of organizations that develop products such as websites and mobile software. The focus on developing cohesive, modular, measurable features that can be estimated relatively, tracked easily, and that may need to adapt quickly to changing market conditions makes scrum particularly appropriate for these types of projects.
在各种敏捷技术中，scrum特别适合开发网站和移动软件等产品的组织类型。 专注于开发具有凝聚力，模块化，可测量的功能，这些功能可以相对估计，轻松跟踪，并且可能需要快速适应不断变化的市场状况，这使得Scrum特别适合这些类型的项目。
Scrum encourages teams to work in a focused way for a limited period of time on a clearly defined set of features, understanding that the next set of features they may be asked to work on could be unpredictable because of changes in the marketplace, feedback from customers, or any number of factors. Scrum allows teams to develop an improved ability to estimate how much effort it will take to produce a new feature in a relative way, based on the work involved in features they’ve developed before. And scrum creates the opportunity for a team to reflect on the process and improve it regularly, bringing everybody’s feedback into play.
Scrum鼓励团队在有限的时间内集中精力使用一组明确定义的功能，并了解由于市场的变化，客户的反馈，可能要求他们使用下一组功能的原因是不可预测的，或许多因素。 Scrum允许团队开发一种改进的功能，以基于他们以前开发的功能所涉及的工作来估算以相对方式生成新功能将花费的精力。 Scrum为团队创造了机会来反思和定期改进流程，使每个人的反馈都可以发挥作用。
A familiar anti-pattern in non-agile organizations looking to mask their process problems is using the terminology of scrum as a labeling system on top of their waterfall techniques and tools. That can create confusion, and even negative associations among people who have seen these terms used incorrectly, and who mistakenly believe they’ve seen scrum in action.
希望掩盖其过程问题的非敏捷组织中一种熟悉的反模式是将scrum术语用作其瀑布技术和工具之上的标记系统。 这可能会造成混淆，甚至会在看到这些术语使用不当，错误地认为自己看到了行动混乱的人们之间产生消极的联想。
As we go through this book, you’re going to find out more about how scrum functions. You’re going to be introduced to all of the aspects of scrum, including its rituals, its artifacts, and the roles that it creates for the people in an organization. We’re going to introduce you to a team of people working in a scrum environment, and show you how they adopted scrum in the first place, and how they adapted to it.
在阅读本书时，您将发现更多有关Scrum功能的信息。 您将被介绍到Scrum的所有方面，包括它的仪式，工件以及它为组织中的人员创建的角色。 我们将向您介绍一个在Scrum环境中工作的团队，并向您展示他们如何首先采用Scrum以及他们如何适应Scrum。
Before we get there, it’s worthwhile taking a moment to position scrum in its historical context. After all, scrum isn’t the only way to organize product development. Scrum came into existence right around the time that web development emerged on the engineering landscape, and it flourished as mobile technology became part of our daily lives. If you consider how scrum works, where it came from, and how we apply it, I think you’ll see that there might be a reason for that.
在到达那里之前，值得花点时间将Scrum定位于其历史背景中。 毕竟，scrum并不是组织产品开发的唯一方法。 当Web开发出现在工程领域时，Scrum就诞生了，随着移动技术成为我们日常生活的一部分，Scrum蓬勃发展。 如果您考虑Scrum的工作原理，来源以及我们如何应用它，我想您会发现这可能是有原因的。
The vocabulary of scrum is distinctive, and may sound odd. That’s intentional. Scrum uses terms such as ritual, artifact, and story to make it clear that these concepts are different from related ideas that may be encountered in other project management approaches.
Scrum的词汇很独特，听起来可能很奇怪。 那是故意的。 Scrum使用仪式，人工制品和故事等术语来明确说明这些概念与其他项目管理方法中可能遇到的相关概念不同。
The original concept for scrum came out of Japan, introduced in 1986 as part of The New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka. They applied the concept of a scrum, taken from the team game rugby, to describe cross-functional team organization based around moving forward in a layered approach.
Scrum的原始概念来自日本，于1986年在竹内弘隆和野中郁次郎的“新产品开发游戏”中引入。 他们应用了从团队游戏橄榄球中获得的Scrum概念，来描述跨职能的团队组织，该组织围绕着以分层的方式前进。
Their concepts were codified as the Scrum Methodology at a joint presentation in 1995 by Ken Schwaber and Jeff Sutherland, based on their personal experiences applying the concepts in their own organizations. This work inspired the 2001 book, Agile Software Development with Scrum, written by Schwaber and Mike Beedle.
他们在1995年由Ken Schwaber和Jeff Sutherland联合发表的演讲中将他们的概念编为Scrum方法论，这是基于他们在自己的组织中应用概念的个人经验。 这项工作启发了Schwaber和Mike Beedle在2001年出版的《 用Scrum进行敏捷软件开发》一书。
At the time, the most prevalent approach for software development was called the waterfall model. Under the waterfall model, product development happens in stages, leading sequentially from requirements through design, implementation, and release. Until the 1990s, most software development was targeted at packaged software delivery for desktop computers. Such products had long development and release cycles. While waterfall is well-suited to products that have a long development trajectory, it doesn’t adapt well to situations where the product needs to change constantly in response to changing conditions.
当时，最流行的软件开发方法称为瀑布模型 。 在瀑布模型下，产品开发是分阶段进行的，从需求到设计，实施和发布依次进行。 直到1990年代，大多数软件开发都针对台式计算机的打包软件交付。 这样的产品具有较长的开发和发布周期。 虽然Waterfall非常适合具有长发展轨迹的产品，但它不能很好地适应产品因应不断变化的条件而需要不断变化的情况。
In the mid-to-late 1990s, new publishing models emerged involving electronic media and the Internet. To support these, software development organizations had to incorporate more flexibility to adapt to changing browsers, tight media deadlines, and a variety of platforms with different requirements. Soon after that, the development of large monolithic software applications that lived on desktop computers gave way to smaller, more nimble apps that were delivered through mobile devices. A different approach was needed for developing these.
在1990年代中后期，出现了涉及电子媒体和互联网的新出版模式。 为了支持这些，软件开发组织必须具有更大的灵活性，以适应不断变化的浏览器，紧迫的媒体截止日期以及具有不同要求的各种平台。 此后不久，生活在台式计算机上的大型整体软件应用程序的开发就让位给了通过移动设备交付的更小，更灵活的应用程序。 开发这些需要不同的方法。
It isn’t a coincidence that agile approaches became codified, and quickly became popular, just as the marketplace was shifting from desktop software to web and mobile software.
敏捷方法变得规范化并Swift流行起来，这并不是一个巧合，就像市场正在从台式机软件转向Web和移动软件一样。
The slow cycle of waterfall development may still be appropriate in a world of hardware development, or even in gaming. These industries rely on long, stable markets, where many of the decisions are either repetitive, constrained by external resources, or need to be made far in advance because of the massive scale and expense of development.
瀑布式开发的缓慢周期可能仍然适用于硬件开发甚至游戏领域。 这些行业依赖长期稳定的市场，在这些市场中，许多决定都是重复性的，受到外部资源的约束，或者由于规模庞大且开发成本高昂而需要提前做出决定。
Web and mobile technology moves too fast for a waterfall approach. By the time you’re done developing a solution to one problem and gathering feedback from users, the technology has already moved on, and you may have a very small window of opportunity to capitalize on your solution.
对于瀑布式方法，Web和移动技术发展太快。 当您完成针对一个问题的解决方案并收集用户反馈时，该技术已经开始发展，您可能只有很小的机会可以利用您的解决方案。
In a waterfall approach, the ideas for what needs to be developed may come from customers, from the executives, from market research, or from the imagination of people making the decisions and setting the budgets. Those ideas are passed on to product managers, who create a long product roadmap. They establish and collect requirements, write out classic product requirement documents, and then pass those requirements on to designers to create prototypes as wireframes and mockups. Those prototypes are passed on to an engineering team that implements those ideas, and produces a product that can finally be released to the marketplace. Until that product is released and put in the hands of customers, no feedback into the process is generated.
在瀑布式方法中，关于需要开发什么的想法可能来自客户，高管，市场研究或做出决策并制定预算的人们的想象力。 这些想法会传递给产品经理，后者会制定长期的产品路线图。 他们建立并收集需求，写出经典的产品需求文档，然后将这些需求传递给设计师，以创建线框和模型的原型。 这些原型被传递给实施这些构想的工程团队，并生产出最终可以投放市场的产品。 在该产品发布并交付客户之前，不会对流程产生任何反馈。
In an agile organization, guiding objectives and key performance indicators guide the process, but the team manages itself to meet those objectives. A product owner maintains the overall vision, and works with the scrum master to make sure that everyone on the team is clear about the objectives and how they’ll be measured. The input of the designers and the engineers is included at every stage in this process. Features are conceived and formulated into stories when the team is ready to work on them. No idea gets locked into a static product timeline.
在敏捷组织中，指导目标和关键绩效指标指导流程，但是团队要自我管理以实现这些目标。 产品负责人维护了总体愿景，并与Scrum主管合作，以确保团队中的每个人都清楚目标以及如何衡量目标。 在此过程的每个阶段都包含了设计师和工程师的意见。 当团队准备进行工作时，就将功能构思并编入故事中。 没有任何想法被锁定在静态的产品时间表中。
The value to a company of hiring its own team of designers and engineers is that these people can bring their design thinking and their current technical knowledge to the table for the benefit of the organization’s own objectives. Designers should be evaluating the user experience and figuring out the best solutions to real customers’ problems, not decorating bad ideas to make them functional.
对于一家公司而言，雇用自己的设计师和工程师团队的价值在于，这些人可以将他们的设计思想和当前的技术知识带到餐桌上，以实现组织自身的目标。 设计师应该评估用户体验，并为实际客户的问题找出最佳解决方案，而不是修饰坏主意以使其发挥作用。
Getting engineers involved in ideation allows them to pull in the latest technology as early as possible, since they’re in the best position to know what’s technically feasible. The sooner the designers and engineers are brought into the planning process, the more agile development will be.
让工程师参与构想可以使他们尽早采用最新技术，因为他们最有资格知道什么在技术上可行。 设计师和工程师越早进入规划过程，开发就越敏捷。
Scrum allows the full resources of the team to be applied when and where they can do the most good, and to work together in a sustainable and productive way. Instead of waiting until the entire cycle has completed before any data can be fed back into the system, ideas are generated at every stage, and encouraged to bubble to the surface at the end of each sprint. Total participation of the team in every stage of the process allows these ideas to feed into the objectives, and support the vision of the organization.
Scrum允许团队的全部资源被应用在他们能够最大程度地发挥作用的时间和地点，并以可持续和高效的方式进行合作。 可以在每个阶段生成想法，并鼓励他们在每个sprint结束时冒出气泡，而不是等到整个周期完成之后再将任何数据反馈到系统中。 团队在流程的每个阶段的全面参与使这些想法能够融入目标并支持组织的愿景。
While some organizations may claim to follow scrum, many of them actually follow a modified waterfall approach, using scrum techniques only for development. The rest of the organization structures itself around long-lived product timelines with static objectives. While that may be an improvement over pure waterfall, in that it allows the engineers to iterate and improve their process, it doesn’t take full advantage of the potential of scrum. Isolating scrum inside the development loop without inviting the learnings of the team into the planning and market testing process is a waste of resources, and a wasted opportunity.
尽管某些组织可能声称遵循Scrum，但许多组织实际上遵循修改后的瀑布方法，仅将Scrum技术用于开发。 该组织的其余部分根据具有固定目标的长期产品时间表来构造自己。 尽管这可能是对纯瀑布的一种改进，但它允许工程师迭代和改进其过程，但并未充分利用scrum的潜力。 在开发循环中孤立混乱，而没有邀请团队的知识参与计划和市场测试过程，这既浪费资源，又浪费了机会。
Mixing a little scrum into an otherwise waterfall organization is usually not a good idea, since it can draw attention to the fundamental conflicts between the different approaches, and foster friction.
将少量Scrum混入原本属于瀑布式组织中通常不是一个好主意，因为它可以引起人们对不同方法之间基本冲突的关注，并加剧摩擦。
翻译自: https://www.sitepoint.com/a-brief-introduction-to-scrum/
scrum
相关资源：jdk-8u281-windows-x64.exe