CPSC 333 SENG 311: Foundations Principles of SE

1
CPSC 333 / SENG 311 Foundations / Principles
of SE

• Extreme Programming

2
Agenda

• What is XP? Some Definitions
• Why XP?
• XP Team Roles
• 4 Variables
• 4 Values
• Back to Basics
• Core Practices

3
What is XP? Some Definitions

• Created by Kent Beck lthttp//c2.com/ppr/about/auth
  or/kent.htmlgt
• lightweight, efficient, low-risk, flexible,
  predictable, scientific and fun approach to
  developing software.

4
What is XP? Some Definitions

• a set of values, principles and practices for
  rapidly developing high-quality software that
  provides the highest value for the customer in
  the fastest way possible.
• low-ceremony, high-discipline software
  methodology.
• iterative, incremental, evolving design

5
Why XP?

• Attempt to solve recurrent software development
  problems
• schedules slip
• project cancellation
• too many defects / maintenance problems
• misunderstood business
• unnecessary features
• personnel shifts

6
Why XP?

• Attempt to address project uncertainty and
  what-ifs
• what if you had to abandon?
• what if you had to switch to another project?
• what if you could wait or defer feature
  implementation?
• what if the market changed or grows
• Use XP when requirements are unclear, or could
  change frequently

7
Why XP?

• The requirements are NEVER clear at first, so
• Big focus quick, and keep customer involved!
• take advantage of the softness of requirements
• Develop first release, and customer can get a
  better feel for future releases

8
Why XP?

• Cost of change can be managed
• a problem caught in analysis is about 200
  times cheaper to fix than if caught in testing or
  maintenance phases
• XP but do we have to anticipate every
  problem in advance?
• remember change WILL occur, always
• avoid over-design due to fear of the unknown
• over-design increases cost, time, scope, and
  complexity
• flow with the customer, and always be ready to
  change

9
Why XP?

• Cost of change can be managed
• cost of change does not necessarily rise
  exponentially over time
• this is THE technical premise of XP
• if the cost of change rose slowly over time,
  you would make big decisions as late in the
  process as possible, defer the cost of making
  those decisions, and have the greatest possible
  chance that you would be right when the decisions
  are made

10
Why XP?

• Cost of change can be managed
• cheap change is easier to maintain in an
  object-oriented environment, where encapsulation
  allows changes to be made easily without
  affecting external interfaces.
• make quick and simple design decisions, be ready
  to re-design when necessary, and write automated
  tests to facilitate continuous design refinement
  process

11
XP Team Roles

• Coach
• technical, advisory, or management expert
• guides others to making good decisions
• explains process to higher managers
• keeps team motivated and communicating

12
Roles

• Tracker
• may be the same person as coach
• measures progress based on estimates
• make team aware of metrics and actual
  measurements
• enforces rules of the planning game
• (must not be a pain in the neck to other team
  players). Dont track too frequently

13
Roles

• Programmer
• Customer
• writes stories
• write functional or acceptance tests
• pays for the project
• End User
• actually uses the software product, hands-on

14
Roles

• Tester
• help customer choose and write functional tests
• run tests regularly and broadcast results
• Consultant
• objective expert needed to advise XP team, esp.
  when something goes wrong

15
Roles

• Big Boss
• project manager
• must be courageous

16
4 Variables

• 4 variables that could be used to control the
  pace / process of a software development project
• cost, time, quality, scope
• Typically, customers and managers pick the values
  of 3 variables, and developers pick the value of
  the 4th variable
• Unfortunately, managers/customers erroneously
  believe they can influence all 4 variables, to
  the detriment of software quality.

17
4 Variables

• XP strategy
• expose values of all 4 variables, so all players
  can choose which ones to control.
• Cost (often controlled by managers)
• insufficient money can cripple a project, and
  affect quality
• too much money too soon can lead to mismanaged
  funds, and lower quality
• Too many developers too soon can also cripple
  project
• 9 women cant make 1 baby in 1 month

18
4 Variables

• Time (often controlled by customer)
• too little time? compromise overall quality
• too much time? project could be
  abandoned/cancelled
• increased scope vs. higher quality?
• Quality (often controlled by developers)
• internal vs. external quality
• as seen by customer or as seen by developer
• reduced quality high cost to all parties, esp.
  supplier (legal suits, etc.)
