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

0
00:00:08,090 --> 00:00:12,110
After watching this video, you'll be able to describe the Waterfall approach to software

1
00:00:12,110 --> 00:00:13,560
development.

2
00:00:13,560 --> 00:00:18,860
Explain the problems with the Waterfall approach, describe Extreme Programming approach, list

3
00:00:18,860 --> 00:00:22,430
of values of XP approach, define Kanban,

4
00:00:22,430 --> 00:00:25,310
and list its core principles.

5
00:00:25,310 --> 00:00:28,360
So, let's take a look at a traditional Waterfall development.

6
00:00:28,360 --> 00:00:32,820
It all starts out with a requirements phase. People are gathering requirements, seeing

7
00:00:32,820 --> 00:00:35,820
what the customer wants, making sure that we're going to deliver something that the

8
00:00:35,820 --> 00:00:38,780
customer wants. At least for that point in time.

9
00:00:38,780 --> 00:00:43,960
And so this is a phase where all you're doing is documenting all the requirements of the

10
00:00:43,960 --> 00:00:49,380
customer might want in the system. Then you move on to the design phase.

11
00:00:49,380 --> 00:00:51,329
Notice I'm using the term phases here.

12
00:00:51,329 --> 00:00:56,880
This is very important, because there was exit criteria and entrance criteria to move

13
00:00:56,880 --> 00:00:58,650
from one phase to the other.

14
00:00:58,650 --> 00:01:03,670
So once we've got all the requirements, we move on to the design, hoping that we have

15
00:01:03,670 --> 00:01:06,930
all the requirements that we actually need.

16
00:01:06,930 --> 00:01:10,840
So then in the design phase, the architects are designing. They're figuring out how do

17
00:01:10,840 --> 00:01:15,869
we take those requirements, turn them into working software, and so they design the entire

18
00:01:15,869 --> 00:01:16,869
system.

19
00:01:16,869 --> 00:01:20,270
And then once that phase is done, we move on to the coding phase.

20
00:01:20,270 --> 00:01:23,840
So this is where the developers are hackety hacking coding away.

21
00:01:23,840 --> 00:01:29,039
Now, you'll notice this is called Waterfall and those arrows are flowing down.

22
00:01:29,039 --> 00:01:32,599
because it's really hard to swim up a waterfall.

23
00:01:32,599 --> 00:01:34,649
This is an appropriate name.

24
00:01:34,649 --> 00:01:38,870
Because when you're in the coding phase, and you find out, this is a bad design, it doesn't

25
00:01:38,870 --> 00:01:42,930
work, it's real hard to go back up and redesign things.

26
00:01:42,930 --> 00:01:47,590
In fact, because we treat software development like civil engineering projects, sometimes

27
00:01:47,590 --> 00:01:52,310
some of those designers have moved on to the next project, and you've got to go find them.

28
00:01:52,310 --> 00:01:56,220
So very, very difficult to go back and swim with the waterfall.

29
00:01:56,220 --> 00:01:59,150
Then after coding, we finally get to integrate.

30
00:01:59,150 --> 00:02:04,470
So all along, we're coding in isolation, we're not integrating my module with the next person's

31
00:02:04,470 --> 00:02:07,820
module. You know, there's a time when all those modules come together. The first time

32
00:02:07,820 --> 00:02:11,849
we realized, do all these pieces of code even work together?

33
00:02:11,849 --> 00:02:15,459
And then we move on to the testing phase, because now we've got a system that people

34
00:02:15,459 --> 00:02:16,730
can test.

35
00:02:16,730 --> 00:02:21,760
And as they find bugs, they got to go back, swim up the waterfall, and open some bugs

36
00:02:21,760 --> 00:02:23,989
in the coding phase and do some recoding.

37
00:02:23,989 --> 00:02:28,370
And then if one of those bugs that they tested, turns out to be, you really need to change

38
00:02:28,370 --> 00:02:33,980
the design because these things aren't interacting well, way, way up the waterfall, very expensive

39
00:02:33,980 --> 00:02:36,569
to go back up to the design phase.

40
00:02:36,569 --> 00:02:41,580
And then finally, after all the testing is done, we deploy the software.

41
00:02:41,580 --> 00:02:43,879
So what's wrong with this approach?

42
00:02:43,879 --> 00:02:46,490
Well, there's no provision for change.

43
00:02:46,490 --> 00:02:48,840
Every phase has entrance and exit criteria.

44
00:02:48,840 --> 00:02:51,750
And when one ends, you know, the next one begins.

45
00:02:51,750 --> 00:02:55,640
And there's just no provision for going back and changing the design or changing the requirements

46
00:02:55,640 --> 00:02:57,840
or anything like that.

47
00:02:57,840 --> 00:03:01,940
So the other problem is, you don't know if it works to the end, right, there's no intermediate

48
00:03:01,940 --> 00:03:06,299
delivery. Nothing is delivered, until that last step, when we give it to the operations

