Name: 10分鐘介紹敏捷開發 (Intro to Scrum in Under 10 Minutes)
Uploaded: 2017-03-19T16:07:59.000Z
Duration: 8 min 53 s

My name is Hamid Shojaee, and I've been involved with a number of software development projects

我的名字是Hamid Shojaee，我參與了許多軟件開發項目。

at a number of different companies, and I've come to recognize 'Scrum,'

在一些不同的公司，我已經認識到了'Scrum，'

as one of the best agile development practices in use today.

作為當今使用的最佳敏捷開發實踐之一。

I want to show you why Scrum is so great, and how you can get started with Scrum in

我想告訴你，為什麼Scrum如此偉大，以及你如何在Scrum中開始。

我'將涵蓋所有Scrum的核心概念。

like product backlogs, team roles, sprints, burndown charts, and more.

如產品積壓、團隊角色、spring、burndown圖表等。

So get ready to be bombarded with information.

Lets say THIS is the product we want to build.

讓我們說這是我們要打造的產品。

For this product, we get all kinds of feature requests from customers, executives, or even

對於這個產品，我們會收到客戶、高管的各種功能需求，甚至是。

In Scrum, features are written from the perspective of the end-user,

在Scrum中，功能是站在最終用戶的角度來寫的。

therefore, features are known as user-stories.

The collection of all these user-stories is called the product backlog.

所有這些用戶故事的集合稱為產品積壓。

Another way to think of the product backlog

is to think of it as a wish list of all the things that would make this product great.

就是把它當成一個願望清單，列出所有能讓這個產品變得偉大的東西。

Once we have our wish list or the product backlog,

一旦我們有了我們的願望清單或產品積壓。

we need to start planning which specific user-stories

我們需要開始規劃哪些具體的用戶故事。

we're going to put into a particular release of our product.

我們'將投入到我們產品的特定版本中。

we need to have one or more people in our team who are going to play a variety of roles.

我們的團隊中需要有一個或多個要扮演各種角色的人。

她扮演的是產品所有者的角色。

and helps make sure the right features make it into the product backlog

並幫助確保正確的功能進入產品積壓期

representing the users and customers of the product.

She helps set the direction of the product.

He is the Scrum Master and his job is to make sure the project is progressing smoothly

他是Scrum Master，他的工作是確保項目的順利進行。

and that every member of the team has the tools they need to get their job done.

並確保團隊的每個成員都有完成工作所需的工具。

He sets up meetings, monitors the work being done and facilitates release planning.

他安排會議，監督正在進行的工作，並協助制定放行計劃。

He's a lot like a project manager, but that's such a boring title.

他'很像一個項目經理，但這'真是一個無聊的頭銜。

So, we'll call him a Scrum Master [Karate yell] to imply he knows some Jui-Jitsu.

所以，我們'就叫他Scrum Master[空手道大喊]，暗示他懂點柔術。

And the rest of the team has similar roles to other development processes.

而團隊其他成員的角色與其他開發流程類似。

while these guys test it to make sure it works right.

而這些傢伙測試它，以確保它的工作正確。

These guys use it, and hopefully pay for it.

這些人用了，希望能付出代價。

And these guys, they generally get in the way, but it turns out you can't build many

而這些傢伙，一般都會礙於情面，但事實證明，你不能'建很多。

But lets get back to this: Release Planning.

但讓我們回到這個問題上。發行計劃。

To plan a release, the team starts with this, the product backlog,

為了計劃發佈，團隊從這個開始，產品積壓。

and they identify the user-stories they want to put into this release.

他們確定了他們想要放到這個版本中的用戶故事。

These user-stories then become part of the release backlog.

這些用戶故事就會成為發行積壓的一部分。

The team then prioritizes the user-stories and estimates the amount of work involved

然後，團隊會對用戶故事進行優先排序，並對所涉及的工作量進行估算。

Sometimes larger user-stories are broken down into smaller more manageable chunks.

有時，較大的用戶故事會被分解成更小的、更容易管理的塊。

The collection of all the estimates provides a rough idea

收集了所有的估計數，就有了一個粗略的瞭解。

