掌握敏捷Scrum项目管理：实践与价值交付

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

《敏捷项目管理与Scrum》是一本由Ken Schwaber编著的专业书籍，针对的是软件项目管理领域，特别是应用Scrum，一种流行的敏捷开发方法。本书适合那些希望将敏捷原则融入日常项目管理流程，并强调团队如何通过交付实际商业价值来提高效率的读者。该书的ISBN号为073561993x，由Microsoft Press在2004年出版。全书分为多个章节，深入探讨了Scrum在项目管理中的关键角色和实践。首先，"背景：Scrum的科学"章节为读者介绍了Scrum的基本理论和背景，让读者理解其在复杂项目环境中的价值。接着，"新的管理责任"章节阐述了在敏捷项目中管理者应该如何调整角色，以便更好地支持团队的自主性和灵活性。 "Scrum Master"一章专门聚焦于这个核心角色，讲解Scrum Master如何在团队中充当催化剂，维护Scrum流程并确保其遵循规则。"从混乱中带来秩序"章节则关注Scrum如何帮助组织结构化和优化工作流程，以应对快速变化的需求。 "产品负责人"的角色在"产品所有者"章节中被详述，他们负责定义和优先级排序项目需求，确保产品始终符合商业目标。"规划Scrum项目"章节涉及项目计划和迭代的设定，使团队明确目标并进行有效的工作分配。 "项目报告—保持透明度"章节强调了沟通的重要性，通过透明的进度报告和反馈机制，确保团队内外的信息流通。"团队"章节深入探讨了团队成员的角色、协作和技能发展，以及如何建立高效协作的文化。 "扩展项目使用Scrum"部分探讨了Scrum如何在大型项目或分布式团队中进行适应和扩展，确保Scrum原则得以在不同规模下应用。附录A提供了详细的规则和实践指南，而附录B则列出术语定义，帮助读者更好地理解和运用Scrum概念。最后，附录C和D分别列出了相关资源和处理固定价格、固定日期合同的建议，以及如何与传统的CMM（能力成熟度模型）相结合。索引部分方便读者查找特定主题，而未注册的ChmMagic文档链接要求用户访问指定网站进行注册。《敏捷项目管理与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页未读，继续阅读

lyy00001

粉丝: 0
资源: 2

掌握敏捷Scrum项目管理：实践与价值交付

Agile Project Management with Scrum

敏捷编程管理Agile Project Management with Scrum

Agile.Project.Management.with.Scrum

Agile Project Management with Scrum.pdf

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

Agile Project Management with Kanban

Agile Project Management with Azure DevOps

Agile Project Management

The Agile Project Management Approach

Scrum in Action - Agile Software Project Management and Development

最新资源