Lecture 3

Lecture 3
COMSATS Islamabad
Enterprise
Systems
Development
(CSC447)
Muhammad Usman, Assistant Professor
Agile Development
2001: Kent Beck and 16 other software developers,
referred to as “Agile Alliance”, signed the “manifesto for
Agile software development”. It stated:
Through this work we have come to Value:
Individuals and interaction over processes and tool
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following plan
That is, while there is value in the items on the right ,
we values the items on the left more.
2
Agile Methods
 Agile software development is a group of software
development methodologies that are based on similar
principles.
 Agile methodologies generally promote a project
management process that encourages
– frequent inspection and adaptation
– a leadership philosophy that encourages team
work
– a set of engineering best practices that allow for
rapid delivery of high-quality software, and a
business approach that aligns development with
customer needs and company goals
3
What are Agile Methods?
 Agile software development is a conceptual
framework for undertaking software engineering
projects.
 Most agile methods attempt to minimize risk by
developing software in short timeboxes, called
iterations, which may typically last one to four weeks.
 Each iteration is like a miniature software project of its
own, and includes all of the tasks necessary to
release the mini-increment of new functionality.
4
Agile Methods v/s Traditional Methods
 Agile methods emphasize real time communication,
preferably face-to-face, over written documents.
 Agile methods like XP relies on the close collaboration
of activity engaged individuals with ordinary talents
and has the ability to flexibly schedule the
implementation of functionality, responding to
changing business needs.
 Reference: Extreme Programming explained:
Embrace Change By: Kent Beck with Cynthia
Andres; 2nd ed., 2005
5
Different Agile Methods?
•
•
•
•
•
•
•
•
•
Extreme Programming (XP)
Scrum
Agile Modeling
Adaptive Software Development (ASD)
Crystal Clear and Other Crystal Methodologies
Dynamic Systems Development Method (DSDM)
Feature Driven Development
Lean software development
Agile Unified Process (AUP)
6
Extreme Programming
• Emphasis on four characteristics of agility
– Communication: continual interchange between
customers and developers
– Simplicity: select the simplest design or
implementation
– Courage: commitment to delivering functionality early
and often
– Feedback: loops built into the various activitites
during the development process
eXtreme Programming (XP)
• Philosophy
– Take known good practices and push them to
extremes
• For example
– “If code reviews are good, we’ll review code all the
time”
– “If testing is good, we’ll test all the time”
– “If design is good, we’ll make it part of everybody’s
daily business”
eXtreme Programming (XP)
Essence of XP
• Four variables in software development :
– Cost, Time, Quality, Scope
• Four Values
– Communication, Simplicity, Feedback, and Courage
• Five Principles
– Provide feedback, assume simplicity, make incremental changes,
embrace change, quality work
• 12 Practices
Twelve Facets of XP
• The planning game
(customer defines value)
• Small releases
• Metaphor (common vision,
common names)
• Simple design
• Writing tests first
• Refactoring
• Pair programming
• Collective ownership
• Continuous integration
(small increments)
• Sustainable pace (40
hours/week)
• On-site customer
• Coding standards
XP (Extreme Programming)
XP Practices
– Planning game - programmers estimate effort of
implementing customer stories and customer
decides about scope and timing of releases
– Short releases - new release every 2-3 months
– Simple design - emphasis on simplest design
– Testing - development test driven…*
– Refactoring - restructuring and changes to simplify
– Pair Programming - 2 people at 1 computer
12
XP (Extreme Programming)…….
XP Practices
– Collective ownership - anyone can change any part
of the code at any time.
– Continuous integration - new builds as soon as
code ready
– 40 hour week - maximum 40-hour week. No
overtime
– On-site customer - customer present and available
full-time for team
– Coding standards - rules exist and are followed
– Open workspace - large room small cubicles
– Just rules - team has own rules but can be changed
any at time
13
Key Practices…..
Planning
– User stories are written.
– Release planning creates the schedule.
– Make frequent small releases
– The Project Velocity is measured.
– The project is divided into iterations.
– Iteration planning starts each iteration.
– Move people around.
– A stand-up meeting starts each day.
– Fix XP when it breaks.
Designing

Simplicity.

Choose a system metaphor. (system of names for your objects
that everyone can relate to)

Use CRC cards for design sessions.

Create spike solutions to reduce risk.

Refactor whenever and wherever possible.
14
Key Practices
Coding
–
–
–
–
–
–
–
The customer is always available.
Code must be written to agreed standards.
Code the unit test first.
All production code is pair programmed.
Only one pair integrates code at a time.
Integrate often.
No overtime.
Testing




