diff options
Diffstat (limited to 'usth/ICT2.7/P4L4 Agile Development Methods Subtitles/2 - Cost of Change - lang_en_vs4.srt')
| -rw-r--r-- | usth/ICT2.7/P4L4 Agile Development Methods Subtitles/2 - Cost of Change - lang_en_vs4.srt | 207 |
1 files changed, 0 insertions, 207 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 deleted file mode 100644 index 3b5a261..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/2 - Cost of Change - lang_en_vs4.srt +++ /dev/null @@ -1,207 +0,0 @@ -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. |