1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
|
1
00:00:00,180 --> 00:00:01,740
Okay so let's look at the first one. Well I
2
00:00:01,740 --> 00:00:04,760
don't think that the fact of keeping developers busy is really
3
00:00:04,760 --> 00:00:08,020
one of the highlights or the main benefits of iterative
4
00:00:08,020 --> 00:00:12,310
approaches. Developers are really busy without any need for additional help.
5
00:00:12,310 --> 00:00:14,950
So I will just not mark this one. The second
6
00:00:14,950 --> 00:00:19,280
one conversely is definitely one of the advantages of iterative approaches.
7
00:00:19,280 --> 00:00:21,710
So the fact that iterative approaches give the developers a early
8
00:00:21,710 --> 00:00:25,890
feedback, is a great advantage which has in turn additional advantages.
9
00:00:25,890 --> 00:00:29,340
For example, it increases the project tempo, so it gives the developers
10
00:00:29,340 --> 00:00:32,350
not busy but more focused. It's easier to be focused when you
11
00:00:32,350 --> 00:00:35,790
have a short term deadline, or a short term goal
12
00:00:35,790 --> 00:00:38,670
rather than a release that is planned in six months or even
13
00:00:38,670 --> 00:00:42,420
later. Another advantage of this early feedback is the fact that developers
14
00:00:42,420 --> 00:00:45,390
are rewarded for their efforts so, there is sort of an immediate
15
00:00:45,390 --> 00:00:48,360
rewards because you can see the results of your effort instead of
16
00:00:48,360 --> 00:00:51,310
having to wait a long time to see such results. And last,
17
00:00:51,310 --> 00:00:55,126
but not least the fact of getting early feedback also minimizes
18
00:00:55,126 --> 00:00:58,570
the risks of developing the wrong system. So why is that?
19
00:00:58,570 --> 00:01:01,820
Well because getting early feedback will also allow us to find
20
00:01:01,820 --> 00:01:05,140
out whether we're going in the wrong direction early in the development process
21
00:01:05,140 --> 00:01:08,460
rather than at the end. And therefore, will minimize this risk.
22
00:01:08,460 --> 00:01:10,760
Going back to the previous question, yeah, I don't think that, you
23
00:01:10,760 --> 00:01:12,960
know, doing the same thing over and over is a great
24
00:01:12,960 --> 00:01:16,170
advantage. And in fact, iterative approaches do not do the same thing
25
00:01:16,170 --> 00:01:18,940
over and over. So they keep iterating, but they keep
26
00:01:18,940 --> 00:01:21,930
augmenting the amount of functionality in the system. They don't
27
00:01:21,930 --> 00:01:24,960
just repeat the same thing. As for improving planning, actually
28
00:01:24,960 --> 00:01:27,980
improving planning is not really a strength of these approaches,
29
00:01:27,980 --> 00:01:30,880
because sometimes the number of iterations is hard to predict,
30
00:01:30,880 --> 00:01:33,050
so it's hard to do a natural planning when you
31
00:01:33,050 --> 00:01:36,440
are using an iterative approach. So finally, are iterative approaches
32
00:01:36,440 --> 00:01:38,700
good for accomodating evolving requirements?
33
00:01:38,700 --> 00:01:41,630
Most definitely. First, iterative approaches, and
34
00:01:41,630 --> 00:01:44,590
in particular, the one that we're discussing consider requirements
35
00:01:44,590 --> 00:01:47,900
incrementally, so they can better incorporate your requirements. So if
36
00:01:47,900 --> 00:01:51,030
there are new requirements, it's easier to accommodate them using
37
00:01:51,030 --> 00:01:55,210
an iterative approach. Second, these approaches realize a few requirements
38
00:01:55,210 --> 00:01:57,740
at a time. Something from the most risky ones, as
39
00:01:57,740 --> 00:02:00,600
we said. So any problem with those risky requirements will
40
00:02:00,600 --> 00:02:04,220
be discovered early, and suitable course corrections could be taken.
41
00:02:04,220 --> 00:02:06,850
So in case you still have doubts about iterative approaches,
42
00:02:06,850 --> 00:02:08,460
it might be worth it to go back to
43
00:02:08,460 --> 00:02:11,390
mini course number one, lesson number two to discuss the
44
00:02:11,390 --> 00:02:14,620
life cycle models. Because we talk about iterative approaches
45
00:02:14,620 --> 00:02:17,770
and their advantages and their characteristics there in some detail.
|
