Agile Methods (Extreme Programming)

1
Agile Methods (Extreme Programming)

• A Framework For Pulling It All Together

2
Extreme Programming

• A deliberate and disciplined approach to software
  development
• Suited to risky projects with dynamic
  requirements
• Including late life cycle changes
• Emphasizes customer satisfaction
• Unproductive activities have been trimmed from
  the process
• Reduces cost
• Reduces frustration

3
Extreme Programming (cont.)

• Promotes team work
• Managers
• Customers
• Developers
• Software project improvements (see following
  slides)
• Communication
• Simplicity
• Feedback
• Courage

4
Software project improvements

• Communication
• Between developers
• Between managers and developers
• Between customer and developers
• Simplicity
• Designs are keep simple
• Designs are keep clean (uncluttered with
  extraneous features)

5
Software project improvements (cont.)

• Feedback
• Testing begins on day 1 thus encouraging feedback
• Customer feedback/requests are implemented
  immediately
• Courage
• Programmers respond to changing requirements
• Programmers respond to changing technology
• No fear of repercussion such as cost/time

6
Something New?

• software engineered to be simple and elegant is
  no more valuable than software that is complex
  and hard to maintain
• XP refutes this view
• Programs that are easy to understand and maintain
  save time and money

7
Something New? (cont.)

• Testing is a crucial part of development
• Tests are created before, during, and after code
  is written
• Tests are well matched to the code they are
  testing
• Identification of bugs leads to new tests to
  ensure that the same bugs do not reoccur

8
Something New? (cont.)

• Change is embraced
• Customer feedback is encouraged throughout
  development
• Allows customers to take full advantage of
  unseen/unanticipated opportunities in the
  marketplace

9
When?

• Created in response to problem domains whose
  requirements change
• Address areas of risk
• Time schedule
• Unproven/unfamiliar technology
• Small groups of developers (2-10)
• Not good for large teams of developers

10
When? (cont.)

• Extended development team
• Developers
• Managers
• Customers
• All must buy in to the process

11
Another Methodology?

• Software methodology
• The set of rules and practices used to create
  computer programs
• Heavyweight methodology
• Many rules, practices, and documents
• Requires discipline and time to follow correctly
• Lightweight methodology
• Few rules, practices, and documents
• Easy to follow

12
Another Methodology? (cont.)

• To facilitate use of heavyweight methodologies,
  tools were invented
• CASE (Computer Aided Software Engineering) tools,
  but the tools themselves are often difficult to
  learn
• Time that could be spent on the problem is
  redirected to the meta-problem

13
Another Methodology? (cont.)

• For the lightweight methodologies we pick and
  choose the rules to follow
• Learn from the past
• Keep rules that directly lead to the creation of
  quality software
• Omit the rules that hinder progress
• Simplify the rules that are too complex
• Make programmers feel free to be creative and
  productive while remaining organized and focused

14
What is Extreme Programming?

• A collection of rules and practices each of which
  supports the development and delivery of quality
  software
• The rules and practices support each other (are
  used together)
• Its an iterative process

15
Stages

• Planning
• User Stories
• Design of the system architecture
• Architectural spikes or prototypes
• Code creation
• Testing
• From day 1
• Not necessarily in this order

16
User Stories

• Similar in purpose to use cases
• Create time estimates for release planning (to be
  defined later)
• Replace large requirements documents
• Written by customers as things the system must do
  for them (like scenarios)
• Helps to avoid technical jargon

17
User Stories (cont.)

• Drive the creation of acceptance tests
• Derive tests to verify the implementation of the
  story as the story is being written
• Provide only enough detail to make an
  implementation time estimate
• Detailed descriptions will be solicited during
  implementation (i.e. questions for the domain
  expert or customer)

18
User Stories (cont.)

• Time estimates
• Provided by developers
• ideal development time units
• Assuming no distractions
• Assuming no other assignments
• Assuming you know exactly what to do
• Should be 1-3 weeks in duration
• Shorter stories get merged
• Long stories get split

19
User Stories (cont.)

• Focus is on user needs
• As opposed to technical details that may be
  present in a classical requirements
  specification
• As opposed to GUI designs that may be present in
  a classical requirements specification

20
Release Plan/Planning

• Layout the overall project
• Layout individual iterations through the project
• Release planning follows a set of rules
• Development team estimates user story times
• Customer determines user story priorities
• Management make resource decisions

21
Release Plan/Planning (cont.)

• Business people make business decisions
• Technical people make technical decisions
• Negotiation results in a schedule all can commit
  to
• The approach yields a useable system (in terms of
  customer needs and technical abilities) delivered
  as early as possible

22
Release Plan/Planning (cont.)

• Planning may be based on time or scope
• Time
• How many user stories can be implemented by a
  specified date
• Scope
• How long it will take to complete a set of user
  stories
