eXtreme Programming and Agile Concepts

1
eXtreme Programming andAgile Concepts

• Roy Osherove
• www.iserializable.com
• Roy_at_Magen.com

2
Agenda

• Agile Methodologies
• eXtreme Programming
• When to use XP
• Simple rules and practices
• Test Driven Development

3
Methodology

• Code and fix
• Methodology
• Engineering methodologies
• Lightweight methodologies (agile)

Process
Cowboy
Agile
4
Agile properties

• Engineering
• Predictive
• Process-Oriented

• Agile
• Adaptive
• People-Oriented

5
Predictive vs. adaptive

• Separation of Design and Construction
• The Unpredictability of Requirements
• Is Predictability Impossible?
• Controlling an Unpredictable Process - Iterations
  
• The Adaptive Customer

6
Putting People First

• Plug Compatible Programming Units
• Programmers are Responsible Professionals
• Managing a People Oriented Process
• The Difficulty of Measurement
• The Role of Business Leadership

7
The Methodologies

• XP
• The Crystal family
• Open Source
• Highsmith's ASD (Adaptive Software Development)
• Scrum
• Feature Driven Development
• DSDM (Dynamic Systems Development Method)
• Rational Unified Process? (dX)

8
The Agile Manifesto

• We are uncovering better ways of developing
  software by doing it and helping others do it.
  Through this work we have come to value
• Individuals and interactions over processes and
  tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• That is, while there is value in the items on
  the right, we value the items on the left more.

9
What is XP?

• A brief introduction
• Communication, Simplicity
• Feedback, Courage

10
When to use XP

• dynamically changing requirements
• Risky projects
• Small dev groups (up to 100)
• Non-fixed scope(price) contract

11
Simple rules and practices

• Planning
• User Stories
• Release Planning
• Small Releases
• Measure Project Velocity
• Divide project to iterations
• Iterations Planning
• Move People around
• Stand up meeting

• Designing
• Simplicity
• System Metaphor
• CRC cards
• Spike solutions
• YAGNI
• Refactor

12
Simple rules and practices

• Planning
• User Stories
• Release Planning
• Small Releases
• Measure Project Velocity
• Divide project to iterations
• Iterations Planning
• Move People around
• Stand up meeting

• Designing
• Simplicity
• System Metaphor
• CRC cards
• Spike solutions
• YAGNI
• Refactor

13
Simple rules and practices

• Planning
• User Stories
• Release Planning
• Small Releases
• Measure Project Velocity
• Divide project to iterations
• Iterations Planning
• Move People around
• Stand up meeting

• Designing
• Simplicity
• System Metaphor
• CRC cards
• Spike solutions
• YAGNI
• Refactor

14
Simple rules and practices

• Planning
• User Stories
• Release Planning
• Small Releases
• Measure Project Velocity
• Divide project to iterations
• Iterations Planning
• Move People around
• Stand up meeting

• Designing
• Simplicity
• System Metaphor
• CRC cards
• Spike solutions
• YAGNI
• Refactor

15
Simple rules and practices

• Planning
• User Stories
• Release Planning
• Small Releases
• Measure Project Velocity
• Divide project to iterations
• Iterations Planning
• Move People around
• Stand up meeting

• Designing
• Simplicity
• System Metaphor
• CRC cards
• Spike solutions
• YAGNI
• Refactor

16
Simple rules and practices

• Planning
• User Stories
• Release Planning
• Small Releases
• Measure Project Velocity
• Divide project to iterations
• Iterations Planning
• Move People around
• Stand up meeting

• Designing
• Simplicity
• System Metaphor
• CRC cards
• Spike solutions
• YAGNI
• Refactor

17
Simple rules and practices

• Planning
• User Stories
• Release Planning
• Small Releases
• Measure Project Velocity
• Divide project to iterations
• Iterations Planning
• Move People around
• Stand up meeting

• Designing
• Simplicity
• System Metaphor
• CRC cards
• Spike solutions
• YAGNI
• Refactor

18
Simple rules and practices

