And assuming that cost is flat that we can really lower that
curve then teher are a few interesting consequences. First of all upfront
work becomes a liability, we pay for speculative work some of which
is likely to be wrong. Some of which we are likely to undo
and the reason for ambiguity and volability for example in requirements then
it's good to delay We don't want to plan for something that
might never happen, to invest resources in something that we might have
to throw away later on. In general, if cost is flat it is
cost effective to delay all decisions until the last possible
moment and only pay for what we use, so to
speak. In other words, there is value in waiting, time
answers questions and removes uncertainty. And we want to take advantage
of that. This and other considerations led to the birth
of Agile Softer Development. Specifically for those of you who are
interested in a little bit of history. In February 2001
a group of software developers, 17 of them, met to discuss
lightweight development methods and published Manifesto for Agile
Software Developement. Which introduces and defines the concept of
agile software development, or agile methods. In a
nutshell, agile methods aim at flat cost and a
decrease in traditional overhead by following a set
of important principles. Our first principle is to focus
on the code, rather than the design, to avoid
unnecessary changes. Another principle is to focus on people,
value people over process, and make sure to reward people.
In addition agile methods are all based on iterative approaches to
software development, to deliver working software quickly, and to be
evolve it Just as quickly based on feedback. And feedback can
come from many sources, in particular, it'll come from the
customer, it'll be customer feedback. And to be able to do
so, agile methods need to involve the customer throughout the development
process. Finally, there are two more principles I want to mention.
Which are cornerstones of agile methods. The first
one is the expectation that requirements will change, and
therefore, we need to be able to handle some
changes. We can't count on the requirements to be
still and unmutable. And the last principle is
the mentality of simplicity. Simple design and simple code
and so on. But be careful, because simple does
not mean inadequate, but rather, as simple as possible.