|
Size: 2409
Comment:
|
Size: 2437
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 10: | Line 10: |
| Line 11: | Line 12: |
| Line 12: | Line 14: |
| Line 19: | Line 22: |
| Line 20: | Line 24: |
| Line 21: | Line 26: |
| Line 22: | Line 28: |
| Line 23: | Line 30: |
| Line 24: | Line 32: |
| Line 25: | Line 34: |
| Line 26: | Line 36: |
| Line 27: | Line 38: |
| Line 28: | Line 40: |
| Line 29: | Line 42: |
ExtremeProgramming
attachment:dilbert-xp.gif
Extreme Programming (XP) is a set of 12 practices that enables a team to collaborate effectively to deliver working software closely aligned with current business needs within realistic, proven timelines. Project management transforms from crisis management into merely a series of business decisions, and all the participants have excellent visibility into the project. See Kent Beck's 'Extreme Programming Explained', Addison-Wesley 2000, IBSN 0-201-61641-6. (Chris H.)
Four Values
Communication
Simplicity
Feedback
Courage
(Chris H.)
The Twelve Core Practices
Metaphor
The Planning Game or Planning
On-site Customer
Coding Standards
Simple Design
Testing
Refactoring
Collective Ownership
Pair Programming
40-hour Week or Sustainable Pace
Continuous Integration
Small Releases
(Chris H.)
Earlier Comments
Extreme Programming is a methodology for getting programs working quickly without suffering from "analysis paralysis". The basic tenets of Extreme Programming are:
Write your tests first
If you write your tests before writing your code, you already know what the code should do. Initially, your tests will fail, but then you write enough code to make the tests work.
Refactor early and often
Refactoring means improving the design of your code in incremental steps that don't change the results, and instead just make things neater and cleaner. This is where Python comes in. Dynamically typed languages in general are easier to refactor with. Python has the added advantage of good readability and this is key to refactoring. When you refactor you optimize for simplicity and readability.
Work in pairs to review design and code, and to get the collaborative juices flowing
Having people work in pairs encourages communication, which gets and keeps ideas flowing. This also discourages individual code ownership, and keeps the code reviewed continuously. Plus, with two people working together, many bugs get caught and fixed almost as soon as they're written.
Working together also allows you to validate that your ideas about testing and refactoring are really correct.
I'm just starting to learn about it myself, but a good description can be found at [http://www.xprogramming.com/xpmag/whatisxp.htm].
attachment:dilbert-xp-team.gif