From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 24 May 2020 16:34:31 +0700 Subject: [usth/ICT2.7] Engineer software --- .../1 - Lesson Overview - lang_en_vs4.srt | 75 +++++++ .../10 - Refactoring - lang_en_vs4.srt | 103 ++++++++++ .../11 - Pair Programming - lang_en_vs4.srt | 99 ++++++++++ .../12 - Continuous Integration - lang_en_vs4.srt | 111 +++++++++++ .../13 - On Site Customer - lang_en_vs4.srt | 55 ++++++ ...14 - Requirements Engineering - lang_en_vs4.srt | 139 +++++++++++++ .../15 - Testing Strategy - lang_en_vs4.srt | 147 ++++++++++++++ .../16 - Testing Strategy Quiz - lang_en_vs4.srt | 47 +++++ ...esting Strategy Quiz Solution - lang_en_vs4.srt | 127 ++++++++++++ .../18 - Scrum Intro - lang_en_vs4.srt | 99 ++++++++++ ...19 - High Level Scrum Process - lang_en_vs4.srt | 215 +++++++++++++++++++++ .../2 - Cost of Change - lang_en_vs4.srt | 207 ++++++++++++++++++++ ... - Agile Software Development - lang_en_vs7.srt | 159 +++++++++++++++ .../4 - Extreme Programming (XP) - lang_en_vs4.srt | 179 +++++++++++++++++ ...es, Principles, and Practices - lang_en_vs4.srt | 151 +++++++++++++++ .../6 - Incremental Planning - lang_en_vs4.srt | 71 +++++++ .../7 - Small Releases - lang_en_vs4.srt | 95 +++++++++ .../8 - Simple Design - lang_en_vs4.srt | 63 ++++++ .../9 - Test First Development - lang_en_vs4.srt | 59 ++++++ 19 files changed, 2201 insertions(+) create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/1 - Lesson Overview - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/10 - Refactoring - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/11 - Pair Programming - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/13 - On Site Customer - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/14 - Requirements Engineering - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/15 - Testing Strategy - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/16 - Testing Strategy Quiz - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/17 - Testing Strategy Quiz Solution - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/18 - Scrum Intro - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/19 - High Level Scrum Process - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/2 - Cost of Change - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/3 - Agile Software Development - lang_en_vs7.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/4 - Extreme Programming (XP) - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/5 - XP's Values, Principles, and Practices - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/6 - Incremental Planning - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/8 - Simple Design - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/9 - Test First Development - lang_en_vs4.srt (limited to 'usth/ICT2.7/P4L4 Agile Development Methods Subtitles') 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 new file mode 100644 index 0000000..2e839f9 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/1 - Lesson Overview - lang_en_vs4.srt @@ -0,0 +1,75 @@ +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 new file mode 100644 index 0000000..800ffb5 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/10 - Refactoring - lang_en_vs4.srt @@ -0,0 +1,103 @@ +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 new file mode 100644 index 0000000..ad48828 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/11 - Pair Programming - lang_en_vs4.srt @@ -0,0 +1,99 @@ +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 new file mode 100644 index 0000000..d40bda6 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt @@ -0,0 +1,111 @@ +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 new file mode 100644 index 0000000..a95cc07 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/13 - On Site Customer - lang_en_vs4.srt @@ -0,0 +1,55 @@ +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 new file mode 100644 index 0000000..7a00887 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/14 - Requirements Engineering - lang_en_vs4.srt @@ -0,0 +1,139 @@ +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 new file mode 100644 index 0000000..af5ee6c --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/15 - Testing Strategy - lang_en_vs4.srt @@ -0,0 +1,147 @@ +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 new file mode 100644 index 0000000..c26e977 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/16 - Testing Strategy Quiz - lang_en_vs4.srt @@ -0,0 +1,47 @@ +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 new file mode 100644 index 0000000..b60861f --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/17 - Testing Strategy Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,127 @@ +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 new file mode 100644 index 0000000..4d8eab6 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/18 - Scrum Intro - lang_en_vs4.srt @@ -0,0 +1,99 @@ +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 new file mode 100644 index 0000000..d646b4e --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/19 - High Level Scrum Process - lang_en_vs4.srt @@ -0,0 +1,215 @@ +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 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. 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 new file mode 100644 index 0000000..38fe4c3 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/3 - Agile Software Development - lang_en_vs7.srt @@ -0,0 +1,159 @@ +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 new file mode 100644 index 0000000..62cc2fa --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/4 - Extreme Programming (XP) - lang_en_vs4.srt @@ -0,0 +1,179 @@ +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 new file mode 100644 index 0000000..d12e73d --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/5 - XP's Values, Principles, and Practices - lang_en_vs4.srt @@ -0,0 +1,151 @@ +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 new file mode 100644 index 0000000..faf25db --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/6 - Incremental Planning - lang_en_vs4.srt @@ -0,0 +1,71 @@ +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 new file mode 100644 index 0000000..0437621 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt @@ -0,0 +1,95 @@ +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 new file mode 100644 index 0000000..3a8962c --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/8 - Simple Design - lang_en_vs4.srt @@ -0,0 +1,63 @@ +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 new file mode 100644 index 0000000..b2a461b --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/9 - Test First Development - lang_en_vs4.srt @@ -0,0 +1,59 @@ +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. -- cgit 1.4.1