Course Code: CSE-3319
Lecture 3
Agile Software
Development
Methodologies
Agile
Agile development methodologies have been designed to
address the problem of delivering high quality software:
On time
Under rapid requirement changes
Agility = ability to react to changing situations quickly,
appropriately, and effectively.
notice changes early
initiate action promptly
create a feasible and effective alternative plan quickly
reorient work and resources quickly and effectively
Characteristics…
Intensive communication between key stakeholders
Small and flexible team
Fast iterative cycle
Where to use Agile Development Process?
There is no requirement freezing
Incremental and Iterative approach is used for
modeling
Clients are actively take part in modeling
Prioritization of tasks is being done by key
stakeholders
Everyone in the team is an active participant and
everyone’s input is welcomed
Where not use Agile Development
Customers have limited involvement in the
development effort
Need to prepare documents at each stage
Need to hand over documents to the next stage
Advantages
Shorten Development Cycle
Higher Stability of deliverable
Improved Utilization of resources
Better quality of deliverable due to involvement of the
customer
Limitation
Works well for small and medium size teams
Needs highly motivated and skilled individual
Scrum
Scrum as it exist today grew from is beginning in Japan
in the mid-1980. The name scrum is from the game of
rugby and refers to a strategy used to get a ball back
into play.
Scrum
Small working teams to maximize communication,
minimize overhead and maximize knowledge
sharing.
Adaptable to technical and business changes.
Yields frequent software increments that can be
inspected.
Development work and the people who perform it
are partitioned into clean, low coupling partitions.
Constant testing and documentation is performed.
Ability to declare project “done” whenever required.
Scrum
Backlog: A prioritised list project requirements or
features that provide business value.
Sprints: Consists of work units that are required to
achieve a defined backlog into a predefined time-box
(usually 30 days).
Scrum Meetings: Short 15 mins. meetings held daily
by the scrum team. The Scrum master leads the
meeting.
Demos: Demonstrate software increment to the
customer for evaluation.
Scrum Process
Product Owner
This is the person who makes decisions about features that will be added to the
project.
This person may be a customer, but can be a person in the company who acts as
the customer’s representative.
This person will be the ultimate judge of a projects successful completion.
SCRUM Master
Equivalent to a project manager for a small project or a team lead on a larger
project, with a size of 4 to 8 people.
The scrum master ensures that the rules of scrum are followed:
- By the development team.
- By management and customers.
Extreme Programming
(XP)
Based on ideas and methods from the late 1980s.
Published in 1999 by Kent Beck.
Doesn’t adhere to any particular language, but
generally more suited to object oriented
development.
Extreme Programming (1999–)
XP: Planning
Creation of user stories that describe features and
functionality for software to be built.
Stories are written by the customer on an index card.
Customers assign a priority or value to the card and
developers assign a cost.
If a story takes longer than 3 development weeks, the
customer is asked to split the story into smaller stories
and cost and value are assigned again.
Both sides agree on which stories are to be grouped
for next release.
XP: Planning
XP team orders implementation by
all stories implemented immediately.
stories with highest priority implemented first.
stories with highest risk implemented first.
XP: Project Velocity
Project velocity: Number of customer stories
implemented in first release.
helps estimate delivery rates and schedule for
further releases.
determines whether an over-commitment has been
made for all stories across the entire project.
XP: Test first
Test first – Test cases are written before code.
Initially, tests must fail (no code yet).
Replaces (formal) specification.
Validated by executing the test.
XP: Pair Programming
Coding is traditionally split amongst the
development team with each taking a particular
function or specification and generating the code and
unit tests.
In XP all code is built by two programmers, sitting
side by side, at the same machine.
Pair Programming
Pair programming ensures that all production code
is reviewed by at least one other programmer, and
results in better design, better testing, and better
code.
Knowledge transfer amongst the team is also a major
advantage when using pair programming.
Both programmers in the pair are familiar with the
code and have either written the code or has been
actively involved as the programmer watching the
code generation.
Some Rules
Healthy pairings have communications every 45 to
60 seconds.
Pairs should switch roles often.
Pairs can break off for low complexity tasks.
Pairing is intense (suggest a break every 2 hours).
Refactoring
Refactoring: any change to a computer program's
code which improves its readability or simplifies its
structure without changing its results.
Polish existing code to make it better.
Improve or change design, architecture, efficiency,
quality.
but not functionality.
XP: Design
Basic Principle: “KIS” (Keep It Simple).
Simple design always preferred over a more complex
representation.
Design provides story implementation guidance.
Extra functionality is discouraged.
XP: Coding
Coding does not follow stories and initial design.
Unit test cases are developed to help better focus on
what has to be implemented.
Once coding is complete, tests are run to get
instantaneous feedback.
Continuous Integration
When developers go to release new code, they run
all the unit tests, not just theirs, on the integration
machine.
The tests must run at 100%.
When a test fails, the problem must have been
caused by the last change.
Reason: Developers know the tests ran at 100% the
last time anything was released.
XP: Testing
Implementation of unit tests should be such that
they can be automated.
As soon as code is modified, it can be tested.
Integration and validation of the system can occur on
a daily basis using universal test suite.
A continual indication of progress.
Acceptance tests are specified by customers to test
features and functionality.
XP: 12 Practices
1. The Planning Game
2. Small Releases
3. Metaphor
4. Simple Design
5. Testing
6. Refactoring
7. Pair Programming
8. Collective Ownership
9. Continuous Integration
10. 40-hour Week
11. On-site Customer
12. Coding Standards
The Planning Game
Use stories to facilitate knowledge transfer.
Put decisions in the hands of the person with the best
knowledge:
Plan only as far as your knowledge allows (next
iteration or next release).
Small Releases
Supports quick feedback from users.
Simplify the tracking of metrics.
stories per iteration = project velocity
Increase the manageability of the project for the
customer.
Metaphor
Ground all discussions in a single shared story of
how the whole system works.
Provide an overarching view of the project.
Connect program to work process.
Collective Ownership
Code to belongs to the project, not to an individual
engineer.
Anyone can change any code anywhere and no personal
ownership of modules.
Everyone is permitted access to all the code so everyone
has a stake in knowing all of the code.
As engineers develop required functionality, they may
browse into and modify any class.
They are responsible for keeping all the Unit Tests
running (and writing new ones for new functionality).
“You break it, you fix it.”
Requires deserved trust.
40 Hour Week
Knowledge can only be transferred at a limited rate.
Work for sustained speed, not a single sprint.
Burning the midnight oil kills performance.
If you mess with people’s personal lives (by taking it
over), in the long run the project will pay the
consequences.
On-site Customer
A real, live user available full-time to answer
questions as they occur.
Programmers don’t know everything.
Business knowledge is the key to a successful
business project.
