about summary refs log tree commit diff
path: root/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt
diff options
context:
space:
mode:
Diffstat (limited to 'usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt')
-rw-r--r--usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt95
1 files changed, 95 insertions, 0 deletions
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.