MobileRobotK4/Education/bahan ajar/agile/IBM CD0116EN Agile and Scrum Fundamentals/1/3.1.1.7_Working_Agile-en.srt

0
00:00:07,200 --> 00:00:12,000
After watching this video, you'll be able to list the five practices of working Agile,

1
00:00:12,000 --> 00:00:17,200
explain working in small batches, define a minimum viable product, understand behavior

2
00:00:17,200 --> 00:00:22,720
driven development, understand test driven development, explain how pair programming works.

3
00:00:24,320 --> 00:00:31,200
So let's take a look at what it really means to work in an Agile fashion. First, you want to work in

4
00:00:31,200 --> 00:00:36,800
small batches. We get this from lean manufacturing. You don't want to make a big batch of something

5
00:00:36,800 --> 00:00:41,040
and then find out that you did it wrong because that's a lot of waste having to go back and change

6
00:00:41,040 --> 00:00:47,280
it. Next, you want to use minimum viable products to figure out what does the customer like, what

7
00:00:47,280 --> 00:00:52,480
doesn't the customer like. And then you want to use practices like behavior driven development

8
00:00:52,480 --> 00:00:58,400
and test driven development to improve your testing of the system from the outside in and

9
00:00:58,400 --> 00:01:03,760
from the inside out. And then finally you want to take advantage of pair programming. This came

10
00:01:03,760 --> 00:01:08,560
from extreme programming but pair programming is critically important. So we're going to look at

11
00:01:08,560 --> 00:01:16,800
each one of these in turn. Working in small batches-- let's say I need to mail out a thousand brochures.

12
00:01:17,600 --> 00:01:22,240
And the steps are you need to fold the brochures and then insert the brochures into envelopes,

13
00:01:22,240 --> 00:01:26,240
and then seal the envelopes and then finally stamp the envelopes with postage.

14
00:01:27,200 --> 00:01:32,560
So let's say that we're going to do these thousand in batches of 50, right, big batches, 50 a piece and

15
00:01:32,560 --> 00:01:37,600
assume that each step takes about six seconds to complete. So I can do about 10 steps per minute.

16
00:01:38,400 --> 00:01:44,080
And so we do the first step folding, right? And at 10 for a minute, it takes me about five minutes to

17
00:01:44,080 --> 00:01:50,160
fold 50 of them. Then I move on to the next step. The next step is inserting them all and again,

18
00:01:50,160 --> 00:01:55,440
if I could do about 10 of them per minute, and so it takes me five more minutes, plus the five

19
00:01:55,440 --> 00:02:00,080
minutes from before. Now I'm 10 minutes into it. I've got them all folded and inserted then I

20
00:02:00,080 --> 00:02:05,520
move on to step three sealing them all, right? So now again about 10 per minute I could do another

21
00:02:06,240 --> 00:02:12,160
50 in another five minutes. So I'm up to 15 minutes, right? Wall clock time. And then

22
00:02:12,160 --> 00:02:18,720
finally I get to step four and it took me 16 minutes to get my first finished product right?

23
00:02:18,720 --> 00:02:23,840
The first one where I had things that I could actually inspect it and see what the quality was.

24
00:02:23,840 --> 00:02:30,640
So, what if the envelopes had no glue, right? It would be 11 minutes before I figure out that

25
00:02:30,640 --> 00:02:34,400
something went wrong. What if there's a typo on the brochure? I have to go all the way back

26
00:02:34,400 --> 00:02:40,560
to the beginning, right? So, this is just very, very wasteful working in these large batches like this.

27
00:02:41,200 --> 00:02:45,920
Now let's look at the same example with single piece flow. And again, assume each step takes about

28
00:02:45,920 --> 00:02:51,840
six seconds to complete. With single piece flow, I fold, right? And put them in the envelope and

29
00:02:51,840 --> 00:02:57,040
seal them and put a stamp on them and the first finished product is in about 24 seconds. Now I

30
00:02:57,040 --> 00:03:02,800
can inspect it see if it works, see if it's what I thought it was, and then let the rest of the flow