• increased quality? what is that, really?
• may lead to excess time / cost / scope

19
4 Variables

• Scope
• increased scope? more time, more money, lower
  quality depending on management strategies
• reduced scope? less time, less money, higher
  quality.
• varies a lot, since requirements often change
• do enough based on current knowledge, save time,
  minimize cost, and maximize quality
• if theres fixed cost, time and quality, adjust
  scope accordingly, minimize the cost of scope
  changes
• establish a management strategy to manage scope
  changes (Avoid scope creep)

20
4 Variables

• XP focus is on scope
• controlling scope controls the other variables,
  and its relatively easy to control scope based
  on user requirements.
• develop customers most important features first
• feedback previous estimate results (time/cost)
  into future iterations

21
4 Values

• Communication
• always talk to your team about project
• unit tests, pair programming, task estimation, do
  facilitate communication
• helps clarify concepts, issues, esp. in pair
  programming
• Coach reintroduces communication when no one is
  talking

22
4 Values

• Simplicity
• What is the simplest thing that could possibly
  work?
• Avoid the trap of just in case Dont implement
  features that may never be used
• Incremental change only when feature is required

23
4 Values

• Feedback
• find out how the system is behaving
• time estimates provides f/b to customers, test
  cases and production try-outs provide f/b to
  developers, etc.
• provide rapid feedback

24
4 Values

• Courage
• dont be afraid to redesign
• dont hesitate to throw away code thats leading
  nowhere
• experiment with different design and solution
  strategies

25
Principles

• Just like driving, or playing a ball game
• a little here, a little change there, eyes on the
  ball
• rapid feedback timing is critical, and could
  mean everything to a projects survival. Think
  opportunity, and seize the moment
• assume simplicity think of every problem as if
  it could be solved with ridiculous simplicity,
  because thats reality, most of the time.
• dont plan designs for the future focus on the
  known and the now
• incremental change apply a series of small
  changes

26
Principles

• embrace and prepare for change
• get yourself psychologically trained to accept
  changes, because they WILL occur
• quality work
• teach learning focus on teaching project
  development strategies
• small initial investment use tight budget rather
  than excess
• play to win dont settle for the status quo.
  Push for the gold

27
Principles

• concrete experiments try out new designs to see
  if they are feasible
• open, honest communication dont be afraid of
  your team members
• work with peoples instincts, not against them
  sometimes a hunch could be right
• accepted responsibility let people volunteer to
  take on tasks
• local adaptation adapt to your specific work
  environment

28
Principles

• travel light maintain few, simple, valuable
  artifacts
• reasonable measurement sometimes its hard to be
  exactly precise, but estimate to as close as
  possible.

29
Back to Basics

• Coding
• Testing
• Listening
• Designing

30
Core Practices

• The planning game
• Small releases
• System metaphor
• Simple design
• Continuous testing (unit / acceptance)
• Refactoring
• Pair programming

31
Core Practices

• Pair programming
• Collective code ownership
• Continuous integration
• 40-hour work week
• On-site customer
• Coding standards

32
The Planning Game

• 2 players Business and Development
• cooperate to produce maximum business value as
  quickly as possible
• Business creates a list of desired features, and
  develops USER STORY Cards for them
• Development estimates effort for each story, and
  projected team results for each given iteration
• Business prioritizes stories, and decides which
  story to implement, in what order
• Business also decides iteration frequency

33
The Planning Game

• User Stories
• similar to traditional use cases
• usually on 4x6 cards
• a User Story per card
• feature has a name, and is described in broad
  terms
• story can be divided into multiple tasks

34
Small Releases

• Small releases
• start with the smallest highest-priority set of
  stories
• release early
• release often
• add new features in each iteration
• iterations are usually 1 to 3 weeks long

35
System Metaphor / Simple Design

• Project has an organizing metaphor
• helps everyone remember naming convention and
  internal standards
• Simple Design
• use the simplest design possible
• get todays features / requirements done
• avoid just in case over-design
• Remember customers will always change the
  requirements, so dont design excessive
  generalizations

36
Continuous Testing

• Test before coding!
• write test for features before they are coded
• after coding, run test cases
• if the test suite runs, the feature is done
• two major types of tests
• unit tests
• acceptance tests

