Hi. This is me.

嗨，這是我

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

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

over the years,

多年來，。

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

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

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

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

In this fast-paced video,

在這個快節奏的視頻中。

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

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

under 10 minutes.

10分鐘以內。

I'll cover all the core Scrum concepts,

我'將涵蓋所有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

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

other team members.

其他團隊成員。

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.

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

But we're getting ahead of ourselves.

但我們'是在自作多情。

Let's back up a bit.

讓'我們退後一點。

To build this product,

為了打造這個產品。

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

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

First, we need her.

首先，我們需要她。

She plays the role of product owner,

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

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.

她幫助設定產品的方向。

Then, we need this guy.

那麼，我們需要這個傢伙。

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.

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

These guys build the product,

這些傢伙打造的產品。

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

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

products without them.

的產品，而沒有它們。

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

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

for each item.

每個項目的。

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.

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

A quick side note about estimates.

關於估價的一個小插曲。

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,

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

“When will my project ship?”

"我的項目什麼時候能出貨？"

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.

比如說，不會有3小時的估計。

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

3小時的項目就屬於4小時桶。

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

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

before work actually begins.

在工作實際開始之前。

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

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

But for now, lets go back to this:

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

The Release Backlog.

發行積壓。

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

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

the project

該項目

and get it to a ship-ready state.

並使其達到船用狀態。

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:

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

Sprint Backlogs.

衝刺積壓。

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

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

state.

態。

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

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

of that sprint 100% complete.

的那個衝刺100%完成。

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

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

needs to be done.

需要做的。

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

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

A Burndown Chart.

一張伯樂圖。

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

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

sprint or release.

衝刺或釋放。

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

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

day to day,

每天都有。

but is generally trending towards zero.

但總體上是趨向於零。

Because historical information is provided in the burndown chart,

因為在爆料圖中提供了歷史資訊。

it's easy to see if the team is on the right track.

它'很容易看到球隊是否在正確的軌道上。

Using the burndown chart, the team can quickly calculate this:

利用燒傷圖，團隊可以快速計算出這一點。

the slope of the graph, which is also called the Burndown Velocity.

圖形的斜率，也叫降速。

This is the average rate of productivity for each day.

這是每一天的平均生產力率。

For example, a team's rate of productivity might be that on a typical day,

例如，一個團隊'的生產力率可能是，在典型的一天。

they finish approximately 50 hours of work.

他們大約完成50小時的工作。

Knowing that, it's possible to calculate an estimated completion date for the sprint

知道了這一點，就可以計算出衝刺的預計完成日期。

or even for the entire release, based on the amount of work remaining.

甚至根據剩餘的工作量，對整個發佈。

What's great about the burndown chart

爆料圖有什麼好處？

is that we can compare our actual velocity and projected completion date

是我們可以比較我們的實際速度和預計完成日期。

to what the team needs to do in order to finish OnTime.

到團隊需要做什麼才能完成OnTime。

This is perhaps the most useful piece of knowledge

這也許是最有用的知識

that any team member, product owner or product executive can have about the project,

任何團隊成員、產品負責人或產品主管都可以對項目進行。

because knowing whether or not the project is on track early in the schedule

因為在進度表的早期就知道項目是否走上了正軌。

can help teams make the proper adjustments necessary to get the project on track.

可以幫助團隊進行必要的適當調整，使項目走上正軌。

The burndown chart provides empirical proof that the project is on track or if it's going

消耗圖表提供了項目是否按部就班或是否要進行的經驗證明。

to be late.

要遲到了。

So, let's talk a little about where the data for this incredibly useful burndown chart

那麼，讓我們來談談這個令人難以置信的有用的爆表的數據在哪裡吧

comes from.

來自。

As you recall, part of the release planning process was to create an estimate for each

您還記得，發佈規劃流程的一部分是為每個項目創建一個估計值。

user-story in the release backlog.

用戶故事在發佈積壓。

The collection of these estimates for a given sprint represents the total amount of work

某一特定衝刺的這些估計值的集合代表了總的工作量。

that must be done to complete that sprint.

為了完成這個衝刺必須做的事情。

As each team member goes through and makes progress on one or more of the user-stories,

當每個團隊成員在一個或多個用戶故事上經歷並取得進展時。

they simply update the amount of time remaining for each of their own items.

他們只需更新自己每個項目的剩餘時間量即可。

So, the total amount of time remaining on the group of user-stories that make up a sprint,

所以，構成衝刺的用戶故事群的剩餘總時間。

changes on a day-by-day basis,

逐日變化。

hopefully going downward until it hits zero when the sprint is complete.

希望往下走，直到衝刺完成後達到零。

The burndown chart aggregates the remaining work data and shows it visually.

爆料圖將剩餘的工作數據進行彙總，並直觀地顯示出來。

It's brilliant because it communicates a massive amount of information in just a few seconds.

