sample use case templateexample test plan templateProject plan template
ICS 121: Extreme Programming
- What is extreme programming?
- XP key practices
- Who does what and when?
- Some things to notice about XP
What is Extreme Programming?
- XP is a set of key practices that suggest a software development
- Key concept: Embrace change. Rather than avoid changes, try to
reduce the cost of making changes.
- Key concept: Defer costs. Rather than face every problem up
front, try to start with a small subset and incrementally plan and
carry out improvements.
- User story
- A short, concrete paragraph about how a user might use
one feature of the system.
- Test case
- Programmatic unit test case. Each test case is very small and
would take only an hour or less to write.
- The work it takes to implement a few user stories. Usually 1-4
- Several iterations happen lead up to one release. The release
produces an externally visible verison of the software. A release
can take a few months.
XP Key Practices
- Don't plan too far ahead
- Try to steer the project toward success, one iteration at a time
- Lots of things change, so planning too far ahead is unreliable
- Realize that you will change things later no matter what
- The Planning Game
- Record user stories and other development tasks on index cards
- Have a customer (or customer representative) on the team
- Quickly estimate and prioritize user stories
- Negotiate a set of user stories for the next release
- Small releases
- Build the smallest, simplest system possible
- Then make a long series of small upgrades, each of which also works
- Simple design
- Just do the simplest thing that will get you through this milestone
- Eliminate duplication in the design
- Don't over engineer, solve problems only when they occur
- Write a simple, automated test and prove that it fails
- Then, implement the feature and prove that it passes the test
- Rerun tests frequently to find defects and measure progress
- Use tools that make it easy to make design changes as you go
- Pair programming
- Two people at the keyboard
- One codes, one thinks about the design and catches errors
- Collective code ownership
- Any developer can change any code any time
- Everyone codes to the same stylistic standards
- Automated tests catch any errors that are introduced
- Continuous integration
- Merge changes from different developers very frequently
- 40-hour work week
- It is better to be awake and alert
Who Does What and When?
- XP Workers:
- Coach: Technical mentoring, long-term sylistic goals
- Tracker: track progress toward short-term goals
- Steps within each iteration:
- Customer picks user stories with highest priority
- Stories are split into developer tasks
- Develop test cases for each task
- Implement each task and evolve the design as needed
- Otherwise, there is not a lot of guidance
Some things to notice about XP
- XP is better than _no_ process at all.
- XP is closest to build-and-fix process model because planning
and doing are both incremental with the same duration.
- Certain practices of XP are good:
- User stories are a quick and easy way to get started capturing
- Continuous integration, frequent iterations and regression
- Joint code ownership, shared coding style
- Tracking of issues
- Pair programming can be nice sometimes
- Other practices of XP are not good:
- Short-sighted planning is wasteful
- Refactoring is not as cool as it seems
- Tests are no substitute for written requirements
- Requires a lot of access to customer
- Code is the central artifact, there are few formal
requirements or design documents. That means less effort so long
as all developers remember the history of decision-making, but
it makes it very hard for new developers to join the project