Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Extreme Programming

CE320 - Large Scale Software Systems and Extreme Programming
by

Bahit Hamid

on 3 May 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Extreme Programming

Collective Code Ownership
Refactoring
Pair-Programming
Unit Testing
Test-Driven Development (TDD)
Incremental Requirement
Simple Design
Planning
Releasing
XP and Risks
Goal
Start
XP's Value
Effectively dealing with risks - using XP
Done done. Nuff said.
Extreme Programming
A revision for visual learners
Developing
Releases
Schedule Slips
XP's
short release cycles
= limited slip
XP's
short tasks
= problem solved during cycle
XP
uses 1-week iteration
= rapid feedback
XP implements
highest priority feature first
Project Canceled
XP chooses smallest release that makes the most business sense
Value
of the software is
greatest at all stages
System Goes Sour
Automated tests ensure a quality baseline
XP keeps the system
in deployable condition
Defect rate
Constants testing
= defect rate low
Business Changes
XP's short release cycle = less change during development of a single release
During release - customer is free to pick/choose new functionality for functionality not yet completed
The Mythical Man-Month
Why?
I don't know,
the story always start with this Mythical Man... month. :D
Lets GO!
The Story is Simple..
You start with a project.
You have money.
You want to finish it quickly.
You add more resource to project by:
Adding more developers and such..
But you have to teach the developers how the team works..
You spend more time and money to keep everyone on the same page
And finally you missed your milestone and deadline.
PROJECT FAIL!
NEXT!
Solution
Use Agile's
EXTREME PROGRAMMING
Main key points here:
Programmers deliver
SATISFACTION
of user needs rather than any tangible product
Changes in objectives are
inevitable
-
DEAL WITH IT
.
Lets start with values..
XP's Value
Simplicity
Courage
Respect
Feedback
Communication
Vision
Estimating
Story
Slack
Iteration Planning
Release planning and the planning game
Root-cause analysis
Risk management
Other values
Release Planning
One project at a time
Release early.. release often
Group the smallest possible
minimum marketable features
The Planning Game
Choose
release dates
[timeboxed plan]
1
3
Discuss
minimum marketable features
Decompose MMFs into specific
stories
(tasks)
2
Get programmers to
estimate
how long each story requires
4
Get customers to
prioritise
features and stories
5
Compute how many
person hours/day
the team has before the release date
6
MMF
so that the highest-value, lowest-cost features/stories are done first
7
Form the
release plan
by picking as many items from the top of the priority list as you can fit in the available person time
Keep Your Options Open
Allow releasing at any time
Tasks are standalone
Slice your application vertically (across components)
Plan at the
last possible moment
.
Objective = Maximise ROI
Iteration Planning
Say wha..?
Iterations are safety mechanism
Allowing the team to
stop
and
compare
plan
with
reality
Iterations...
are timed boxed
work ends at a particular time regardless of how much you've finished
why?
This reveals problems early
How to plan an iteration
Previous velocity
Sum of original estimates of stories entirely completed
=
Break down the stories into programmer-centric engineering task
Brainstorm the tasks
Estimate the tasks
Split task that are too big
What if things go wrong?
See if there is
any way to change your plan
so that you still meet your commitments
If the problem is too big to absorb?
Reduce the scope
of the iteration
Under
no
circumstances one should
change
the iteration deadline
Slack
Iteration deadlines are
fixed
and unmovable
Slack = extra capacity
How?
Schedule useful and important work
that isn't time critical
aside - in time of emergencies
Pay down technical debt
Research Time
Risk Management
Why manage risk?
Risk management
allows you
to
make
and
meet commitments despite difficulties
.
Generic Risk Management
Risk such as:
flawed release plan
employee turnover
Risk = unusual events that have an impact on your team's work.
Risk
Multipliers
Depend on
acceptable schedule slip
and rigour in applying XP
Risk
increase
the time taken to finish the work
What about Problem Specific Risks? (specific to your project)
THEY NEED TO BE IDENTIFIED FIRST
Probability estimated
Risk Exposure
= Risk probability x impact if the risk happens.
support all the features!
allows the team to get started while... customer work out requirements detail
F . I . R . S . T
Steps:-
1.
Fast:
test run quickly and frequently - find problem early when they are easy to fix.
2.
Independent:
Each test should be independent - run in any combination/order
3.
Repeatable:
repeatable in any environment
4.
Self-Validating:
test have boolean output - pass or fail - they are automatic
5:
Timely:
Unit tests need to be written a timely fashion - before production code they test thus TDD.
Unit Testing
means
testing individual units
of source code to
determine if they work as required
Addresses
Staff Turnover
spreading responsibility
by
Collective code ownership
means
no
single person
claims
ownership over any part of the system
Allowing
anyone to make changes and fix code
improved code quality
leads to
Code Refactoring
is the
process of changing
a computer program's
source code
without
modifying its external functional behavior
in order
to improve
some of the
non-functional attributes
of the software.
code is easier to
understand
maintain
extend
Why?
code is simpler and better designed
We Refactor...
to get
CLEAN CODE
CODE
Clean
Bad code = slow programmers
Bad code = slow projects down
way
Clean code is an
essential
requirement in XP
Bad code = hard to understand
Clean
The name of a variable, a class or a method should say
why it exists
,
why it does
and
how it was used
.
Name
Functions
Formatting
Comments
Object and Data structure
Classes
Code
Functions should be small
Should do one thing
Should have very few arguments
Avoid output arguments when possible
Avoid duplication
Formatting is
about communicating well with the reader
Ensure the
filename tells a story
Variable
should be declared as close as possible to their usage
Use short lines
Avoid alignment that leads the eye away from the intent of the code
Indent lines
Good code clearly shows its intent - so no need for comment...
but
Comments are OK in a small number of cases
Legal
Explanation of pattern
Explanation of intent
TODOs
Still..
Comments do not make up for bad code
Comment can be
deceptive,
if..
code and comment are out of sync
Hide implementation by
exposing
abstract interfaces that allow users to manipulate the essence of the data.
The Law of Demeter: a method
m
of a class
C
should only call the methods of these:
C
An object created by
m
An object passed as an argument to
m
An object held in an instance of
C
Avoid
train wrecks
Avoid
feature envy
String dir = ctxt.getThis().getThat().getOut()
a class that uses methods of
another class excessively
Classes should be small
The name of class should
describe
what
responsibility it fulfills
.
Single responsibility principle:
A class or module should have one, and only one, reason to change
Cohesion... ?
Classes should have a small number of instance variables.
When classes lose cohesion..
SPLIT THEM!
Pair Programming
You divide up into pairs
Driver:
Responsible for implementing
Navigator:
Should think ahead and look at the overall picture
Work Incrementally
One function or One refactoring
at a time..
Commit
every time you have a new unit (function, method)
or.. a refactoring
implemented and tested
UNIT TESTING
ACT AS DOCUMENTATION OF THE SYSTEMS
FACILITATE CHANGE
SIMPLIFIES INTEGRATION
HELP DESIGN SYSTEM
Benefit of Unit Testing
TDD
Laws of TDD
First Law:
You may not write production code
until you have written a failing unit test
Second Law:
You may not write more of a unit test than
is sufficient to fail and not compiling is failing
Third Law:
You may not write more production code than
is sufficient to pass the currently failing test
TDD asks us to
write unit test
first,
before

