From Extreme Software Engineering: A Hands-On Approach

1. Extreme Programming Practices From Extreme Software Engineering: A Hands-On Approach Daniel H. Steinberg Daniel W. Palmer Extreme Software Engineering A Hands-On Approach

2. Whole Team • No artificial barrier between the customer and the development team. • The client is part of the team • responsibility and authority to make development decisions • The rest of the team consists of: • developers, testers, managers, archivers, administrative assistants, etc. • these roles are filled at various times by different members of the team. Extreme Software Engineering A Hands-On Approach

3. Metaphor • The development team should use the language of a common analogy to discuss the system. • The common terminology supports: • Design discussions among developers • Communication between developers and client • Conceptual integrity of the system. • The greatest example is the ‘desktop metaphor’. Extreme Software Engineering A Hands-On Approach

4. The Planning Game • The planning process in XP provides an incrementally describing what can and will be accomplished by the next, short-term deadline. • The client expresses software goals through user stories • Development team estimates costs of these stories • Client prioritizes the stories, driving the project. • After a mini-delivery, the team evaluates their estimates, and incorporates that data into the next round of estimation. Extreme Software Engineering A Hands-On Approach

5. Simple Design • System design is always as simple as the current level of functionality allows. • No extraneous complexity needed or allowed. • Incremental design extends only far enough to include the next iteration’s new features. • When the code becomes unwieldy, it must be refactored. Extreme Software Engineering A Hands-On Approach

6. Small Releases • XP teams release tested, working code • Functionality is specified by the client • These frequent deliveries are necessarily small • Every development cycle (iteration – typically two weeks), the client gets new software • The client then evaluates it and uses the current status to dictate the content of the next delivery Extreme Software Engineering A Hands-On Approach

7. Customer Tests • The customer develops acceptance tests to determine deliveries satisfy the user stories • These tests can be semi-automated and used to determine when the development team has completed a user story. • These tests are written in a form familiar to the client, but mechanically useable by the development team. Extreme Software Engineering A Hands-On Approach

8. Pair Programming • Programmers working in pairs write every line of code delivered to the client. • Two programmers and one computer represent the indivisible unit of XP code development. • One person types, the other supports in whatever role is appropriate at a given time. • Track and correct typos • Make implementation suggestions • Supply needed information • May take over keyboard at any time Extreme Software Engineering A Hands-On Approach

9. Test-Driven Development • Developers established their next mini-goal • They write an automated unit test to verify that the mini-goal is satisfied - before writing code • The test becomes part of an ever-increasing test suite • They write code to pass the test as simply as possible • The test suite is running constantly, providing feedback on the developing system. Extreme Software Engineering A Hands-On Approach

10. Design Improvement • Deficiencies in the software design are refactored, incrementally improving the system • Refactoring leaves the code functionally equivalent, yet better designed • By starting with a simple design, and always making small improvements, by induction, XP produces code with good design characteristics. Extreme Software Engineering A Hands-On Approach

11. Collective Code Ownership • The team, as a whole, owns the system software. • The original author of a section of code is unimportant • Anyone can modify any code at anytime without asking anyone for permission. • A revision control system is necessary to make such an open system work Extreme Software Engineering A Hands-On Approach

12. Continuous Integration • At all times, regardless of the level of functionality, the system compiles, runs and passes all the tests. • Any new code must, compile, run and pass all the tests before being added back into the system. • Continuous integration means making new system builds multiple times per day. Extreme Software Engineering A Hands-On Approach

13. Sustainable Pace • The team should put about the same amount of work and effort into every iteration. • Overtime leads to burnout, mistakes and more overtime. • By maintaining a steady development effort, the team can create better software in shorter amounts of time in the long run. • There is no such thing as “a big final push” to meet a deadline Extreme Software Engineering A Hands-On Approach

14. Coding Standards • Developed code should look like it was written by a single, consistent person • The team must adopt and follow some coding standard to be used throughout the development. • The details of a particular standard are not nearly as important as consistently adhering to that standard. Extreme Software Engineering A Hands-On Approach