1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
|
1
00:00:00,290 --> 00:00:03,500
We will start our discussion about test written and development by going
2
00:00:03,500 --> 00:00:06,790
back to a softer life cycle to examine a little bit ago
3
00:00:06,790 --> 00:00:09,460
which is the waterfall life cycle. And if you remember, that was
4
00:00:09,460 --> 00:00:12,980
a totally rigid process in which we were preparing documents and we
5
00:00:12,980 --> 00:00:16,570
were not studying any phase before the previous one was finished. And
6
00:00:16,570 --> 00:00:19,710
once a phase was finished, we were really going back to it.
7
00:00:19,710 --> 00:00:22,110
So today we are going to examine how it is possible to go
8
00:00:22,110 --> 00:00:25,320
from such a rigid process to an agile one, in which we can
9
00:00:25,320 --> 00:00:27,800
better deal with changes. So remember what we saw in the
10
00:00:27,800 --> 00:00:31,510
first lesson when Barry Boehm stated that the cost of change
11
00:00:31,510 --> 00:00:35,830
grows exponentially with time. So if we imagine to have time
12
00:00:35,830 --> 00:00:39,400
over here on the x-axis and cost on the y-axis, we
13
00:00:39,400 --> 00:00:41,650
can see the cost that will go up more or less
14
00:00:41,650 --> 00:00:44,325
this way. And what that means is finding a problem while
15
00:00:44,325 --> 00:00:47,890
collecting requirements will cost you much less than finding a problem
16
00:00:47,890 --> 00:00:50,830
in the analysis phase, which in turn, will cost you less
17
00:00:50,830 --> 00:00:53,130
than finding a problem during design, and so on for
18
00:00:53,130 --> 00:00:56,110
the subsequent phases. So if this is the case, and cost
19
00:00:56,110 --> 00:00:59,450
is really growing this fast as we proceed in our process,
20
00:00:59,450 --> 00:01:01,530
what should we do? The key thing is to discover errors
21
00:01:01,530 --> 00:01:04,700
early before they become expensive, which in turn means doing a
22
00:01:04,700 --> 00:01:09,420
lot of upfront planning. And because models are cheaper to modify
23
00:01:09,420 --> 00:01:13,150
in code, we're willing to make large investments in upfront analysis
24
00:01:13,150 --> 00:01:16,150
and design models. And only after we have built and checked
25
00:01:16,150 --> 00:01:18,750
these models, we're going to go ahead and build the code. In
26
00:01:18,750 --> 00:01:20,178
other words, we are following
27
00:01:20,178 --> 00:01:23,140
a waterfall mentality. However, something definitely
28
00:01:23,140 --> 00:01:26,510
changed in the last 30 years. For example, 30 years ago,
29
00:01:26,510 --> 00:01:28,770
we needed to walk down the hall, submit a deck of
30
00:01:28,770 --> 00:01:31,490
cards to an operator, and wait a day for our program
31
00:01:31,490 --> 00:01:34,280
to run and produce some results. Today we can leverage the
32
00:01:34,280 --> 00:01:37,820
computational power of the cloud. Computers used to be very slow
33
00:01:37,820 --> 00:01:42,322
and very expensive. Today, computer are a thousand times faster and
34
00:01:42,322 --> 00:01:44,380
a thousand times cheaper than what they used to be. In
35
00:01:44,380 --> 00:01:47,530
particular, if you think about the compile and test cycle, that has
36
00:01:47,530 --> 00:01:51,110
gone from days to seconds. Now we can change our code, compile
37
00:01:51,110 --> 00:01:54,460
it, run it our tests, all in a matter of instants, something
38
00:01:54,460 --> 00:01:57,660
that was unthinkable before. Finally, developers in the past had to
39
00:01:57,660 --> 00:02:01,380
do a lot of tasks manually in a very time-consuming way and
40
00:02:01,380 --> 00:02:04,220
often in a very painful way. Today, on the contrary, we can
41
00:02:04,220 --> 00:02:07,540
now automate a lot of these tasks. We have high level programming
42
00:02:07,540 --> 00:02:11,890
languages, version control systems, smart ideas. Basically a whole set of tools
43
00:02:11,890 --> 00:02:15,110
that can help developers. And they can make them more efficient. In
44
00:02:15,110 --> 00:02:18,440
general, what that means is, it's easy to change, much easier than
45
00:02:18,440 --> 00:02:21,310
what it was before. So maybe if we take all that into account,
46
00:02:21,310 --> 00:02:23,430
the cost of change can be flat. So if we go back
47
00:02:23,430 --> 00:02:26,580
to our diagram, the one in which we showed the cost with
48
00:02:26,580 --> 00:02:29,930
respect to the project time, maybe instead of having this kind of
49
00:02:29,930 --> 00:02:32,740
curve, we might have a different kind of curve. Maybe the curve is
50
00:02:32,740 --> 00:02:36,020
more like this one. So maybe we can make all of this happen, as long as
51
00:02:36,020 --> 00:02:38,440
we use tools, practices and principles in the
52
00:02:38,440 --> 00:02:40,170
right way. And we're going to see what that means.
|
