From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001
From: Nguyễn Gia Phong <mcsinyx@disroot.org>
Date: Sun, 24 May 2020 16:34:31 +0700
Subject: [usth/ICT2.7] Engineer software

---
 .../7 - Small Releases - lang_en_vs4.srt           | 95 ++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt

(limited to 'usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt')

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.
-- 
cgit 1.4.1