Name: 10分以内にスクラム入門
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,'

数々の異なる会社で、私はスクラムを認識するようになりました。

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

今日使用されている最高のアジャイル開発プラクティスの1つとして。

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

でスクラムがなぜ素晴らしいのか、スクラムを始めるにはどうすればいいのかを紹介したいと思います。

私はスクラムのコアとなる概念をすべてカバーします。

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

製品のバックログ、チームの役割、スプリント、バーンダウン・チャートなど。

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,

スクラムでは、機能はエンドユーザー目線で書かれています。

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.

チームの中に1人以上、様々な役割を担ってくれる人が必要なんです。

プロダクトオーナーの役割を担っている。

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

彼はスクラムマスターであり、プロジェクトがスムーズに進むようにするのが彼の仕事です。

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.

だから、私たちは彼をスクラムマスターと呼ぶことにします[空手の叫び]彼はいくつかの柔術を知っていることをほのめかすために、[空手の叫び]。

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

例えば、1日以内に完了するもの

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

しかし、現実には、そのようなものを大幅に分解する必要があります。

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つから十数個のスプリントが必要になるでしょう。

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

そのため、各スプリントの最後には、すべての機能を備えた完全にテストされた製品を用意しなければなりません。

そのスプリントの100％が完了しました。

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

スプリントは非常に短いですが、製品の一部をリアルに表現しているので。

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:

そのため、これを使って各スプリントの進捗状況を監視することは非常に重要です。

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

バーンダウンチャートはスクラムの人気の理由の第一位です。

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

と、プロジェクトがスムーズに進むようにするための最高のプロジェクト可視化ツールの1つです。

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分以内にスクラム入門

entire

extremely

essential

prioritize