[usth/ICT2.7] Engineer software

author: Nguyễn Gia Phong <mcsinyx@disroot.org> 2020-05-24 16:34:31 +0700
committer: Nguyễn Gia Phong <mcsinyx@disroot.org> 2020-05-24 16:34:31 +0700
commit: b2d80610db6beda38573890ed169815e495bc663 (patch)
tree: 176e1bca6fe644c619d53cf1c24682c244b79cf6 /usth/ICT2.7/P4L4 Agile Development Methods Subtitles
parent: 49376ab97c7427f1c1eca64072d1a934c2e52f50 (diff)
download: cp-b2d80610db6beda38573890ed169815e495bc663.tar.gz
19 files changed, 2201 insertions, 0 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
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.
author	Nguyễn Gia Phong <mcsinyx@disroot.org>	2020-05-24 16:34:31 +0700
committer	Nguyễn Gia Phong <mcsinyx@disroot.org>	2020-05-24 16:34:31 +0700
commit	b2d80610db6beda38573890ed169815e495bc663 (patch)
tree	176e1bca6fe644c619d53cf1c24682c244b79cf6 /usth/ICT2.7/P4L4 Agile Development Methods Subtitles
parent	49376ab97c7427f1c1eca64072d1a934c2e52f50 (diff)
download	cp-b2d80610db6beda38573890ed169815e495bc663.tar.gz