-
Notifications
You must be signed in to change notification settings - Fork 9
/
Copy path01_agile-intro.Rmd
86 lines (62 loc) · 5.34 KB
/
01_agile-intro.Rmd
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
# (PART) Agile Data Science... {-}
# Agile in a Nutshell
## The Origins of Agile
Agile software development is not a specific methodology, a process, or a prescription on how to do your job.
Rather, it is a set of beliefs, a philosophy, that should guide a software development team in making optimal decisions.
Agile was not created out of thin air of course, it was very much a reaction to the then ubiquitous approach called Waterfall.
In Waterfall large software projects are divided into specific stages, each stage should be completed before the next stage can start.
Subsequently these stages are *problem analysis*, *designing the project*, *writing the software*, *testing it* and finally *implementation and maintenance*.
[Here](https://www.youtube.com/watch?v=LxEmGNgqYJA) you can find a clear and neutral introduction into the Waterfall approach.
The goal of Waterfall is delivering complete and faultless software.
The gravity of a Waterfall project is the documentation, in which every requirement and aspect of the software is written down meticulously.
The underlying conviction is that the software is written faster and is of higher quality when all aspects of it are decided upon upfront.
Projects done with the Waterfall method have a major pitfall, however.
They can take a very long time to be completed.
The combination of sequentiality and completeness might cause projects to last many years before software is delivered.
Each time an error or incompleteness is found in one of the later stages, the project moves back to the previous stage to fix it.
Because of the long duration of the entire process, it often occurred that the end result was no longer a good fit for the ever changing market.
The problem analysis might be done years ago and the problem has changed in the meantime.
## The Manifesto
During the nineties, several reactions to the cumbersome Waterfall came to be.
A number of influential thinkers in the world of software development started to explore different ways of writing software.
Alternative processes were suggested, such as Scrum and Xtreme programming.
Eventually, in 2001 a group of seventeen people came together in Utah and drew up the *Manifesto for Agile Software Development*.
Their short 68 word statement is:
> We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
>
> Individuals and interactions over processes and tools
>
> Working software over comprehensive documentation
>
> Customer collaboration over contract negotiation
>
> Responding to change over following a plan
>
> That is, while there is value in the items on the right, we value the items on the left more.
If you think "well, that is rather vague", that is on purpose.
It is not a process you should follow or a methodology that prescribes how you should approach software development.
Rather, they are core values that guide the development team with the many choices it has to make along the way.
At every crossroads the option that is most in line with these values should be selected.
Agile has a radically different approach to software design, by recognising a number of flaws in Waterfall thinking.
First, it is impossible to think through all the aspects of a complex design and architecture before starting to write code.
Software has to grow organically instead.
Secondly, customers typically don't really know what they want from the product, until they start interacting with it.
Legally it might be a good idea to have all the aspects checked off before getting to work, but it will not keep the customer satisfied.
Finally, customers and stakeholders will lose interest and the faith a project will be completed if it takes a long time before a working product is delivered.
## The Twelve Principles
The Manifesto was accompanied by a set of twelve principles that flow from these values.
They are more applicable than the four values and are thereby the principle guidelines when making choices.
They are (numbering added by me):
1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4) Business people and developers must work together daily throughout the project.
5) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7) Working software is the primary measure of progress.
8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9) Continuous attention to technical excellence and good design enhances agility.
10) Simplicity--the art of maximizing the amount of work not done--is essential.
11) The best architectures, requirements, and designs emerge from self-organizing teams.
12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
In Chapter 4 we will interpret them in the data science context.