Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

Principle roles of people involved in a software development project:

  • Customer
  • Developer
  • Manager
  • *?

SGB: We need to define roles we believe to be important and how each aspect of an Agile or XP process impacts each player. (see See bullets on Feedback below.)

"Agree as a team - including the customer - on an acceptable level of quality. Agree to consider that time and resources are fixed. The only remaining question is that of scope. What will be delivered? When will it be delivered? The customer will set priorities for individual features. You will work on them in turn. The software will always be kept in a releasable state." XPPG, p6

...

Perfect is the enemy of done. Aim for a solution that is good enough.Fundamental assumption of XP: Exposing the tradeoffs of changes leads to fewer surprises and smoother development.

Anchor
Feedback
Feedback

Feedback is fundamental to every XP practice. (XPPG, pp. 8-10)

  • Exposing the tradeoffs of changes to any of the 4 variables above leads to fewer surprises and smoother development.
  • "The sooner you can get feedback, the more time you have to react to it."
  • "It is only through actual work that you can understand your real obstacles."
  • "For the customer, seeing a feature implemented leads to a better understanding of the software and how it works."
  • "Feedback from testing helps you to be confident about making changes. Whether adding a new feature or improving the design of the code, knowing that a change in the last 10 minutes (or even 10 seconds) has broken a test reduces the amount of debugging detective work to manageable chunks."
  • "Feedback from frequent releases gives the customer confidence in the value of the project."
  • "The only way to recover from a mistake is to admit to it and to fix it."

Want development to Development should be a process of refinement. Want We want to get to a point where this is true quickly.

...

  • Code and design simply. Goal: produce software that's easy to change
  • Refactor mercilously. After making a test pass, look for ways to improve the way your code works. After finishing a task, do a little house cleaning. Eliminate repetition. Break long methods and functions into smaller ones. Clarify variable and method names.
  • Develop coding conventions (SGB: such as we've discussed)
  • Develop a common vocabulary (for the project, for elements of the code, etc.)

...

  • Adopt test-driven development
  • Practice pair programming (SGB: not sure this is doable)
  • Adopt collective code ownership. The entire code base belongs to the whole team. For example, anyone is permitted to change any part of the code at any time.
  • Integrate continually

...

  • Add a customer to the team.
  • Play the planning game. The planning game is the give and take process of deciding which features to implement in what order. Goal is to maximize the value of the features produced.
  • Release regularly. Return the customers investment often.
  • Work at a sustainable pace. Go home tired, but not exhausted.

XP Events:

  • Stories: The customer presents desired features as story cards.
  • Task cards: Developers discuss each feature and generate one task card for each step required to implement the story.
  • Estimates/schedules: Developers estimate how much time each task will take and schedule each task within an iteration.
  • Iterate (iteration should be measured in days)
  • Release

Need to spell out the benefits of XP to:

...