Unit-2 –Agile Development

(1) Agility and Agile Process Model

Agility:
• Agility is dynamic, content specific, aggressively change embracing, and growth oriented
• It encourages team structures and attitudes that make communication (among team members, between
technologists and business people, between software engineers and their managers) more simplistic.
• It emphasizes rapid delivery of operational software and de-emphasizes the importance of intermediate
work products.
• It recognizes that planning in an uncertain world has its limits and that a project plan must be flexible.
• Agility can be applied to any software process.
Agile Process:
• Any agile software process is characterized in a manner that addresses a number of key assumptions
[1] It is difficult to predict in advance which software requirements will persist and which will change. It is
equally difficult to predict how customer priorities will change as the project proceeds.
[2] For many types of software, design and construction are interleaved. That is, both activities should be
performed in tandem so that design models are proven as they are created. It is difficult to predict how
much design is necessary before construction is used to prove the design.
[3] Analysis, design, construction, and testing are not as predictable as we might like.
Agility Principles:
1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2 Welcome changing requirements, even late in development.
3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to
the shorter timescale.
4 Business people and developers must work together daily throughout the project.
5 Build projects around motivated individuals. Give them the environment and support they need, and
trust them to get the job done.
6 The most efficient and effective method of conveying information to and within a development team is
face-to-face conversation.
7 Working software is the primary measure of progress.
8 Agile processes promote sustainable development. The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
9 Continuous attention to technical excellence and good design enhances agility.
10 Simplicity—the art of maximizing the amount of work not done—is essential.
11 The best architectures, requirements, and designs emerge from self– organizing teams.
12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.
Agile Process Models:
• Extreme Programming (XP)
• Adaptive Software Development (ASD)
• Dynamic Systems Development Method (DSDM)
• Scrum
• Crystal
• Feature Driven Development (FDD)
• Agile Modeling (AM)
 Unit-2 –Agile Development

(2) Extreme Programming

• It is most widely used agile process model.
• XP uses an object-oriented approach as its preferred development paradigm.
• It defines four (4) framework activities Planning, Design, Coding, and Testing.

Planning:

Figure: Extreme Programming Process

• Begins with the creation of a set of stories (also called user stories)
• Each story is written by the customer and is placed on an index card
• The customer assigns a value (i.e. a priority) to the story
• Agile team assesses each story and assigns a cost
• Stories are grouped to for a deliverable increment
• A commitment is made on delivery date
• After the first increment “project velocity” is used to help define subsequent delivery dates for other
increments
Design:
• Follows the keep it simple principle
• Encourage the use of CRC (class-responsibility-collaborator) cards
• For difficult design problems, suggests the creation of “spike solutions”—a design prototype
• Encourages “refactoring”—an iterative refinement of the internal program design
• Design occurs both before and after coding commences
Coding:
• Recommends the construction of a series of unit tests for each of the stories before coding commences
• Encourages “pair programming”
– Developers work in pairs, checking each other's work and providing the support to always do a good
job.
– Mechanism for real-time problem solving and real-time quality assurance
 Unit-2 –Agile Development

– Keeps the developers focused on the problem at hand

• Needs continuous integration with other portions (stories) of the s/w, which provides a “smoke testing”
environment
Testing:
• Unit tests should be implemented using a framework to make testing automated. This encourages a
regression testing strategy.
• Integration and validation testing can occur on a daily basis
• Acceptance tests, also called customer tests, are specified by the customer and executed to assess
customer visible functionality
• Acceptance tests are derived from user stories

Adaptive Software Development (ASD)

Adaptive Software Development (ASD) is a technique for building complex software and systems.
ASD focus on human collaboration and team self-organization.
ASD incorporates three phases Speculation, Collaboration, and Learning.

Figure: Adaptive Software Development

Speculation:

• “Speculate” refers to the planning paradox—outcomes are unpredictable, therefore, endless

suppositions on a product’s look and feel are not likely to lead to any business value.
• The big idea behind speculate is when we plan a product to its smallest detail as in a requirements up
front Waterfall variant, we produce the product we intend and not the product the customer needs.
• In the ASD mindset, planning is to speculation as intention is to need.
Collaboration:
• Collaboration represents a balance between managing the doing and creating and maintaining the
 Unit-2 –Agile Development
collaborative environment.”
 Unit-2 –Agile Development

Speculation says we can’t predict outcomes. If we can’t predict outcomes, we can’t plan. If we can’t plan,
traditional project management theory suffers.
• Collaboration weights speculation in that a project manager plans the work between the predictable parts
of the environment and adapts to the uncertainties of various factors—stakeholders, requirements,
software vendors, technology, etc.
Learning:
• “Learning” cycles challenge all stakeholders and project team members.
• Based on short iterations of design, build and testing, knowledge accumulates from the small mistakes we
make due to false assumptions, poorly stated or ambiguous requirements or misunderstanding the
stakeholders’ needs.
• Correcting those mistakes through shared learning cycles leads to greater positive experience and
eventual mastery of the problem domain.

