쉐도잉 연습: Intro to Scrum in Under 10 Minutes - 영상으로 영어 말하기 배우기
연습 모드 선택
각 모드는 전체 화면 연습실로 열립니다.
122 문장
문장이 너무 짧거나 길면 Edit를 눌러 조정하세요.
1
Hi, this is me.
2
My name is Hamid Chodjai
3
and I've been involved with a number of software development projects over the years at a number of different companies
4
and I've come to recognize Scrum as one of the best agile development practices in use today.
5
In this fast-paced video, I want to show you why Scrum is
6
so great and how you can get started with Scrum in under 10 minutes.
7
I'll cover all the core Scrum concepts like product backlogs, team roles, sprints, turn-down charts, and more.
8
So get ready to be bombarded with information.
9
Let's say this is the product we want to build.
10
For this product, we get all kinds of feature requests from customers, executives, or even other team members.
11
In Scrum, features are written from the perspective of the end-user.
12
Therefore, features are known as user stories.
13
The collection of all these user stories is called the product backlog.
14
Another way to think of the product backlog is to think
15
of it as a wish list of all the things that would make this product great.
16
Once we have our wish list or the product backlog, we need to start planning which specific user stories we're going to be putting into a particular release of our product.
17
But we're getting ahead of ourselves.
18
Let's back up a bit.
19
To build this product, we need to have one
20
or more people in our team who are going to play a variety of roles.
21
First, we need her.
22
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.
23
She helps set the direction of the product.
24
Then we need this guy.
25
He's the scrum master and his job is to make sure the project is progressing smoothly
26
and that every member of the team has the tools they need to get their job done.
27
He sets up meetings, monitors the work being done and facilitates release planning.
28
He's a lot like a project manager but that's such a boring title
29
so we'll call him a scrum master to imply he knows some jujitsu.
30
And the rest of the team has similar roles to other development processes.
31
These guys build the product while these guys test it to make sure to make sure it works right.
32
These guys use it and hopefully pay for it.
33
And these guys, they generally get in the way, but it turns out you can't build many products without them.
34
But let's get back to this, release planning.
35
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.
36
These user stories then become part of the release backlog.
37
The team then prioritizes the user stories and estimates the amount of work involved for each item.
38
Sometimes larger user stories are broken down into smaller, more manageable chunks.
39
The collection of all the estimates provides a rough idea of the total amount of work involved to complete the entire release.
40
A quick side note about estimates.
41
There are a lot of techniques for creating good estimates.
42
Some prefer estimating in story points, where estimates are made relative to building a small component with a known level of difficulty.
43
Unfortunately, story points don't answer the question of, when will my project ship?
44
I've found that the best technique is to estimate work in hours, but to use some standards in how estimates are done.
45
For example, things that take less than a day to complete will be estimated as 1 hour, 2 hours, 4 hours, or 8 hours.
46
Every item will fall into one of those buckets.
47
There will be no 3-hour estimates, for example.
48
A 3-hour item would fall into the 4-hour bucket.
49
Larger items will be estimated as 2 days, 3 days, 5 days, or 10 days.
50
Again, all estimates in between will fall into the next larger bucket.
51
Extremely large items are similarly estimated in months.
52
1, 2, 3, or 6 months.
53
But the reality is that such items will need to be broken down substantially before work actually begins.
54
We'll come back to these estimates in just a minute.
55
But for now, let's get back to this, the release backlog.
56
With a prioritized set of user stories and the estimated amount of work at hand, we're now ready to plan out several sprints to get the work done.
57
Sprints are short duration milestones that allow teams to tackle a manageable chunk of the project
58
and get it to a ship ready state.
59
Sprints generally range from a couple of days to as much as 30 days in length, depending on the product's release cycles.
60
The shorter the release cycles, the shorter each sprint should be.
61
And you'll want to have at least two to as many as a dozen sprints in a given release.
62
So at this point, we can take our release backlog and split it up into several of these, sprint backlogs.
63
One of the most important things to remember about sprints is
64
that the goal of each sprint is to get a subset of the release backlog to a ship-ready state.
65
So at the end of each sprint, you should have a fully tested product with all the features of the sprint 100% complete.
66
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
67
that the project is not on schedule and something needs to be done.
68
Therefore, it's extremely important to monitor the progress of each sprint with this, a burndown chart.
69
The burndown chart is the number one reason for scrum's popularity
70
and one of the best project visibility tools to ensure a project is progressing smoothly.
71
The burndown chart provides a day-by-day measure of the amount of work that remains in a given sprint or release.
72
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.
73
Because historical information is provided in the burndown chart, it's easy to see if the team is on the right track.
74
Using the burndown chart, the team can quickly calculate this, the slope of the graph, which is also called the burndown velocity.
75
This is the average rate of productivity for each day.
76
For example, a team's rate of productivity might be that on a typical day they finish approximately 50 hours of work.
77
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.
78
What's great about the burndown chart is that we can compare our actual velocity
79
and projected completion date to what the team needs to do in order to finish on time.
80
This is perhaps the most useful piece of knowledge that any team member, product owner, or product executive can have about the project.
81
Because knowing whether
82
or not the project is on track early in the schedule
83
can help teams make the proper adjustments necessary to get the project on track.
84
The burndown chart provides empirical proof that the project is on track or if it's going to be late.
85
So let's talk a little about where the data for this incredibly useful burndown chart comes from.
86
As you recall, part of the release planning process was to create an estimate for each user story in the release backlog.
87
The collection of these estimates for a given sprint represents the total amount of work
88
that must be done to complete that sprint.
89
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.
90
So the total amount of time remaining on the group of user stories
91
that make up a sprint changes on a day-by-day basis, hopefully going downward until it hits zero when the sprint is complete.
92
The burndown chart aggregates the remaining work data and shows it visually.
93
It's brilliant because it communicates a massive amount of information in just a few seconds.
94
And that brings us to this, the daily scrum.
95
The daily scrum is an essential tool to having communication flow freely between team members.
96
The idea is to have fast-paced, stand-up meetings where team members quickly list the work they have completed since the last meeting and any obstacles in their way.
97
By meeting daily, it ensures the team is always in sync
98
and any major issues are dealt with as soon as they are known.
99
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.
100
After all, Scrum is a flexible, agile development method that needs constant improving and tweaking for every team.
101
So there you have it, Scrum in under 10 minutes.
102
You now know all the essential concepts to start implementing Scrum inside of your organization.
103
But wait a second, what about tools to help you implement Scrum?
104
Well, it just so happens that I've spent the last 10 years building such a tool, with a lot of help from these guys, a group of genius coders and design ninjas.
105
The tool is called OnTime, and it helps you manage your products, your backlogs, your team, releases and your sprints.
106
It gives you project visibility with burndown charts and always answers the question of who is working on what.
107
You can get started with it for free at Axiosoft.com.
108
Of course, you could use a giant whiteboard, some note cards, and a bunch of different spreadsheets to track everything.
109
You could also use an abacus instead of a calculator to do math, but we're getting a little off topic.
110
So let's quickly review everything.
111
In Scrum, you work with this, a product backlog, which is nothing more than a list of features that we call user stories.
112
You then break down the product backlog into one or more release backlogs.
113
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.
114
You then monitor the progress of each sprint using these, burndown charts, and have daily scrum meetings to ensure everything is on track.
115
After each sprint, you have a retrospective meeting to fine-tune everything.
116
And if you want a tool to implement scrum, you can use OnTime.
117
It'll help you ship software OnTime.
118
That's all there is to it.
119
Oh, and one last thing.
120
Whether you loved or hated this video, I'd love to hear from you.
121
You can reach me on Twitter or via email if you have any feedback.
122
Now get going, create a great team, collaborate, and ship software on time.
앱 다운로드
유창하게 말하는 데 필요한 모든 것
AI 발음 평가문장마다 점수 확인
IPA 발음 연습모든 소리 마스터
단어 학습나만의 단어장 만들기
단어 게임놀면서 외우기
FOR YOU
추천 영상
C16
44 문장
Scrum Events
Business EnglishUniversity StudentsWorking Adults
C12
30 문장
C++ in 100 Seconds
American AccentBusiness EnglishUniversity StudentsWorking Adults
C12
213 문장
The Technical, Business and UX Skills Every Product Manager Needs
Business EnglishUniversity StudentsWorking Adults
C18
24 문장
Introducing Automations: always-on coding agents
Business EnglishUniversity StudentsWorking Adults
C12
494 문장
Everything we learned in 29 minutes at Harvard Business School (part 1)
Business EnglishUniversity StudentsWorking Adults
C11
83 문장
How an Agile Coach can help Product Owners
Daily ConversationUniversity StudentsWorking Adults
C12
155 문장
On the Power of the 15 Minute Habit
Business EnglishUniversity StudentsWorking Adults
C13
260 문장
【TED】優れたリーダーはどうやって行動を促すか/サイモン・シネック （日本語字幕）
Business EnglishDaily ConversationUniversity Students
B228
29 문장
How to build a startup in one month | Pieter Levels and Lex Fridman
Business EnglishUniversity StudentsWorking Adults
C11
343 문장
FREE 30 minutes Disciplined Agile Senior Scrum Master Overview + Q&A Session
Daily ConversationUniversity StudentsWorking Adults
C110
25 문장
10 Usability Heuristics: From Theory to Practice | Course Preview
Business EnglishUniversity StudentsWorking Adults
C11
28 문장
Kubernetes Explained in 100 Seconds
American AccentBusiness EnglishUniversity StudentsWorking Adults
맥락 및 배경
오늘의 영상에서는 Hamid Chodjai가 스크럼(Scrum)이라는 애자일 개발법에 대해 소개합니다. 그는 여러 소프트웨어 개발 프로젝트에 참여한 경험을 바탕으로, 스크럼이 왜 뛰어난지, 그리고 10분 안에 어떻게 시작할 수 있는지를 설명합니다. 그는 제품 백로그, 팀 역할, 스프린트, 차트 생성 등의 핵심 개념을 간략하게 다루며, 이러한 내용을 이해하는 것이 얼마나 중요한지를 강조합니다.
일상 대화를 위한 Top 5 구문
- “이 제품을 구축하기 위해서 우리는..." - 다른 사람들과 프로젝트를 계획할 때 꼭 필요한 시작 문구입니다.
- “제품 소유자 역할을 하다.” - 특정한 역할에 대한 설명을 할 때 유용합니다.
- “스프린트 계획을 세우다.” - 각 작업을 일정에 맞춰 조율할 때 사용하는 표현입니다.
- “사용자 스토리로 제품의 기능을 쓰다.” - 제품 개발에서 사용자 관점을 강조할 때 유용합니다.
- “작업의 양을 추정하다.” - 업무량 및 일정을 계획할 때 필요합니다.
단계별 섀도잉 가이드
이 비디오의 내용을 섀도스피크(shadowspeak) 연습을 통해 더 잘 이해할 수 있습니다. 다음 단계를 따라해 보세요:
- 1단계: 비디오를 처음부터 끝까지 시청합니다. 전체적인 내용을 파악하고, 말하는 사람의 억양과 발음을 익히세요.
- 2단계: 특정 구문이나 대사를 반복해서 들어보세요. 예를 들어, “사용자 스토리로 제품의 기능을 쓰다”와 같은 기술적 용어에 집중하세요.
- 3단계: 구문을 하나씩 따라 해서 영어 발음 교정(영어 발음 교정)을 실천해 보세요. 발음의 유사성과 리듬에 주의하면서 연습합니다.
- 4단계: 비디오를 잠시 멈추고, 자신이 했던 발음을 녹음해보세요. 이를 통해 자신의 발음을 점검할 수 있습니다.
- 5단계: 반복 학습 후, 같은 스크립트를 다른 주제로 바꾸어 연습해 보세요. 이는 shadow speech와 관련된 경험을 높이는 데 도움이 됩니다.
이러한 연습을 통해, 여러분은 스크럼의 개념뿐만 아니라 영어에 대한 자신감을 높일 수 있습니다. 효과적인 shadowing site를 활용하여 지속적으로 영어 실력을 향상시키세요.
이 영상의 문법
화자가 가장 많이 쓰는 문형을 영상 속 실제 표현과 함께 정리했습니다.
| 문형 | 영상 속 표현 |
|---|---|
| 수동태 be + 과거분사 — 누가 하는지보다 무슨 일이 일어나는지에 초점 | I've been involved · be bombarded · are written |
| 현재완료 have/has + 과거분사 — 과거의 일이 지금도 관련이 있을 때 | I've been involved · I've come · I've found |
| 관계절 who / which + 절 — 사람이나 사물에 대한 추가 정보 | graph, which is · backlog, which is · backlogs, which are |
쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법
쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.