of the total amount of work involved to complete the entire release.

完成整個發行工作所涉及的總工程量的百分比。

There are a lot of techniques for creating good estimates.

Some prefer estimating in story points where estimates are made

有些人喜歡在故事點中進行估算，在故事點中進行估算。

relative to building a small component with a known level of difficulty.

相對於構建一個已知難度的小部件。

Unfortunately, story points don’t answer the question of,

遺憾的是，故事點並沒有回答的問題。

I have found that the best technique is to estimate work in hours,

我發現，最好的技術是以小時來估算工作。

but to use some standards in how estimates are done.

但要用一些標準在如何進行估算。

For example, things that take less than a day to complete

例如，需要不到一天時間就能完成的事情

will be estimated as 1 hour, 2 hours, 4 hours or 8 hours.

估計為1小時、2小時、4小時或8小時。

Every item will fall into one of those buckets.

每件物品都會落入其中的一個桶中。

There will be no 3 hour estimates, for example.

A 3 hour item would fall into the 4 hour bucket.

Larger items will be estimated as 2 days, 3 days, 5 days, or 10 days.

較大的項目預計為2天、3天、5天或10天。

Again, all estimates in between will fall into the next larger bucket.

同樣，中間的所有估計都將歸入下一個更大的桶。

Extremely large items are similarly estimated in months: 1, 2, 3 or 6 Months,

極大的項目同樣以月為組織、部門進行估算。1、2、3或6個月。

but the reality is that such items will need to be broken down substantially

但現實是，這類項目需要大量分解

We’ll come back to these estimates in just a minute.

我們一會兒再來談談這些估計。

但現在，讓我們回到這個問題上。

With a prioritized set of user-stories and the estimated amount of work at hand,

有了一組優先級的用戶故事和手頭估計的工作量。

we are now ready to plan out several sprints to get the work done.

我們現在準備規劃出幾個衝刺，把工作做好。

Sprints are short-duration milestones that allow teams to tackle a manageable chunk of

衝刺是一個短期的里程碑，讓團隊能夠處理可管理的一大塊工作。

Sprints generally range from a couple of days to as much as 30 days in length,

短跑的時間一般從幾天到30天不等。

depending on the product's release cycles.

The shorter the release cycles, the shorter each sprint should be.

釋放週期越短，每次衝刺的時間應該越短。

And you'll want to have at least 2 to as many as a dozen sprints in a given release.

而且你會希望在一個給定的版本中至少有2個到十幾個sprint。

So, at this point, we can take our release backlog and split it up into several of these:

所以，此時，我們可以把我們的發行積壓，抽成這樣幾個。

One of the most important things to remember about sprints

關於短跑，最重要的事情之一就是要記住

is that the goal of each sprint is to get a subset of the release backlog to a ship-ready

是指每一個衝刺的目標是讓發佈積壓的子集達到出貨準備的狀態。

So, at the end of each sprint, you should have a fully tested product with all the features

所以，在每個衝刺結束時，你應該有一個經過全面測試的產品，並具備所有的功能。

Since sprints are a very short, but a realistic representation of part of the product,

由於sprint是一個很短的，但卻能真實的體現一部分產品。

a late finish of the sprint is a great indicator that the project is not on schedule and something

衝刺晚完成是一個很好的指標，說明項目沒有按計劃進行，有些事情是不可能的

Therefore, it's extremely important to monitor the progress of each sprint with THIS:

是以，用this監控每一次衝刺的進度是極其重要的。

The burndown chart is the number one reason for Scrum's popularity,

爆料圖是Scrum'受歡迎的首要原因。

and one of the best project visibility tools to ensure a project is progressing smoothly.

和最好的項目可視性工具之一，以確保項目的順利進行。

The burndown chart provides a day-by-day measure of the amount of work that remains in a given

消耗圖表提供了一個逐日衡量給定的剩餘工作量的方法。

In this graph, you can see that the amount of work remaining bounces up and down from

在這張圖中，你可以看到，剩餘的工作量在從

字幕列表影片播放

10分鐘介紹敏捷開發 (Intro to Scrum in Under 10 Minutes)

entire

extremely

essential

prioritize