Agile and Extreme Programming

1
Agile and Extreme Programming
2
Project discussion
3
Requirements Wrap-up
4
What are Agile Methods and Extreme Programming

• ?
• AKA XP
• AKA Rapid development

5
What are Agile Methods and Extreme Programming

• Refer to methods for organizing the way the team
  works
• Methods for organizing the day-to-day details of
  the life-cycle model chosen
• Mostly compatible with the incremental/evolutionar
  y development model described in Chapter 4
• One of the 3 classes of models we cover in this
  class
• Lifecycle
• Architecture
• Team

6
Why Agile/XP/Rapid

• Different from traditional team management
  structures
• Focus on adaptability, agility, user involvement,
  quick turnaround
• Less stress on formality, specifications,
  separation of stages and roles

7
Why Agile/XP/Rapid

• Goals
• Accelerated delivery to customers
• Reduce risks
• Increase efficiency
• Lower costs
• User engagement
• Users part of design team leads to higher
  satisfaction, fewer mistakes, less redesign,
  higher acceptance

8
Foundations of Rapid Development

• Specification, design and implementation
  concurrent
• Documentation kept to a minimum, instantiated in
  artifacts
• Incremental/evolutionary development,
  end-users/customers involved in every step
• UI prototyping key, often among first steps

9
Agile methods

• Focus on
• Customer involvement
• Incremental delivery
• People not process
• Embrace change
• Maintain simplicity

10
Extreme Programming

• Most popular example of Agile methods
• XP Development/Release cycle
• Select user stories/scenarios
• Break down into tasks (use-cases)
• Plan release
• Develop, integrate, test
• Release
• Evaluate
• Start again

11
Extreme programming practices

• Incremental planning
• Use of story cards
• Small releases
• Delivery, involvement of users, lots of
  evaluation and interaction
• Simplicity
• Both design and implementation
• Continuous integration
• A necessity
• Refactoring
• See above (3)
• Test first
• Test cases written before development, and
  automatically run
• Pair programming
• Devs work in pairs
• Collective ownership
• Everyone works on everything
• Sustainable pace
• On-site customer

12
Test-first mentality

• Key development
• When determining what to implement, identify and
  implement test plan
• Automate
• Key survival strategy when lacking central
  organization
• Overall improvement in software quality

13
Pair programming

• Idea of 2 programmers sharing 1 machine, writing
  code collaboratively
• Very efficient practice
• Less defects (peer review)
• Higher productivity
• More natural/social process
• More interaction (less ownership/ego)

14
Why prototype?

• Facilitates evaluation and feedback
• Stakeholders can see, hold, interact with a
  prototype more easily than with a document
• Team members can communicate more effectively
• You can test out ideas for yourself
• Encourages reflection
• Prototypes answer questions, and support
  designers in choosing between alternatives

15
Compromises in prototyping

• All prototypes involve compromises
• For software-based prototyping maybe there is a
  slow response? sketchy icons? limited
  functionality?
• Two common types of compromise
• horizontal provide a wide range of functions,
  but with little detail
• vertical provide a lot of detail for only a
  few functions

16
Low-fidelity Prototyping

• Uses a medium which is unlike the final medium,
  e.g. paper, cardboard
• Intentionally rough and unfinished
• Is quick, cheap and easily changed (?)
• Encourages high-level criticism problems with
  conceptual models and fundamental
  usability/functionality issues

17
Low-fidelity prototype
18
High-fidelity prototyping

• Prototype looks and behaves like (subset of) the
  final system
• Commonly used tools Macromedia Director, Visual
  Basic, and Smalltalk.
• Users may think they have a full system
  (problem!)
• Get at details of design (layout, icons, colors
  etc)

19
Key thing about prototypes!

• Throw Away!

20
Potential problems with Agile/XP/Rapid

• Management problems
• Different way of organizing teams
• Not everyone can adapt
• Not all managers can adapt
• Contractual problems
• No fixed spec, not always a clear timeline
• Validation problems
• See above
• Maintenance problems
• Lack of documentation/specifications