• Planning
• User Stories
• Release Planning
• Small Releases
• Measure Project Velocity
• Divide project to iterations
• Iterations Planning
• Move People around
• Stand up meeting

• Designing
• Simplicity
• System Metaphor
• CRC cards
• Spike solutions
• YAGNI
• Refactor

19
Simple rules and practices

• Planning
• User Stories
• Release Planning
• Small Releases
• Measure Project Velocity
• Divide project to iterations
• Iterations Planning
• Move People around
• Stand up meeting
• Fix XP when it breaks

• Designing
• Simplicity
• System Metaphor
• CRC cards
• Spike solutions
• YAGNI
• Refactor

20
Simple rules and practices

• Planning
• User Stories
• Release Planning
• Small Releases
• Measure Project Velocity
• Divide project to iterations
• Iterations Planning
• Move People around
• Stand up meeting

• Designing
• Simplicity
• System Metaphor
• CRC cards
• Spike solutions
• YAGNI
• Refactor

21
Simple rules and practices

• Planning
• User Stories
• Release Planning
• Small Releases
• Measure Project Velocity
• Divide project to iterations
• Iterations Planning
• Move People around
• Stand up meeting

• Designing
• Simplicity
• System Metaphor
• CRC cards
• Spike solutions
• YAGNI
• Refactor

22
Simple rules and practices

• Planning
• User Stories
• Release Planning
• Small Releases
• Measure Project Velocity
• Divide project to iterations
• Iterations Planning
• Move People around
• Stand up meeting

• Designing
• Simplicity
• System Metaphor
• CRC cards
• Spike solutions
• YAGNI
• Refactor

23
Simple rules and practices

• Planning
• User Stories
• Release Planning
• Small Releases
• Measure Project Velocity
• Divide project to iterations
• Iterations Planning
• Move People around
• Stand up meeting

• Designing
• Simplicity
• System Metaphor
• CRC cards
• Spike solutions
• YAGNI
• Refactor

24
Simple rules and practices

• Planning
• User Stories
• Release Planning
• Small Releases
• Measure Project Velocity
• Divide project to iterations
• Iterations Planning
• Move People around
• Stand up meeting

• Designing
• Simplicity
• System Metaphor
• CRC cards
• Spike solutions
• YAGNI
• Refactor

25
Simple rules and practices

• Coding
• Customer available
• Code standards
• Test-Driven
• Pair Programming
• Sequential change integration
• Integrate often
• Collective code ownership
• Dont optimize early
• No overtime

• Testing
• Unit test everything
• All tests pass before release
• Bug new test
• Acceptance tests

26
Simple rules and practices

• Coding
• Customer available
• Code standards
• Test-Driven
• Pair Programming
• Sequential change integration
• Integrate often
• Collective code ownership
• Dont optimize early
• No overtime

• Testing
• Unit test everything
• All tests pass before release
• Bug new test
• Acceptance tests

27
Simple rules and practices

• Coding
• Customer available
• Code standards
• Test-Driven
• Pair Programming
• Sequential change integration
• Integrate often
• Collective code ownership
• Dont optimize early
• No overtime

• Testing
• Unit test everything
• All tests pass before release
• Bug new test
• Acceptance tests

28
Simple rules and practices

• Coding
• Customer available
• Code standards
• Test-Driven
• Pair Programming
• Sequential change integration
• Integrate often
• Collective code ownership
• Dont optimize early
• No overtime

• Testing
• Unit test everything
• All tests pass before release
• Bug new test
• Acceptance tests

29
Simple rules and practices

• Coding
• Customer available
• Code standards
• Test-Driven
• Pair Programming
• Sequential change integration
• Integrate often
• Collective code ownership
• Dont optimize early
• No overtime

• Testing
• Unit test everything
• All tests pass before release
• Bug new test
• Acceptance tests

30
Simple rules and practices

• Coding
• Customer available
• Code standards
• Test-Driven
• Pair Programming
• Sequential change integration
• Integrate often (and build daily)
• Collective code ownership
• Dont optimize early
• No overtime

