Scrum方法指南：敏捷项目管理实践

Project
Management
Scrum
4星 · 超过85%的资源 需积分: 33 24 下载量 181 浏览量 更新于2024-07-30 2 收藏 2.43MB PDF 举报
"Agile Project Management With Scrum" 是由 Ken Schwaber 所著的一本关于敏捷项目管理的权威书籍，特别关注 Scrum 方法论在软件项目管理中的应用。这本书于2007年由世界图书出版公司在中国上海出版，被誉为Scrum领域的经典之作。 Scrum 是一种敏捷开发框架，它强调迭代和增量式开发，以适应快速变化的需求，并通过团队协作提高生产效率。在本书中，Ken Schwaber 阐述了Scrum的核心原则、角色、过程和实践，帮助项目团队聚焦于提供真正的商业价值。 书中的章节涵盖了以下关键知识点： 1. **前言**：介绍了敏捷项目管理与Scrum的背景，以及为何选择Scrum作为应对复杂软件项目的解决方案。 2. **引言**：概述了Scrum的基本理念，以及在软件开发中的重要性。 3. **第1章 - 背景：Scrum的科学**：详细解释了Scrum的起源和科学基础，包括它如何应对传统项目管理的挑战。 4. **第2章 - 新的管理职责**：探讨了在Scrum中管理者角色的变化，特别是如何转变管理方式以支持敏捷流程。 5. **第3章 - Scrum主管（Scrum Master）**：阐述了Scrum Master的角色，他们是团队的教练和守护者，确保Scrum框架的正确执行。 6. **第4章 - 从混乱中带来秩序**：讲解了如何在项目开始时建立结构，包括定义产品待办事项列表（Product Backlog）和迭代待办事项列表（Sprint Backlog）。 7. **第5章 - 产品负责人（Product Owner）**：说明产品负责人的职责，他们负责明确需求，优先级排序，并与利益相关者沟通。 8. **第6章 - 规划Scrum项目**：介绍如何进行敏捷规划，包括 sprint 的设定、估算和计划会议。 9. **第7章 - 项目报告：保持一切可见**：讨论了Scrum中透明度的重要性，以及如何通过看板和其他工具进行有效的进度报告。 10. **第8章 - 团队**：强调团队自组织和协作的关键性，以及如何培养高效的Scrum团队。 11. **第9章 - 使用Scrum扩展项目**：探讨了如何在大型或多团队环境中应用Scrum，以实现规模化敏捷。 12. **附录**：包含了Scrum的规则、定义、资源以及关于固定价格、固定日期合同和能力成熟模型（CMM）的相关讨论。 这本书对于理解Scrum方法和实施敏捷项目管理具有很高的价值，不仅适用于项目经理，也适用于开发人员、产品经理和其他项目团队成员，有助于他们理解和实践敏捷开发的核心原则。通过学习本书，读者能够掌握如何运用Scrum来应对不断变化的需求，提高软件开发的效率和质量。

Agile Project Management with Scrum

2007-11-24 上传
Foreword: Why Scrum Works
Suppose I’m traveling from Chicago to Boston by airplane. Before and during the flight, the pilot gets instructions from air traffic control. We take off on command and follow the prescribed route. Once we are in the air, computers predict almost to the minute when we will land in Boston. If things change—say the air is bumpy—the pilot must get permission to move to a different altitude. As we approach the airport, the pilot is told what runway to land on and what gate to go to.

If, however, I set out for Boston in a car, I can take whatever route I want, whenever I want. I don’t know exactly when I’ll get there, and I probably haven’t planned what route I’ll take or where I’ll stop for the night. En route, I follow traffic laws and conventions: I stop at red lights, merge into traffic according to the prevailing customs, and keep my speed consistent with the flow. In an automobile, I am an independent agent, making decisions in my own best interests framed by the rules of the game of driving.

It’s amazing to me that thousands upon thousands of people travel by car every day, accomplishing their goals in a framework of simple traffic rules, with no central control or dispatching service. It also amazes me that when I want to ship a package, I can enter a pickup request on the shipper’s Web site and a driver will arrive at my door before the time that I specify. The driver isn’t dispatched to each house; he or she receives a continually updated list of addresses and deadlines. It’s the driver’s job to plot a route to get all the packages picked up on time.

As complexity increases, central control and dispatching systems break down. Some might try valiantly to make the control system work by applying more rigor, and indeed that works for a while. But the people who prevail are those who figure out how to change to a system of independent agents operating under an appropriate set of rules. It might work to provide same-day delivery with a dispatch system that plans a driver’s route at the beginning of the day. However, it is far more difficult to preplan a pickup route when customers can enter pickup requests at any time. Taxi companies sort things out at a central control center. Some shipping companies send the request to the driver responsible for the area and let the driver determine the best route based on current conditions and other demands.

