Chapter 4
Agile Development
CHAPTER OVERVIEW AND COMMENTS
4.1 What is Agility?
The main point of this section is to introduce agility in the context of software development. Agility is more than change management. Agility means that customers and developers need to work together as collaborators on the development team and try to build products that can be adapted to a rapidly changing market place. Part of this adaptation is learning when and how to streamline the production of work products and focus on the development of incremental operational prototypes.
A manifesto is normally associated with an emerging political movement-one that attacks the old guard and suggests revolutionary change.
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
That is, while there is value in the items on the right, we value the items on the left more.”
Kent Beck et al
Agility is today’s buzzword when describing a modern software process. It is how to appropriately respond to changes.
Change is what software development is very much about.
Changes in the software being built, changes to team members, changes b/c of new technology that may have impact on the project that creates the product.
Agility encompasses the philosophy espoused in the manifesto noted earlier.
It adopts the customer as a part of the development team and works to eliminate the “us and them” attitude that continue to pervade many software projects.
The Agile Alliance http://www.agilealliance.org/home defines 12 principles for those who want to achieve agility.
Principles behind the Agile Manifesto
We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
4.2 What is an Agile Process?
Any agile software process is characterized in a manner that addresses three key assumptions:
An agile software process must adapt incrementally. To adapt incremental adaptation, an agile team requires customer feedback.
An operational prototype is an effective catalyst for customer feedback. Hence, incremental development strategy should be instituted.
Software increments (executable prototypes) must be delivered in short time so that adaptation keeps pace with change.
4.2.1 The Politics of Agile Development
Check out the debate in the book on page 75.
4.2.2 Human Factors
Check out the debate in the book on page 76.
4.3 Agile Process Models
4.3.1 Extreme Programming (XP) http://www.extremeprogramming.org/rules/crccards.html
The most widely used agile process, originally proposed by Kent Beck. It encompasses a set of rules and practices that occur within the context of four framework activities: planning, design, coding and testing.
Planning
Begins with the creation of “user stories” and then placed on an index card.
The customer assigns a value to the story based on the overall business value of the function.
Agile “XP” team assesses each story and assigns a cost “measured in development weeks.”
If stories take more than 3 weeks to develop, the customer is asked to split the stories into smaller ones.
Stories are grouped to form a deliverable increment “done by customer and XP team.”
Once a commitment is made on delivery date, the XP team orders the stories that will be developed in one of three ways:
After the first increment (project release), “project velocity” is used to help define subsequent delivery dates for other increments.
Project velocity is the number of customer stories implemented during the first release. http://www.extremeprogramming.org/rules/velocity.html
Project velocity can be used then to:
Design
XP Follows the KIS(S) principle. A simple design is always preferred over a more complex representation.
Encourage the use of CRC (class-responsibility collaboration) cards which identify and organize the O-O classes that are relevant to the current software increment.
For difficult design problems, suggests the creation of “spike solutions”—a design prototype that is implemented and evaluated. http://www.ironspeed.com/articles/Evolving%20With%20Extreme%20Programming/Article.aspx
Encourages “refactoring”—an iterative refinement of the internal program design that controls the code modifications by suggesting small design changes that may improve the design.
Coding
Recommends the construction of a unit test for a story before coding commences
Encourages “pair programming” where two programmers work together at one workstation to create code for a story. “Two heads better than one.”
Testing
All unit tests are executed daily which provides the XP team with a continual indication of progress and also can raise warning flags early if things are going awry.
“Acceptance tests” are defined by the customer “user stories” and executed to assess customer visible functionality
4.3.2 Adaptive Software Development (ASD)
Was originally proposed by Jim Highsmith.
ASD: A technique that is used for building complex software and systems.
Highsmith defines ASD lifecycle that incorporates 3 phases: speculation, collaboration, and learning.
Speculation: An adaptive cycle-planning is conducted where it uses the customer’s mission statement, project constraints (delivery dates, user description) and basic requirements.
Collaboration: People working together must trust one another to:
Learning
Learning will help them to improve their level of real understanding.
4.3.3 Dynamic System Development Method (DSDM)
Promoted by the DSDM Consortium (www.dsdm.org)
Dynamic System Development Method is an agile S/W development approach that provides a framework for building and maintaining systems which meet tight time constraints through the use of incremental prototyping in a controlled project environment.
It defines three different iterative cycles preceded by two additional life cycles activities:
Feasibility Study: Business requirements and constraints.
Business Study: Establishes req. that will allow the application to provide business value.
Functional Model Iteration: Produce iterative prototypes.
Design and build iteration: Revisit prototyping.
Implementation: Include the latest prototype into the operational environment.
4.3.4 Scrum
Originally proposed by Schwaber and Beedle; the name derived from an activity that occurs during a rugby match.
Scrum—distinguishing features
Development work is partitioned into “packets”
Testing and documentation are on-going as the product is constructed
Work occurs in “sprints è framework activities” and is derived from a “backlog è requirements that provide business values” of existing requirements
Meetings are very short and sometimes conducted without chairs
“Demos” are delivered to the customer with the time-box allocated
Source: https://www2.southeastern.edu/Academics/Faculty/galkadi/285/notes/Chapter4.doc
Web site to visit: https://www2.southeastern.edu
Author of the text: indicated on the source document of the above text
If you are the author of the text above and you not agree to share your knowledge for teaching, research, scholarship (for fair use as indicated in the United States copyrigh low) please send us an e-mail and we will remove your text quickly. Fair use is a limitation and exception to the exclusive right granted by copyright law to the author of a creative work. In United States copyright law, fair use is a doctrine that permits limited use of copyrighted material without acquiring permission from the rights holders. Examples of fair use include commentary, search engines, criticism, news reporting, research, teaching, library archiving and scholarship. It provides for the legal, unlicensed citation or incorporation of copyrighted material in another author's work under a four-factor balancing test. (source: http://en.wikipedia.org/wiki/Fair_use)
The information of medicine and health contained in the site are of a general nature and purpose which is purely informative and for this reason may not replace in any case, the council of a doctor or a qualified entity legally to the profession.
The texts are the property of their respective authors and we thank them for giving us the opportunity to share for free to students, teachers and users of the Web their texts will used only for illustrative educational and scientific purposes only.
All the information in our site are given for nonprofit educational purposes