Dynamic Systems Development Methods (DSDM)

• The Dynamic Systems Development Method is an agile software 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”
• DSDM is an iterative software process in which each iteration follows the 80 percent rule.
• That is, only enough work is required for each increment to facilitate movement to the next increment.
• The remaining detail can be completed later when more business requirements are known or changes
have been requested and accommodated.
DSDM life cycle that defines three different iterative cycles, preceded by two additional life cycle activities:
Feasibility study—establishes the basic business requirements and constraints associated with the
application to be built and then assesses whether the application is a viable candidate for the DSDM process.
Business study—establishes the functional and information requirements that will allow the application to
provide business value; also, defines the basic application architecture and identifies the maintainability
requirements for the application.
Functional model iteration—produces a set of incremental prototypes that demonstrate functionality for the
customer.
Design and build iteration—revisits prototypes built during functional model iteration to ensure that each
has been engineered in a manner that will enable it to provide operational business value for end users.
Implementation—places the latest software increment into the operational environment.

• DSDM can be combined with XP to provide a combination approach that defines a solid process model (the
DSDM life cycle) with the nuts and bolts practices (XP) that are required to build software increments.
• In addition, the ASD concepts of collaboration and self-organizing teams can be adapted to a combined
process model.

Scrum
• Scrum principles are consistent with the agile manifesto and are used to guide development activities
within a process that incorporates the five framework activities: requirements, analysis, design, evolution,
and delivery.
• Within each framework activity, work tasks occur within a process pattern called a sprint.
 Unit-2 –Agile Development

• The work conducted within a sprint (the number of sprints required for each framework activity will vary
depending on product complexity and size) is adapted to the problem at hand and is defined and often
modified in real time by the Scrum team.
• Scrum emphasizes the use of a set of software process patterns that have proven effective for projects
with tight timelines, changing requirements, and business criticality.
• Each of these process patterns defines a set of development actions: Backlog—a prioritized list of project
requirements or features that provide business value for the customer.
• Items can be added to the backlog at any time (this is how changes are introduced).
• The product manager assesses the backlog and updates priorities as required.

Crystal
• The Crystal methodology is one of the most lightweight, adaptable approaches to software development.
Crystal is actually comprised of a family of agile methodologies such as Crystal Clear, Crystal Yellow, Crystal
Orange and others, whose unique characteristics are driven by several factors such as team size, system
criticality, and project priorities.
• This Crystal family addresses the realization that each project may require a slightly tailored set of
policies, practices, and processes in order to meet the project‘s unique characteristics.
• Several of the key tenets of Crystal include teamwork, communication, and simplicity, as well as
reflection to frequently adjust and improve the process.
• Like other agile process methodologies, Crystal promotes early, frequent delivery of working software,
high user involvement, adaptability, and the removal of bureaucracy or distractions.

Feature Driven Development (FDD)

Figure: Feature Driven Development Model

• FDD is a model-driven, short-iteration process.

• It begins with establishing an overall model shape.
• Then it continues with a series of two-week “design by feature, build by feature” iterations.
• The features are small, “useful in the eyes of the client” results.
• FDD designs the rest of the development process around feature delivery using the following eight
practices:
– Domain Object Modeling
– Developing by Feature
– Component/Class Ownership
 Unit-2 –Agile Development

– Feature Teams
– Inspections
– Configuration Management
– Regular Builds
– Visibility of progress and results
• FDD recommends specific programmer practices such as “Regular Builds” and
“Component/Class Ownership”.
• Unlike other agile methods, FDD describes specific, very short phases of work, which are to
be accomplished separately per feature.
• These include Domain Walkthrough, Design, Design Inspection, Code, Code Inspection, and
Promote to Build.

Agile Modeling (AM)

• Agile Modeling (AM) is a practice-based methodology for effective modeling and
documentation of software-based systems.
• Simply put, Agile Modeling (AM) is a collection of values, principles, and practices for
modeling software that can be applied on a software development project in an effective
and light-weight manner.
• Although AM suggests a wide array of “core” and “supplementary” modeling principles, those
that make
AM unique are:
Use multiple models. There are many different models and notations that can be used to
describe software. AM suggests that to provide needed insight, each model should present a
different aspect of the system and only those models that provide value to their intended
audience should be used.
Travel light. As software engineering work proceeds, keep only those models that will provide
long-term value and jettison the rest.
Content is more important than representation. Modeling should impart information to its
intended audience. A syntactically perfect model that imparts little useful content is not as
valuable as a model with flawed notation that nevertheless provides valuable content for its
audience.
Know the models and the tools you use to create them. Understand the strengths and
weaknesses of each model and the tools that are used to create it.
Adapt locally. The modeling approach should be adapted to the needs of the agile team.