• Testing
• Unit test everything
• All tests pass before release
• Bug new test
• Acceptance tests

31
Simple rules and practices

• Coding
• Customer available
• Code standards
• Test-Driven
• Pair Programming
• Sequential change integration
• Integrate often
• Collective code ownership
• Dont optimize early
• No overtime

• Testing
• Unit test everything
• All tests pass before release
• Bug new test
• Acceptance tests

32
Simple rules and practices

• Coding
• Customer available
• Code standards
• Test-Driven
• Pair Programming
• Sequential change integration
• Integrate often
• Collective code ownership
• Dont optimize early
• No overtime

• Testing
• Unit test everything
• All tests pass before release
• Bug new test
• Acceptance tests

33
Simple rules and practices

• Coding
• Customer available
• Code standards
• Test-Driven
• Pair Programming
• Sequential change integration
• Integrate often
• Collective code ownership
• Dont optimize early
• No overtime

• Testing
• Unit test everything
• All tests pass before release
• Bug new test
• Acceptance tests

34
Simple rules and practices

• Coding
• Customer available
• Code standards
• Test-Driven
• Pair Programming
• Sequential change integration
• Integrate often
• Collective code ownership
• Dont optimize early
• No overtime

• Testing
• Unit test everything
• All tests pass before release
• Bug new test
• Acceptance tests

35
Simple rules and practices

• Coding
• Customer available
• Code standards
• Test-Driven
• Pair Programming
• Sequential change integration
• Integrate often
• Collective code ownership
• Dont optimize early
• No overtime

• Testing
• Unit test everything
• All tests pass before release
• Bug new test
• Acceptance tests

36
Simple rules and practices

• Coding
• Customer available
• Code standards
• Test-Driven
• Pair Programming
• Sequential change integration
• Integrate often
• Collective code ownership
• Dont optimize early
• No overtime

• Testing
• Unit test everything
• All tests pass before release
• Bug new test
• Acceptance tests

37
Simple rules and practices

• Coding
• Customer available
• Code standards
• Test-Driven
• Pair Programming
• Sequential change integration
• Integrate often
• Collective code ownership
• Dont optimize early
• No overtime

• Testing
• Unit test everything
• All tests pass before release
• Bug new test
• Acceptance tests

38
XP map - Project
39
XP map - Iteration
40
XP map - Development
41
XP map Collective code ownership
42
Test Driven Development
43
Unit Testing makes your developer lives easier

• Easier to find bugs
• Easier to maintain
• Easier to understand
• Easier to Develop

44
A Unit Test is a testof a small functional piece
of code
45
You have already done Unit testing

• Not structured
• Not Repeatable
• Not on all your code
• No Framework

46
Test-Driven Development

• Make it Fail
• No code without a failing test
• Make it Work
• As simply as possible
• Make it Better
• Refactor

47
The xUnit Frameworks

• Original was for SmallTalk
• Kent Beck and Erich Gamma
• Ported to Various languages and platforms
• JUnit, CppUnit, DUnit, VBUnit, RUnit, PyUnit,
  Sunit, HtmlUnit,
• Good list at www.xprogramming.com
• Standard test architeture

48
Testing Tasks

• Write Tests
• Make it easy to create and organize tests
• Run Tests
• Allow running all of our tests, a group or just
  one.
• Review Results
• Immediate Pass/Fail feedback
• Details on each failure

49
Test Identification

• Manual
• Programmer writes code to call each test
• Reflection
• Framework examines the program and finds tests
• Uses inheritance and naming conventions
• Attributes
• Extension of the reflection approach for .Net
• Provide a clean, orthogonal way to identify tests

50
Writing Tests

• The 3A Pattern
• NUnit Features
• TestFixtures, Tests and Assertions
• Test Results
• Setup and Teardown Methods
• How NUnit Runs Tests
• Ignored Tests
• Expected Exceptions
• Test Suites
• Physical Test Organization

51
The 3A Pattern

• Arrange
• Act
• Assert

