1

TOPIC: AGILE METHODOLOGY

NAME : DIGVIJAY JADHAV

ROLL NO : 09

CLASS : TE COMPUTER.

PRN : 72159760C

Audit Course 6
2 TOPICS COVERED

Agile methods
Plan-driven and agile development
Extreme programming
Agile project management
Scaling agile methods
RAPID SOFTWARE DEVELOPMENT
3
 Why?
 Need to react to changes more quickly than 2 year long waterfall projects
 2 years and then you got the design wrong anyway! Small deliveries aren't
abstract
 How?
 Goal - Deliver working software quickly
• Compromise - less functionality in a delivery, not lower quality
• Less documentation
 Focus on the code rather than the design
 Interleave
• Specification, design and implementation are inter-leaved
 Deliver small versions and get user (stakeholder) input
 Ouch!

s
es
en
siv
on
sp
Re e
od
C
tle it
Br
ty
ali

Copyright © 2010 AgileInnovation

Qu
Your Favorite!
Transparency
PAINPOINTS

im es
Cy cle T
Long
ty
plexi
Com
ity
uctiv
Prod
5 AGILE MANIFESTO

Our values:
 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.
 6 PLAN-DRIVEN AND AGILE
separate
SPECIFICATION
Iteration within stage
development Not
stages with necessarily
the outputs to waterfall
be produced model – plan-
at each of driven,
these stages incremental
planned in development
advance. is possible

User's full
agreement at
end, not before
code
Iteration of stage
Copyright © 2010 AgileInnovation
8 PROBLEMS WITH AGILE
METHODS
 It can be difficult to keep the interest of customers / users 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 approaches to iterative development.

 Because of their focus on small, tightly-integrated teams, there are problems in

scaling agile methods to large systems.
 Less emphasis on documentation - harder to maintain when you get a new team
for maintenance
 9 BALANCE PLAN DRIVEN AND
•
AGILE
Not great for Agile:
• What type of system is being developed?
• Plan-driven approaches may be required for systems that require a lot of analysis before implementation (e.g. real-
time system with complex timing requirements).
• What is the expected system lifetime?
• Long-lifetime systems may require more design documentation to communicate the original intentions of the system
developers to the support team.
• What technologies are available to support system development?
• Agile methods rely on good tools to keep track of an evolving design
• How is the development team organized?
• Many teams; Outsourcing ---> need design documents to control borders
 Culture or contract needs detailed specification
 Is rapid feedback from users realistic?
 Large scale, not co-located may require more formal communication methods
 Need high level programming skills - refactoring, work with little spec
 Outside regulation documentation requirements
10 EXTREME PROGRAMMING

 A popular form of Agile

 Extreme Programming (XP) takes an ‘extreme’ approach to iterative
development.
 New versions may be built several times per day;
 Increments are delivered to customers every 2 weeks;
 All tests must be run for every build and the build is only accepted if tests run
successfully.

 Customer involvement means full-time customer engagement with the team. -

Specifications through user stories broken into tasks

 People not process : pair programming, collective ownership and a process

that avoids long working hours.
 Regular system releases. - release set of user stories

 Maintaining simplicity through constant refactoring of code.

11 THE EXTREME PROGRAMMING
RELEASE CYCLE
THE PARTS AND THE WHOLE

• Iteration
Plan
• Daily Stand-
Up

Set
Adapt Controller
Target

• Clean Design & Code &

Refactor Inspect
• User Stories - Late
Elaboration
• Shared Code Ownership • Pair Programming
• Test Driven • Customer Reviews
Development….. & Feedback
• Retrospectives
Sustainable pace • AutoTest…..
Collective Ownership with users
Minimal documentation for sprint
THE LIFE OF AN ITERATION

Copyright © 2010 AgileInnovation

TRANSPARENCY

“Tell me how you will measure

me and I’ll tell you how I’ll
behave”

Copyright © 2010 AgileInnovation

15 A ‘PRESCRIBING MEDICATION’
STORY
16 EXAMPLES OF TASK CARDS FOR
PRESCRIBING MEDICATION
18 REFACTORING

 Programming team look for possible software improvements and make

these improvements even where there is no immediate need for them.
 This improves the understandability of the software and so reduces the
need for documentation.
 Changes are easier to make because the code is well-structured and
clear.
 However, some changes requires architecture refactoring and this is
much more expensive.
 RISK:
 Changes the user does not test
 Changes to working software break it
19 EXAMPLES OF REFACTORING

Re-organization of a class hierarchy to remove

duplicate code.
Tidying up and renaming attributes and methods to
make them easier to understand.
The replacement of inline code with calls to methods
that have been included in a program library.
20 TEST CASE DESCRIPTION FOR
DOSE CHECKING
21 TEST AUTOMATION

Automate tests (junit)

Run upon checkin
Difficulties:
 Time constraints
 Programmer preferences to not test
 Test coverage
22 PAIR PROGRAMMING

In XP, programmers work in pairs, sitting together to

develop code.
Common ownership
Knowledge spread
Informal review
Refactoring
Similar output to two people coding
23 SCRUM

Project Manager's job: - Deliver needed system on time

within budget
The Scrum approach - manage the iterations
There are three phases in Scrum.
 outline planning phase - general picture and architecture
 Sprint cycles releasing increments of the system.
 The project closure phase - final delivery, documentation and
review of lessons learned.
24 THE SCRUM PROCESS
25 THE SPRINT CYCLE

 Every 2–4 weeks (a fixed length).

 1) Project team with customer: Look at product backlog - select
stories to implement
 2) implement with all customer communication through scrum
master (protecting pgmr at this point)
 Scrum master has project manager role during sprint
 Daily 15 min meetings
 Stand up often
 Team presents progress and impediments
 Scrum master tasked with removing impediments

 3) Review system release with user

26 SCRUM BENEFITS

 The product is broken down into a set of manageable and

understandable chunks.
 Unstable requirements do not hold up progress.
 The whole team have visibility of everything and consequently
team communication is improved.
 Customers see on-time delivery of increments and gain feedback
on how the product works.
 Trust between customers and developers is established and a
positive culture is created in which everyone expects the project
to succeed.
27 SUMMARY

 Plan Driven (Ex: Waterfall) vs Incremental (Ex: Agile )

 Structure and benefits and downfalls

 XP - an implementation of Agile - Power to the Programmer

 User story requirements
 Test driven design with continual retest and integration
 Pair Programming
 Refactoring encouraged

 Scrum - project management of Agile using sprints

 Iterations of full team contact / Scrum master protection of
programmers / full team release review