The more complex the system, the more likely it is that central control systems will break down. This is the reason companies decentralize and governments deregulate—relinquishing control to independent agents is a time- honored approach to dealing with complexity. Scrum travels this well-trodden path by moving control from a central scheduling and dispatching authority to the individual teams doing the work. The more complex the project, the more necessary it becomes to delegate decision making to independent agents who are close to the work.

Another reason that Scrum works is that it dramatically shortens the feedback loop between customer and developer, between wish list and implementation, and between investment and return on investment. Again, complexity plays a role here. When a system is simple, it’s not so hard to know in advance what to do. But when we are dealing with a market economy that changes all the time and with technology that won’t stand still, learning through short cycles of discovery is the tried-and-true problem-solving approach.

We already know this. We try out various marketing campaigns and discover which approach works. We simulate vehicle behavior during car design to discover the best slope of the hood and best distribution of weight. Virtually all process-improvement programs use some version of the Deming cycle to study a problem, experiment with a solution, measure the results, and adopt proven improvements. We call this fact-based decision making, and we know that it works a lot better than front-end-loaded predictive approaches.

Scrum is built on 30-day learning cycles that prove complete business concepts. If we already know everything and have nothing to discover, perhaps we don’t need to use Scrum. If we need to learn, however, Scrum’s insistence on delivering complete increments of business value helps us learn rapidly and completely. One of the reasons complete increments are important is that partial answers often fool us into thinking that an approach will work, when in reality, the approach doesn’t work upon closer examination. We know that until software is tested, integrated, and released to production, we can’t really be sure that it will deliver the intended business value. Scrum forces us to test and integrate our experiments and encourages us to release them to production, so that we have a complete learning cycle every 30 days.

Scrum doesn’t focus on delivering just any increment of business value; it focuses on delivering the highest priority business value as defined by the customer (Product Owner). The Product Owner and the Team confer about what that definition is, and then the Team decides what it can do in 30 days to deliver high-priority business value. Thus the short feedback loop becomes a business feedback loop—Scrum tests early and often whether the system being developed will deliver value and exactly what that value will look like. This allows the system to be molded over time to deliver value as it is currently understood, even as it helps to develop a better understanding of that value.

Another reason Scrum works is that it unleashes the brainpower of many minds on a problem. We know that when things go wrong, there are people around who knew there was a problem, but somehow their ideas were overlooked. For example, when the space shuttle disintegrated on reentry, a widely reported interpretation of the causes of the disaster suggests that there were engineers who were well aware that there could be a problem, but they were unable to get their concerns taken seriously. What management system can we use to leverage the experience, ideas, and concerns of the people closest to the work to be done?

According to Gary Convis, president of Toyota Motor Manufacturing Kentucky, the role of managers in a healthy, thriving, work environment is “to shape the organization not through the power of will or dictate, but rather through example, through coaching and through understanding and helping others to achieve their goals.[1]

Scrum turns small teams into managers of their own fate. We know that when we are responsible for choosing our own driving route to Boston, we will find a way to get there. We will detour around construction and avoid rush hour traffic jams, making decisions on the fly, adapting to the independent decisions of all of the other drivers out there. Similarly, Scrum Teams accept a challenge and then figure out how to meet that challenge, detouring around roadblocks in creative ways that could not be planned by a central control and dispatching center.

If teams are of a size that encourages every member to participate, and team members feel like they are in control of their own destiny, the experience, ideas, and concerns of individual members will be leveraged, not squelched. When team members share a common purpose that everyone believes in, they will figure out how to achieve it. When teams understand and commit to delivering business value for their customers, when they are free to figure out how to perform tasks, and when they are given the resources they need, they will succeed.

Gary Convis notes that Toyota’s sustainable success comes from an “interlocking set of three underlying elements: the philosophical underpinnings, the managerial culture and the technical tools. The philosophical underpinnings include a joint [worker], customer-first focus, an emphasis on people first, a commitment to continuous improvement…. The managerial culture…is rooted in several factors, including developing and sustaining a sense of trust, a commitment to involving those affected by first, teamwork, equal and fair treatment for all, and finally, fact-based decision making and long-term thinking.[2]

Scrum works for all the same reasons. Its philosophical underpinnings focus on empowering the development team and satisfying customers. Its managerial culture is rooted in helping others achieve their goals. Its technical tools are focused on making fact-based decisions through a learning process. When all of these factors are in place, it’s hard for Scrum not to succeed.

