Scrum方法在敏捷项目管理中的应用

Agile
Project
Management
With
Scrum
5星 · 超过95%的资源 需积分: 9 10 下载量 193 浏览量 更新于2024-08-01 收藏 1.26MB PDF 举报
"敏捷项目管理与Scrum" "Agile Project Management with Scrum" 是一本由Ken Schwaber编著，由Microsoft Press在2004年出版的书籍，它深入介绍了Scrum方法在软件项目管理中的应用，以帮助团队专注于交付实际的商业价值。这本书涵盖了Scrum的原理、新的管理职责、Scrum Master的角色、如何从混乱中带来秩序、产品负责人的角色、Scrum项目的规划、项目报告、团队协作、以及如何使用Scrum扩展项目规模等多个方面。 Scrum是一种敏捷开发框架，特别适合处理复杂性和不确定性高的项目。它的核心原则包括迭代开发、自组织团队、透明性、频繁的反馈和持续改进。Scrum强调通过短期的、称为Sprint的工作周期来快速交付可工作的软件，每个Sprint通常为1到4周。 在第一章"Backdrop: The Science of Scrum"中，作者可能探讨了Scrum的起源和科学基础，解释了为什么这种方法在敏捷开发中如此有效。它可能涉及到敏捷宣言的价值观和原则，以及Scrum如何与这些价值观相契合。 第二章"New Management Responsibilities"讨论了在Scrum环境中管理者角色的变化。传统的管理方式往往注重控制和计划，而在Scrum中，管理者更多地扮演教练和支持者的角色，鼓励团队自我管理和持续改进。 第三章"The Scrum Master"深入介绍了Scrum Master的角色，他们是团队的守护者，负责确保Scrum过程得到遵循，去除团队障碍，并促进跨职能团队的协作。 第四章"Bringing Order from Chaos"可能讨论了如何在项目初期的混乱中建立秩序，例如通过产品待办事项列表（Product Backlog）的创建和优先级排序，以及首次Sprint的规划。 第五章"The Product Owner"探讨了产品负责人的角色，他们负责代表利益相关者，清晰定义需求，管理产品待办事项列表，并与团队密切合作以确保产品的愿景得以实现。 第六章"Planning a Scrum Project"可能详细介绍了Scrum的规划过程，包括Sprint计划会议、每日Scrum会议、Sprint评审和Sprint回顾。 第七章"Project Reporting—Keeping Everything Visible"讨论了在Scrum中如何进行透明的项目报告，比如使用燃尽图（Burndown Charts）和看板（Kanban）来跟踪进度和工作流程。 第八章"The Team"重点关注团队协作和自组织，Scrum团队通常是跨职能的，所有成员共同负责产品的交付。 第九章"Scaling Projects Using Scrum"则讨论了如何在大型或复杂项目中应用Scrum，可能涉及多个Scrum团队的协调和同步。 附录提供了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

Agile.Project.Management.with.Scrum

2008-09-06 上传
关于敏捷开发的一个方法论，Scrum是敏捷开发的一种方法。

Agile Project Management with Scrum.pdf

2011-08-22 上传
Agile Project Management with Scrum by en Schwaber Microsoft Press 2004

敏捷编程管理Agile Project Management with Scrum

2009-05-14 上传
《Agile Project Management with Scrum》这本书，出自微软出版社，深入探讨了如何运用Scrum进行敏捷项目管理。 Scrum的核心概念包括： 1. **角色**：Scrum有三个关键角色——产品负责人（Product Owner）、Scrum ...

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

2011-01-19 上传
### 敏捷项目管理Scrum入门指南 #### Scrum简介 Scrum是一种敏捷开发方法，旨在提高团队的工作效率和灵活性。它强调通过迭代的方式完成项目，每次迭代都会产生可用的产品增量。Scrum的核心理念是适应变化而非严格...

Agile Project Management with Kanban

2018-12-18 上传
This book provides pragmatic and prescriptive step-by-step instructions on how to produce the most value for your customers, with the highest quality at the lowest cost in the least amount of time....

Agile Project Management with Azure DevOps

2019-06-22 上传
"Agile Project Management with Azure DevOps" 是一种将敏捷理念与强大的云服务工具——Azure DevOps 结合的实践方式。Azure DevOps 提供了一整套解决方案，支持敏捷团队从需求规划、代码开发、测试到部署的全过程...

Agile Project Management

2013-09-06 上传
- **Scrum**：一种迭代和增量的敏捷软件开发框架，包含固定长度的迭代周期（Sprint），以及Sprint计划会议、每日站立会议、Sprint回顾和Sprint回顾会议等。 敏捷方法论的实施面临着各种挑战，包括组织文化的不适应...

The Agile Project Management Approach

2018-11-16 上传
- **Scrum**：这是一种轻量级框架，旨在通过短周期冲刺实现快速反馈循环。 - **极限编程 (XP)**：强调高质量代码的重要性，并通过持续集成等实践确保软件质量。 - **精益 (Lean)**：聚焦于消除浪费，提高效率。 - **...

Scrum in Action - Agile Software Project Management and Development

2012-11-10 上传
### Scrum in Action: 敏捷软件项目管理和开发 #### Scrum简介 Scrum是一种敏捷开发框架，主要用于软件开发项目，但也可应用于其他复杂产品或服务的开发过程。Scrum的核心理念是通过迭代（通常称为Sprints）的方式...
kinx28
  • 粉丝: 0
  • 资源: 1
上传资源 快速赚钱

最新资源