All code must have unit tests.
All code must pass all unit tests before it can be released.
When a bug is found tests are created.
Acceptance tests are run often and the score is published.
15
XP > Practices > “Circles of Life”
On-site Customer
Coding
Standards
Metaphor
Refactoring
Customer – Team – Developer Pair – Team – Customer
Acceptance
Tests
Unit Tests
Pair
Programming
Continuous
Integration
Collective
Ownership
Simple Design
Sustainable
Pace
Release
Planning
Synergy >
Small Releases
16
When is Extreme Too Extreme?
• Extreme programming's practices are
interdependent
– A vulnerability if one of them is modified
• Requirements expressed as a set of test cases
must be passed by the software
– System passes the tests but is not what the customer
is paying for
• Refactoring issue
– Difficult to rework a system without degrading its
architecture
Scrum
• In Rugby, a scrum is a
way to restart the game
after an interruption, e.g.
after a minor foul.
• “During a Scrum, the
pack must work as a unit,
not as 8 individuals.
Everybody has a role to
play. The important goal
to bear in mind is that
when you work well
together as a unit, the
whole is much greater
than the sum of the
parts.”
The On-Line Rugby Coaching Manual
What is Scrum?
• Scrum is not an acronym
• Scrum is
– a team-based approach
– to iteratively, incrementally develop systems and
products
– when requirements are rapidly changing
• Assumes complicated, unpredictable environment
• It produces a potentially shippable set of functionality at
the end of every iteration
How does Scrum work?
•
•
•
•
Small teams (< 10 people)
A series of Sprints (1-4 weeks)
Visible, usable increments
Time-boxed
How does Scrum work?
Sprint Rules
• Total focus—no unwanted diversion
• NO interruptions/changes from the outside
• New work may be uncovered by the team
• Very XP-ish
22
What Happens During a Sprint?
• Frequent, short Scrum Meetings
• Each team produces a visible, usable increment
• Each increment builds on prior increments
• Clearly defined deliverables and responsibilities
• Each team member buys into the assignment
23
What’s a Scrum Meeting?
• Short (15 - 30 min) frequent meetings,
facilitated by the ScrumMaster
• All team members attend—even teleworkers
• One activity -- ScrumMaster asks each
attendee 3 questions
24
What Are The 3 Questions?
1. What have you completed (relative to the
Backlog) since the last Scrum meeting?
2. What got in your way of completing this work?
3. What will you do between now and the next
Scrum meeting?
25
At the End of a Sprint?
•
•
•
•
Status meeting with all stakeholders.
Increments are delivered.
Surprises are reported.
ANYTHING can be changed, work can be added,
eliminated, re-prioritized.
• New estimates and team assignments are made for the
next Sprint.
• The project can be cancelled.
“Experience from earlier increments allows better estimates and
planning as project progresses. It's always easier to estimate shorter
development periods”
26
Rational Unified Process
•
•
•
•
S/W Engineering Process
Process Framework
Process Product
Workers, Activities, Artifacts, Workflows
RUP Phases
development cycle
iteration
inc.
elaboration
milestone
An iteration endpoint when some
significant decision
or evaluation
occurs.
phase
construction
transition
release
increment
A stable executable
subset of the final
product. The end of
each iteration is a
minor release.
The difference
(delta) between the
releases of 2
subsequent
iterations.
final production
release
At this point, the
system is released
for production use.
The Architecture of RUP
You Didn’t Understand the RUP When…
• You think that
– Inception = requirements
– elaboration = design
– construction = implementation.
• You think that the purpose of elaboration is to fully and carefully define
models, which are translated into code during construction
• You think that only prototypes are created in elaboration
• You try to define most of the requirements before starting design or
implementation.
• You try to define most of the design before starting implementation
• A “long time” is spent doing requirements or design work before
programming starts
• You try to plan a project in detail from start to finish, allocating the work
to each iteration; you try to speculatively predict all the iterations
• An organization wants believable plans and estimates for projects before
they have entered the elaboration phase
RUP Support
• Templates
– http://sce.uhcl.edu/helm/rationalunifiedprocess/
process/templates.htm
– http://pic.dhe.ibm.com/infocenter/reqpro/v7r1m
0/index.jsp?topic=/com.ibm.reqpro.help/administ
ering/projects/creating_modifying/r_rup_proj_te
mplate.html
• Tools
– http://www.rational.com.ar/tools/herramientas.h
tml
S/W Development Best Practices
•
•
•
•
•
•
Develop software iteratively
Manage requirements
Use component based architecture
Visually model software
Continuously verify software quality ?
Control changes to software
Process Models
•
•
•
•
•
•
Waterfall
Prototyping
RAD
Incremental
Spiral
Agile
– XP
– SCRUM
• RUP