—Mary Poppendieck
Poppendieck.LLC

project management with scrum

2009-05-21 上传
scrum项目管理经典书籍, 最佳实践指南!

Agile.Project.Management.with.Scrum

2007-04-18 上传
Foreword: Why Scrum Works
Suppose I’m traveling from Chicago to Boston by airplane. Before and during the flight, the pilot gets instructions from air traffic control. We take off on command and follow the prescribed route. Once we are in the air, computers predict almost to the minute when we will land in Boston. If things change—say the air is bumpy—the pilot must get permission to move to a different altitude. As we approach the airport, the pilot is told what runway to land on and what gate to go to.

If, however, I set out for Boston in a car, I can take whatever route I want, whenever I want. I don’t know exactly when I’ll get there, and I probably haven’t planned what route I’ll take or where I’ll stop for the night. En route, I follow traffic laws and conventions: I stop at red lights, merge into traffic according to the prevailing customs, and keep my speed consistent with the flow. In an automobile, I am an independent agent, making decisions in my own best interests framed by the rules of the game of driving.

It’s amazing to me that thousands upon thousands of people travel by car every day, accomplishing their goals in a framework of simple traffic rules, with no central control or dispatching service. It also amazes me that when I want to ship a package, I can enter a pickup request on the shipper’s Web site and a driver will arrive at my door before the time that I specify. The driver isn’t dispatched to each house; he or she receives a continually updated list of addresses and deadlines. It’s the driver’s job to plot a route to get all the packages picked up on time.

As complexity increases, central control and dispatching systems break down. Some might try valiantly to make the control system work by applying more rigor, and indeed that works for a while. But the people who prevail are those who figure out how to change to a system of independent agents operating under an appropriate set of rules. It might work to provide same-day delivery with a dispatch system that plans a driver’s route at the beginning of the day. However, it is far more difficult to preplan a pickup route when customers can enter pickup requests at any time. Taxi companies sort things out at a central control center. Some shipping companies send the request to the driver responsible for the area and let the driver determine the best route based on current conditions and other demands.

The more complex the system, the more likely it is that central control systems will break down. This is the reason companies decentralize and governments deregulate—relinquishing control to independent agents is a time- honored approach to dealing with complexity. Scrum travels this well-trodden path by moving control from a central scheduling and dispatching authority to the individual teams doing the work. The more complex the project, the more necessary it becomes to delegate decision making to independent agents who are close to the work.

Another reason that Scrum works is that it dramatically shortens the feedback loop between customer and developer, between wish list and implementation, and between investment and return on investment. Again, complexity plays a role here. When a system is simple, it’s not so hard to know in advance what to do. But when we are dealing with a market economy that changes all the time and with technology that won’t stand still, learning through short cycles of discovery is the tried-and-true problem-solving approach.

We already know this. We try out various marketing campaigns and discover which approach works. We simulate vehicle behavior during car design to discover the best slope of the hood and best distribution of weight. Virtually all process-improvement programs use some version of the Deming cycle to study a problem, experiment with a solution, measure the results, and adopt proven improvements. We call this fact-based decision making, and we know that it works a lot better than front-end-loaded predictive approaches.

Scrum is built on 30-day learning cycles that prove complete business concepts. If we already know everything and have nothing to discover, perhaps we don’t need to use Scrum. If we need to learn, however, Scrum’s insistence on delivering complete increments of business value helps us learn rapidly and completely. One of the reasons complete increments are important is that partial answers often fool us into thinking that an approach will work, when in reality, the approach doesn’t work upon closer examination. We know that until software is tested, integrated, and released to production, we can’t really be sure that it will deliver the intended business value. Scrum forces us to test and integrate our experiments and encourages us to release them to production, so that we have a complete learning cycle every 30 days.

Scrum doesn’t focus on delivering just any increment of business value; it focuses on delivering the highest priority business value as defined by the customer (Product Owner). The Product Owner and the Team confer about what that definition is, and then the Team decides what it can do in 30 days to deliver high-priority business value. Thus the short feedback loop becomes a business feedback loop—Scrum tests early and often whether the system being developed will deliver value and exactly what that value will look like. This allows the system to be molded over time to deliver value as it is currently understood, even as it helps to develop a better understanding of that value.

Another reason Scrum works is that it unleashes the brainpower of many minds on a problem. We know that when things go wrong, there are people around who knew there was a problem, but somehow their ideas were overlooked. For example, when the space shuttle disintegrated on reentry, a widely reported interpretation of the causes of the disaster suggests that there were engineers who were well aware that there could be a problem, but they were unable to get their concerns taken seriously. What management system can we use to leverage the experience, ideas, and concerns of the people closest to the work to be done?

