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

4星 · 超过85%的资源需积分: 33 186 浏览量更新于2023-07-10 收藏 2.43MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"《使用Scrum进行敏捷项目开发》是由Ken Schwaber编著，由Microsoft Press于2004年出版的一本关于敏捷项目管理的专业书籍。Scrum是一种流行的敏捷编程方法，本书主要介绍了如何将Scrum原则应用于软件项目管理，以使团队专注于交付实际的商业价值。" 在本书中，作者Ken Schwaber详细阐述了Scrum方法的核心概念和实践，旨在帮助读者理解并实施Scrum框架。以下是对书中的关键章节和主题的概述： 1. **前言和介绍**：这部分可能包含对敏捷开发背景的介绍，以及为什么选择Scrum作为敏捷方法的理由。它可能会探讨敏捷项目管理与传统项目管理的区别，以及Scrum在应对快速变化需求和不确定性方面的优势。 2. **第一章：Scrum的科学背景**：这一章深入讲解了Scrum的基础理论，包括迭代开发、自组织团队、透明度和反馈循环等核心原则。 3. **第二章：新的管理责任**：书中讨论了在Scrum环境中管理者角色的变化，如如何促进跨职能协作，以及如何适应敏捷环境下的决策制定。 4. **第三章：Scrum主管的角色**：这一部分详细介绍了Scrum Master的角色，包括他们如何协调团队，解决冲突，确保遵循Scrum规则，并促进团队的自我改进。 5. **第四章：从混乱中建立秩序**：此章节可能涵盖了Scrum如何通过产品积压工作列表（Product Backlog）和每日站会（Daily Scrums）来管理项目的混乱，以及如何保持团队的专注和同步。 6. **第五章：产品负责人**：书中解释了产品所有者的职责，如定义和优先级排序产品功能，以及与利益相关者沟通。 7. **第六章：规划Scrum项目**：这一章可能介绍了Scrum项目规划的步骤，包括冲刺（Sprint）计划会议，以及如何在不确定性和变化中设定可实现的目标。 8. **第七章：项目报告与可见性**：这部分讨论了如何在Scrum中进行项目跟踪和报告，以确保所有相关人员都能了解项目的进度和状态。 9. **第八章：团队**：书中强调了Scrum团队的协作精神，以及如何通过自我组织和跨职能能力来提高生产力。 10. **第九章：使用Scrum扩展项目**：这一章可能探讨了如何在大型或多团队项目中应用Scrum，以保持协调和一致性。此外，书中的附录提供了Scrum的规则、定义、资源以及关于固定价格、固定日期合同和能力成熟度模型（CMM）的相关信息。整体来看，《使用Scrum进行敏捷项目开发》是一本全面而深入的指南，旨在帮助项目经理和团队成员成功地采用Scrum方法，提高项目的效率和灵活性。

资源详情

资源推荐

Figure 1-1: Complexity assessment graph

The third dimension of complexity is the people developing the software. They all have different skills, intelligence levels, experience, viewpoints, attitudes, and prejudices. Ever y

morning, each wakes up in a different mood than the day before, depending on his or her sleep, health, weather, neighbors, and families. These people then start to work together ,

and the complexity level goes through the roof. Taking into account this last dimension—people—in addition to technology and requirements, I believe that the last “simple” projec t

occurred in 1969, when one person from order processing at Sears Roebuck asked me to sort some cards and generate a report on an IBM 360/20. Since then, things have onl y

gotten messier. Scrum addresses the complexity of software development projects by implementing the inspection, adaptation, and visibility requirements of empirical process contro l

with a set of simple practices and rules, which are described in the following sections .

This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks .

The Skeleton and Heart of Scrum

Scrum hangs all of its practices on an iterative, incremental process skeleton. Scrum’s skeleton is shown in Figure 1-2 . The lower circle represents an iteration of developmen t

activities that occur one after another. The output of each iteration is an increment of product. The upper circle represents the daily inspection that occurs during the iteration, in whic h

the individual team members meet to inspect each others’ activities and make appropriate adaptations. Driving the iteration is a list of requirements. This cycle repeats until the projec t

is no longer funded .

Figure 1-2: Scrum skeleton

The skeleton operates this way: At the start of an iteration, the team reviews what it must do. It then selects what it believes it can turn into an increment of potentially shippable

functionality by the end of the iteration. The team is then left alone to make its best effort for the rest of the iteration. At the end of the iteration, the team presents the increment of

functionality it built so that the stakeholders can inspect the functionality and timely adaptations to the project can be made.

The heart of Scrum lies in the iteration. The team takes a look at the requirements, considers the available technology, and evaluates its own skills and capabilities. It then collectivel y

determines how to build the functionality, modifying its approach daily as it encounters new complexities, difficulties, and surprises. The team figures out what needs to be done an d

selects the best way to do it. This creative process is the heart of the Scrum’s productivity .

Scrum implements this iterative, incremental skeleton through three roles. I’ll provide a quick overview of these people operating within the Scrum process. Then I’ll describe th e

Scrum process flow and its artifacts. Appendix A , ?Rules, ? and Appendix B , ?Definitions, ? provide a list of rules as well as Scrum definitions that can be referred to as you read this

book. More detailed information about Scrum can be found in Appendix C , ?Resources, ? and in Ken Schwaber and Mike Beedle’s, Agile Software Development with Scrum (Prentice

Hall, 2002).

This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks .

Scrum Roles

There are only three Scrum roles: the Product Owner, the Team, and the ScrumMaster. All management responsibilities in a project are divided among these three roles. The Produc t

Owner is responsible for representing the interests of everyone with a stake in the project and its resulting system. The Product Owner achieves initial and ongoing funding for th e

