1 files changed, 207 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/2 - Cost of Change - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/2 - Cost of Change - lang_en_vs4.srt
new file mode 100644
index 0000000..3b5a261
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/2 - Cost of Change - lang_en_vs4.srt
@@ -0,0 +1,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.