49
00:03:06,299 --> 00:03:10,640
team and say, go deliver this thing into production.

50
00:03:10,640 --> 00:03:14,390
The other is that each step ends when the next one begins, that's where it got this

51
00:03:14,390 --> 00:03:17,590
waterfall name, where things are just passed down.

52
00:03:17,590 --> 00:03:22,689
And of course, every one of these is an opportunity to lose information, you know, and to have

53
00:03:22,689 --> 00:03:28,109
a mishap happen or to have people get blocked, because they can't accept, you know, the work

54
00:03:28,109 --> 00:03:29,400
from the previous phase.

55
00:03:29,400 --> 00:03:33,080
And now you're waiting to get that next phase going.

56
00:03:33,080 --> 00:03:38,060
The other is that mistakes are found later on are very, very costly, very costly to find

57
00:03:38,060 --> 00:03:42,439
something that's designed wrong and testing and go back and redesign it.

58
00:03:42,439 --> 00:03:46,579
And then finally, there's the long lead times, right between getting that software

59
00:03:46,579 --> 00:03:51,740
delivered. From the time you first want the software, and you design the software and

60
00:03:51,740 --> 00:03:52,760
code it and test it.

61
00:03:52,760 --> 00:03:56,569
And by the time you finally deliver it long, long, long lead times.

62
00:03:56,569 --> 00:04:01,620
So the problem here is teams are working separately, they're unaware of their impact to each other.

63
00:04:01,620 --> 00:04:05,579
Right, designers are unaware of the impact of the code, the coders are unaware of their

64
00:04:05,579 --> 00:04:07,720
impact to integrating all the code together.

65
00:04:07,720 --> 00:04:11,139
There everybody's working in their little silos for their little phase.

66
00:04:11,139 --> 00:04:13,609
And then this should be a scary thought.

67
00:04:13,609 --> 00:04:19,470
The people who are furthest away from a code, the poor operations team, have to run this

68
00:04:19,470 --> 00:04:21,700
and manage this in production, right?

69
00:04:21,700 --> 00:04:26,750
They know the least about the code, and they're the ones who are expected to run it.

70
00:04:26,750 --> 00:04:28,340
Not very efficient.

71
00:04:28,340 --> 00:04:31,600
Let's talk about another methodology, extreme programming.

72
00:04:31,600 --> 00:04:33,610
This was introduced back in 96.

73
00:04:33,610 --> 00:04:38,140
Kent Beck introduced this and if you look at the graphic on the right, you'll see that

74
00:04:38,140 --> 00:04:41,490
it is very iterative and talking about loops.

75
00:04:41,490 --> 00:04:44,680
You've got these major release plan on the outer loop.

76
00:04:44,680 --> 00:04:46,400
And then you've got an iteration plan.

77
00:04:46,400 --> 00:04:49,280
And so the release maybe months, the iterations maybe weeks,

78
00:04:49,280 --> 00:04:54,340
acceptance has maybe days, stand up meetings once a day, right, pair negotiation in hours,

79
00:04:54,340 --> 00:04:58,180
unit testing in minutes, pair prpgramming in seconds.

80
00:04:58,180 --> 00:05:04,690
You know, it's these tighter and tighter loops of doing work and then getting fast feedback.

81
00:05:04,690 --> 00:05:08,160
It's based on an iterative approach to software development.

82
00:05:08,160 --> 00:05:10,580
And in fact, this is where Agile got it from.

83
00:05:10,580 --> 00:05:15,131
And the intent here is to improve software quality, right? Be responsive to change, be

84
00:05:15,131 --> 00:05:18,930
responsive to customer requirements, do things in small increments.

85
00:05:18,930 --> 00:05:25,180
And so many people recognize Extreme Program as one of the first Agile methods.

86
00:05:25,180 --> 00:05:28,009
So let's talk about Extreme Programming values.

87
00:05:28,009 --> 00:05:29,620
First is simplicity, right?

88
00:05:29,620 --> 00:05:30,820
Do what you need

89
00:05:30,820 --> 00:05:36,050
and no more, don't over-engineer, don't over code, don't deliver more code than the customer

90
00:05:36,050 --> 00:05:37,050
asked for.

91
00:05:37,050 --> 00:05:39,069
Keep it simple, very important.

92
00:05:39,069 --> 00:05:41,020
The next one is communication.

93
00:05:41,020 --> 00:05:44,830
Everyone on the team should be communicating know what everyone else is doing, it fosters

94
00:05:44,830 --> 00:05:49,639
a lot, a lot of communication, and people interacting. Very important as well.

95
00:05:49,639 --> 00:05:53,830
And then feedback, you have no idea how you're doing unless you're getting feedback.

96
00:05:53,830 --> 00:05:58,540
So having those feedback loops are critical to extreme programming, and critical to Agile

97
00:05:58,540 --> 00:06:00,070
in general.

