Softenr-3

(1)

Software Engineering

Software Process

(2)

Chapter-3: Agile Development

• _Objectives

–

_{Agile methods}

–

_{Plan-driven and agile development}

–

_{Extreme programming}

–

_{Agile project management}

–

_{Scaling agile methods}

(3)

Rapid software development

• _{Rapid development and delivery is now often}

the most important requirement for software

systems

–

_{Businesses operate in a fast –changing requirement}

and it is practically impossible to produce a set of

stable software requirements

–

_{Software has to evolve quickly to reflect changing}

business needs.

(4)

Rapid software development

• _{Rapid software development}

–

_{Specification, design and implementation are}

inter-leaved

–

_{System is developed as a series of versions with}

stakeholders involved in version evaluation

–

_{User interfaces are often developed using an IDE}

(5)

5

What is “Agility”?

• _{Effective (rapid and adaptive) response to change}

• _{Effective communication among all stakeholders}

• Drawing the customer onto the team

• _{Organizing a team so that it is in control of the work}

performed

Yielding …

(6)

Plan-driven and agile processes

• _{Plan-driven processes are processes where all of}

the process activities are planned in advance and

progress is measured against this plan.

• _{In agile processes, planning is incremental and it}

is easier to change the process to reflect

changing customer requirements.

• _{In practice, most practical processes include}

(7)

Plan-driven and agile specification

(8)

Agile methods

• _{Dissatisfaction with the overheads involved in software design}

methods of the 1980s and 1990s led to the creation of agile

methods. These methods:

–

Focus on the code rather than the design

–

_{Are based on an iterative approach to software development}

–

Are intended to deliver working software quickly and evolve this

quickly to meet changing requirements.

• _{The aim of agile methods is to reduce overheads in the}

(9)

9

(10)

Agile values

1. Individuals and Interactions Over Processes and Tools.

2. Working Software Over Comprehensive Documentation.

3. Customer Collaboration Over Contract Negotiation.

(11)

11

Agility Principles - I

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. Agile processes

harness change for the customer's competitive advantage.

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

(12)

Agility Principles - II

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.

(13)

13

Human Factors

• _{the process molds to the needs of the people}

_{and team,}

_not

the other way around

• _{key traits must exist among the people on an agile}

team and the team itself:

–

_Competence.

–

_{Common focus.}

–

_{Collaboration.}

–

_{Decision-making ability.}

–

_{Fuzzy problem-solving ability.}

–

_{Mutual trust and respect.}

(14)

Problems with agile methods

• _{It can be}

_{difficult to keep the interest of customers}

who are involved in the process.

• _{Team members may be unsuited}

_{to the intense}

involvement that characterizes agile methods.

• _{Prioritizing changes}

_{can be difficult where there are}

multiple stakeholders

.

• _Maintaining

_{simplicity requires extra work}

_.

• _Contracts

_{may be a problem as with other}

(15)

15

Extreme Programming (XP)

• _{The most widely used agile process, originally proposed by}

Kent Beck

• _{XP Planning}

–

_{Begins with the creation of “}

_{user stories}

_”

–

_{Agile team assesses each story and assigns a}

_cost

–

_{Stories are grouped to form a}

_{deliverable increment}

–

_A

_commitment

_{is made on delivery date}

–

_{After the first increment “}

_{project velocity}

_{” is used to help}

(16)

(17)

17

(18)

Extreme programming practices (a)

Principle or practice Description

Incremental planning Requirements are recorded on story cards and the stories to be

included in a release are determined by the time available and their relative priority. The developers break these stories into development ‘Tasks’.

Small releases The minimal useful set of functionality that provides business

value is developed first. Releases of the system are frequent and incrementally add functionality to the first release.

Simple design Enough design is carried out to meet the current requirements

and no more.

Test-first development An automated unit test framework is used to write tests for a

(19)

Extreme programming practices (b)

Pair programming Developers work in pairs, checking each other’s work and

providing the support to always do a good job.

Collective ownership The pairs of developers work on all areas of the system, so that

no islands of expertise develop and all the developers take responsibility for all of the code. Anyone can change anything.

Continuous integration As soon as the work on a task is complete, it is integrated into

the whole system. After any such integration, all the unit tests in the system must pass.

Sustainable pace Large amounts of overtime are not considered acceptable as

the net effect is often to reduce code quality and medium term productivity

On-site customer A representative of the end-user of the system (the customer)

should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation.

(20)

Extreme Programming (XP)

unit test pair programming Release user stories values

acceptance test criteria

iteration plan simple design CRC cards spike solutions prototypes refactoring

For reference, here are the 12 Practices of

Extreme Programming

1.Coding Standards

2.Collective Ownership

3.Continuous Integration

4.On-Site Customer

5.Pair Programming

6.Planning Game

7.Refactoring

8.Short Releases

9.Simple Design

10.Sustainable Pace (40 Hour Week)

11.System Metaphor

(21)

21

Adaptive Software Development

• _{Originally proposed by Jim Highsmith}

• _{ASD — distinguishing features}

–

_{Mission-driven}

_planning

–

_{Component-based focus}

–

_{Uses “}

_time-boxing

_”

–

_{Explicit consideration of}

_risks

(22)

(23)

Adaptive Software Development

adaptive cycle planning uses mission statement project constraints basic requirements

time-boxed release plan

Requirements gathering J AD

mini-specs

components implemented/ tested focus groups for feedback formal technical reviews

postmortems

software increment

adjustments for subsequent cycles

(24)

Scrum

• _{Originally proposed by Schwaber and Beedle}

• _{Scrum—distinguishing features}

–

Development work is partitioned into “

packets

”

–

Testing and documentation are on-going

as the product

is constructed

–

_{Work occurs in “}

_sprints

_{” and is derived from a “}

_backlog

_”

of existing requirements

–

_{Meetings are very short}

_{and sometimes conducted}

without chairs

(25)

time-Ref: http://www.dninfotech.com/Home/AgileTraining

(26)

Crystal

• _{Proposed by Cockburn and Highsmith}

• _{Crystal—distinguishing features}

–

_{Actually a}

_{family of process models}

_{that allow}

“

maneuverability

” based on problem characteristics

–

_{Face-to-face communication}

_{is emphasized}

–

_{Suggests the use of “}

_{reflection workshops}

_{” to review the work}

(27)

27

Feature Driven Development

• _{Originally proposed by Peter Coad et al}

• _{FDD—distinguishing features}

–

_{Emphasis is on defining}

_{“features”}

• _a

_feature

_{“is a client-valued function that can be}

implemented in two weeks or less.”

–

_{Uses a}

_{feature template}

• <action> the <result> <by | for | of | to> a(n) <object>

–

_A

_{features list}

_{is created and “}

_{plan by feature}

_{” is}

conducted

(28)

(29)

Summary

(30)