它的聰明之處在於它能在短短几秒鐘內傳達大量資訊。

And that brings us to this:

這也就引出了這個問題。

The Daily Scrum.

每天的Scrum。

The Daily Scrum is an essential tool to having communication flow freely between team members.

每日Scrum是讓團隊成員之間自由交流的重要工具。

The idea is to have fast paced stand-up meetings

我們的想法是開快節奏的站立會議。

where team members quickly list the work they completed since the last meeting,

在這裡，團隊成員迅速列出自上次會議以來完成的工作。

and any obstacles in their way.

和任何障礙。

By meeting daily, it ensures the team is always in-sync,

通過每天開會，確保團隊始終保持同步。

and any major issues are dealt with as soon as they are known.

並對任何重大問題一經瞭解，立即進行處理。

Finally, as each sprint comes to a finish,

最後，隨著每一次衝刺的結束。

it’s important to have a Sprint Retrospective meeting,

開一個衝刺回顧會很重要。

where the team can reflect on what went right and areas of improvement.

在這裡，團隊可以反思哪些地方做得對，哪些地方需要改進。

After all, Scrum is a flexible agile development method

畢竟，Scrum是一種靈活的敏捷開發方法

that needs constant improving and tweaking for every team.

這需要每個團隊不斷的改進和調整。

So, there you have it.

所以，你有它。

Scrum in under 10 minutes.

在10分鐘內完成Scrum。

You now know all the essential concepts to start implementing Scrum inside of your organization.

你現在知道了在你的組織中開始實施Scrum的所有基本概念。

But wait a second,

但等一下。

what about tools to help you implement Scrum?

幫助你實施Scrum的工具呢？

Well, it just so happens that I’ve spent the last 10 years building such a tool.

好吧，恰好我在過去的10年裡一直在打造這樣一個工具。

With a lot of help from these guys:

在這些人的大力幫助下。

a group of genius coders and design ninjas.

一群天才的編碼員和設計忍者。

The tool is called, OnTime,

這個工具叫，OnTime。

and it helps you manage your products, your backlogs, your team,

並幫助你管理你的產品、你的積壓、你的團隊。

your releases and your sprints.

你的發佈和你的衝刺。

It gives you project visibility with burndown charts,

它為您提供了項目的可見性與燃盡圖。

and always answers the question of who is working on what.

並始終回答著誰在研究什麼的問題。

You can get started with it for free, at Axosoft.com.

您可以在Axosoft.com上免費開始使用它。

Of course, you could use a giant white board, some note cards [Paper crumples]

當然，你也可以用一塊巨大的白板，一些便條卡[紙屑]

and a bunch of different spreadsheets [Paper crumples] to track everything.

和一堆不同的電子表格[紙皺]來追蹤一切。

You could also use an abacus instead of a calculator to do math, but we’re getting

你也可以用算盤代替計算器來做數學題，但我們要開始了

a little off topic.

有點跑題。

So, let's quickly review everything.

所以，讓我們'快速回顧一切。

In Scrum, you work with this: a Product Backlog,

在Scrum中，你的工作是：產品積壓。

which is nothing more than a list of features that we call User-Stories.

這不過是一個功能列表，我們稱之為用戶故事。

You then break down the product backlog into one or more Release Backlogs,

然後，您將產品積壓分解為一個或多個發佈積壓。

and for a given release, you further break up the release backlog

而對於一個給定的版本，您可以進一步分解發布積壓的版本。

into a number of Sprint Backlogs

變成一些Sprint積壓的工作

which are essentially short duration milestones throughout your project.

這基本上是整個項目的短期里程碑。

You then monitor the progress of each sprint using these: Burndown Charts

然後，你可以使用這些來監控每個衝刺的進度。Burndown Charts

and have Daily Scrum meetings to ensure everything is on track.

並召開每日Scrum會議，以確保一切都能按計劃進行。

After each sprint, you have a Retrospective meeting to fine-tune everything.

每一次衝刺後，你都要開一個回顧性會議，對一切進行微調。

And if you want a tool to implement Scrum, you can use, OnTime.

而如果你想要一個工具來實現Scrum，你可以使用，OnTime。

It'll help you ship software, OnTime.

它將幫助你按時發送軟件。

That’s all there is to it!

這就是所有的一切!

Oh, and one last thing.

哦，還有最後一件事。

Whether you loved or hated this video, I’d love to hear from you.

無論你是喜歡還是討厭這個視頻，我都很想聽聽你的意見。

You can reach me on twitter or via email if you have any feedback.

如果您有任何反饋意見，可以通過微博或電子郵件聯繫我。

Now get going,

現在去吧

Create a great team,

打造一支優秀的團隊。

Collaborate,

合作。

and Ship Software OnTime.

並按時發送軟件。

[Music with whistling fades]

[音樂隨著口哨聲漸漸消失]