31
00:03:02,800 --> 00:03:09,680
rip. Now what if the envelopes had no glue? Well I would find out after, uh, maybe 18 seconds, right?

32
00:03:09,680 --> 00:03:15,280
And if there was a typo in the brochure, after 24 seconds, so it's very, very important that we don't

33
00:03:15,280 --> 00:03:20,640
work in two larger batches so that we can get fast feedback and that we can pivot and understand,

34
00:03:20,640 --> 00:03:24,480
you know, do we need to do something different and then make the changes that we need to make?

35
00:03:25,680 --> 00:03:31,520
So let's talk about minimum viable product. First, let's understand what it is not, because there's

36
00:03:31,520 --> 00:03:36,800
a misconception that a minimum viable product is like phase one of the project or, you know,

37
00:03:36,800 --> 00:03:42,000
the first beta or something like that. And it's not. This is not what a minimum viable product is.

38
00:03:42,000 --> 00:03:47,920
A minimum viable product is the minimal thing that you can do to prove a hypothesis and gain

39
00:03:47,920 --> 00:03:53,040
learning and gain understanding. The difference between these two is that the first one is all

40
00:03:53,040 --> 00:03:57,120
about delivery, right? What am I going to deliver? But the second one is all about

41
00:03:57,120 --> 00:04:03,920
learning. What can I learn? What can I learn from putting out this MVP and get feedback

42
00:04:03,920 --> 00:04:10,000
and then maybe make the next one even better? So it's important that at the end of each MVP

43
00:04:10,000 --> 00:04:17,600
you decide whether to pivot or persevere. Let's look at an example. Here's a team that's developing

44
00:04:17,600 --> 00:04:22,800
a minimum viable product for a customer that wants a car. And so, in the first iteration, they deliver a

45
00:04:22,800 --> 00:04:27,280
wheel. The customer's like, "What am I going to do with a wheel? I can't do anything with this?" Like,

46
00:04:27,280 --> 00:04:31,920
well, we're working iterations, we're trying to be agile here, right? And so the next iteration, we'll

47
00:04:31,920 --> 00:04:36,640
give you some more. And they give them a chassis and it's like, okay, "I really can't do anything

48
00:04:36,640 --> 00:04:40,640
with this." And then finally, you know, they give them a car with no steering wheel and then

49
00:04:41,360 --> 00:04:48,080
eventually they get the car, right? And so they get this coupe. That team did not understand

50
00:04:48,080 --> 00:04:51,520
how to create a minimum viable product. They were just doing iterative development.

51
00:04:52,240 --> 00:04:58,560
The second team understands the value of creating an MVP. At first, they give them

52
00:04:58,560 --> 00:05:03,200
a skateboard and the customer's like, "I asked you for a car and you're giving me a skateboard."

53
00:05:03,200 --> 00:05:09,360
Whoa, whoa we're testing the color. How do you like that color red? Is that the color you want? "Oh yeah,

54
00:05:09,360 --> 00:05:15,280
red's kind of cool but you know it's really hard to steer." No, we'll fix that in the next MVP and

55
00:05:15,280 --> 00:05:20,160
then they add a way to steer it and the customer's like, "Well, okay, you did give me a way to steer it

56
00:05:20,160 --> 00:05:25,120
but I can't go very fast. I need a better form of locomotion." And then we'll deal with that in

57
00:05:25,120 --> 00:05:30,800
the next MVP. In the next iteration, they give them pedals. Somewhere along the way while the customer

58
00:05:30,800 --> 00:05:38,560
is riding on that motorcycle feeling the wind in their hair they decide, "I want a convertible." In the

59
00:05:38,560 --> 00:05:43,120
first instance, the customer got exactly what they asked for months before because they were just

60
00:05:43,120 --> 00:05:49,440
following a plan but in the second instance the customer got exactly what they desired

61
00:05:49,440 --> 00:05:55,200
because they were working interactively with the development team and in the end, you develop

62
00:05:55,200 --> 00:05:59,440
something that's a little bit different but it's closer to what the customer really, really wants.

63
00:06:01,280 --> 00:06:07,680
Behavior driven development is when we describe the system from the outside in. This is usually