• Create the objects we will use for the test.
  These objects form the context for our test and
  are collectively known as the tests fixture.

52
The 3A Pattern

• Arrange
• Act
• Assert

• Tell the objects in the fixture to perform some
  actions that we are trying to test.

53
The 3A Pattern

• Arrange
• Act
• Assert

• Verify the result of our test, comparing what
  happened to what was expected and reporting the
  result.

54
The 3A Pattern

• ltTestFixture()gt _
• Public Class MoneyTest
• ltTest()gt _
• Public Sub TestSimpleAdd()
• Dim m12CHF As New Money(12, "CHF")
• Dim m14CHF As New Money(14, "CHF")
• Dim expected As New Money(26, "CHF")
• Dim result As MoneyTest
  m12CHF.Add(m14CHF)
• Assert.IsTrue(expected.Equals(result))
• End Sub
• End Class

55
The 3A Pattern

• ltTestFixture()gt _
• Public Class MoneyTest
• ltTest()gt _
• Public Sub TestSimpleAdd()
• Dim m12CHF As New Money(12, "CHF")
• Dim m14CHF As New Money(14, "CHF")
• Dim expected As New Money(26, "CHF")
• Dim result As MoneyTest
  m12CHF.Add(m14CHF)
• Assert.IsTrue(expected.Equals(result))
• End Sub
• End Class

arrange
56
The 3A Pattern

• ltTestFixture()gt _
• Public Class MoneyTest
• ltTest()gt _
• Public Sub TestSimpleAdd()
• Dim m12CHF As New Money(12, "CHF")
• Dim m14CHF As New Money(14, "CHF")
• Dim expected As New Money(26, "CHF")
• Dim result As MoneyTest
  m12CHF.Add(m14CHF)
• Assert.IsTrue(expected.Equals(result))
• End Sub
• End Class

arrange
act
57
The 3A Pattern

• ltTestFixture()gt _
• Public Class MoneyTest
• ltTest()gt _
• Public Sub TestSimpleAdd()
• Dim m12CHF As New Money(12, "CHF")
• Dim m14CHF As New Money(14, "CHF")
• Dim expected As New Money(26, "CHF")
• Dim result As MoneyTest
  m12CHF.Add(m14CHF)
• Assert.IsTrue(expected.Equals(result))
• End Sub
• End Class

arrange
act
assert
58
The 3A Pattern

• ltTestFixture()gt _
• Public Class MoneyTest
• ltTest()gt _
• Public Sub TestSimpleAdd()
• Dim m12CHF As New Money(12, "CHF")
• Dim m14CHF As New Money(14, "CHF")
• Dim expected As New Money(26, "CHF")
• Dim result As MoneyTest
  m12CHF.Add(m14CHF)
• Assert.IsTrue(expected.Equals(result))
• End Sub
• End Class

fixture
arrange
act
assert
59
NUnit Framework components

• Test Fixtures
• Tests
• Assertions
• Setup
• TearDown
• TestFixtureSetUp
• TestFixtureTearDown

• Ignore
• ExpectedException
• Suites(namespaces)

60
Demo

• TDD with NUnit

61
Questions?

• Roy_at_Magen.com
• www.iserializable.com

62
Additional Resources

• Mailing Lists
• Yahoo Group testdrivendevelopment
• Yahoo Group agiledotnet
• Books
• Test-Driven Development in Microsoft .NET James
  Newkirk and Alexei Vorontsov
• Test-Driven Development, by Example Kent Beck
• Test-Driven Development, A Practical Guide
  David Astels
• Unit Testing in Java, Johannes Link

63
Web Siteshttp//www.testdriven.comhttp//www.xpr
ogramming.comAgileAlliance.com ExtremeProgramming
.org Blogshttp//dotnetjunkies.com/WebLog/darrell
_nortonhttp//www.peterprovost.orghttp//weblogs
.asp.net/nunitaddinhttp//weblogs.asp.net/jamesne
wkirk http//www,iserializable.com
Roy_at_Magen.com