Dt1nh6: 1 revision imported

2016-05-09T13:27:30Z

1 revision imported

Macrop at 13:10, 17 March 2015

2015-03-17T13:10:44Z

New page

[[Category:Agile]]
[[Category:Project Management]]

== What is Agile ==
* Software evolves over time
* Adaptive planning, evolutionary development, early delivery
* Deliver value to the business sooner
* Flexible response to change
[[File:Agile.PNG|thumbnail]]

== Agile Manifesto ==
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.

=== Principles ===
==== Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. ====
In a recent workshop, a software development manager questioned the feature or story approach to
iterative cycle planning. "But aren't requirements specifications and architecture documents important?" he
asked. "Yes," Jim replied, "They are important, but we need to understand that '''customers don't care about
documents, UML diagrams or legacy integration. Customers care about whether or not you're delivering
working software''' to them every development cycle—some piece of business functionality that proves to
them that the evolving software application serves their business needs."

Implementing a "customer value" principle is one of those "easier said than done" activities. Traditional
project management practices assume that achieving a plan equals project success equals demonstrated
customer value. The volatility associated with today's projects demands that customer value be reevaluated
frequently, and meeting original project plans may not have much bearing on a project's ultimate success.
Welcome changing requirements, even late in development. Agile processes harness change for the
customer's competitive advantage. The growing unpredictability of the future is one of the most
challenging aspects of the new economy. Turbulence—in both business and technology—causes change,
which can be viewed either as a threat to be guarded against or as an opportunity to be embraced.
Rather than resist change, the agile approach strives to accommodate it as easily and efficiently as possible,
while maintaining an awareness of its consequences. Although most people agree that feedback is important,
they often ignore the fact that the result of accepted feedback is change. Agile methodologies harness this
result, because their proponents understand that facilitating change is more effective than attempting to
prevent it.
==== Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale. ====
For many years, process gurus have been telling everyone to use an incremental
or iterative style of software development, with multiple deliveries of ever-growing functionality. While the
practice has grown in use, it's still not predominant; however, it's essential for agile projects. Furthermore,
we push hard to reduce delivery cycle time.
However, remember that deliver is not the same as release. The business people may have valid reasons for
not putting code into production every couple of weeks. We've seen projects that haven't achieved releasable
functionality for a year or more. But that doesn't exempt them from the rapid cycle of internal deliveries that
allows everyone to evaluate and learn from the growing product.

==== Business people and developers work together daily throughout the project. ====
Many folks want to buy software the way they buy a car. They have a list of features in mind, they negotiate a price, and they pay for
what they asked for. This simple buying model is appealing, but for most software projects, it doesn't work.
So agile developers respond with a radical change in our concept of the requirements process.
For a start, we don't expect a detailed set of requirements to be signed off at the beginning of the project;
rather, we see a high-level view of requirements that is subject to frequent change. Clearly, this is not enough
to design and code, so the gap is closed with frequent interaction between the business people and the
developers. The frequency of this contact often surprises people. We put "daily" in the principle to
emphasize the software customer's continuing commitment to actively take part in, and indeed take joint
responsibility for, the software project.

==== Build projects around motivated individuals, give them the environment and support they need and trust them to get the job done. ====
Deploy all the tools, technologies and processes you like, even our agile
processes, but in the end, it's people who make the difference between success and failure. We realize that
however hard we work in coming up with process ideas, the best we can hope for is a second-order effect on
a project. So it's important to maximize that first-order people factor.
For many people, trust is the hardest thing to give. Decisions must be made by the people who know the
most about the situation. This means that managers must trust their staff to make the decisions about the
things they're paid to know about.

==== The most efficient and effective method of conveying information with and within a development team is face-to-face conversation. ====

Inevitably, when discussing agile methodologies, the topic of documentation
arises. Our opponents appear apoplectic at times, deriding our "lack" of documentation. It's enough to make
us scream, "the issue is not documentation—the issue is understanding!" Yes, physical documentation has
heft and substance, but the real measure of success is abstract: Will the people involved gain the
understanding they need? Many of us are writers, but despite our awards and book sales, we know that
writing is a difficult and inefficient communication medium. We use it because we have to, but most project
teams can and should use more direct communication techniques.
"Tacit knowledge cannot be transferred by getting it out of people's heads and onto paper," writes Nancy
Dixon in Common Knowledge (Harvard Business School Press, 2000). "Tacit knowledge can be transferred
by moving the people who have the knowledge around. The reason is that tacit knowledge is not only the
facts but the relationships among the facts—that is, how people might combine certain facts to deal with a
specific situation." So the distinction between agile and document-centric methodologies is not one of
extensive documentation versus no documentation; rather a differing concept of the blend of documentation
and conversation required to elicit understanding.

==== Working software is the primary measure of progress. ====
Too often, we've seen project teams who don't realize they're in trouble until a short time before delivery. They did the requirements on time, the design on
time, maybe even the code on time, but testing and integration took much longer than they thought. We favor
iterative development primarily because it provides milestones that can't be fudged, which imparts an
accurate measure of the progress and a deeper understanding of the risks involved in any given project. As
Chet Hendrickson, coauthor of Extreme Programming Installed (Addison-Wesley, 2000), remarks, "If a
project is going to fail, I'd rather know that after one month than after 15."
"Working software is the measure of progress because there's no other way of capturing the subtleties of the
requirements: Documents and diagrams are too abstract to let the user 'kick the tires,'" says Dave Thomas,
coauthor of The Pragmatic Programmer (Addison-Wesley, 1999).

==== Agile processes promote sustainable development. ====
The sponsors, developers and users should be able
to maintain a constant pace indefinitely. Our industry is characterized by long nights and weekends,
during which people try to undo the errors of unresponsive planning. Ironically, these long hours don't
actually lead to greater productivity. Martin and Kent Beck have often recalled working at companies where
they spent all day removing errors made late the previous night.
Agility relies upon people who are alert and creative, and can maintain that alertness and creativity for the
full length of a software development project. Sustainable development means finding a working pace (40 or
so hours a week) that the team can sustain over time and remain healthy.

==== Continuous attention to technical excellence and good design enhances agility. ====
When many people look at agile development, they see reminders of the "quick and dirty" RAD (Rapid Application Development)
efforts of the last decade. But, while agile development is similar to RAD in terms of speed and flexibility,
there's a big difference when it comes to technical cleanliness. Agile approaches emphasize quality of design,
because design quality is essential to maintaining agility.
One of the tricky aspects, however, is the fact that agile processes assume and encourage the alteration of
requirements while the code is being written. As such, design cannot be a purely up-front activity to be
completed before construction. Instead, design is a continuous activity that's performed throughout the
project. Each and every iteration will have design work.
The different agile processes emphasize different design styles. FDD has an explicit step at the beginning of
each iteration in which design is executed, usually graphically with the UML. XP places great emphasis on
refactoring to allow the design to evolve as development proceeds. But all of these processes borrow from
each other: FDD uses refactoring as developers revisit earlier design decisions, and XP encourages short
design sessions before coding tasks. In all cases, the project's design is enhanced continually throughout the
project.

==== Simplicity—the art of maximizing the amount of work not done—is essential. ====
Any software development task can be approached with a host of methods. In an agile project, it's particularly important to
use simple approaches, because they're easier to change. It's easier to add something to a process that's too
simple than it is to take something away from a process that's too complicated. Hence, there's a strong taste
of minimalism in all the agile methods. Include only what everybody needs rather than what anybody needs,
to make it easier for teams to add something that addresses their own particular needs.
"Simple, clear purpose and principles give rise to complex, intelligent behavior," says Dee Hock, former
CEO of Visa International. "Complex rules and regulations give rise to simple, stupid behavior." No
methodology can ever address all the complexity of a modern software project. Giving people a simple set of
rules and encouraging their creativity will produce far better outcomes than imposing complex, rigid
regulations.

==== The best architectures, requirements and designs emerge from self-organizing teams. ====
Contrary to what you've heard, form doesn't follow function: Form follows failure. "The form of made things is always subject
to change in response to their real or perceived shortcomings, their failures to function properly," writes
Henry Petroski, civil engineering professor and author of The Evolution of Useful Things (Vintage Books,
1994). Stuart Brand writes that the "form follows function" idea has misled architects into believing that they
could predict how buildings would actually be used.
Petroski's views are similar to one of the two key points of this principle—that the best designs
(architectures, requirements) emerge from iterative development and use rather than from early plans. The
second point of the principle is that emergent properties (emergence, a key property of complex systems,
roughly translates to innovation and creativity in human organizations) are best generated from selforganizing
teams in which the interactions are high and the process rules are few.

==== At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. ====
Agile methods are not something you pick and follow slavishly. You may start with
one of these processes, but we all recognize that we can't come up with the right process for every situation.
So any agile team must refine and reflect as it goes along, constantly improving its practices in its local
circumstances.
Jim has been working with a consulting company to develop an Adaptive Software Development–Extreme
Programming combination methodology. The first team to use it modified it immediately. Martin has worked
with a number of teams at ThoughtWorks to tailor Extreme Programming practices to various project
situations. Trust in people, believing that individual capability and group interaction are key to success
extends to trusting teams to monitor and improve their own development processes.

=== Toward an Agile Future ===
Early response to the Agile Manifesto has been gratifying. Several e-mails expressed sentiments such as,
"My product manager has already posted the Manifesto on her wall." Many of Martin's colleagues at
ThoughtWorks have popped in to say how much they shared the values.
One question that arose immediately was whether or not the Alliance was a precursor to what one conference
attendee tagged a Unified Lightweight Methodology. Absolutely not! While the group believes that a set of
common purposes and principles will benefit the users of agile methodologies, we are equally adamant that
variety and diversity of practices are necessary. When it comes to methodologies, each project is different
and each project team is different—there's no one-size-fits-all solution.
What of the future? We can confidently say that we don't know. Agility is all about trusting in one's ability to
respond to unpredictable events more than trusting in one's ability to plan ahead for them. We also know that
the personal relationships formed by our collaboration matter far more than the document that we've
produced. One thing is clear: we've only just started.

← Older revision	Revision as of 13:27, 9 May 2016
(No difference)

Agile - Revision history

Dt1nh6: 1 revision imported

Macrop at 13:10, 17 March 2015