project by creating the project’s initial overall requirements, return on investment (ROI) objectives, and release plans. The list of requirements is called the Product Backlog. Th e

Product Owner is responsible for using the Product Backlog to ensure that the most valuable functionality is produced first and built upon; this is achieved by frequently prioritizing th e

Product Backlog to queue up the most valuable requirements for the next iteration. The Team is responsible for developing functionality. Teams are self-managing, self-organizing ,

and cross-functional, and they are responsible for figuring out how to turn Product Backlog into an increment of functionality within an iteration and managing their own work to do so .

Team members are collectively responsible for the success of each iteration and of the project as a whole. The ScrumMaster is responsible for the Scrum process, for teaching Scru m

to everyone involved in the project, for implementing Scrum so that it fits within an organization’s culture and still delivers the expected benefits, and for ensuring that everyone follow s

Scrum rules and practices .

The people who fill these roles are those who have committed to the project. Others might be interested in the project, but they aren’t on the hook. Scrum makes a clear distinctio n

between these two groups and ensures that those who are responsible for the project have the authority to do what is necessary for its success and that those who aren’t responsibl e

can’t interfere unnecesarily. Throughout this book, I refer to these people as “pigs” and “chickens,” respectively. These names come from an old joke: A chicken and a pig are walkin g

down the road. The chicken says to the pig, “Do you want to open a restaurant with me?” The pig considers the question and replies, “Yes, I’d like that. What do you want to call th e

restaurant?” The chicken replies, “Ham and Eggs!” The pig stops, pauses, and replies, “On second thought, I don’t think I want to open a restaurant with you. I’d be committed, bu t

you’d only be involved. ”

This distinction is important in Scrum and is relevant to Scrum’s insistence upon total visibility. It should always be clear who is on the hook and who is just a kibitzer. Who i s

responsible for the ROI, and who has a stake in the ROI but isn’t accountable? Who has to turn difficult technology into functionality, and who is a troublesome “devil’s advocate”? Th e

rules of Scrum distinguish between the chickens and the pigs to increase productivity, create momentum, and put an end to floundering .

This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks .

Scrum Flow

A Scrum project starts with a vision of the system to be developed. The vision might be vague at first, perhaps stated in market terms rather than system terms, but it will becom e

clearer as the project moves forward. The Product Owner is responsible to those funding the project for delivering the vision in a manner that maximizes their ROI. The Product Owne r

formulates a plan for doing so that includes a Product Backlog. The Product Backlog is a list of functional and nonfunctional requirements that, when turned into functionality, wil l

deliver this vision. The Product Backlog is prioritized so that the items most likely to generate value are top priority and is divided into proposed releases. The prioritized Produc t

Backlog is a starting point, and the contents, priorities, and grouping of the Product Backlog into releases usually changes the moment the project starts—as should be expected .

Changes in the Product Backlog reflect changing business requirements and how quickly or slowly the Team can transform Product Backlog into functionality .

All work is done in Sprints. Each Sprint is an iteration of 30 consecutive calendar days. Each Sprint is initiated with a Sprint planning meeting, where the Product Owner and Team ge t

together to collaborate about what will be done for the next Sprint. Selecting from the highest priority Product Backlog, the Product Owner tells the Team what is desired, and th e

Team tells the Product Owner how much of what is desired it believes it can turn into functionality over the next Sprint. Sprint planning meetings cannot last longer than eigh t

hours—that is, they are time-boxed to avoid too much hand-wringing about what is possible. The goal is to get to work, not to think about working .

The Sprint planning meeting has two parts. The first four hours are spent with the Product Owner presenting the highest priority Product Backlog to the Team. The Team questions

him or her about the content, purpose, meaning, and intentions of the Product Backlog. When the Team knows enough, but before the first four hours elapses, the Team selects as

much Product Backlog as it believes it can turn into a completed increment of potentially shippable product functionality by the end of the Sprint. The Team commits to the Product

Owner that it will do its best. During the second four hours of the Sprint planning meeting, the Team plans out the Sprint. Because the Team is responsible for managing its own work,

it needs a tentative plan to start the Sprint. The tasks that compose this plan are placed in a Sprint Backlog; the tasks in the Sprint Backlog emerge as the Sprint evolves. At the start

of the second four- hour period of the Sprint planning meeting, the Sprint has started, and the clock is ticking toward the 30-day Sprint time-box.

Every day, the team gets together for a 15-minute meeting called a Daily Scrum. At the Daily Scrum, each Team member answers three questions: What have you done on this

project since the last Daily Scrum meeting? What do you plan on doing on this project between now and the next Daily Scrum meeting? What impediments stand in the way of you

meeting your commitments to this Sprint and this project? The purpose of the meeting is to synchronize the work of all Team members daily and to schedule any meetings that the

Team needs to forward its progress.

At the end of the Sprint, a Sprint review meeting is held. This is a four-hour, time-boxed meeting at which the Team presents what was developed during the Sprint to the Product

Owner and any other stakeholders who want to attend. This informal meeting at which the functionality is presented is intended to bring people together and help them collaboratively

determined what the Team should do next. After the Sprint review and prior to the next Sprint planning meeting, the ScrumMaster holds a Sprint retrospective meeting with the Team.

At this three-hour, time-boxed meeting, the ScrumMaster encourages the Team to revise, within the Scrum process framework and practices, its development process to make it more

effective and enjoyable for the next Sprint. Together, the Sprint planning meeting, the Daily Scrum, the Sprint review, and the Sprint retrospective constitute the empirical inspection

and adaptation practices of Scrum. Take a look at Figure 1-3 to see a diagram of the Scrum process.

This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks .

剩余174页未读，继续阅读