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

Agile
Project
Management
With
Scrum
5星 · 超过95%的资源 需积分: 9 10 下载量 189 浏览量 更新于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

JIRA Software Agile开发与Scrum敏捷实战

点击了解资源详情
# 第一章：JIRA Software简介 ## 1.1 JIRA Software概述 JIRA Software是由澳大利亚公司Atlassian开发的一款敏捷项目管理工具，旨在帮助软件开发团队践行敏捷开发方法，提高项目的可见性和透明度，从而更好地规划、...

agile project management

2023-04-10 上传
b'agile project management'是一种敏捷项目管理的方法，它强调团队协作、灵活性和快速反应能力。这种方法包括每日站会、Sprint周期、迭代式开发和自我组织化团队等特性，旨在提高项目成功率、降低风险和增加创造性...

A body of knowledge for project management

2023-05-12 上传
The body of knowledge for project management ... Additionally, the PMBOK also covers project management frameworks, such as Agile and Waterfall methodologies, and project management best practices.

agile 和scrum的关系

2023-05-17 上传
而Scrum是一种实现Agile方法论的具体框架，它包含了一系列规定的角色、工件和活动，帮助团队组织和管理敏捷开发过程。 换句话说，Scrum是一种基于Agile的敏捷开发框架。它强调团队合作、迭代式开发、持续交付和迭代...

 You+are+handed+over+a+project+of+a+bank+for+testing.+Using+agile+scrum

2023-11-14 上传
但是，我可以为您提供一些关于使用敏捷Scrum方法测试银行项目的一般信息。 在使用敏捷Scrum方法测试银行项目时，您需要遵循以下步骤： 1. 确定项目的范围和目标，以及测试的重点和优先级。 2. 根据项目的需求和...

软件项目如何进行项目管理

2023-02-21 上传
项目管理是一个复杂的过程...为此，可以采用多种项目管理方法，如迭代式项目管理（Iterative Project Management）、敏捷项目管理（Agile Project Management）和结构化项目管理（Structured Project Management）等。

解决org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'userController': Unsatisfied dependency expressed through field 'userService': Error creating bean with name 'userService': Unsatisfied dependency expressed through field 'userMapper': Error creating bean with name 'userMapper' defined in file [F:\secBachelor\agile\agile-software-development-master\rbac524-post\target\classes\com\lhm\rbac524post\mapper\UserMapper.class]: Property 'sqlSessionFactory' or 'sqlSessionTemplate' are required

2023-05-25 上传
3. Error creating bean with name 'userMapper' defined in file [F:\secBachelor\agile\agile-software-development-master\rbac524-post\target\classes\com\lhm\rbac524post\mapper\UserMapper.class]: Property...
kinx28
  • 粉丝: 0
  • 资源: 1
上传资源 快速赚钱

最新资源