• Project velocity is used in the estimates
• A measure for time estimates and progress
• More on this later

23
Release Plan/Planning (cont.)

• Iterations are not planned in detail until just
  before they begin
• Facilitates scheduling change
• Addresses issue of poor estimates in time
• Facilitates task (user story) priority changes

24
Release Plan/Planning (cont.)

• But it looks like its going to take too long
• Dont change estimates based on such statements
• This will cause problems later (when theyre more
  difficult to correct)
• Negotiate a release plan that is acceptable to
  all partiesdevelopers, customers, management

25
Release Plan/Planning (cont.)

• A release plan can be quantified by four
  variables
• Scope how much is to be done
• Resources how many people are how much
  equipment is available
• Time when will the project be done
• Quality how good will the finished produce be

26
Release Plan/Planning (cont.)

• Management can only choose to manipulate 3 of
  these variables
• Developers always get the 4th
• and, skimping on quality is never acceptable
• Always causes problems at a later date
• Let developers have a say in how many people get
  dumped onto the project

27
Release Plan

• Result of Release Planning
• Based on user stories and release planning
• Specifies exactly which user stories are going to
  be implemented for each release date

28
Release Plan (cont.)

• Provide a set of user stories for the customer to
  choose from for the next iteration (iteration
  planning)
• Translate these stories into programming tasks
  for the iteration
• Will be translated into acceptance tests during
  the iteration
• If the project velocity changes for an iteration,
  schedule another release planning meeting and
  update the release plan

29
Releases

• Results of the Release Plan
• Release iterative versions often
• Get the software into the customers environment
  as soon as possible
• Get meaningful feedback from the customer in a
  timely manner
• The longer you wait, the less time you have to
  fix problems

30
Project Velocity

• A measure of how fast work is getting completed
• The number of user stories (programming tasks)
  that were completed during an iteration
• Used for subsequent release planning
• Update estimates/priorities
• Hopefully its more meaningful than lines of
  code

31
Project Velocity (cont.)

• Used for subsequent iteration planning
• Developers sign-up for programming tasks equal
  to the current project velocity
• Allows developers to recover and clean up after
  iterations i.e. they dont become overworked
  and stressed
• Developers can ask for another user story
  (programming task) in the event that they finish
  early
• Causes project velocity to increase

32
Project Velocity (cont.)

• Project velocity will vary throughout system
  development
• Use release planning and iteration planning to
  smooth out the ups and downs

33
Iterative Development

• Each iteration should be of limited time (1 to 3
  weeks?)
• Dont schedule programming tasks in advance
  (just-in-time planning)
• Dont implement anything that was not planned for
  a given iteration (never add functionality)
• Facilitates dealing with changing user
  requirements

34
Iteration Planning

• Meet prior to each iteration
• Map out programming tasks for the iteration
• User stories are selected by the customer based
  on their priorities
• Failed acceptance tests from the previous
  iteration are selected

35
Iteration Planning (cont.)

• User stories are translated into programming
  tasks
• Tasks are written down on cards which become the
  detailed iteration plan
• Tasks should be 1-3 days ideal development time
  units
• Shorter tasks are merged
• Longer tasks are split

36
Iteration Planning (cont.)

• The developer does the time estimate
• Theres a novel approach
• Project velocity is used to check the booking
  of the iteration
• If over booked, the customer must choose which
  user stories are to be eliminated (moved to the
  next iteration) (snow plowing)
• If under booked, the customer may add user stories

37
Iteration Planning (cont.)

• Dont fudge your time estimates, no matter how
  tempting this may be
• And dont let others fudge your time estimates
  either

38
Moving People Around

• One expert in a given area can be disastrous
• Moving people from one task to another allows all
  to become knowledgeable in various areas
• Loss of a team member is now manageable
• Pair programming (discussed later) eases the pain
  of cross training people
• Avoids productivity loss
• Ensures continuity of thought

39
Daily Stand Up Meeting

• Communicate problems, solutions, and promote team
  focus
• Avoid long, drawn out meetings that leave people
  feeling demoralized and stressed out (due to not
  working on the project)
• Specialized meetings can be scheduled as the need
  arises
• Involve only pertainent team members

40
Simplicity

• Avoid complexity
• Difficult to implement
• Difficult to debug
• Difficult to maintain
• Not always possible, but try anyway
• KISS approach Keep It Simple Stupid

41
CRC Cards

• Class, Responsibility, and Collaboration
• Object-oriented design
• Cards represent objects (instances)
• Class
• Responsibility
• Collaborating classes
• Cards are easily manipulated (physically)
  facilitating stepping through the process

42
CRC Cards (cont.)

• Easy for many people to become involved in the
  class design process/verification
• Informal walk-through or structured walk-though
  may be stifling to some people
• Criticism
• Cards result in lack of written documentation
• Solution is to write one card from each class
  formally and store it away

