Embracing change with Extreme Programming Method Engineering Erik ten Brinke

Content 1)Introduction to Extreme Programming 2)What makes XP stands out? 3) Related literature 4) XP PDD 5) XP in practice 6) Questions

Extreme Programming  Agile development  Agile Manifesto (2001)  Kent Beck

 User stories  Open work environment  Face-to-face communication  Customer involvement  The Planning Game  What makes XP stand out?  Daily meeting  Pair programming  Unit tests  Continuous integration  Refactoring  Collective ownership Main aspects

 User stories  Open work environment  Face-to-face communication  Customer involvement  The Planning Game  Daily meeting  Pair programming  Unit tests  Continuous integration  Refactoring  Collective ownership Main aspects

Related Literature  Abrahamsson et al. (2002) indentified the differences and similarities between the several Agile software development methods. Their study showed the key points, special features, identified shortcomings, and differences of several Agile methods. Table 1: Comparison of four Agile methods (Abrahamsson et al., 2002) Agile methodKey pointsSpecial featuresIdentified shortcomings DSDMApplications of controls to RAD, use of timeboxing, empowered DSDM teams, active consortium to steer the method development First truly Agile software development method, use of prototyping, several user roles: ‘ambassador’, ‘visionary’ and ‘advisor’ While the method is available, only consortium members have access to white papers dealing with the actual use of the method. FDDFive step process, object oriented component (i.e. feature) based development, very short iterations from hours to 2 weeks Method simplicity, design and implement the system by features, object modeling FDD focuses only on design and implementation, needs other supporting approaches ScrumIndependent, small, self organizing development teams, 30 release cycles Enforce a paradigm shift from the ‘defined and repeatable’ to the ‘new product development view of Scrum’ While Scrum details in specific how to manage the 30 day release cycle, the integration and acceptance tests are not detailed XPCustomer driven development, small teams, daily builds Refactoring, the ongoing redesign of the system to improve its performance and responsiveness to change While individual practices are suitable for many situations, overall view and management practices are given less attention.

 Layman, Williams, and Cunningham (2004) performed a case study at an airline company named Sabre Airline Solutions. Their case study compared two releases from the same product, one from before the team used XP and one from when the team had been using XP for two years. H10: pre-release quality (as measured by defects found before product release) H20: post-release quality (as measured by defects found by the customer after release) H30: programmer productivity (as measured by both user stories and lines of code per person-month) H40: customer satisfaction (measured via interview and customer feedback) H50: team morale (assessed via a survey)  Pre-release quality: decrease of 65% in test defects  Post-release quality: increased by 35%, due to a decrease of defects found by the customer after a release  Programmer productivity: improved by a 50% increase in code output Case: Airline Company

XP PDD

XP in Practice A company wants to develop a software update for its ERP system.  Assuming the user stories are already written, the customer chooses the user stories that fit within the scope of the sprint. The chosen user stories could be functionality like the possibility to generate specific management reports or bug fixes for aspects that don’t work properly.  The chosen user stories are documented in a release definition.  The Planning Game is initiated.  (First)Daily meeting is performed.  Pair Programming.  Assuming that the organization already uses XP for some time, they have a collection of unit tests which they can use to test the developed user stories.  When the individual developed user stories pass the unit tests, they come together in a software release.  This software release is validated via an acceptance test, if it passes this test the software release is ready to be implemented at customers that use their ERP system.

Questions  Reviewers  Others