64
00:06:07,680 --> 00:06:13,360
done at an integration testing level, right? So, this is where we're taking the customer's

65
00:06:13,360 --> 00:06:18,880
view of the system usually when you're doing BDD testing, you're doing it against the user interface,

66
00:06:18,880 --> 00:06:24,800
right? You're doing it against the thing that the customer sees to see if the system behaves the

67
00:06:24,800 --> 00:06:28,640
way it's supposed to. So, if it's an e-commerce system, when I put something in my cart, does it

68
00:06:28,640 --> 00:06:33,040
behave the way I want? When I transfer a cart to an order, does it behave the way I want? It's

69
00:06:33,040 --> 00:06:37,920
really taking an outside-in approach. It's not too concerned with the things going on underneath.

70
00:06:39,040 --> 00:06:44,720
The cool thing is it uses a single syntax that both the developers and the stakeholders can

71
00:06:44,720 --> 00:06:50,160
use to describe the system and agree on the behavior of the system, on what the system does.

72
00:06:50,160 --> 00:06:57,200
So, let's take a look at that syntax. It starts with these BDD feature scenarios. Where I say,

73
00:06:57,200 --> 00:07:03,680
"As a sum role, so, I want to know who is this for. I need some function, right? So what is

74
00:07:03,680 --> 00:07:09,600
it the functionality that we actually need so that I get some business value?" So, now you know

75
00:07:09,600 --> 00:07:14,240
who is it for. Is it for the customers? For the system administrator, right? Who's getting the

76
00:07:14,240 --> 00:07:19,840
value out of this what do they need and why do they need it? And that's the beginning of your

77
00:07:19,840 --> 00:07:25,440
feature file. And then you start running through scenarios and here's where we use this common

78
00:07:25,440 --> 00:07:32,560
syntax. It's known as Gherkin syntax after the Gherkin pickle. And it goes something like this:

79
00:07:32,560 --> 00:07:37,760
Given a set of preconditions, right? So, that kind of sets up the scenario-- given that this is true.

80
00:07:37,760 --> 00:07:43,920
I've got two items in my cart. I got three items that I order, whatever. When some event happens,

81
00:07:43,920 --> 00:07:50,320
right? So, that's the thing that's under test. Then I should see some observable outcome. So, using this

82
00:07:50,320 --> 00:07:56,560
given when-then syntax, developers can understand it, stakeholders can understand it, everybody can

83
00:07:56,560 --> 00:08:02,800
understand this common syntax that when I have something in my cart and then I clear my cart, you

84
00:08:02,800 --> 00:08:08,400
know, I should see nothing in my cart. So very, very important to have the syntax in these BDD

85
00:08:08,400 --> 00:08:17,600
scenarios. Test-driven development is testing a system from the inside out. Unlike behavior-driven

86
00:08:17,600 --> 00:08:22,720
development. It is concerned with the internals of the system, the single modules. Usually this

87
00:08:22,720 --> 00:08:27,680
is called unit testing, right? And this is something that is unit test case driven and we want to make

88
00:08:27,680 --> 00:08:33,280
sure that given these inputs I get these outputs at a small module level. I don't know if when I put

89
00:08:33,280 --> 00:08:37,920
them all together I'm going to get the behavior I want. That's kind of BDD but for TDD, test driven

90
00:08:37,920 --> 00:08:43,520
development, I'm just testing the system way down at the unit level and so you write a test

91
00:08:43,520 --> 00:08:48,720
case first for the code you wish you had and then you write enough code to make that test case pass

92
00:08:48,720 --> 00:08:53,280
and then you start all over again and refactor. So the workflow goes something like this:

93
00:08:53,280 --> 00:08:58,960
I write a test case. You might say, "You write test cases before you write the code?" Yeah this keeps me

94
00:08:59,760 --> 00:09:04,640
featured on what is the code supposed to do. When I call this, how do I want to call this? What are the

95
00:09:04,640 --> 00:09:09,920
parameters I think I  want to pass in and then what does it do for me? So, you write the test case first

