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

Extreme Software Engineering A Hands-On Approach 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 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 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 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 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 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 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 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 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 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 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 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 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.