AGILE SOFTWARE

DEVELOPMENT
Lecture 5
DEFINITIONS
 The term agile can be defined as
1) marked by ready ability to move with quick
easy grace(style), or
2) having a quick resourceful and adaptable
character

Agile = rapid, quick

(Fin: ketterä, vilkas)
AGILE SOFTWARE
DEVELOPMENT
 “Agility, for a software development
organization, is the ability to adopt and react
expeditiously(quickly) and appropriately to
changes in its environment and to demands
imposed by this environment. An agile
process is one that readily embraces(hold)
and supports this degree of adaptability. So,
it is not simply about the size of the process
or the speed of delivery; it is mainly about
flexibility.”
 CHARACTERISTICS OF HEAVY, TRADITIONAL
SOFTWARE DEVELOPMENT METHODS
 Process control or documentation oriented methods like
structured analysis and design

 The main problems of the traditional development

methods are their inability to face challenges set by
changing organisational, business and technical
environment and their insufficient emphasis on
individuals and individual talent and creativity

 Traditional methods are often considered bureaucratic

and restrictive
WHY AGILE METHODS?
 “Agilists” believe that traditional methods
are not suitable when using new
innovative technologies in fast software
product creation
 According to agilists, traditional methods can
not handle constantly changing requirements
and changes
 There are also arguments that traditional
methods kill creativeness and team spirit
 TRADITIONAL VS. AGILE
SOFTWARE DEVELOPMENT
AGILE MANIFESTO– BACKGROUND

 The Agile Alliance is a non-profit organisation dedicated to

promoting the concepts of agile software development, and
helping organizations adopt those concepts (Agile Alliance
2002)
 Agile Alliance was formed by seventeen professional
software developers practicing lightweight approaches to
software development
 Representatives of different agile methods, such as Extreme
Programming (XP), Scrum and Crystal Family
 Their aim was to discuss alternatives to rigorous,
documentation driven software development
 The discovered concepts are outlined in Agile
Manifesto(policy)
VALUES OF AGILE MANIFESTO
1. Individuals and interactions over processes
and tools
2. Working software over comprehensive
documentation
3. Customer collaboration over contract
negotiation
4. Responding to change over following a plan
1. INDIVIDUALS AND INTERACTIONS OVER PROCESSES AND
TOOLS

 Agile methods reject the assumption that people

who are involved in software development are
replaceable parts
 Although process descriptions and organisation
charts are needed to get the project started, Agile
Alliance wants to emphasise individual people over
roles and encourage interaction between individuals
 Interaction and communication between people are
frequently addressed issues in agile software
development
2. WORKING SOFTWARE OVER COMPREHENSIVE
DOCUMENTATION

 Documents containing requirements, analysis or

design can be very useful to guide developer's
work and help to predict the future
 However, working code that has been tested and
debugged reveals information about the
development team, the development process and
the nature of problems to be solved
 According to Cockburn, running program is the
only reliable measure of the speed and
shortcomings of the team and gives a
glimpse(quick look) into what the team should
really be building
3. CUSTOMER COLLABORATION OVER CONTRACT
NEGOTIATION

 Emphasis on close relationships between the

software development team and the customer
 Agile Alliance suggests that fruitful and close
collaboration can make contracts unnecessary
and if a contract situation is in jeopardy(danger),
good collaboration can save the situation
 The basic assumption behind this value statement
is customer satisfaction in general, which is a
main driver in agile software development
4. RESPONDING TO CHANGE OVER FOLLOWING A PLAN

 Plans are useful and planning is included in agile

methods, which also have mechanisms for dealing with
changing requirements
 However, instead of following a plan rigorously,
development teams should constantly reflect the plan
to the current situation and change it accordingly
PRINCIPLES OF AGILE
MANIFESTO
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.
PRINCIPLES OF AGILE
MANIFESTO (CONT.)
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(speed) indefinitely(until further notice).
PRINCIPLES OF AGILE
MANIFESTO (CONT.)
9. Continuous attention to technical
excellence and good design enhances
agility.
10.Simplicity – the art of maximising the
amount of work not done – is essential.
11.The best architectures, requirements, and
designs emerge from self-organising teams.
12.At regular intervals, the team reflects on
how to become more effective, then tunes
and adjusts its behaviour accordingly.
 HUMAN FACTORS

 key traits must exist among the people on an

