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, 0 insertions, 159 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 deleted file mode 100644 index 38fe4c3..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/3 - Agile Software Development - lang_en_vs7.srt +++ /dev/null @@ -1,159 +0,0 @@ -1 -00:00:00,150 --> 00:00:03,250 -And assuming that cost is flat that we can really lower that - -2 -00:00:03,250 --> 00:00:06,590 -curve then teher are a few interesting consequences. First of all upfront - -3 -00:00:06,590 --> 00:00:10,330 -work becomes a liability, we pay for speculative work some of which - -4 -00:00:10,330 --> 00:00:13,320 -is likely to be wrong. Some of which we are likely to undo - -5 -00:00:13,320 --> 00:00:16,870 -and the reason for ambiguity and volability for example in requirements then - -6 -00:00:16,870 --> 00:00:19,310 -it's good to delay We don't want to plan for something that - -7 -00:00:19,310 --> 00:00:22,380 -might never happen, to invest resources in something that we might have - -8 -00:00:22,380 --> 00:00:25,170 -to throw away later on. In general, if cost is flat it is - -9 -00:00:25,170 --> 00:00:28,820 -cost effective to delay all decisions until the last possible - -10 -00:00:28,820 --> 00:00:30,990 -moment and only pay for what we use, so to - -11 -00:00:30,990 --> 00:00:34,550 -speak. In other words, there is value in waiting, time - -12 -00:00:34,550 --> 00:00:37,810 -answers questions and removes uncertainty. And we want to take advantage - -13 -00:00:37,810 --> 00:00:40,610 -of that. This and other considerations led to the birth - -14 -00:00:40,610 --> 00:00:44,590 -of Agile Softer Development. Specifically for those of you who are - -15 -00:00:44,590 --> 00:00:47,200 -interested in a little bit of history. In February 2001 - -16 -00:00:47,200 --> 00:00:50,430 -a group of software developers, 17 of them, met to discuss - -17 -00:00:50,430 --> 00:00:53,950 -lightweight development methods and published Manifesto for Agile - -18 -00:00:53,950 --> 00:00:57,630 -Software Developement. Which introduces and defines the concept of - -19 -00:00:57,630 --> 00:01:00,990 -agile software development, or agile methods. In a - -20 -00:01:00,990 --> 00:01:03,770 -nutshell, agile methods aim at flat cost and a - -21 -00:01:03,770 --> 00:01:06,190 -decrease in traditional overhead by following a set - -22 -00:01:06,190 --> 00:01:09,400 -of important principles. Our first principle is to focus - -23 -00:01:09,400 --> 00:01:11,700 -on the code, rather than the design, to avoid - -24 -00:01:11,700 --> 00:01:16,080 -unnecessary changes. Another principle is to focus on people, - -25 -00:01:16,080 --> 00:01:20,100 -value people over process, and make sure to reward people. - -26 -00:01:20,100 --> 00:01:22,990 -In addition agile methods are all based on iterative approaches to - -27 -00:01:22,990 --> 00:01:26,310 -software development, to deliver working software quickly, and to be - -28 -00:01:26,310 --> 00:01:29,230 -evolve it Just as quickly based on feedback. And feedback can - -29 -00:01:29,230 --> 00:01:31,740 -come from many sources, in particular, it'll come from the - -30 -00:01:31,740 --> 00:01:34,500 -customer, it'll be customer feedback. And to be able to do - -31 -00:01:34,500 --> 00:01:38,040 -so, agile methods need to involve the customer throughout the development - -32 -00:01:38,040 --> 00:01:41,260 -process. Finally, there are two more principles I want to mention. - -33 -00:01:41,260 --> 00:01:43,620 -Which are cornerstones of agile methods. The first - -34 -00:01:43,620 --> 00:01:46,520 -one is the expectation that requirements will change, and - -35 -00:01:46,520 --> 00:01:48,010 -therefore, we need to be able to handle some - -36 -00:01:48,010 --> 00:01:50,570 -changes. We can't count on the requirements to be - -37 -00:01:50,570 --> 00:01:52,890 -still and unmutable. And the last principle is - -38 -00:01:52,890 --> 00:01:56,430 -the mentality of simplicity. Simple design and simple code - -39 -00:01:56,430 --> 00:01:58,810 -and so on. But be careful, because simple does - -40 -00:01:58,810 --> 00:02:02,060 -not mean inadequate, but rather, as simple as possible. |