Agile Software Development
Agile software development is a conceptual framework for undertaking software development projects as an alternative to traditional methods. The word agile means nimble, agile.
Contents:
1 Introduction
2 History
Agile Software Development
2.1 Agile methods
2.2 Agile Manifesto
3 Characteristics of the methods
3.1 Iterations
3.2 Communication
3.3 Progress
4 Criticism
5 Comparison with other methods
5.1 Adaptive versus prescriptive
5.2 Against ‘iterative development’
5.3 Opposite the waterfall method
5.4 Against “cowboy coding”
6 Suitability of agile methods
7 Agile methods and customized method
8 Agile methods and project management
9 Measuring Agility
10 Overview of Agile methods
1911 Conferences
12 See also
13 Literature
Introduction to Agile Software Development
Although the practices that fall under the term already applied agile software have been developed, is the birth of agile as a term and concept to bring back to the Agile Manifesto in February 2001, during an informal gathering of developers. The Charter states that good software is made by:
Individuals and interactions, rather than processes and tools
Software that works, rather than bulky documentation
Cooperation with the client, rather than negotiating the contract
Dealing with change, rather than following a plan
The twelve charter following principles:
Customer satisfaction by rapid, continuous delivery of useful software
Even late changes in requirements are welcome
Working software is delivered frequently (weeks rather than months)
The developers are working closely and daily with the people who know the business
Projects supported by motivated and reliable people
A conversation in person is the best way of communication, which means that people are quite the same place
Working software is the first measure of progress
The development can always be continued
There is constant attention to technical excellence and good design
Simplicity is key: more is not done, the better
The teams organize themselves
It adapts to the circumstances
The Charter and the principles were a crystallization of ideas that had emerged in the mid nineties, in response to methods that we traditionally classifies as waterfall development approaches. These models were perceived as bureaucratic, slow and narrow, and the creativity and effectiveness would hamper developers.
History of Agile Software Development
Agile methods
It could be that agile and iterative development methods return to development practice in the early history of software development. Originally, agile methods “lightweight methods” (lightweight methods) mentioned.
Agile methods have much in common with the “Rapid Application Development (RAD) techniques from the year 1980, according to James Martin et al
Early pre-agile methods are Scrum-2000 (1986), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and DSDM (1995).
With Extreme Programming (abbreviated as “XP”), agile methods have become popular, although it may not be the first method is agile. Extreme Programming Kent Beck’s answer was in 1996 the struggle of the Chrysler Comprehensive Compensation-(C3) project. The method was refined by Ron Jeffries, through public debate in Portland Pattern Repository Ward Cunningham and further work by Beck, including a book in 1999. There appear elements of Extreme Programming to occur based on Scrum and Episodes pattern language of Ward Cunningham.
Following the publication of the Charter, founded some signatories to the Agile Alliance, to further the principles into practice. In 2005 gathered Alistair Cockburn and Jim Highsmith another group of people – namely, management experts – and wrote an addendum: the PM Declaration of Interdependence.
Agile Manifesto
The Agile Manifesto (Manifesto for Agile Software Development) was established at a meeting of seventeen software developers. The meeting took place from 11 to 13 February 2001 at The Lodge at Snowbird, a ski resort in Utah.
Characteristics of the Methods
Iterations
Most agile methods attempt to reduce risk by developing software in short clear periods (time boxes) that ‘iterations’ are called. Each iteration is like a miniature project itself, and includes all the necessary tasks: planning, analysis, design, testing and documentation. An iteration is not always enough to make the final release. Nevertheless, the aim of an agile project after every iteration something useful for the market to deliver. For software that is often when they are web-based. But, whatever the result after each iteration by the development herafgewogen what the project priorities.
Communications
In agile methods focus on direct communication, preferably as personal contact, rather than written reports. Most agile teams are located at a location called a bullpen. If possible, all people needed for the project in a team charged. But at least these are the developers and those that defines the product. That can help product managers, business analysts and even customers.
Advances
In agile methods, progress was measured by means of working products and prototypes. In agile projects, very little written documentation produced, compared with other methods. This has led to criticism as agile methods were undisciplined. With the publication of this manifesto was the agile development movement put into motion.
Agile Software Development Criticism
Agile development is sometimes criticized as ‘cowboy coding’. XP gave birth to his controversial teachings such as pair programming and continuous design initially provoked considerable controversy and criticism as McBreen and Boehm and Turner and Extreme Programming refactored Matt Stephens. Much of the criticism by Agile practitioners as incomprehension dismissed.
Agile Software Development Criticism includes:
lack of structure and necessary documentation
only works with experienced developers
includes insufficient software design
requires too much cultural change
may result in difficult contract negotiations
Comparison with other methods
Adaptive versus prescriptive
Agile methods are sometimes characterized as misleading the opposite of “planned” and “disciplined” methods. A more accurate description can be made by distinguishing between “adaptive” and “prescriptive” methods. Agile methods are adaptive than at the end of this spectrum.
‘Adaptive’ methods are aimed to rapidly adapt to the changing reality. An ‘adaptive’ team adapts quickly but has a hard time describing exactly what the future will happen and what it will do so.
Other hand there are “prescriptive” methods. These are aimed at the future plans in detail. A team with such a method works is exactly what results and tasks planned for the entire development period, but is struggling to deal with change.
Opposite ‘iterative development’
Most agile methods share iterative development’s emphasis on creating products to be released in short periods. Agile methods differ because of the span is even shorter (weeks instead of months) and because of the emphasis on intensive cooperation. In addition, their agile methods timebox literally.
Opposite the waterfall method
The waterfall method is still widely used. It is the most prescriptive of all models with extensive requirements for process steps in a strictly planned sequence. Progress is measured by it of all documents on which progress management decisions.
The inflexible nature of the waterfall model, the breaking down projects into separate phases and premature commitments that make it difficult responses to change. Therefore, it is actually unusable as project objectives and product requirements in advance is not detailed or may be subject to change during the project.
Conversely deliver agile methods every few weeks mature and proven components, though these are always small parts of the whole. Emphasis is on as soon as possible the smallest functional components to deliver and continually improve and expand. Some agile teams apply the waterfall method to a small scale during each iteration. Others, especially XP teams to the waterfall completely and simultaneously work on different tasks.
Opposite “cowboy coding”
At Cowboy coding is not a distinct method. Team members do what they please. Agile teams often create the impression to cowboy coding to do. Regular review of plans and emphasis on personal contact rather than documented unstructured communication can happen. But agile teams coordinate their activities and continuous monitoring is well defined and disciplined processes.
As with all methods, its success depends on the skill of the user. In a clear and systematic requirements practitioners can be easily settled. The repeal of these requirements may result in activities related to cowboy coding could be identified.
Agile Software Development Part 2