Computer Engineering 203 R Smith

1
Agile Methods

• What are Agile Methods?
• Extreme Programming is the best known example
• SCRUM is another popular example
• Agile Methods have the following in common
• Individuals over process
• Working software over documentation
• Collaboration over Contracts
• Responding to change over following a plan
• Each of these helps to optimize the process

2
Agile Methods

• Why is there an interest in Agile Methods
• Traditional methods have not greatly improved the
  state of
• On time, in budget delivery of Software
• Customer satisfaction
• Developer dissatisfaction with
• Hours and schedules
• Jobs are not fun
• Speed of changes in the market

3
Agile Methods

• Comparison with traditional methods
• Agile methods require customer involvement
  throughout development versus involvement only at
  specific phases.
• Agile methods only develop detailed plans for the
  near term versus detailed planning over the
  entire project.
• Agile methods use working code and prototypes
  versus documentation

4
Agile Methods

• Agile methods rely on early developer test case
  development versus separate test functions.
• Example Test Driven Development
• Agile methods design for one feature at a time
  versus complete design.
• LEAN development
• Agile methods produce many small release versus a
  limited number of larger releases.

5
Agile still needs discipline

• Even in Agile development models there are still
  processes and procedures that must be followed.
• For example Scrums daily meeting is a
  requirement of the process.

6
Agile Methods

• Example Agile Methods
• Extreme Programming
• OpenUP
• LEAN Development
• Crystal
• SCRUM
• Test Driven Development

7
Agile Methods

• Agile Modeling
• Flexible use of modeling to describe various
  aspects of the system.
• Simplified approach of modeling without the
  formal syntax of UML
• Method of communications that complements Agile
  development techniques.
• Use of multiple models.

8
Agile Principles

• Customer satisfaction through early and
  continuous delivery of software.
• Welcome changing requirements.
• Delivery schedules in the scale of weeks.
• Daily contact with the customer.
• Motivated developers.
• Face to Face interactions

9
Agile Principles

• Working software as a measure of progress.
• Develop at a sustainable pace.
• Promote technical excellence.
• Simplicity.
• Self-organizing teams.
• Regular reflection.
• Elimination of waste

10
Agile Methods

• Agile Modeling and UML
• From Agile Modelings point of view
• UML is not sufficient
• Example user interface interaction flow
• UML is too complex
• UML working in practice

11
Extreme Programming

• Extreme Programming Practices
• Programming
• Program incrementally
• Test first
• Refactoring
• Coding standards
• Team Practices
• Code ownership
• Integration

12
Extreme Programming

• Overtime
• Workspace
• Release schedule
• Metaphor
• Pair programming
• Process
• On-site customer
• Incremental planning

13
Extreme Programming

• Test first
• Why?
• You know the system works
• Establish a stable code base
• You know when something breaks
• You have a test base when you make major changes
• What to test?
• Anything that could break
• You know what already works

14
Test First

• When to test?
• When implementing a new task
• Before refactoring
• After refactoring
• Test frameworks
• You will run tests often and you will need a
  frame work to run them

15
Extreme Programming

• Planning cycle
• Estimates are given for near term implementations
• Release planning
• Cost of releases
• Iterations
• Setting priorities

16
Extreme Programming

• Onsite Customer
• The onsite customer is a key factor in XP
• Developing user stories
• Developing test cases
• Setting priorities

17
Extreme Programming

• Design and Refactoring
• Design only enough to implement the current
  planning iteration
• Write the simplest code
• Design is an iterative process
• Design spikes
• Exploration effort in code
• Often used in planning to provide better estimates

18
Extreme Programming

• Refactoring
• What it is
• A disciplined approach to improving the design of
  existing code.
• What it not
• Code hacking or implementing new features.
• When to refactor?
• Before you implement a new feature
• Make the code easier to understand
• Make the code easier to enhance

19
Extreme Programming

• When you finish a task to clean up the code
• When you have trouble understanding the code or
  finding a bug.
• Before you refactor make sure you have a complete
  test base.
• Run the tests before and after you refactor.

20
Extreme Programming

• Pair Programming
• Pair programming is two developers sitting at a
  single computer with one keyboard.
• Tasks include design, code, test and debug
• Focus is on constant review
• Shared ownership
• Higher quality code, fewer defects

21
Extreme Programming

• Issues, Reality Check
• Can you really have an onsite customer
• Authority to make decisions
• Time and location involved
• Pair programming
• Finding the right partner, hours, location, style
• Can you only plan a piece at a time?

22
Software Craftsmanship

• Craftsman versus Engineer
• An engineer takes a planned structured approach.
• The engineer relies on process to create
  structure and ensure results.
• The craftsman takes one small step at a time.
• The craftsman relies on the quality of the
  individual developer to ensure overall quality.

23
Professional Responsibility

• What is your role and responsibility as a
  Software engineer?
• Workmanship and quality
• Planning, estimates and schedule
• What does the customer expect?
• Cost
• Schedule
• quality

24
A Management View of XP

• Being a coach, monitor, enforce and change the
  process, mentor.
• Running interference, XP requires a different way
  of thinking on senior managements part.
• Providing the environment
• Knowing how to let the team run itself.

25
A Management View of XP

• Onsite User
• Small releases
• Limited planning horizon
• Pair programming
• Test first
• Limited documentation

26
Onsite User

• The manager needs to decide if having an onsite
  customer is realistic.
• Does the onsite customers reflect the views of
  the customer or are they only a body?
• How stable are the requirements?
• Is there only one customer?
• Chrysler example

27
Small Releases

• Are small releases realistic?
• What is the nature of your product?
• What does it take to install?
• How many customers are there?
• How many releases will you need to support?
• How accepting are your customers of new releases?

28
Limited Planning Horizon

• Does XPs limited planning horizon work in your
  company environment?
• Project/Product orientation
• Budget cycle and control
• Will the customer accept not knowing when the
  work will be done?

29
Pair Programming

• How do you create the pairs?
• How do you estimate the production rate?
• Productivity gains are in the quality of the code
  not in coding speed.
• How to do you reward individual performance?
• Programmer skill level

30
Test First

• Provides a stable environment
• You know how far you have come
• No separation between developers and testers
• Aids in debugging by giving immediate feedback
• When is the big picture tested?

31
Limited Documentation

• What is your view of your project team and work
  force?
• How much job movement is there?
• How are new developers added to the environment?
• What is the effect of good times versus bad times?

32
Does one model work best?

• What is the scientific method to determine the
  best method?
• Can we do experiments?
• Are results repeatable?
• How can comparisons be made?

33
Balancing Agile Methods and Traditional
Development

• Management has valid requirements for traditional
  planned methods
• Budgets
• Customers
• Still Agile methods can provide positive
  improvements to the development process

34
Balancing Agile Methods and Traditional
Development

• Understand the environment you are developing
  within
• Your team
• Your customer
• Your Management
• Select the techniques that are most effective in
  that environment.