we
write production code
Benefits
Scope Creep
Coupling and cohesion
Trust
Rhythm - Test, Code, Refactor
If you really want to put
other
code, write test for it
If it's hard to write test = you have design problem
Writing clean code that works and demonstrating your intentions with automated tests increases trust in you
It's clearer what to do next:
either write another test
or
make the broken test work
A story is "done done" if it is:
tested
coded
refactored
integrated
reviewed
debugged
accepted
documented
...
..
.
10-minute Build
TRAC
Continuous Integration -
CI
Subversion Essential Tasks
Version Control
No Bugs
A bug or defect is any behavior of your software that will unpleasantly surprise important stakeholders
No bug allows you to release your software without separate testing phase
Achieving ZERO bugs
Write fewer bugs
using TDD
Eliminate bug breeding ground -
pay technical debt
Fix bugs
now or never
Test your process using
exploratory testing
Fix your process using
root-cause analysis
on bugs
Version control is the management of changes to documents, program and other information stored as computer files
Team members work together without stepping on each other's toes
Changes identified with a
revision number
+
time
+
who
Revision can be made, undone, notified, compared and merged...
You should not fear change
Checking out
Committing
Updating
your
working copy
Automatic
merging
and copy
Checking the status
Reverting change
Finding difference
Adding new files
Removing files and folders
Wiki
Web interface to Subversion
Project management (Milestone + Roadmap)
Timeline
Ticket System
Hyperlinking information
Searching
Trac is a web-based management and bug-tracking system for software projects.
Builds a tested release in 10 minutes
Automating your build is one of the
easiest ways
to
improve morale
and
increase productivity
Project
grows
- increases build time
Keep it under 10 minutes
or
else you will not build often enough
Continuous integration means
keeping everybody's code integrated
and
building release infrastructure
along with the rest of the application
Why it works..
Integration is painful, but short cycles make integration less so:
Shorter cycle
Smaller changes
Less chance for changes to overlap
Overcoming:
False feature rich
XP insists that only
highest priority tasks are addressed
Staff turnover
XP
gives programmers responsibility
for
estimating
& completing work
Teaching
how to
improve estimates
respect those estimates
Less frustration
- nobody is asked to do the obviously impossible
XP encourage human
contact among team
-
reducing loneliness
By
Bahit Hamid

Owh.. since you reached here

Take note on the last 5 slides of lecture 9
Features:
Face-to-face communication
Deliver Frequently
Satisfy Customer
Working software
Simplicity
Self-organising teams
Maintain a constant pace
Clean design
Trust people
Welcome change in requirement
Team reflect and adjust
Agile 12 Princple
Full transcript