CSC/ECE 517 Fall 2011/ch18 6d na
6d. The Agile landscape.
Overview
Traditional software development methodologies like waterfall methodology are notorious for their lack of flexibility and slowness. That’s why today traditional development methodologies are often replaced by agile development methodologies, which accelerate the process of software development and allow quicker project finalization. Agile software development methodologies give a chance to step away from bureaucracy and strike a balance between laissez-faire style and immersion into paper work.
Introduction to Agile Software Development
Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90's as an answer to the long-growing frustrations of the waterfall SDLC concepts. The term promotes an iterative approach to software development using shorter and lightweight development cycles and some deliverable.
After extensive research, we have found that like other resources, the term Agile as it relates to modern software development, was being used during the 1990's in various published articles both on the internet as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to software process. While the ideas were not new, they gained enough steam for people to pay close attention especially while search engines on the internet became very popular. There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the consitution and the Declaration of Independence. They then hijacked the term 'Agile' in early 2001 when a bunch of people who had been heavily involved in the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software Development.
The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt were actively involved in software development communities with these similar ideas and got seventeen of them together for the Snowbird workshop. Initially, they wanted to get together and build better understanding of each others' approaches. Robert Martin was keen to get some statement, a manifesto that could be used to rally the industry behind these kinds of techniques. We also decided we wanted to choose a name to act as an umbrella name for the various approaches. One next step that did follow, with the active involvement of many of these authors, was the formation of the agile alliance. This group is a non-profit group intended to promote and research agile methods. Amongst other things it sponsors an annual conference in the US.
Agile Manifesto
Manifesto for Agile Software development
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.
Agile planning activities
In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict accurately how much work is involved in each project activity. This leads to a significant investment early in the project, when it is uncertain that the designed functionality is actually desired. Any agile approach to large-scale development has to avoid the reintroduction of the big design up front. One solution is to incorporate levels of planning incorporate a view of ‘the whole.' Agile planning activities for large-scale development efforts should rely on these five levels.
Level 1 - Product Visioning The highest-level view that the stakeholder can paint of the future is the product vision. In this vision, they explain what an organization or product should look like after project completion. They indicate what parts of the system need to change and what efforts can be used to achieve this goal.
Level 2 - Product Roadmap The era of large-scale projects that deliver results in years is behind us. Customers demand faster frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps - into thinking of a road towards the final product. A product roadmap is created and communicated to fellow delivery people to provide a map so concept is more of a reality.
Level 3 - Release Planning In small projects, the product backlog can provide adequate project overview. The size, duration and deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of this changes when applying agile concepts to programs. The first time when rouping activities and allocating them to teams occurs during release planning.
Level 4 - Iteration Planning For each iteration within the release, a planning session occurs to append detail and increase accuracy. Before or during the session, detail is added to the features by breaking them down into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.
Level 5 - Daily Plan The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.
Agile Methodologies
Extreme Programming
XP, originally devised by Kent Beck, has emerged as one of the more popular and controversial agile methods. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks. The original XP recipe is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices: Planning Game, Small Releases, Customer Acceptance Tests, Simple Design, Pair Programming, Test-Driven Development, Refactoring, Continuous Integration, Collective Code Ownership, Coding Standards, Metaphor and Sustainable Pace.