43
Spike Solution

• A simple program used to explore potential
  solutions
• Also known as a prototype
• Figure out answers to tough technical questions
• Reduce technical risk
• Increase user story estimate reliability
• This used to scare developers for fear that at
  spike solution will be made the solution
  through a business/management decision

44
Spike Solution (cont.)

• Only addresses the problem at hand
• Total disregard to all other issues
• Throw-away code

45
Never Add Functionality Early

• Keep the system focused and uncluttered
• Items you predict might be useful may turn out to
  be totally unnecessary
• Concentrate on todays tasks
• These are the high priority items as specified by
  the customer

46
Refactor

• Learn to let go
• Perhaps the hardest thing for a software
  developer to do is to walk away from something
  theyve poured their heart into
• Ego-less programming
• This is a key part of XP (and iterative design
  methodologies in general)

47
Refactor (cont.)

• Refactor
• Remove redundancy
• Eliminate unused functionality
• Rejuvenate obsolete designs
• Constant refactoring results in
• Life cycle time savings
• Increased software quality
• Design simplicity

48
Include the Customer

• Throughout the process
• Beginning to end
• Develop user stories its their system so who
  better to describe how it will be used
• Prioritize user stories its their system so
  who better to decide which parts are most
  important
• Release planning its their system so who
  better to decide which parts to deliver first

49
Include the Customer (cont.)

• Throughout the process (cont.)
• During iterations to fill in details
  intentionally left out of user stories
• Functional testing creation of test data and
  verification of results (on site quality
  assurance)
• Requires full cooperation/buy-in
• Trade-off up front requirements specification
  time for development time through-out
• Dont settle for a trainee, even though that may
  seem cost effective you need a domain expert

50
Coding Standards

• Define them and stick to them
• Provides consistency facilitating team
  understanding and refactoring
• Supports moving people around and pair
  programming
• More on this later

51
Unit Test

• Create the unit test plan prior to creating the
  code
• Aids in describing exactly what the software unit
  must do
• Makes requirements very specific
• Provides immediate feedback (the tests either
  pass or fail)
• Provides a definite finish point (when all the
  tests pass)

52
Unit Test (cont.)

• Designs are then driven by the desire of the
  customer to have all tests pass
• Remember the customer is also involved in
  designing the tests (the functionality to be
  tested) as well as performance of the testing
• The resulting code does exactly what the tests
  specifyno more, no less
• Better make sure the tests are all encompassing

53
Pair Programming

• Two people work together at a single computer
• Driver/backseat driver
• Two people working together on one task will be
  more productive than two people working on
  separate tasks
• Very counter intuitive

54
Pair Programming (cont.)

• Reason Quality!
• Higher quality now results in lower more costly
  maintenance later
• Two people physically sit at one computer
• One thinks tactically e.g. doing the current
  class method
• One think strategically e.g. envisioning how
  current class method interacts with other methods

55
Pair Programming (cont.)

• Very awkward at first
• but it beats talking to yourself

56
Sequential Integration

• Integration is the act of taking one task and
  making it work with the rest of the system
• Classically, this is done simultaneously (by all
  developers) when all individual tasks are
  completed
• Or by a development team trained at such tasks

57
Sequential Integration (cont.)

• XP specifies that each developer (pair?) should
  integrate their task into the system
• This is done one developer (pair?) at a time
  (sequentially)
• The mechanics of this is some sort of source code
  repository with locking method that allows only
  one developer access at a time
• MicroSoft has a product called SourceSafe for
  such a system

58
Integrate Often

• Integrating often should shorten the lock-out
  time from the repository
• Reduces the complexity of the integration task
• Makes latest code available to all developers
• Identifies incompatibilities early (before its
  too late)

59
Collective Code Ownership

• Everyone has full access to all code
• Not allowed to label something as my code
• Anyone can fix any portion of the code
• Anyone can break any portion of the code
• Hopefully, since designs are simple, someone
  wont misconstrue working code for a bug
• Unit testing plays an influential role here too

60
Optimize Last

• Dont guess what the system bottleneck will be
• Measure performance when the system is complete
• Address performance when the bottlenecks are well
  known

61
No Overtime

• Dont ask (make?) developers to work overtime
• Call a release planning meeting to change project
  scope or timing
• Over worked developers make bad decisions leading
  to low quality software
• Dont add people to the team without consulting
  existing developers

62
Unit Test Frameworks

• Weve discussed this previously
• A test suite for performing regression testing
  automatically
• JUnit
• others

63
Acceptance Tests

• Basically, when the software passes all of the
  customer defined functional tests, youre done

64
Summary

• Extreme Programming (and other agile methods)
  suggests some software development practices and
  allows you to pick and choose the ones that work
  best for your team
• Most of all, it stresses
• Teamwork
• Communication