diff options
Diffstat (limited to 'usth/ICT2.7/P4L4 Agile Development Methods Subtitles/3 - Agile Software Development - lang_en_vs7.srt')
-rw-r--r-- | usth/ICT2.7/P4L4 Agile Development Methods Subtitles/3 - Agile Software Development - lang_en_vs7.srt | 159 |
1 files changed, 159 insertions, 0 deletions
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. |