37
Continuous Testing

• Unit tests
• automated tests written by a developer to test
  implemented features
• each test tests a single class, or a small set of
  related classes
• use testing framework like Junit

38
Continuous Testing

• Acceptance (or Functional) tests
• script of user interface actions and expected
  results
• could be automated using a unit testing framework
• test for combined functioning of the overall
  system, or a large component
• specified by the customer
• a given user story is considered complete when
  all its acceptance tests pass

39
Refactoring / Pair Programming

• Remove any duplicate code
• will typically not break anything
• because refactoring is accompanied by tests as
  well
• Pair programming
• ALL code is written by sets of two programmers
  sitting at one machine
• code is reviewed as it is written, making
  development process faster.

40
Pair Programming

• Does not cut productivity in half
• XPers claim that two programmers working as a
  pair are more than twice as productive as a
  single programmer working alone, and also produce
  higher quality code.
• emphasis of pair programming is on avoiding big
  design flaws rather than little syntax errors
• see Laurie Williams and Alistair Cockburns
  Costs and Benefits of Pair Programming
• http//members.aol.com/humansandt/papers/pairprogr
  ammingcostbene/pairprogrammingcostbene.htm

41
Collective Code Ownership / Continuous Integration

• Collective code ownership
• No single person owns the code.
• EVERYONE is expected to work on ANY part of the
  code at any point in time
• Continuous integration
• all changes are INTEGRATED into the codebase
  daily.
• Tests must ALL run BEFORE AFTER integration
• Best with an Automated Build tool

42
40-Hour Week

• 40-hr week
• Excessive overtime not allowed, max 1week in
  crunch mode
• Programmers go home on time
• Multiple consecutive weeks of overtime are
  treated as a sign that something is wrong with
  team dynamics and/or process structure

43
On-Site Customer

• Absence of customers is accountable for most
  delays in traditional software engineering
  processes.
• presence of customer makes for easier and faster
  communication
• on-site customer helps to shorten the traditional
  requirements analysis phase, since customer is
  around all the time
• (note that analysis accounts for about 40 of
  software development cycles)

44
Coding Standards

• everyone codes according to the same standards
• usually difficult to tell who has written code by
  just looking at it
• probably the most difficult discipline of extreme
  programming !

45
The Practices support each other!
Onsite customer
40-Hour-Week
System Metaphor
Planning Game
Simple Design
Testing
Short Releases
Refactoring
Pair Programming
Coding Standards
Collective ownership
Continuous Integration
46
Structure of XP Projects

• all programmers work together, usually around in
  the same room or around a large table, mostly for
  communication purposes
• fixed iteration cycles, usually 1-3 weeks long
• feature planning meeting with customer at the
  beginning of each iteration
• includes task decomposition and assignment
• no developer is allowed to sign up for more work
  than they did in previous iterations (work
  according to loading ability)

47
Structure of XP Projects

• task assignment followed by pair programming
  implementation, test first!
• develop unit test cases, test, then when a test
  fails, implement new features
• customer provides functional / acceptance tests
  to validate developed features.

48
Management Strategy

• Decentralized decision making, with centralized
  control
• highlight what needs to be done
• work closely with developers (facilitate)
• provide guidance all along the way, not just at
  project commencement
• be aware of issues and adapt XP practice
• dont impose time-consuming reports/docs
• realistic measures / estimates

49
Management Strategy

• Metrics
• let team decide project velocity
• place relevant metrics on a Big Visible Chart
  where team can see them (e.g. number of
  test-cases)
• update info on the chart often daily, weekly
• Track metrics
• gather results without being a nuisance
• make team aware of results
• remind team of targets vs. actual results
• know and enforce the rules of the Planning Game

50
Management Strategy

• Coaching
• confident, preferably technical communication to
  team
• mentor / guide to team, and advisor to management
• provide toys, food and beverage (lighten up!)
• Intervention
• be ready to make decisions, even if unpopular,
  esp. when things get out of control
• humbly learn lessons, and move on
• eg firing personnel, change mgmt., killing the
  project, etc.

51
Facilities Strategy

• XP is a communal development discipline
• team work together, in close space, within
  earshot
