敏捷开发实战：Scrum与XP的前线经验

需积分: 10 199 浏览量更新于2024-08-02 收藏 5MB PDF 举报

"硝烟中的Scrum和XP"是一本关于敏捷开发实践的指南，主要聚焦于Scrum和极限编程（XP）这两种敏捷方法论。书中通过丰富的图示和实例，帮助读者理解并掌握这两种敏捷框架，使得学习过程更为直观易懂。 Scrum是一种敏捷项目管理框架，它强调迭代和增量开发，以快速适应需求变化。核心概念包括产品积压工作（Product Backlog）、冲刺（Sprint）、每日站会（Daily Scrum）、冲刺评审（Sprint Review）和冲刺回顾（Sprint Retrospective）。Scrum团队通常由跨职能成员组成，如开发人员、产品负责人和Scrum Master，他们共同协作以实现高效且灵活的软件开发。极限编程（XP）则是一种注重代码质量、测试驱动开发（TDD）和持续集成的敏捷开发方法。XP的关键实践包括：编写自动化测试、结对编程、简单设计、重构、集体代码所有制、持续集成、客户参与和计划游戏等。这些实践旨在确保团队能够快速响应变化，同时保持代码的高质量。书中的"Burndown Chart"展示了Scrum中的一个关键工具，即燃尽图，用于跟踪在冲刺期间剩余工作的进度。图表中，"Unplanned items"表示未计划的工作，"Not checked out"表示未开始的任务，"Done!"表示已完成的任务。书中的例子显示了一个项目中不同任务的持续时间，如"DAO DB design"、"Integr test"、"GUI spec"等，这些都代表了项目中的具体工作。通过这本书，读者可以了解到如何在实际项目中应用Scrum和XP，包括如何编写失败测试先行，进行数据库设计，集成测试，GUI开发，以及与后端系统的集成等。此外，书中还提到了需求澄清和代码清理的重要性，这些都是敏捷开发过程中不可或缺的部分。 "硝烟中的Scrum和XP"提供了关于这两种敏捷方法的实战经验，帮助读者跳过理论，直接进入实践，对于想要理解和实施敏捷开发的人来说是一份宝贵的资源。InfoQ网站提供了这本书的最新版本，不仅有电子版，还有印刷版供读者选择。

Scrum and XP from the Trenches - Henrik Kniberg

Deprecated version! Latest version at:

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

page 16 / 105

5.4 Sprint planning meeting agenda

Having some kind of preliminary schedule for the sprint planning meeting will reduce the risk

of breaking the timebox.

Here’s an example of a typical schedule for us.

Sprint planning meeting: 13:00 – 17:00 (10 minute break each hour)

· 13:00 – 13:30. Product owner goes through sprint goal and summarizes product

backlog. Demo place, date and time is set.

· 13:30 – 15:00. Team time-estimates, and breaks down items as necessary. Product

owner updates importance ratings as necessary. Items are clarified. “How to demo” is

filled in for all high-importance items.

· 15:00 – 16:00. Team selects stories to be included in sprint. Do velocity calculations

as a reality check.

· 16:00 – 17:00. Select time and place for daily scrum (if different from last sprint).

Further breakdown of stories into tasks.

The schedule is by no means strictly enforced. The Scrum master may lengthen or shorten the

sub-time-boxes as necessary as the meeting progresses.

5.5 Defining the sprint length

One of the outputs of the sprint planning meeting is a defined sprint demo date. That means

you have to decide on a sprint length.

So what is a good sprint length?

Well, short sprints are good. They allow the company to be “agile”, i.e. change direction

often. Short sprints = short feedback cycle = more frequent deliveries = more frequent

customer feedback = less time spent running in the wrong direction = learn and improve

faster, etc.

But then, long sprints are good too. The team gets more time to build up momentum, they get

more room to recover from problems and still make the sprint goal, you get less overhead in

terms of sprint planning meetings, demos, etc.

Generally speaking product owners like short sprints and developers like long sprints. So

sprint length is a compromise. We experimented a lot with this and came up with our favorite

length: 3 weeks. Most of our teams (but not all) do 3 week sprints. Short enough to give us

adequate corporate agility, long enough for the team to achieve flow and recover from

problems that pop up in the sprint.

One thing we have concluded is: do experiment with sprint lengths initially. Don’t waste too

much time analyzing, just select a decent length and give it a shot for a sprint or two, then

change length.

Scrum and XP from the Trenches - Henrik Kniberg