agile team and the team itself:
 Competence. ( talent, skills, knowledge)
 Common focus. ( deliver a working software increment )
 Collaboration. ( peers and stakeholders)
 Decision-making ability. ( freedom to control its own destiny)
 Fuzzy problem-solving ability.(ambiguity and constant changes,
today problem may not be tomorrow’s problem)
 Mutual trust and respect.
 Self-organization. ( themselves for the work done, process for its
local environment, the work schedule)
EXTREME PROGRAMMING (XP)

or
 EXTREME PROGRAMMING (XP)
 The most widely used agile process, originally proposed by Kent Beck in
2004. It uses an object-oriented approach.
 XP Planning
 Begins with the listening, leads to creation of “user stories” that describes
required output, features, and functionality. Customer assigns a value(i.e., a
priority) to each story.
 Agile team assesses each story and assigns a cost (development weeks. If
more than 3 weeks, customer asked to split into smaller stories)
 Working together, stories are grouped for a deliverable increment next
release.
 A commitment (stories to be included, delivery date and other project
matters) is made. Three ways: 1. Either all stories will be implemented in a
few weeks, 2. high priority stories first, or 3. the riskiest stories will be
implemented first.
 After the first increment “project velocity”, namely number of stories
implemented during the first release is used to help define subsequent
delivery dates for other increments. Customers can add stories, delete
existing stories, change values of an existing story, split stories as
development work proceeds.
 EXTREME PROGRAMMING (XP)
 XP Design ( occurs both before and after coding as refactoring is encouraged)
 Follows the KIS principle (keep it simple) Nothing more nothing less than the story.
 Encourage the use of CRC (class-responsibility-collaborator) cards in an object-
oriented context. The only design work product of XP. They identify and organize
the classes that are relevant to the current software increment.
 For difficult design problems, suggests the creation of “spike solutions”—a design
prototype for that portion is implemented and evaluated.
 Encourages “refactoring”—an iterative refinement of the internal program design.
Does not alter the external behavior yet improve the internal structure. Minimize
chances of bugs. More efficient, easy to read.
 XP Coding
 Recommends the construction of a unit test for a story before coding commences.
So implementer can focus on what must be implemented to pass the test.
 Encourages “pair programming”. Two people work together at one workstation.
Real time problem solving, real time review for quality assurance. Take slightly
different roles.
 XP Testing
 All unit tests are executed daily and ideally should be automated. Regression tests
are conducted to test current and previous components.
 “Acceptance tests” are defined by the customer and executed to assess customer
visible functionality
EXTREME PROGRAMMING (XP)
sp ike so lut io ns
simp le d e sig n
p ro t o t yp e s
CRC c ard s
use r st o rie s
v alue s
ac c e p t anc e t e st c rit e ria
it e ra t io n p la n

re fa c t o ring

p air
p ro g ra mming

Re lea se
s o ft wa re in cre m e n t unit t e st
p ro je ct v e locit y co m p ut e d c o nt inuo us int e g ra t io n

a c ce p t a nc e t e st ing
 SCRUM
 A software development method Originally proposed by Schwaber
and Beedle (an activity occurs during a rugby match) in early 1990.
 Scrum—distinguishing features
 Development work is partitioned into “packets”
 Testing and documentation are on-going as the product is constructed
 Work units occurs in “sprints” and is derived from a “backlog” of
existing changing prioritized requirements
 Changes are not introduced in sprints (short term but stable) but in
backlog.
 Meetings are very short (15 minutes daily) and sometimes conducted
without chairs ( what did you do since last meeting? What obstacles are
you encountering? What do you plan to accomplish by next meeting?)
 “demos” are delivered to the customer with the time-box allocated.
May not contain all functionalities. So customers can evaluate and give
feedbacks.
CHARACTERISTICS
 Self-organizing teams
 Productprogresses in a series of two- to-
four-week “sprints”
 Requirements are captured as items in a
list of “product backlog”
 Usesgenerative rules to create an agile