According to Gary Convis, president of Toyota Motor Manufacturing Kentucky, the role of managers in a healthy, thriving, work environment is “to shape the organization not through the power of will or dictate, but rather through example, through coaching and through understanding and helping others to achieve their goals.[1]

Scrum turns small teams into managers of their own fate. We know that when we are responsible for choosing our own driving route to Boston, we will find a way to get there. We will detour around construction and avoid rush hour traffic jams, making decisions on the fly, adapting to the independent decisions of all of the other drivers out there. Similarly, Scrum Teams accept a challenge and then figure out how to meet that challenge, detouring around roadblocks in creative ways that could not be planned by a central control and dispatching center.

If teams are of a size that encourages every member to participate, and team members feel like they are in control of their own destiny, the experience, ideas, and concerns of individual members will be leveraged, not squelched. When team members share a common purpose that everyone believes in, they will figure out how to achieve it. When teams understand and commit to delivering business value for their customers, when they are free to figure out how to perform tasks, and when they are given the resources they need, they will succeed.

Gary Convis notes that Toyota’s sustainable success comes from an “interlocking set of three underlying elements: the philosophical underpinnings, the managerial culture and the technical tools. The philosophical underpinnings include a joint [worker], customer-first focus, an emphasis on people first, a commitment to continuous improvement…. The managerial culture…is rooted in several factors, including developing and sustaining a sense of trust, a commitment to involving those affected by first, teamwork, equal and fair treatment for all, and finally, fact-based decision making and long-term thinking.[2]

Scrum works for all the same reasons. Its philosophical underpinnings focus on empowering the development team and satisfying customers. Its managerial culture is rooted in helping others achieve their goals. Its technical tools are focused on making fact-based decisions through a learning process. When all of these factors are in place, it’s hard for Scrum not to succeed.

—Mary Poppendieck
Poppendieck.LLC

Agile Project Management with Scrum.pdf

255 浏览量
**Agile Project Management with Scrum** 这个标题明确地指出了本书的主题：如何将敏捷开发中的Scrum方法应用于项目管理。Scrum是一种流行的敏捷开发框架，它强调团队合作、迭代式进展以及适应性计划。 #### 描述...

THE SCRUM PRIMER: An Introduction to Agile Project Management with Scrum

2011-01-19 上传
考虑到Scrum的复杂性和深度，初学者建议进一步阅读Ken Schwaber的《敏捷项目管理》或《敏捷软件开发》，并考虑参加Scrum联盟提供的培训课程。这些资源不仅提供了理论基础，还包含了实践经验分享和案例研究，有助于更...

scrum primer

2018-08-19 上传
对于考虑采用Scrum的团队，建议在开始之前装备Ken Schwaber的《Agile Project Management with Scrum》或Mike Cohn的《Succeeding with Agile》。同时，可以通过***网站了解更多关于Scrum的培训和辅导选项。这些书籍...

Takeaway_AGILE Bibliography

2011-08-02 上传
**Schwaber, Ken, Agile Project Management with Scrum (2003) 和 The Enterprise and Scrum (2007)** - **核心知识点**： - **Scrum框架**：介绍了Scrum框架的基本原则和实践。 - **企业级敏捷**：探讨了如何...

应用Scrum进行敏捷项目管理

点击了解资源详情
"本书《Agile Project Management with Scrum》由Ken Schwaber撰写，是关于Scrum敏捷项目管理的经典著作，适用于英文读者。书中详细介绍了Scrum方法论，旨在帮助团队专注于提供真正的商业价值。作者探讨了Scrum背后...

使用Scrum进行敏捷项目管理

点击了解资源详情
"Agile Project Management With Scrum" 是一本由 Ken Schwaber 撰写的书籍，主要讨论了敏捷项目管理方法中的Scrum框架。这本书是Microsoft Press在2004年出版的，旨在帮助软件项目团队通过Scrum实现更高效、更聚焦...

Scrum实战：敏捷项目管理指南

点击了解资源详情
"Agile Project Management with Scrum" 是一本由 Ken Schwaber 编写的书籍，专注于介绍Scrum这一敏捷项目管理方法，它在大型游戏公司中广泛应用。这本书由Microsoft Press于2004年出版，旨在帮助团队将注意力集中在...
tel5169553
  • 粉丝: 0
  • 资源: 9
上传资源 快速赚钱

最新资源