diff options
Diffstat (limited to 'usth/ICT2.7/P4L4 Agile Development Methods Subtitles')
19 files changed, 0 insertions, 2201 deletions
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/1 - Lesson Overview - lang_en_vs4.srt deleted file mode 100644 index 2e839f9..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/1 - Lesson Overview - lang_en_vs4.srt +++ /dev/null @@ -1,75 +0,0 @@ -1 -00:00:00,270 --> 00:00:02,880 -In previous lessons, we covered testing principles and - -2 -00:00:02,880 --> 00:00:06,610 -techniques. In this lesson, we will discuss a - -3 -00:00:06,610 --> 00:00:09,550 -type of software process that is heavily based - -4 -00:00:09,550 --> 00:00:12,812 -on the use of testing. The agile development - -5 -00:00:12,812 --> 00:00:17,310 -process. Also called test-driven development. To do that, - -6 -00:00:17,310 --> 00:00:19,290 -we will revisit some of the assumptions that - -7 -00:00:19,290 --> 00:00:21,490 -led to the definition of the more traditional - -8 -00:00:21,490 --> 00:00:24,030 -software processes. The ones that we discussed so far. - -9 -00:00:25,440 --> 00:00:27,690 -We will see how, when some of these assumptions are - -10 -00:00:27,690 --> 00:00:30,210 -no longer valid, we can change the way in which we - -11 -00:00:30,210 --> 00:00:32,560 -look at software processes. And we can change the way - -12 -00:00:32,560 --> 00:00:36,120 -in which we look at software development in general. We will - -13 -00:00:36,120 --> 00:00:40,250 -discuss how this changing perspective, lets us rethink software processes - -14 -00:00:40,250 --> 00:00:43,520 -and make them more agile and better suited for context in - -15 -00:00:43,520 --> 00:00:46,120 -which changes are the norm and we need to adapt - -16 -00:00:46,120 --> 00:00:50,535 -fast. In particular, we will discuss two processes that apply the - -17 -00:00:50,535 --> 00:00:53,570 -principles of agile software development and that are commonly - -18 -00:00:53,570 --> 00:00:59,170 -used in industry. Extreme programming, also called XP, and Scrum. - -19 -00:00:59,170 --> 00:01:01,560 -[BLANK_AUDIO] diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/10 - Refactoring - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/10 - Refactoring - lang_en_vs4.srt deleted file mode 100644 index 800ffb5..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/10 - Refactoring - lang_en_vs4.srt +++ /dev/null @@ -1,103 +0,0 @@ -1 -00:00:00,100 --> 00:00:02,469 -A couple of minutes ago we talked about the fact that well, we - -2 -00:00:02,469 --> 00:00:05,260 -might need to change our design a lot, so how we going to do - -3 -00:00:05,260 --> 00:00:08,540 -that, that's going to be expensive. Well it's not very expensive, if we can - -4 -00:00:08,540 --> 00:00:10,876 -do efficient refactoring. Which is another - -5 -00:00:10,876 --> 00:00:13,120 -one of the important xp practices. And - -6 -00:00:13,120 --> 00:00:15,280 -what does it mean to refactor? It means to take a piece of - -7 -00:00:15,280 --> 00:00:19,530 -code who's design might be suboptimal, because for example, we evolved it, we - -8 -00:00:19,530 --> 00:00:22,600 -didn't take into account that from the beginning some of the features that - -9 -00:00:22,600 --> 00:00:25,110 -had to be added later, probably because we didn't even know about this - -10 -00:00:25,110 --> 00:00:28,200 -feature, because the requirements evolved. So we're going to take this piece - -11 -00:00:28,200 --> 00:00:31,870 -of code and we're going to restructure it, so that it becomes simple - -12 -00:00:31,870 --> 00:00:34,070 -and maintainable. Developers are expected to - -13 -00:00:34,070 --> 00:00:35,590 -refactor as soon as opportunities for - -14 -00:00:35,590 --> 00:00:39,530 -improvement, are found. And that happens for example, before adding some code. - -15 -00:00:39,530 --> 00:00:41,730 -You might look at the code that you're about to modify, or - -16 -00:00:41,730 --> 00:00:43,850 -to which you are about to add parts, and say can we - -17 -00:00:43,850 --> 00:00:47,060 -change the program to make the addition simple, that has maintainability or - -18 -00:00:47,060 --> 00:00:50,220 -we can do it after adding some code to our code base. - -19 -00:00:50,220 --> 00:00:52,730 -We might look at the code, the resulting code, and say well - -20 -00:00:52,730 --> 00:00:55,770 -can we make the program simpler? Was the running all the tests - -21 -00:00:55,770 --> 00:00:57,920 -and the key point here is that we don't want to refactor on - -22 -00:00:57,920 --> 00:01:01,580 -speculation, but we want to refactor on demand, on the system, and the - -23 -00:01:01,580 --> 00:01:04,840 -process needed. Again the goal is just to keep the code simple - -24 -00:01:04,840 --> 00:01:07,680 -and maintainable, not to over do it. And as I mentioned before - -25 -00:01:07,680 --> 00:01:10,810 -we're going to have a whole lesson, the next lesson on refactoring. So - -26 -00:01:10,810 --> 00:01:13,470 -we're going to go in more depth in the discussion of this topic. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/11 - Pair Programming - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/11 - Pair Programming - lang_en_vs4.srt deleted file mode 100644 index ad48828..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/11 - Pair Programming - lang_en_vs4.srt +++ /dev/null @@ -1,99 +0,0 @@ -1 -00:00:00,100 --> 00:00:02,530 -The next practice I want to discuss is a very important one - -2 -00:00:02,530 --> 00:00:05,750 -in XP, and also one of the scandal, controversial, and it's - -3 -00:00:05,750 --> 00:00:08,390 -the practice of pair programming. What does it mean? It means - -4 -00:00:08,390 --> 00:00:11,790 -that all production code is written with two people looking at one - -5 -00:00:11,790 --> 00:00:15,170 -machine. And not that they're, they're working with one keyboard and - -6 -00:00:15,170 --> 00:00:18,450 -one mouse or they're not just interfering and writing on each other's - -7 -00:00:18,450 --> 00:00:20,920 -code. And the way in which that happens is by playing - -8 -00:00:20,920 --> 00:00:25,180 -different roles at different times. So the two developers alternate between the - -9 -00:00:25,180 --> 00:00:29,080 -role of programming and strategizing, where strategizing means, for example, - -10 -00:00:29,080 --> 00:00:31,660 -looking at the code that has been written and thinking whether - -11 -00:00:31,660 --> 00:00:34,420 -that would work. Or what other tests that are not there - -12 -00:00:34,420 --> 00:00:37,050 -might not work, given the way the code is being written. - -13 -00:00:37,050 --> 00:00:39,300 -Or maybe looking at the code from a, you know, slightly - -14 -00:00:39,300 --> 00:00:42,380 -detached perspective and trying to figure out whether the code can - -15 -00:00:42,380 --> 00:00:46,900 -be made simpler, more maintainable, more efficient. And interestingly, there are - -16 -00:00:46,900 --> 00:00:48,440 -measurements, there are studies that - -17 -00:00:48,440 --> 00:00:50,340 -suggest that development productivity with pair - -18 -00:00:50,340 --> 00:00:52,550 -programming is similar to that of two people - -19 -00:00:52,550 --> 00:00:55,080 -working independently. And that answers one of the - -20 -00:00:55,080 --> 00:00:57,740 -main objections against pair programming, which is why - -21 -00:00:57,740 --> 00:00:59,840 -should I put two developers together, which is - -22 -00:00:59,840 --> 00:01:01,860 -going to cut their productivity in half. It is - -23 -00:01:01,860 --> 00:01:04,390 -not. Studies shows that that does not happen. - -24 -00:01:04,390 --> 00:01:06,380 -And that the resulting code can actually benefit - -25 -00:01:06,380 --> 00:01:08,350 -from the fact that two developers are working together. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt deleted file mode 100644 index d40bda6..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt +++ /dev/null @@ -1,111 +0,0 @@ -1 -00:00:00,280 --> 00:00:02,980 -An important practice to get all of this to work is - -2 -00:00:02,980 --> 00:00:05,230 -continuous integration, which means integrating and - -3 -00:00:05,230 --> 00:00:06,770 -testing every few hours, or a - -4 -00:00:06,770 --> 00:00:10,390 -day at most, because we don't want problems to pile up and - -5 -00:00:10,390 --> 00:00:13,060 -to be discovered too late when there are too many of them - -6 -00:00:13,060 --> 00:00:16,020 -to fix. So what goes on here is a cycle. And the - -7 -00:00:16,020 --> 00:00:19,380 -cycle starts with the developer's programming, as soon as the developers are - -8 -00:00:19,380 --> 00:00:22,050 -done modifying the code and they have a stable version they will - -9 -00:00:22,050 --> 00:00:25,380 -run the local tests. If the local tests fail, the developers will - -10 -00:00:25,380 --> 00:00:28,350 -go back to programming to fix their code and possibly add - -11 -00:00:28,350 --> 00:00:31,990 -new code as needed, and this cycle, mini cycle will continue - -12 -00:00:31,990 --> 00:00:35,000 -until all the local tests pass. At that point the developers - -13 -00:00:35,000 --> 00:00:37,960 -can integrate their code with the code of other developers. And they - -14 -00:00:37,960 --> 00:00:41,220 -can run test for the integrated system, and when they run - -15 -00:00:41,220 --> 00:00:44,830 -this test again there are two possibilities. The test might fail, and - -16 -00:00:44,830 --> 00:00:47,160 -if the test fails you broke it, and therefore you'll have - -17 -00:00:47,160 --> 00:00:50,710 -to fix it. So developers will have to go back and modify - -18 -00:00:50,710 --> 00:00:54,010 -the system and again going through the cycle of running the local - -19 -00:00:54,010 --> 00:00:55,900 -tests, integrating, and running the systems - -20 -00:00:55,900 --> 00:00:57,890 -tests. Conversely, if all the systems - -21 -00:00:57,890 --> 00:01:00,150 -tests pass, then at that point the code is good to go - -22 -00:01:00,150 --> 00:01:02,500 -and it is integrated into the system. And it will be the problem - -23 -00:01:02,500 --> 00:01:05,370 -of some other developers if something breaks because at the time you - -24 -00:01:05,370 --> 00:01:09,530 -integrated your code, the code was compiling, running and passing the tests - -25 -00:01:09,530 --> 00:01:12,495 -successfully. So again, if we do this every few hours or every - -26 -00:01:12,495 --> 00:01:15,740 -day, we can find problems very early, and we can avoid the situations - -27 -00:01:15,740 --> 00:01:18,105 -in which we have many different changes coming from - -28 -00:01:18,105 --> 00:01:21,290 -many different developers in a integration nightmare as a result. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/13 - On Site Customer - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/13 - On Site Customer - lang_en_vs4.srt deleted file mode 100644 index a95cc07..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/13 - On Site Customer - lang_en_vs4.srt +++ /dev/null @@ -1,55 +0,0 @@ -1 -00:00:00,060 --> 00:00:03,500 -The last practice I want to mention is on-site customer, and what - -2 -00:00:03,500 --> 00:00:07,590 -that means is that literally the customer is an actual member of - -3 -00:00:07,590 --> 00:00:10,310 -the team. So the customer will sit with the team and will - -4 -00:00:10,310 --> 00:00:13,546 -bring requirements to the team and discuss the requirements with them. So - -5 -00:00:13,546 --> 00:00:16,461 -the typical objection to this practice is the fact that it's just - -6 -00:00:16,461 --> 00:00:19,640 -impossible in the real world. There is no way that the customer - -7 -00:00:19,640 --> 00:00:22,550 -can have one person staying with the team all the time, and - -8 -00:00:22,550 --> 00:00:25,130 -the answer to that objection is that if the system is not - -9 -00:00:25,130 --> 00:00:28,700 -worth the time of one customer then maybe the system is not worth building. In - -10 -00:00:28,700 --> 00:00:30,530 -other words, if you're investing tons of - -11 -00:00:30,530 --> 00:00:33,440 -dollars, tons of money in building a system, - -12 -00:00:33,440 --> 00:00:36,870 -you might just as well invest a little more and have one of the people - -13 -00:00:36,870 --> 00:00:39,080 -in the customer's organization stay with the - -14 -00:00:39,080 --> 00:00:41,450 -team and be involved in the whole process. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/14 - Requirements Engineering - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/14 - Requirements Engineering - lang_en_vs4.srt deleted file mode 100644 index 7a00887..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/14 - Requirements Engineering - lang_en_vs4.srt +++ /dev/null @@ -1,139 +0,0 @@ -1 -00:00:00,210 --> 00:00:02,680 -Now that we saw what the main values and practices - -2 -00:00:02,680 --> 00:00:05,200 -of XP are, I want to go back for a minute - -3 -00:00:05,200 --> 00:00:08,800 -to discussion of requirements engineering in XP. In XP, user - -4 -00:00:08,800 --> 00:00:12,180 -requirements are expressed as scenarios or user stories, as we already - -5 -00:00:12,180 --> 00:00:15,500 -discussed. These are written by customers on cards, and what - -6 -00:00:15,500 --> 00:00:18,550 -the development team does is to take these cards, take these - -7 -00:00:18,550 --> 00:00:22,240 -users stories and break them down into implementation tasks. And - -8 -00:00:22,240 --> 00:00:25,310 -those implementation tasks are then used as a basis for scheduling - -9 -00:00:25,310 --> 00:00:29,210 -cost estimates. So given these estimates, and based on their priorities, - -10 -00:00:29,210 --> 00:00:31,770 -the customer will choose the stories that will be included in - -11 -00:00:31,770 --> 00:00:34,980 -the next release, in the next iteration. And at this point, - -12 -00:00:34,980 --> 00:00:39,220 -the corresponding cards will be taken by the developers and the, - -13 -00:00:39,220 --> 00:00:42,380 -the task will be performed, and the relative, and the corresponding - -14 -00:00:42,380 --> 00:00:44,350 -card will be developed. And just to give an idea of - -15 -00:00:44,350 --> 00:00:47,330 -the order of magnitude, if you consider a few months project, - -16 -00:00:47,330 --> 00:00:50,390 -there might be 50 to 100 user stories for a project of - -17 -00:00:50,390 --> 00:00:52,820 -that duration. So, now let me give you an example of what - -18 -00:00:52,820 --> 00:00:55,630 -the story card might look like, and I'm going to do it using - -19 -00:00:55,630 --> 00:00:58,930 -a story card for document downloading and you can really do all of - -20 -00:00:58,930 --> 00:01:00,780 -this, basically as seeing what the - -21 -00:01:00,780 --> 00:01:03,440 -scenario is, downloading and printing an article. - -22 -00:01:03,440 --> 00:01:06,590 -And it describes basically what happens when you do that, what is - -23 -00:01:06,590 --> 00:01:09,530 -the scenario. First, you select the article that you want from a displayed - -24 -00:01:09,530 --> 00:01:12,760 -list. You then have to tell the system how you will pay for - -25 -00:01:12,760 --> 00:01:15,680 -it. This can either be through a subscription, through a company account or - -26 -00:01:15,680 --> 00:01:18,670 -by credit card, and so on. So what developers do, they take - -27 -00:01:18,670 --> 00:01:22,020 -this story card, and they break it down in to development tasks. - -28 -00:01:22,020 --> 00:01:25,100 -So, here I'm showing you some examples of task cards for the - -29 -00:01:25,100 --> 00:01:28,360 -user story that we just saw. In particular I'm showing three task cards - -30 -00:01:28,360 --> 00:01:30,740 -and if we look at the third one, there is a name - -31 -00:01:30,740 --> 00:01:34,260 -for the task, which is implement payment collection. So this is the development - -32 -00:01:34,260 --> 00:01:37,600 -task that we have the perform and here, there's a description of - -33 -00:01:37,600 --> 00:01:41,240 -what that developed code should do. And notice that, you know, the task - -34 -00:01:41,240 --> 00:01:44,400 -card can even be more. explicit than this, more - -35 -00:01:44,400 --> 00:01:47,450 -specific than this, and talk about actual development tasks. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/15 - Testing Strategy - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/15 - Testing Strategy - lang_en_vs4.srt deleted file mode 100644 index af5ee6c..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/15 - Testing Strategy - lang_en_vs4.srt +++ /dev/null @@ -1,147 +0,0 @@ -1 -00:00:00,360 --> 00:00:03,320 -As you probably realized by now, at job development, it's a - -2 -00:00:03,320 --> 00:00:06,280 -lot about testing. So there is a lot of emphasis on - -3 -00:00:06,280 --> 00:00:09,420 -testing. Testing first, te, testing early. So that's the reason why - -4 -00:00:09,420 --> 00:00:12,710 -I also want to discuss what is the testing strategy in XP. - -5 -00:00:12,710 --> 00:00:14,820 -So first of all what is the basic principle? The basic - -6 -00:00:14,820 --> 00:00:18,770 -principle is that testing is Coded confidence. You write your test - -7 -00:00:18,770 --> 00:00:22,150 -cases and then you can run them anytime you want. And - -8 -00:00:22,150 --> 00:00:25,540 -if they pass, they'll give you confidence that your code is behaving - -9 -00:00:25,540 --> 00:00:27,920 -the way it's expected. If they don't pass on the other - -10 -00:00:27,920 --> 00:00:30,870 -hand, you'll know that there's something to fix. Another important concept is - -11 -00:00:30,870 --> 00:00:34,600 -that test might be isolated and automated. So both the running and - -12 -00:00:34,600 --> 00:00:37,400 -the checking of the tests has to be automated for all of - -13 -00:00:37,400 --> 00:00:39,830 -this to work. And there are two types of tests. The first - -14 -00:00:39,830 --> 00:00:43,170 -type of test is unit tests, that are created by the programmers, - -15 -00:00:43,170 --> 00:00:45,830 -and they're created by looking at the task cards. The task cards - -16 -00:00:45,830 --> 00:00:48,410 -describe what they implemented, functionality should - -17 -00:00:48,410 --> 00:00:50,740 -do, and therefore allows the developers. - -18 -00:00:50,740 --> 00:00:53,970 -The right test that can test this functionality. That can - -19 -00:00:53,970 --> 00:00:57,000 -check that the code's correctly implemented functionality. And as we - -20 -00:00:57,000 --> 00:01:00,670 -said, you should really test every meaninful feature. So, for - -21 -00:01:00,670 --> 00:01:04,250 -example, you should test every meaningful method in your classes. - -22 -00:01:04,250 --> 00:01:08,490 -You should put specific attention to possibly complex implementations, special - -23 -00:01:08,490 --> 00:01:11,100 -cases or specific problems that you might think of. while - -24 -00:01:11,100 --> 00:01:13,110 -reading the task cards. In some cases, when you do - -25 -00:01:13,110 --> 00:01:15,800 -refactoring, you might also want to write test cases specific - -26 -00:01:15,800 --> 00:01:18,300 -to that refactoring. But we'll say more about that. So this - -27 -00:01:18,300 --> 00:01:20,610 -was for the first kind of tests that are involved in - -28 -00:01:20,610 --> 00:01:23,650 -the, in the XP process. The second kind of tests are - -29 -00:01:23,650 --> 00:01:27,710 -the system tests, also called acceptance tests. And those tests involve - -30 -00:01:27,710 --> 00:01:30,920 -the customer. So basically what happens is that the customer provides - -31 -00:01:30,920 --> 00:01:33,760 -the test cases for their stores and then the development team - -32 -00:01:33,760 --> 00:01:37,630 -transforms those into actual automated tests. So these are tests created - -33 -00:01:37,630 --> 00:01:40,700 -by the developers. They run very quickly and they run very frequently. - -34 -00:01:40,700 --> 00:01:43,120 -These are tests developed with the help, with the - -35 -00:01:43,120 --> 00:01:46,170 -involvement of the customer they run longer. And run less - -36 -00:01:46,170 --> 00:01:48,710 -frequently, they run every time the system is integrated. - -37 -00:01:48,710 --> 00:01:50,890 -According to the cycle we saw a few minutes ago. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/16 - Testing Strategy Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/16 - Testing Strategy Quiz - lang_en_vs4.srt deleted file mode 100644 index c26e977..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/16 - Testing Strategy Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,47 +0,0 @@ -1 -00:00:00,130 --> 00:00:02,776 -Now that we are done discussing XP Extreme Programming, I - -2 -00:00:02,776 --> 00:00:04,612 -would like to have a quiz, in which I make - -3 -00:00:04,612 --> 00:00:06,772 -sure that some of the concepts behind XP are well - -4 -00:00:06,772 --> 00:00:10,040 -understood. So, I'm going to ask you which of the following statements - -5 -00:00:10,040 --> 00:00:13,390 -about Extreme Programming are true, and here are the statements. - -6 -00:00:13,390 --> 00:00:17,700 -Because of pair programming, XP requires twice the number of developers. - -7 -00:00:17,700 --> 00:00:21,260 -In XP, code is rarely changed after being written. XP - -8 -00:00:21,260 --> 00:00:25,200 -follows the test driven development, or TDD, paradigm. The customer does - -9 -00:00:25,200 --> 00:00:27,560 -not need to provide any requirements in XP. - -10 -00:00:27,560 --> 00:00:31,120 -XP is an iterative software development process. So I - -11 -00:00:31,120 --> 00:00:32,700 -would like for you to mark all of - -12 -00:00:32,700 --> 00:00:35,020 -the statements that you think are true about XP. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/17 - Testing Strategy Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/17 - Testing Strategy Quiz Solution - lang_en_vs4.srt deleted file mode 100644 index b60861f..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/17 - Testing Strategy Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,127 +0,0 @@ -1 -00:00:00,120 --> 00:00:02,600 -The first statement is false. It is not true - -2 -00:00:02,600 --> 00:00:04,840 -that because of pair programming, we need twice as many - -3 -00:00:04,840 --> 00:00:08,039 -developers. In fact that there is some evidence that even - -4 -00:00:08,039 --> 00:00:11,700 -though in pair programming we have two developers working together, - -5 -00:00:11,700 --> 00:00:15,175 -that the overall efficiency of the programmers is not really - -6 -00:00:15,175 --> 00:00:19,080 -affected by use of this practice. In XP, code is - -7 -00:00:19,080 --> 00:00:23,280 -rarely changed after being written. This is also definitely false. - -8 -00:00:23,280 --> 00:00:25,233 -In fact in XP there is a lot of emphasis - -9 -00:00:25,233 --> 00:00:27,879 -on change on the fact that the code can be changed, - -10 -00:00:27,879 --> 00:00:30,462 -it can be resigned, because of the fact when we do - -11 -00:00:30,462 --> 00:00:32,793 -that, we have a set of these cases that we can - -12 -00:00:32,793 --> 00:00:35,439 -use to check right away that the code still works as - -13 -00:00:35,439 --> 00:00:39,850 -expected. So again in XP, it's all about steering rather than - -14 -00:00:39,850 --> 00:00:43,430 -just driving down one fixed direction. And therefore, the code can - -15 -00:00:43,430 --> 00:00:46,580 -be changed. So this statement is false. It is definitely true - -16 -00:00:46,580 --> 00:00:50,950 -that XP follows the test driven development paradigm. In XP we first - -17 -00:00:50,950 --> 00:00:53,320 -write tests, and then we write the code, which is - -18 -00:00:53,320 --> 00:00:55,980 -exactly what TDD is about. It is not true that - -19 -00:00:55,980 --> 00:00:58,740 -the customer does not need to provide requirements in XP. - -20 -00:00:58,740 --> 00:01:02,020 -The customer does provide requirements in the form of user - -21 -00:01:02,020 --> 00:01:04,879 -stories, and the user stories are the starting point of - -22 -00:01:04,879 --> 00:01:09,370 -the development process. Finally, XP is definitely an iterative software - -23 -00:01:09,370 --> 00:01:12,500 -development process. In fact, we saw that XP is based - -24 -00:01:12,500 --> 00:01:16,100 -on subsequent iterations of the same cycle, in which we - -25 -00:01:16,100 --> 00:01:18,110 -select from a set of story cards, or user - -26 -00:01:18,110 --> 00:01:21,270 -stories, the stories that we want to implement in the - -27 -00:01:21,270 --> 00:01:24,250 -next iteration. Based on that we develop task cards, - -28 -00:01:24,250 --> 00:01:26,060 -and then we use the task cards to write this - -29 -00:01:26,060 --> 00:01:28,400 -case and then to write code. And we continue - -30 -00:01:28,400 --> 00:01:31,140 -this cycle in an iterative way until we are done - -31 -00:01:31,140 --> 00:01:33,030 -with all the story cards, and all the user - -32 -00:01:33,030 --> 00:01:36,612 -stories, so definitely XP is an iterative software development process. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/18 - Scrum Intro - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/18 - Scrum Intro - lang_en_vs4.srt deleted file mode 100644 index 4d8eab6..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/18 - Scrum Intro - lang_en_vs4.srt +++ /dev/null @@ -1,99 +0,0 @@ -1 -00:00:00,220 --> 00:00:02,830 -Before concluding this class on java development, I want to - -2 -00:00:02,830 --> 00:00:06,330 -talk about another process that is very popular these days, and - -3 -00:00:06,330 --> 00:00:09,990 -it's used in many companies, which is called Scrum. Which similar - -4 -00:00:09,990 --> 00:00:13,370 -to XP is another agile development process, and I'm going to - -5 -00:00:13,370 --> 00:00:16,400 -start by discussing what the Scrum actors are. There's three - -6 -00:00:16,400 --> 00:00:19,490 -main kinds of actors. The first one is the product owner, - -7 -00:00:19,490 --> 00:00:22,590 -which means the customer. The product owner is mainly responsible for - -8 -00:00:22,590 --> 00:00:25,460 -the product back log, where the product back log is basically - -9 -00:00:25,460 --> 00:00:27,660 -the list of things that have to be done, the - -10 -00:00:27,660 --> 00:00:30,670 -back log in fact for the project. And that is - -11 -00:00:30,670 --> 00:00:33,640 -analogous to the user stories to be realized in XP, - -12 -00:00:33,640 --> 00:00:36,190 -that we just saw. So what the product owner does is - -13 -00:00:36,190 --> 00:00:39,310 -to clearly express these back log items, and to also - -14 -00:00:39,310 --> 00:00:42,680 -order them by value, so they can be prioritized. The second - -15 -00:00:42,680 --> 00:00:45,680 -actor is the team. The team is responsible for delivering - -16 -00:00:45,680 --> 00:00:48,012 -shippable increments to estimate the - -17 -00:00:48,012 --> 00:00:50,600 -back log items. It's normally self-organized, - -18 -00:00:50,600 --> 00:00:53,055 -consists of four to nine people, and it's what you - -19 -00:00:53,055 --> 00:00:56,180 -would consider normally as the main development team in a - -20 -00:00:56,180 --> 00:00:59,080 -project. And finally we have the Scrum master. The Scrum - -21 -00:00:59,080 --> 00:01:02,860 -master is the person who's responsible for the overall Scrum process, - -22 -00:01:02,860 --> 00:01:05,980 -so he or she has to remove obstacles, facilitate events, - -23 -00:01:05,980 --> 00:01:08,668 -helps communications, and so on. So you you can see - -24 -00:01:08,668 --> 00:01:11,013 -the Scrum master as sort of a manager or the - -25 -00:01:11,013 --> 00:01:15,059 -person who's got oversight, or the supervisor of the Scrum process. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/19 - High Level Scrum Process - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/19 - High Level Scrum Process - lang_en_vs4.srt deleted file mode 100644 index d646b4e..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/19 - High Level Scrum Process - lang_en_vs4.srt +++ /dev/null @@ -1,215 +0,0 @@ -1 -00:00:00,100 --> 00:00:02,200 -So I want to conclude this lesson by providing a high - -2 -00:00:02,200 --> 00:00:05,790 -level view of this scrum process. The process is represented here, - -3 -00:00:05,790 --> 00:00:07,939 -and as you can see it has several components. We're going to - -4 -00:00:07,939 --> 00:00:09,860 -go through all of them one at a time. We're going to - -5 -00:00:09,860 --> 00:00:13,110 -start with a product backlog. Product backlog is the single source - -6 -00:00:13,110 --> 00:00:17,420 -of requirements, for the process. They're order by value raised priority - -7 -00:00:17,420 --> 00:00:21,110 -necessity, so that all of this characteristics can be taken into - -8 -00:00:21,110 --> 00:00:25,920 -account when selecting which backlog items to consider for the next iteration. - -9 -00:00:25,920 --> 00:00:28,710 -It's a living list in the sense that backlog items - -10 -00:00:28,710 --> 00:00:31,020 -can be added or removed. And it's not really defined - -11 -00:00:31,020 --> 00:00:33,200 -as we just said, by the product owner. In the - -12 -00:00:33,200 --> 00:00:36,260 -sprint planning, what happens is that the next increment or - -13 -00:00:36,260 --> 00:00:40,180 -the next sprint is defined. So basically, the backlog items - -14 -00:00:40,180 --> 00:00:43,348 -of interest are selected based on the characteristics we just - -15 -00:00:43,348 --> 00:00:46,890 -mentioned: value, [UNKNOWN], priority, and necessity. And the items are - -16 -00:00:46,890 --> 00:00:50,950 -converted into tasks and estimated. So the result is this sprint - -17 -00:00:50,950 --> 00:00:54,240 -backlog, which is the set of backlog items that will - -18 -00:00:54,240 --> 00:00:57,650 -be completed during the next sprint. The sprint is an actual - -19 -00:00:57,650 --> 00:01:01,040 -iteration of this scrum process. It's got a main part - -20 -00:01:01,040 --> 00:01:04,730 -that lasts two to four weeks, and within this main part, - -21 -00:01:04,730 --> 00:01:08,150 -there are many daily scrums that last 24 hours. So - -22 -00:01:08,150 --> 00:01:11,260 -let's see how this work. A daily scrum is typically characterized - -23 -00:01:11,260 --> 00:01:13,960 -by a 50-minute meeting at the beginning of the day - -24 -00:01:13,960 --> 00:01:16,220 -for the team to sync, and what happens during the meeting - -25 -00:01:16,220 --> 00:01:19,010 -is that there is a discussion of the accomplishments since - -26 -00:01:19,010 --> 00:01:21,210 -the last meeting. A to do list for the next - -27 -00:01:21,210 --> 00:01:24,210 -meeting is produced, and there is also an obstacle analysis. - -28 -00:01:24,210 --> 00:01:27,690 -So if some problem appear, they're discussing the daily scrum, and - -29 -00:01:27,690 --> 00:01:30,905 -possible solutions are proposed. At the end of the two - -30 -00:01:30,905 --> 00:01:34,840 -four-week cycle, there is a sprint review and retrospective. The sprint - -31 -00:01:34,840 --> 00:01:37,440 -review normally consists of a four hour meeting. In the - -32 -00:01:37,440 --> 00:01:41,270 -meeting, the product owner assesses the accomplishment for the specific sprint, - -33 -00:01:41,270 --> 00:01:44,020 -and the team discusses issues that were encountered and solved. - -34 -00:01:44,020 --> 00:01:46,530 -There is typically a demo of the deliverable for that - -35 -00:01:46,530 --> 00:01:48,810 -sprint. And at that point, the product owner will also - -36 -00:01:48,810 --> 00:01:52,610 -discuss the backlogs. And together with the team they will decide - -37 -00:01:52,610 --> 00:01:56,230 -what to do next. In the retrospective conversely what happens - -38 -00:01:56,230 --> 00:01:59,140 -is there is more focus on the process. So the - -39 -00:01:59,140 --> 00:02:02,010 -goal of that part of the meeting is discussing possible - -40 -00:02:02,010 --> 00:02:04,850 -process improvements. To identify them - -41 -00:02:04,850 --> 00:02:07,140 -and if promising improvements are identified - -42 -00:02:07,140 --> 00:02:10,810 -try to plan how to implement those improvements and use them - -43 -00:02:10,810 --> 00:02:13,790 -in the next iterations. And something else that might happen at - -44 -00:02:13,790 --> 00:02:16,720 -the end of a sprint is that if the product increment - -45 -00:02:16,720 --> 00:02:19,210 -is good enough as it reach the state in which it - -46 -00:02:19,210 --> 00:02:22,660 -can be actually shipped that will result in a release that - -47 -00:02:22,660 --> 00:02:25,730 -is not just internal. To show the product owner the progress - -48 -00:02:25,730 --> 00:02:28,510 -that can also be deployed and actually used in production. So - -49 -00:02:28,510 --> 00:02:32,650 -one final consideration is that as you can see, XP and scrum - -50 -00:02:32,650 --> 00:02:35,340 -are fairly similar, and that's because they're both agile development - -51 -00:02:35,340 --> 00:02:37,930 -processes. So the main thing to keep in mind is that - -52 -00:02:37,930 --> 00:02:40,620 -they both implement and enforce - -53 -00:02:40,620 --> 00:02:44,380 -those ideas, values, practices, and characteristics - -54 -00:02:44,380 --> 00:02:47,600 -that we saw when we discussed agile development process in general. 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. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/3 - Agile Software Development - lang_en_vs7.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/3 - Agile Software Development - lang_en_vs7.srt deleted file mode 100644 index 38fe4c3..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/3 - Agile Software Development - lang_en_vs7.srt +++ /dev/null @@ -1,159 +0,0 @@ -1 -00:00:00,150 --> 00:00:03,250 -And assuming that cost is flat that we can really lower that - -2 -00:00:03,250 --> 00:00:06,590 -curve then teher are a few interesting consequences. First of all upfront - -3 -00:00:06,590 --> 00:00:10,330 -work becomes a liability, we pay for speculative work some of which - -4 -00:00:10,330 --> 00:00:13,320 -is likely to be wrong. Some of which we are likely to undo - -5 -00:00:13,320 --> 00:00:16,870 -and the reason for ambiguity and volability for example in requirements then - -6 -00:00:16,870 --> 00:00:19,310 -it's good to delay We don't want to plan for something that - -7 -00:00:19,310 --> 00:00:22,380 -might never happen, to invest resources in something that we might have - -8 -00:00:22,380 --> 00:00:25,170 -to throw away later on. In general, if cost is flat it is - -9 -00:00:25,170 --> 00:00:28,820 -cost effective to delay all decisions until the last possible - -10 -00:00:28,820 --> 00:00:30,990 -moment and only pay for what we use, so to - -11 -00:00:30,990 --> 00:00:34,550 -speak. In other words, there is value in waiting, time - -12 -00:00:34,550 --> 00:00:37,810 -answers questions and removes uncertainty. And we want to take advantage - -13 -00:00:37,810 --> 00:00:40,610 -of that. This and other considerations led to the birth - -14 -00:00:40,610 --> 00:00:44,590 -of Agile Softer Development. Specifically for those of you who are - -15 -00:00:44,590 --> 00:00:47,200 -interested in a little bit of history. In February 2001 - -16 -00:00:47,200 --> 00:00:50,430 -a group of software developers, 17 of them, met to discuss - -17 -00:00:50,430 --> 00:00:53,950 -lightweight development methods and published Manifesto for Agile - -18 -00:00:53,950 --> 00:00:57,630 -Software Developement. Which introduces and defines the concept of - -19 -00:00:57,630 --> 00:01:00,990 -agile software development, or agile methods. In a - -20 -00:01:00,990 --> 00:01:03,770 -nutshell, agile methods aim at flat cost and a - -21 -00:01:03,770 --> 00:01:06,190 -decrease in traditional overhead by following a set - -22 -00:01:06,190 --> 00:01:09,400 -of important principles. Our first principle is to focus - -23 -00:01:09,400 --> 00:01:11,700 -on the code, rather than the design, to avoid - -24 -00:01:11,700 --> 00:01:16,080 -unnecessary changes. Another principle is to focus on people, - -25 -00:01:16,080 --> 00:01:20,100 -value people over process, and make sure to reward people. - -26 -00:01:20,100 --> 00:01:22,990 -In addition agile methods are all based on iterative approaches to - -27 -00:01:22,990 --> 00:01:26,310 -software development, to deliver working software quickly, and to be - -28 -00:01:26,310 --> 00:01:29,230 -evolve it Just as quickly based on feedback. And feedback can - -29 -00:01:29,230 --> 00:01:31,740 -come from many sources, in particular, it'll come from the - -30 -00:01:31,740 --> 00:01:34,500 -customer, it'll be customer feedback. And to be able to do - -31 -00:01:34,500 --> 00:01:38,040 -so, agile methods need to involve the customer throughout the development - -32 -00:01:38,040 --> 00:01:41,260 -process. Finally, there are two more principles I want to mention. - -33 -00:01:41,260 --> 00:01:43,620 -Which are cornerstones of agile methods. The first - -34 -00:01:43,620 --> 00:01:46,520 -one is the expectation that requirements will change, and - -35 -00:01:46,520 --> 00:01:48,010 -therefore, we need to be able to handle some - -36 -00:01:48,010 --> 00:01:50,570 -changes. We can't count on the requirements to be - -37 -00:01:50,570 --> 00:01:52,890 -still and unmutable. And the last principle is - -38 -00:01:52,890 --> 00:01:56,430 -the mentality of simplicity. Simple design and simple code - -39 -00:01:56,430 --> 00:01:58,810 -and so on. But be careful, because simple does - -40 -00:01:58,810 --> 00:02:02,060 -not mean inadequate, but rather, as simple as possible. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/4 - Extreme Programming (XP) - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/4 - Extreme Programming (XP) - lang_en_vs4.srt deleted file mode 100644 index 62cc2fa..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/4 - Extreme Programming (XP) - lang_en_vs4.srt +++ /dev/null @@ -1,179 +0,0 @@ -1 -00:00:00,100 --> 00:00:02,490 -So now let's talk about a specific agile method, which - -2 -00:00:02,490 --> 00:00:05,850 -is also one of the first ones, extreme programming, also called - -3 -00:00:05,850 --> 00:00:08,430 -XP. And to introduce XP, I'm going to start with - -4 -00:00:08,430 --> 00:00:12,520 -a quote. The quote says XP is a lightweight methodology for - -5 -00:00:12,520 --> 00:00:16,180 -small to medium sized teams developing software in the face - -6 -00:00:16,180 --> 00:00:19,770 -of vague or rapidly-changing requirements. And this is a quote from - -7 -00:00:19,770 --> 00:00:23,010 -Kent Beck the American Software Engineer that created extreme programming. - -8 -00:00:23,010 --> 00:00:25,630 -And by the way Beck was one of the original 17 - -9 -00:00:25,630 --> 00:00:29,570 -developers who signed the manifesto in 2001. And as you can see - -10 -00:00:29,570 --> 00:00:31,940 -we are still talking about the methodology. So we are not just - -11 -00:00:31,940 --> 00:00:35,760 -talking about going out and just start writing software. There are principles. - -12 -00:00:35,760 --> 00:00:38,130 -And there are practices that we need to follow, but we're going - -13 -00:00:38,130 --> 00:00:40,330 -to do it in a much more agile, and a much more - -14 -00:00:40,330 --> 00:00:43,720 -flexible ways than we did for our software processes. And also note - -15 -00:00:43,720 --> 00:00:45,340 -that the vague and rapidly changing - -16 -00:00:45,340 --> 00:00:47,190 -requirements are explicitly mentioned, because this - -17 -00:00:47,190 --> 00:00:51,130 -is really one of the important parts about all of this agile methodologies. - -18 -00:00:51,130 --> 00:00:54,780 -so what is XP? XP is a. Lightweight. Humanistic. - -19 -00:00:54,780 --> 00:00:58,250 -Discipline. Of software development. It is lightweight because it doesn't - -20 -00:00:58,250 --> 00:01:02,190 -overburden the developers with an invasive process. So process - -21 -00:01:02,190 --> 00:01:04,510 -is kept to a minimum. It's humanistic because as we - -22 -00:01:04,510 --> 00:01:07,760 -said, it's centered on people. People, developers, customers, are - -23 -00:01:07,760 --> 00:01:10,520 -at the center of the process. It's a discipline, as - -24 -00:01:10,520 --> 00:01:12,870 -we said, it includes practices that we to Follow. - -25 -00:01:12,870 --> 00:01:16,470 -And finally, is of course about software development. Software development - -26 -00:01:16,470 --> 00:01:19,530 -is a key point of the whole method. In XP, developing - -27 -00:01:19,530 --> 00:01:22,910 -is like driving, imagine having a road, a wind road, we need - -28 -00:01:22,910 --> 00:01:25,110 -to able to drive our car down the road, take the - -29 -00:01:25,110 --> 00:01:29,640 -abrupt turns, react promptly to changes, for example obstacles on the road. - -30 -00:01:29,640 --> 00:01:32,610 -So, in a nutshell, change is the only constant. Eyes always - -31 -00:01:32,610 --> 00:01:34,980 -have to be on the road and it's about steering and not - -32 -00:01:34,980 --> 00:01:38,110 -pointing, and XP is trying to do the same thing, while creating - -33 -00:01:38,110 --> 00:01:42,190 -softer systems. In XP we need to adopt a mentality of sufficiency, - -34 -00:01:42,190 --> 00:01:44,820 -what does that mean? How would you program if you had all - -35 -00:01:44,820 --> 00:01:48,010 -the time in the world? No time constraints at all, you will probably - -36 -00:01:48,010 --> 00:01:51,090 -write tests instead of skipping them, because there's no more resources. You - -37 -00:01:51,090 --> 00:01:53,200 -will probably restructure your code often, - -38 -00:01:53,200 --> 00:01:55,210 -because you see opportunities to improve it, - -39 -00:01:55,210 --> 00:01:57,300 -and you will take them. And you will probably talk to fellow - -40 -00:01:57,300 --> 00:02:00,910 -programmers and with the customer, interact with them, and this is actually the - -41 -00:02:00,910 --> 00:02:04,700 -kind of mentality that XP is trying to promote and agile processes - -42 -00:02:04,700 --> 00:02:07,760 -in general. And we will see that the following some of the practices - -43 -00:02:07,760 --> 00:02:11,250 -that XP is advocating, you can actually achieve these goals and you can - -44 -00:02:11,250 --> 00:02:12,840 -actually behave in this way. And the - -45 -00:02:12,840 --> 00:02:15,010 -development process is going to benefit overall. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/5 - XP's Values, Principles, and Practices - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/5 - XP's Values, Principles, and Practices - lang_en_vs4.srt deleted file mode 100644 index d12e73d..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/5 - XP's Values, Principles, and Practices - lang_en_vs4.srt +++ /dev/null @@ -1,151 +0,0 @@ -1 -00:00:00,218 --> 00:00:03,030 -Next I'm going to go over some of the XP's values - -2 -00:00:03,030 --> 00:00:05,870 -and principles that I just hinted on earlier in the lesson. - -3 -00:00:05,870 --> 00:00:08,820 -The first one, the first important value is communication. There - -4 -00:00:08,820 --> 00:00:12,350 -is no good project without good communication. And XP tries to - -5 -00:00:12,350 --> 00:00:15,470 -keep the right communication flowing and it uses several practices - -6 -00:00:15,470 --> 00:00:18,890 -to do that. It's got practices based on and require information - -7 -00:00:18,890 --> 00:00:21,950 -and in general share the information. For example, pair programming. - -8 -00:00:21,950 --> 00:00:25,140 -And we're going to say more about that. User stories, customer involvement, - -9 -00:00:25,140 --> 00:00:28,240 -all activities that help communication, - -10 -00:00:28,240 --> 00:00:30,440 -that faster communication. Another important - -11 -00:00:30,440 --> 00:00:33,420 -principle that we already saw, is simplicity. And the motto here - -12 -00:00:33,420 --> 00:00:35,680 -is live for today without worrying too much about the - -13 -00:00:35,680 --> 00:00:38,230 -future. When you have to do something, look for the simplest - -14 -00:00:38,230 --> 00:00:40,580 -thing that works. And the emphasis here is on, that - -15 -00:00:40,580 --> 00:00:43,520 -works. We want to build something simple, but not something stupid. - -16 -00:00:43,520 --> 00:00:47,090 -Feedback. That's extremely important in XP, and it occurs at - -17 -00:00:47,090 --> 00:00:50,560 -different levels, and it is used to drive changes. For example, - -18 -00:00:50,560 --> 00:00:53,910 -developers write test cases. And that's immediate feedback. If your test cases - -19 -00:00:53,910 --> 00:00:56,140 -fail, there's something wrong with the code. Or there's something that you - -20 -00:00:56,140 --> 00:00:59,690 -still haven't developed. Developers also estimate new stories right away as soon - -21 -00:00:59,690 --> 00:01:02,060 -as they get them from the customers and that's immediate feedback to - -22 -00:01:02,060 --> 00:01:05,515 -the customer. And finally, on a slightly longer time frame, customers and - -23 -00:01:05,515 --> 00:01:07,820 -tester develop together functional system test - -24 -00:01:07,820 --> 00:01:09,600 -cases to assess the overall system. - -25 -00:01:09,600 --> 00:01:12,100 -And also in this case, that's a great way to provide feedback - -26 -00:01:12,100 --> 00:01:15,850 -and by the way, also to help communication. And finally, courage, the courage - -27 -00:01:15,850 --> 00:01:18,860 -to throw away code if it doesn't work. To change it if you - -28 -00:01:18,860 --> 00:01:21,710 -find a way to improve it. To fix it if you find a problem. - -29 -00:01:21,710 --> 00:01:24,300 -To try out new things if you think that they might work better - -30 -00:01:24,300 --> 00:01:27,410 -than what you have right now. Now, that we can build and test systems - -31 -00:01:27,410 --> 00:01:30,150 -very quickly, we can be much braver than what we were before. So - -32 -00:01:30,150 --> 00:01:33,790 -how do we accomplish all that? And what are XP's practices that are going to - -33 -00:01:33,790 --> 00:01:37,750 -help us follow these principles and adhere to those values? These are some - -34 -00:01:37,750 --> 00:01:40,900 -of XP practices. There are more, but those are the ones that I'd like - -35 -00:01:40,900 --> 00:01:44,240 -to discuss in a little more depth, individually. Incremental planning, - -36 -00:01:44,240 --> 00:01:48,230 -small releases, simple design, test first, refactoring. We will actually - -37 -00:01:48,230 --> 00:01:51,680 -have a whole lesson next on refactoring. Pair programming, continuous - -38 -00:01:51,680 --> 00:01:55,240 -integration, and on-site customer. So let's start with incremental planning. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/6 - Incremental Planning - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/6 - Incremental Planning - lang_en_vs4.srt deleted file mode 100644 index faf25db..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/6 - Incremental Planning - lang_en_vs4.srt +++ /dev/null @@ -1,71 +0,0 @@ -1 -00:00:00,140 --> 00:00:03,390 -Incremental planning is based on the idea that requirements are recorded - -2 -00:00:03,390 --> 00:00:07,260 -on story cards, sort of use cases or scenarios that the customer - -3 -00:00:07,260 --> 00:00:10,450 -provides. So the first step in incremental planning is to select - -4 -00:00:10,450 --> 00:00:14,120 -user stories for a given release, and which stories exactly to include - -5 -00:00:14,120 --> 00:00:16,975 -depends on the time available and on the priority. For example, - -6 -00:00:16,975 --> 00:00:19,147 -scenarios that we might want to realize right away because they are - -7 -00:00:19,147 --> 00:00:22,110 -particular important for the customer. After we select user stories for - -8 -00:00:22,110 --> 00:00:25,200 -the release, we break stories i to tasks. So what we do, - -9 -00:00:25,200 --> 00:00:29,260 -we take the user stories and we identify specific development tasks - -10 -00:00:29,260 --> 00:00:32,320 -that we need to perform in order to realize these stories. Once - -11 -00:00:32,320 --> 00:00:34,780 -we know our tasks, we can plan our release. And at - -12 -00:00:34,780 --> 00:00:38,050 -that point, we can develop, integrate and test our code. And of - -13 -00:00:38,050 --> 00:00:41,170 -course, this is more kind of an iterative process right here, - -14 -00:00:41,170 --> 00:00:44,250 -so we do this many times. When we're ready, when we accomplish - -15 -00:00:44,250 --> 00:00:46,990 -all of our tasks, all of our tests pass and we're happy, - -16 -00:00:46,990 --> 00:00:50,410 -we release this software. At the point, the released software is evaluated - -17 -00:00:50,410 --> 00:00:53,250 -by us, by the customer, and we can reiterate. We can - -18 -00:00:53,250 --> 00:00:56,360 -continue the process, select more stories and continue it this way. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt deleted file mode 100644 index 0437621..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt +++ /dev/null @@ -1,95 +0,0 @@ -1 -00:00:00,210 --> 00:00:02,790 -The first practice that we just saw goes together with - -2 -00:00:02,790 --> 00:00:06,320 -small releases practice. This idea that instead of having a big - -3 -00:00:06,320 --> 00:00:09,390 -release at the end of a long development cycle, we try - -4 -00:00:09,390 --> 00:00:12,610 -to release very often. And there are many advantages to small - -5 -00:00:12,610 --> 00:00:15,260 -releases and to releasing often. The first one is that - -6 -00:00:15,260 --> 00:00:18,980 -we deliver real business value on a very short cycle. And - -7 -00:00:18,980 --> 00:00:22,070 -what that means is that we get business value sooner, and - -8 -00:00:22,070 --> 00:00:25,550 -that in turn increase our customer confidence and makes the customer - -9 -00:00:25,550 --> 00:00:29,040 -more happy. So more releases also mean rapid feedback. We - -10 -00:00:29,040 --> 00:00:32,420 -release the software soon, we get feedback from the customer soon, - -11 -00:00:32,420 --> 00:00:34,710 -and we can in this way do exactly what we - -12 -00:00:34,710 --> 00:00:38,510 -were saying before, steer instead of driving, adapt weekly to possible - -13 -00:00:38,510 --> 00:00:41,680 -changes in the requirements. We avoid working for six months - -14 -00:00:41,680 --> 00:00:43,970 -on a project and find out six months later that the - -15 -00:00:43,970 --> 00:00:46,950 -customer wanted something else and we got the wrong requirements. In - -16 -00:00:46,950 --> 00:00:50,610 -addition having small releases, so seeing your product deployed and released - -17 -00:00:50,610 --> 00:00:54,040 -soon produces a sense of accomplishment for the developers. - -18 -00:00:54,040 --> 00:00:57,000 -And in addition, it also reduces risk because again, - -19 -00:00:57,000 --> 00:00:58,640 -if we're going down the wrong path, we will - -20 -00:00:58,640 --> 00:01:00,730 -know right away. If we're late, we will know right - -21 -00:01:00,730 --> 00:01:03,370 -away. So these are just additional advantages of having - -22 -00:01:03,370 --> 00:01:06,140 -this quick cycle and more releases. And finally, as we - -23 -00:01:06,140 --> 00:01:09,130 -also said before, we can quickly adapt in the - -24 -00:01:09,130 --> 00:01:12,540 -case our requirements change our code to the new requirements. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/8 - Simple Design - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/8 - Simple Design - lang_en_vs4.srt deleted file mode 100644 index 3a8962c..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/8 - Simple Design - lang_en_vs4.srt +++ /dev/null @@ -1,63 +0,0 @@ -1 -00:00:00,160 --> 00:00:02,790 -The next practice is simple design. We want to avoid - -2 -00:00:02,790 --> 00:00:07,330 -creating a huge complicated possibly cumbersome design at the beginning of - -3 -00:00:07,330 --> 00:00:09,730 -the project. What we want to have instead is just - -4 -00:00:09,730 --> 00:00:14,580 -enough design to meet the requirements, so no duplicated functionality, fewest - -5 -00:00:14,580 --> 00:00:17,910 -possible classes and methods in general, just the amount of - -6 -00:00:17,910 --> 00:00:20,860 -design that we need to get our system to work. So - -7 -00:00:20,860 --> 00:00:23,012 -one might object that to for designing that way we - -8 -00:00:23,012 --> 00:00:25,210 -will have to change the code a lot, we will need - -9 -00:00:25,210 --> 00:00:27,300 -to adapt the design as the code evolves, - -10 -00:00:27,300 --> 00:00:29,180 -and that's exactly the point. That's what we will - -11 -00:00:29,180 --> 00:00:31,670 -do. XP is all about changing and adapting, - -12 -00:00:31,670 --> 00:00:34,850 -changing your design, changing your code, refactoring. And with - -13 -00:00:34,850 --> 00:00:37,420 -the fact that we have test cases throughout - -14 -00:00:37,420 --> 00:00:39,770 -the development process, we can do that with confidence. - -15 -00:00:39,770 --> 00:00:41,220 -Because if we break something we will know - -16 -00:00:41,220 --> 00:00:43,590 -right away, which leads us to the next practice. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/9 - Test First Development - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/9 - Test First Development - lang_en_vs4.srt deleted file mode 100644 index b2a461b..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/9 - Test First Development - lang_en_vs4.srt +++ /dev/null @@ -1,59 +0,0 @@ -1 -00:00:00,040 --> 00:00:03,610 -Which is test-first development. The key idea is that any program - -2 -00:00:03,610 --> 00:00:07,210 -feature that doesn't have an automatic test simply does not exist. If - -3 -00:00:07,210 --> 00:00:09,430 -there is a feature, you need to write a test for the - -4 -00:00:09,430 --> 00:00:13,630 -feature before. So, what developers do is to create unit tests for - -5 -00:00:13,630 --> 00:00:17,420 -each such piece of functionality even before the functionality is implemented. - -6 -00:00:17,420 --> 00:00:19,720 -And of course, when you run this test, they will fail. But - -7 -00:00:19,720 --> 00:00:22,190 -the beauty of it is that, as you write your code and - -8 -00:00:22,190 --> 00:00:25,680 -you add more and more fractionality to the feature that you're developing, - -9 -00:00:25,680 --> 00:00:27,820 -these test cases are going to start to pass. - -10 -00:00:27,820 --> 00:00:30,190 -And that's extremely rewarding because it gives you immediate - -11 -00:00:30,190 --> 00:00:32,530 -feedback, again feedback on the fact that you're - -12 -00:00:32,530 --> 00:00:34,530 -developing the code in the right way. As soon - -13 -00:00:34,530 --> 00:00:37,000 -as you write it, you will know. And if you write a piece of code and the - -14 -00:00:37,000 --> 00:00:38,550 -test says still fail, that means that the - -15 -00:00:38,550 --> 00:00:40,140 -code is not doing what it's supposed to do. |