• allow people to sit side by side
• half-height, or no walls pull them down !
• put the best, fastest machines in open public
  areas, to attract team to use them

52
Facilities Strategy

• create small cubicles with telephones, for
  privacy and phone calls, with or without
  computers
• reserve a lounge area, with coffee, snacks,
  toys
• team wins if theres any argument about space
  arrangement take control of your development
  environment. Experiment with setup until you get
  your ideal layout
• other things to watch lighting, telephone
  volumes, etc.

53
Planning Strategy

• Separate Business from Development
• balance political power, focus on strengths and
  skills business on decisions and directions,
  development on products
• business scope, timing, priorities, scope,
  choice of technology,
• development estimates, dev. process, practices,
  maintain technology

54
Planning Strategy

• Rules of the Planning Game
• the goal is to maximize value of software
  produced by team. Deduct development cost and
  risks
• the strategy is to invest as little as possible,
  and produce the most valuable features as quickly
  as possible, with as little risk as possible
• the pieces story cards
• the players business and development

55
Planning Game

• 3 cyclic phases
• Exploration identify new features for next
  iteration
• Commitment take up responsibilities for features
  and provide estimates
• Steering navigate through project and update
  plan as project evolves

56
Planning Game 3 Cyclic Phases
Exploration
Commitment
Steering
57
Exploration Phase

• Identify new features for next iteration
• Exploration Phase has 3 moves
• Business writes a story
• Development estimates the story (using ideal
  engineering time)
• Business splits the story into two or more if
  necessary

58
Commitment Phase

• Decide scope and timeline
• 4 moves
• Business sorts stories by value (must-have,
  should-have, nice-to-have)
• Development sorts by risk with respect to
  estimates (well estimated, not-so-well estimated,
  no idea of estimate)
• Development sets Velocity based on calendar
  (including weekends, holidays, etc)
• Business chooses final scope for iteration

59
Steering Phase

• Guide development as and dynamically update plan
  as work and reality unfolds
• 4 moves (B Business D Development)
• B iteration pick 1 iterations worth of Most
  Valuable Stories
• D recovery reset velocity based on new
  estimates
• B new story create if needed, and remove
  previous stories not required at this time
• D re-estimate if required, and set new velocity

60
Iteration Planning

• Done by developers
• Based on tasks associated with stories
• Involves the 3 planning game phases, only this
  time played dominantly by the developers
  themselves
• Example
• Exploration write task, break up task
• Commitment accept task, estimate
• Steering create new tasks, reset estimates,
  velocity

61
XP Development Strategy

• Continuous Integration
• Collective Code Ownership
• Pair Programming
• Refer to previous discussions on the above XP
  concepts

62
Design Strategy

• Simple
• KISS
• keep it small and simple
• apply the Once and Only Once Rule
• use fewest possible classes
• write fewest possible methods
• at the same time, be complete in customer
  requirements
• refactor after new features are added
• Popular Coach line You aint gonna need it
  (YAGNI)

63
Testing Strategy

• story-by-story
• unit tests by programmers
• acceptance tests by customer and testers
• parallel / regressive testing
• ensure that new system works like old the old
  features still work, as well as the new
• shows how the new system differs from old system,
  so Business can decide when its okay to ship the
  new release

64
Testing Strategy

• Stress test push system to its worst load level
• Monkey test ensure that system acts sensibly in
  the presence of nonsensical user input.

65
XP Project LifeCycle
Planning
First Release
Productionize
Planning
Maintenance
Next Release
Productionize
Death
66
20 - 80 Rule

• 80 of the benefit comes from 20 of the effort
• Put the most valuable 20 features into
  production
• Implement the most valuable 20 of the current
  design

67
When not to use XP

• if customer / business insists on traditional
  styles
• if your organization demands long hours of your
  physical presence at work
• if your team is large (gt 20)
• if software technology is not good for continuous
  integration and testing
• if team is in an inappropriate non-community
  based physical layout.

68
Were Available!

• Questions?
• if you have any questions about contents of this
  lecture or other course-related issues, please
  come by during our office hours, or send us email
• Dr. Joshua MTW, 12-1pm, ICT 548
• joshuar_at_cpsc.ucalgary.ca
• Dr. Walker WF, 1-2pm, ICT 546
• rwalker_at_cpsc.ucalgary.ca