environment for delivering projects
COMPONENT OF SCRUM
ROLES
 Product Owner
 Scrum master
 Team

 The Product Owner (typically someone from a Marketing

role or a key user in internal development) prioritizes the
Product Backlog.
 The Scrum Master is responsible for making sure a Scrum
team lives by the values and practices of Scrum.
 Scrum teams do not include any of the Traditional
software engineering roles such as Programmer, Designer,
Tester, or Architect. Everyone on the project works
together to complete the set of work, they have
collectively committed to complete within a sprint.
PROBLEM STATEMENT
 In traditional methodology Some vital changes are being
made in project and feel difficulty, and during an
application in the testing Stage, it is very difficult to go
back and do some eminent changes. One may Go to come
across large projects with expensive cost.

 Customer not involvement during any phase.

 Change mind for changing requirement in srs is so difficult

 After project execution Customer satisfaction is less than

expected.

 Tradition methodology Continuous planning for project is the

biggest problem.
GOAL
 All problems occurring during traditional methodology
phases are fixed using Case study on (shopping cart)
project with agile scrum methodology.
LIFE CYCLE OF CASE STUDY
CONTAINS FOLLOWING STEPS
 Product Backlog.
 Sprint Planning Meeting.
 Sprint Backlog.
 Daily Scrum.
 Results.
 Sprint Review Meeting.
 Release Burn chart.
PRODUCT BACKLOG
 The Product Backlog is the master list of all functionality
desired in the product. When using Scrum, it is not
necessary to start a project with a lengthy, upfront effort to
document all requirements.
SPRINT PLANNING MEETING
 The Sprint Planning Meeting is attended by the Product
Owner, the entire Scrum Team.
 During the sprint planning meeting the Product
Owner describes the highest priority features to the
team.
 The Product Owner doesn't have to describe every
item being tracked on the Product Backlog.
SPRINT BACKLOG OF FIRST ITERATION
LAYOUT OF WEBSITE
 DAILY SCRUM

 Team members involve in this meeting on the

following seniors.
 Time:
• 20-minutes
 Three questions:
• What did you do yesterday
• What will you do today?
• What obstacles are in your way?
MENUS ON LAYOUT
LINKS ON MENUS LAYOUT
DISPLAY PRODUCTS ON MAIN
PAGE
CUSTOMER ACCOUNT FORM
TEST CASE ITERATION ONE
RESULTS OF FIRST TWO WEEKS ITERATION
 SPRINT REVIEW MEETING

 Team presents what it accomplished during

the sprint
 Typically takes the form of a demo of new
features or underlying architecture
 Informal
 2-hour prep time rule
 Participants
 Customers
 Management
 Product Owner
 Other engineers
SPRINT BACKLOG OF SECOND
ITERATION
CART IMPLEMENT
CUSTOMER ACCOUNT FORM
CUSTOMER FILLED THE FORM
CUSTOMER LOGIN
TEST CASE 2
RESULTS OF ITERATION TWO
THIRD ITERATION
ORDER PLACEMENT
AFTER ORDER PLACEMENT
FINAL RECEIPT IN PDF
TEST CASE 3
RESULTS OF ITERATION THREE
FOUR ITERATION OF SPRINT
BACKLOG
ADMIN LOGIN FORM
ADMIN PANEL WITH MENUS
PAYMENT PANEL
TEST CASE 4
RESULTS OF FOUR ITERATION
CUSTOMER SATISFACTION GRAPH
RELEASE BURNDOWN
 On a Scrum project, the team tracks its progress against a
release plan by updating a release burn down chart at the end
of each sprint. The horizontal axis of the release burn down
chart shows the sprints months; the vertical axis shows the
amount of work complete.
 CONCLUSION
 Sprint to Sprint check the progress of web project
 Customer involve at the end of every sprint
 Requirements can recharge easily.
 Customer can change his/her mind at the end of
sprint
 Planning is proper sprint to sprint and get idea for
next iteration.
 Proper planning in each sprint get idea for good
planning for next iteration.
 Functionality is improve on each stage.
 Short term sprint is better than long term duration.
 Changing requirements is very easy at the end of
sprint.