字幕表 動画を再生する AI 自動生成字幕 字幕スクリプトをプリント 翻訳字幕をプリント 英語字幕をプリント [Music] [Music] 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,' 数々の異なる会社で、私はスクラムを認識するようになりました。 as one of the best agile development practices in use today. 今日使用されている最高のアジャイル開発プラクティスの1つとして。 In this fast-paced video, このテンポの速い動画では I want to show you why Scrum is so great, and how you can get started with Scrum in でスクラムがなぜ素晴らしいのか、スクラムを始めるにはどうすればいいのかを紹介したいと思います。 under 10 minutes. 10分以内に I'll cover all the core Scrum concepts, 私はスクラムのコアとなる概念をすべてカバーします。 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 この製品については、お客様や役員の方から、あらゆる機能の要望が寄せられたり other team members. 他のチームのメンバーも 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. 私たちの製品の特定のリリースに入れようとしています。 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. チームの中に1人以上、様々な役割を担ってくれる人が必要なんです。 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 彼はスクラムマスターであり、プロジェクトがスムーズに進むようにするのが彼の仕事です。 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. そして、他のチームは他の開発プロセスと似たような役割を持っています。 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 例えば、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 しかし、現実には、そのようなものを大幅に分解する必要があります。 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つから十数個のスプリントが必要になるでしょう。 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, スプリントは非常に短いですが、製品の一部をリアルに表現しているので。 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: そのため、これを使って各スプリントの進捗状況を監視することは非常に重要です。 A Burndown Chart. バーンダウンチャート。 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 バーンダウンチャートは、特定の 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. it's easy to see 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, 各チームのメンバーが1つ以上のユーザーストーリーを通過し、進捗を確認しながら 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. デイリースクラムです。 The Daily Scrum is an essential tool to having communication flow freely between team members. デイリースクラムは、チームメンバー間で自由にコミュニケーションが流れるようにするために必要不可欠なツールです。 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 結局のところ、スクラムは柔軟なアジャイル開発手法である that needs constant improving and tweaking for every team. そのためには、どのチームも常に改善と微調整を必要とします。 So, there you have it. だから、そこにはそれがあります。 Scrum in under 10 minutes. スクラムを10分以内に You now know all the essential concepts to start implementing Scrum inside of your organization. これで、組織の内部でスクラムの実装を開始するために必要なすべての重要な概念がわかりました。 But wait a second, でもちょっと待って what about tools to help you implement 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, スクラムでは、これを使って作業を行います。 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, その後、製品バックログを1つ以上のリリースバックログに分解します。 and for a given release, you further break up the release backlog で、与えられたリリースに対して、リリースバックログをさらに分割します。 into a number of Sprint Backlogs スプリントバックログの数に which are essentially short duration milestones throughout your project. これは、基本的にはプロジェクト全体を通しての短い期間のマイルストーンです。 You then monitor the progress of each sprint using these: Burndown Charts そして、これらを使用して各スプリントの進捗状況を監視します。バーンダウンチャート and have Daily Scrum meetings to ensure everything is on track. また、デイリースクラムミーティングを行い、すべてが軌道に乗っているかどうかを確認します。 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. そして、スクラムを実装するためのツールが欲しいなら、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. ご意見があれば、twitterやメールで連絡してください。 Now get going, さあ、行くぞ。 Create a great team, 素晴らしいチームを作る。 Collaborate, 協力してください。 and Ship Software OnTime. そして、ソフトウェアをOnTimeで出荷します。 [Music with whistling fades] [Whistling with Music with whistling fades]
B1 中級 日本語 米 スプリント リリース チーム ユーザー チャート 製品 10分以内にスクラム入門 827 78 Jimmy Cheng に公開 2017 年 03 月 19 日 シェア シェア 保存 報告 動画の中の単語