96
00:09:09,920 --> 00:09:16,080
then you write enough code to make that test case pass and then once it passes then you can refactor

97
00:09:16,080 --> 00:09:21,120
the code because now you have test cases to keep you honest, you'll know if you broke anything.

98
00:09:21,120 --> 00:09:26,960
Now, because when the test case runs and it fails it usually turns red and then when it works

99
00:09:26,960 --> 00:09:33,360
correctly it turns green; we tend to call this Red, Green, Refactor. Watch a test case, write a test case

100
00:09:33,360 --> 00:09:38,800
watch it fail, make just write enough code to make it pass, and then refactor make it-- you might not

101
00:09:38,800 --> 00:09:42,560
have made it very elegant just to make it pass-- now you can go back and you can add all sorts of

102
00:09:42,560 --> 00:09:47,520
error checking and whatnot make it a little more, uh, robust and then run the test cases. Make sure

103
00:09:47,520 --> 00:09:55,280
you didn't break anything. Pair programming. Pair programming, you might say two programmers working

104
00:09:55,280 --> 00:10:00,960
together on the same thing, uh, and the first thing is: I'm paying two people to do one job?

105
00:10:01,600 --> 00:10:06,400
But actually it works out really, really well because what you're doing is you've got one

106
00:10:06,400 --> 00:10:11,360
person writing code and then you've got another person who has another set of eyes on the code.

107
00:10:11,360 --> 00:10:15,920
So the question is, would you rather find bugs in production? Would you rather find bugs while you're

108
00:10:15,920 --> 00:10:20,320
writing the code? It's a lot cheaper to find them while you're writing the code, so having two sets

109
00:10:20,320 --> 00:10:25,120
of eyes, they check each other and they go back and forth. It's not just one and then the other.

110
00:10:25,120 --> 00:10:29,840
Usually in 20 minute increments, right? Somebody's writing code, the other one is watching and they're

111
00:10:29,840 --> 00:10:33,760
not just watching. Sometimes they're looking things up, sometimes they're discussing. "What do you think

112
00:10:33,760 --> 00:10:38,000
I should call this variable? What do you think I should call this function?" Right? It's two sets of

113
00:10:38,000 --> 00:10:44,080
minds working around this code and what happens is you actually get higher quality code at the end of

114
00:10:44,080 --> 00:10:49,360
the day, right? The code quality goes up because two people have already checked it and so when

115
00:10:49,360 --> 00:10:54,560
you say, "I can't afford to pay two people to write one piece of code." You can't afford not to pay two

116
00:10:54,560 --> 00:10:59,280
people to write it because writing the code is the cheap part. Debugging it, maintaining in production,

117
00:10:59,280 --> 00:11:04,000
that's the expensive part and so if you want the expensive part to get cheaper you want to have

118
00:11:04,000 --> 00:11:09,040
your programmers do pair programming. It's also very good to put a senior programmer with a junior

119
00:11:09,040 --> 00:11:13,760
programmer. Now the junior programmers can see: How does the senior programmer approach the problem?

120
00:11:13,760 --> 00:11:18,480
And so they learn, they get mentorship, and then the senior program can see how the junior person

121
00:11:18,480 --> 00:11:23,600
is making out. Or you get people who are unfamiliar with the code working with someone who is. Now you

122
00:11:23,600 --> 00:11:27,760
get more people learning the code because they they're and they're getting like a tutorial from

123
00:11:27,760 --> 00:11:33,200
the other person. So pair programming is really, really great way of bringing all your people on

124
00:11:33,200 --> 00:11:39,440
your team up to a certain level. In this video you learn that working in small batches means

125
00:11:39,440 --> 00:11:45,840
delivering something useful quickly, an MVP is the cheapest, easiest thing you can do to test the

126
00:11:45,840 --> 00:11:50,640
hypothesis and learn. Behavior driven development makes sure you're building the right thing.

127
00:11:51,520 --> 00:11:54,240
And test driven development makes sure you're building the thing right.

128
00:11:55,360 --> 00:12:05,600
While pair programming enables you to discover defects earlier and increase your code quality.