Deprecated version! Latest version at:

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

page 17 / 105

However, once you have decided what length you like best, stick to it for an extended period

of time. After a few months of experimentation we found that 3 weeks was good. So we do 3

week sprints, period. Sometimes it will feel slightly too long, sometimes slightly too short.

But by keeping the same length this becomes like a corporate heartbeat which everyone

comfortably settles into. There is no argument about release dates and such because everyone

knows that every 3 weeks there is a release, period.

5.6 Defining the sprint goal

It happens almost every time. At some point during the sprint planning meeting I ask “so what

is the goal of this sprint?” and everybody just stares blankly back at me and the product owner

furrows his brow and itches his chin.

For some reason it is hard to come up with a sprint goal. But yet I have found that it really

pays to squeeze one out. Better a half-crappy goal than none at all. The goal could be “make

more money” or “complete the three top-priority stories” or “impress the CEO” or “make the

system good enough to deploy to a live beta group” or “add basic back office support” or

whatever. The important thing is that it should be in business terms, not technical terms. This

means in terms that people outside the team can understand.

The sprint goal should answer the fundamental question “Why are we doing this sprint? Why

don’t we all just go on vacation instead?”. In fact, one way to wheedle a sprint goal out of the

product owner is to literally ask that question.

The goal should be something that has not already been achieved. “Impress the CEO” might

be a fine goal, but not if he is already impressed by the system as it stands now. In that case

everybody could go home and the sprint goal will still be achieved.

The sprint goal may seem rather silly and contrived during the sprint planning, but it often

comes to use in mid-sprint, when people are starting to get confused about what they should

be doing. If you have several Scrum teams (like we do) working on different products it is

very useful to be able to list the sprint goals of all teams on a single wiki page (or whatever)

and put them up on a prominent space so that everybody in the company (not only top-level

management) knows what the company is doing – and why!

Scrum and XP from the Trenches - Henrik Kniberg

Deprecated version! Latest version at:

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

page 20 / 105

The third option is to split a story. The product owner might decide that there are some

aspects of story A that really aren’t that important, so he splits A into two stories A1 and A2

with different importance levels.

As you see, although the product owner normally can’t control the estimated velocity, there

are many ways in which he can influence which stories make it into the sprint.

5.9 How does the team decide which stories to include in the sprint?

We use two techniques for this:

1. Gut feel

2. Velocity calculations

Estimating using gut feel

· Scrum master: “Hey guys, can we finish story A in this sprint?” (points to the most

important item in the product backlog)

· Lisa: “Duh. Of course we can. We have 3 weeks, and that’s a pretty trivial feature.”

· Scrum master: “OK, what if we add story B as well?” (points to the second most

important item)

· Tom & Lisa in unison: “Still a no-brainer.”

· Scrum master: “OK, what about story A and B and C then?”

· Sam (to product owner): “does story C include advanced error handling?”

· Product owner: “no, you can skip that for now, just implement basic error handling.”

· Sam: “then C should be fine as well.”

· Scrum master: “OK, what if we add story D?”

· Lisa: “Hmm....”

· Tom: “I think we could do it.”

· Scrum master: “90% confident? 50%?”

· Lisa & Tom: “Pretty much 90%”.

· Scrum master: “OK, D is in then. What if we add story E?”

· Sam: “Maybe.”

· Scrum master: “90%? 50%?”

· Sam: “I’d say closer to 50%”.

· Lisa: “I’m doubtful.”

· Scrum master: “OK, then we leave it out. We’ll commit to A, B, C, and D. We will

of course finish E if we can, but nobody should count on it so we’ll leave it out of the

sprint plan. How about that?”

· Everybody: “OK!”

剩余104页未读，继续阅读

duke_gun

粉丝: 0
资源: 3

敏捷开发实战：Scrum与XP的前线经验

硝烟中的Scrum和XP.pdf

硝烟中的Scrum和XP 中文版

硝烟中的Scrum和XP 硝烟中的Scrum和XP硝烟中的Scrum和XP

实战指南：硝烟中Scrum与XP的敏捷转型

实战指南：硝烟中Scrum与XP的实施策略

Scrum与XP实战经验：硝烟中的Scrum和XP

实战指南：硝烟中Scrum与XP的敏捷开发策略

实战指南：硝烟中Scrum与XP的团队实施策略

硝烟中的scrum和xp

中国新能源汽车&充电桩（2018-2022）数据-最新出炉.zip

最新资源