98
00:06:00,070 --> 00:06:04,580
And then respect, everyone feels that they are respected on the team, that they can offer

99
00:06:04,580 --> 00:06:09,440
advice that they can make suggestions, and that their suggestions are just as valuable

100
00:06:09,440 --> 00:06:11,270
as anybody else's suggestion on the team.

101
00:06:11,270 --> 00:06:16,520
There's no hierarchy, everybody has peers on the team, and respected for their ideas.

102
00:06:16,520 --> 00:06:21,020
And then finally, courage, right, we don't pad our estimates, we're just very honest

103
00:06:21,020 --> 00:06:22,690
about we think we could do this

104
00:06:22,690 --> 00:06:24,130
And we don't think we can do that.

105
00:06:24,130 --> 00:06:27,199
And we're not going to lie to you that we you know, we can get this, this done in this

106
00:06:27,199 --> 00:06:28,280
amount of time.

107
00:06:28,280 --> 00:06:32,750
We're very open and honest in Extreme Programming on, these are the estimates, this is what we'll commit

108
00:06:32,750 --> 00:06:33,750
to.

109
00:06:33,750 --> 00:06:35,639
Next, there's Kanban.

110
00:06:35,639 --> 00:06:38,520
This comes from the Japanese manufacturing systems.

111
00:06:38,520 --> 00:06:43,221
And kanban literally means billboard sign, and it's all about continuous flow on the

112
00:06:43,221 --> 00:06:48,569
manufacturing floor, where these cards or notes would flow with the product from station

113
00:06:48,569 --> 00:06:52,050
to station, going down the line.

114
00:06:52,050 --> 00:06:55,550
So the core principle with Kanban are visualize the workflow.

115
00:06:55,550 --> 00:06:58,450
If you can't see the work, you can't manage the work.

116
00:06:58,450 --> 00:07:02,080
And this is something we take into Agile too. You're going to find out we're going

117
00:07:02,080 --> 00:07:03,580
to use Kanban boards and Agile.

118
00:07:03,580 --> 00:07:08,039
And it's all about visualizing the work, very important that you can understand the work

119
00:07:08,039 --> 00:07:14,660
that needs to be done, and everything is accounted for. Kanban also stresses limit the work in

120
00:07:14,660 --> 00:07:19,300
progress. You don't want, when you're on a manufacturing floor, you don't want work to back up at one

121
00:07:19,300 --> 00:07:20,300
of the stations.

122
00:07:20,300 --> 00:07:23,470
But even when you're developing software, you don't want to have people working on too

123
00:07:23,470 --> 00:07:25,040
many things at once.

124
00:07:25,040 --> 00:07:29,080
Because, you know, you can only ship 100% of one thing that's working, you can't ship

125
00:07:29,080 --> 00:07:30,080
50% of two things.

126
00:07:30,080 --> 00:07:33,180
And so if you got one person working on two things, it's not good.

127
00:07:33,180 --> 00:07:37,300
And that comes from Kanban to limit the work in progress.

128
00:07:37,300 --> 00:07:41,860
Then there's managing and enhancing the flow. In Kanban, they're always looking to improve.

129
00:07:41,860 --> 00:07:46,479
They're always looking to change and understand how can we get a better flow, a quicker flow

130
00:07:46,479 --> 00:07:52,889
on the manufacturing floor, and then making policies explicit, so that everyone understands

131
00:07:52,889 --> 00:07:54,189
how things work.

132
00:07:54,189 --> 00:07:58,659
And everyone understands the definition of "done," what does it mean to have something be

133
00:07:58,659 --> 00:08:04,840
"done." We take that also from Kanban in our Agile planning to understand what the definition

134
00:08:04,840 --> 00:08:06,300
of"done" is.

135
00:08:06,300 --> 00:08:11,520
And then continuously improving, very, very important to get feedback and continuously

136
00:08:11,520 --> 00:08:12,520
improve on what you're doing.

137
00:08:12,520 --> 00:08:17,850
So Kanban is all about making the flows work better, understanding them, seeing them,

138
00:08:17,850 --> 00:08:22,530
being able to measure them, and then continuously improving on how we can flow faster.

139
00:08:22,530 --> 00:08:27,500
In this video, you learn that your traditional Waterfall approach to software development

140
00:08:27,500 --> 00:08:32,520
is a structured, step-by-step process that can lead to problems not surfaced until later

141
00:08:32,520 --> 00:08:33,980
in development.

142
00:08:33,980 --> 00:08:38,820
The extreme programming was developed to improve software quality and responsiveness to changing

143
00:08:38,820 --> 00:08:40,540
requirements.

144
00:08:40,540 --> 00:08:46,150
XP values include simplicity, communication, feedback, respect, and courage.

145
00:08:46,150 --> 00:08:52,270
Kanban is a system characterized by visualizing workflow, limiting work in progress, managing

146
00:08:52,270 --> 00:08:58,053
and enhancing the flow, making process policies explicit and continuously improving the process.