Extreme Programming (XP)

Assignment D Draft paper Extreme Programming (XP) Course code: INFOME Course name: Method Engineering Faculty of Science, Department of Information and Computer Sciences, Utrecht University, Princetonplein 5, 3584 CC, Utrecht, The Netherlands Notice of Originality Smuc, Domen, 5631033 d.smuc@students.uu.nl I declare that this paper is my own work and that information derived from published or unpublished work of others has been acknowledged in the text and has been explicitly referred to in the list of references. All citations are in the text between quotation marks ( ). I am fully aware that violation of these rules can have severe consequences for my study at Utrecht University. Signed Name Domen Smuc Date Place Utrecht, The netherlands Version 1 Date: 08-04-2016 University year: 2015/2016

Table of Contents 1. INTRODUCTION 1 1.1. CREATORS 1 1.2. GLOBAL OVERVIEW OF EXTREME PROGRAMMING 1 2. EXAMPLE 2 2.1. DESCRIPTION 2 2.2. COLLECTIVE CODE OWNERSHIP 2 2.3. CLASS, RESPONSIBILITIES, AND COLLABORATION (CRC) CARDS 2 3. PROCESS-DELIVERABLE DIAGRAMS (PDDS) 3 3.1. EXTREME PROGRAMMING PDD 3 4. ACTIVITY TABLE 5 5. TABLE OF CONCEPTS 7 6. RELATED LITERATURE 9 6.1. ORIGINS OF EXTREME PROGRAMMING 9 6.2. POSITIONING AND APPLICATION OF EXTREME PROGRAMMING 9 7. REFERENCES 10 Figures Figure 1: Extreme Programming Life Cycle (Abrahamsson et. al., 2002, p19)... 1 Figure 2: Collective code ownership, adapted from Extreme Programming... 2 Figure 3: CRC cards as a deliverable... 2 Figure 4: Extreme Programming PDD... 4 Figure 5: Roots of Extreme Programming (Abrahamsson et. al., 2002, p23)... 9 Tables Table 1: Activity table... 5 Table 2: Table of concepts and definitions... 7 i

1. Introduction 1.1. Creators The Extreme Programming (XP) method began evolving in the 1996. Kent Beck (born 1961) was the person responsible for the initial development of the method, while working for Smalltalk as a consultant and a developer. Other authors, Ward Cunningham and Ron Jeffries, helped Kent with the initial definition of XP. Kent Beck has since been seen as the creator of XP and is one of the original 17 signatories of the Agile Manifesto (Agile Manifesto, 2016) - part of which is also the XP method. 1.2. Global overview of Extreme Programming According to Beck (1999), XP is a lightweight, efficient, low-risk, flexible, predictable method, which was developed to address the needs of smaller software development teams when facing with rapidly changing user requirements. It is designed to be adopted within the teams of two to ten programmers, where the majority of tasks can be performed in a fraction of a work day. For this purpose, Beck (1999) defined the following main stages for XP life cycle: exploration (1), planning (2), iterations to release (3), productionizing (4), maintenance (5), and death (6). Beck further defined four main activities of XP. Namely these are designing (1), coding (2), testing (3), and listening (4). Additionally, the concept of XP approach is built around the following 12 best practices, which encapsulate the idea of agility for software development through simplicity, continuous collaboration and iterative design process. 1. Planning process 2. Small Releases 3. System Metaphor 4. Simple Design 5. Test Driven Development 6. Refactoring 7. Pair Programming 8. Collective Code Ownership 9. Continuous Integration 10. Sustainable Pace 11. On-site Customer 12. Coding Standard The complete life cycle of the XP best practices and stages is illustrated in Figure 1 below. Figure 1: Extreme Programming Life Cycle (Abrahamsson et. al., 2002, p19) XP defines many roles, however according to Beck (1999) the following roles are most often used: tracker, customer, programmer, coach, manager, and tester. It follows that XP is a valuebased method, which core values consist of simplicity, communication, feedback and courage (Beck & Fowler, 2000). Beck (1999) see XP method as a discipline, which focuses on aligning people to be more productive and produce high quality software. Beck further defines the main goal of XP to be reducing the cost of changes, through facilitation of small iterative development life cycles, rather than traditional ones, which take substantial amount of time and are not responsive to changes. In other words, XP perceives changes as a natural process and thus embraces the idea of changes as a desired influence in software development projects. The key goal, as defined by Beck, can be seen in the planning for ongoing changes, rather than having a stable set of requirements. 1

2. Example 2.1. Description It has been discussed by William et. al. (2000) that one of the key steps in XP is the concept of pair programming. The authors further suggest this step is accredited to most of the success associated with this method. With this in mind, the following section focuses on describing this core activity in more detail, by focusing on the principle of Collective Code Ownership, with an example situation where pair-programming could be applied and used, to increase the quality of the produced output. 2.2. Collective code ownership In the given example, as illustrated in Figure 2, a typical iteration cycle is performed by a team of programmers. First the CRC cards are defined, which provide simple design for a complex problem. From this, unit tests are derived and programmers are paired. This is also known as pair programming. The programmers then perfrom refactoring. In other words complex code is refactored into simple code. In case there is a need for help, the defined pair is changed, to provide additional skills for a given task. By continously doing these steps, the programmers provide new functionality with the accompanying unit tests to be performed. This constitutes the continuous integration principle, during which all the unit tests are executed. If all unit tests are sucessful, the programmers move on to the acceptance tests. This step completes the current development iteration, and the next iteration can begin by refining and prioritizing addiitonal user stories. The number of iterations is not limited, and the development process follows this spiral incremental approach until the final solution is reached and all the acceptance tests have been sucessful. Figure 2: Collective code ownership, adapted from Extreme Programming 2.3. Class, Responsibilities, and Collaboration (CRC) Cards One of the core deliverables in the XP process and pair programming in general, are the Class, Responsibilities, and Collaboration cards. Their biggest value that can be seen is the ability for teams to actively contribute to the solution design. Each of the CRC cards contains three things; object class (top), responsibilities (left), and collaboration class (right). This is illustrated in the Figure 3. Figure 3: CRC cards as a deliverable 2

3. Process-Deliverable Diagrams (PDDs) According to Weerd and Brinkkemper (2008) a Process-Deliverable Diagram (PDD) is the technique used for modelling activities and artifacts of a certain process. The authors define the PDD to be consisting of two key diagrams. These two diagrams, or views as the authors refer to them, are then integrated to form a complete process deliverable perspective of the given process. On the left hand side, there is the process view, which models all the activities, and together form the execution of the process being modelled. On the right side however, there is the deliverable view of the process. This view holds all the meta-model details about the deliverables that are derived from the activities of a given process. Furthermore, the process view is based on the activity diagrams in UML (OMG, 2004), and the deliverable view is based on the UML class diagram (2004). As a result, the final PDD diagram is intended to show a complete method, represented by a meta-model of that method. In this case, the PDD provides a meta-model of the Extreme Programming method (Figure 4). 3.1. Extreme programming PDD In our scenario, the PDD is derived from the method fragments of the Extreme Programming method. The constructed PDD is illustrated in Figure 4, and is consisting of 5 main stages, which are modelled as open activities on the process side of the diagram. Namely these are Initiation, Planning game, Conduct daily meeting, Development, and Finish sprint. Additionally, the defined PDD contains the key deliverables, modelled on the right hand side, which can be seen as the outputs of the process view on the left hand side. For clarifying purposes, only the most significant concepts are explained in more depth. Firstly, the concept USER STORY is derived from the activities Define user story and the two estimation activities (cost, workload). These together form the basic picture of a user story. However, additional user story information (concept properties) is derived from the activity Establish project scope. In here, 3 concepts are derived, namely ADDED VALUE, RISK, and SCOPE. Although, these could typically be derived from the Define user story activity, in our case these are derived from the establish project scope. This is for the simple reason that risk, scope and added value, are almost impossible to define when looking at an individual story, but are normally defined at a higher level typically a project level. Further, although these three mentioned concepts are part of the concept USER STORY, the PDD defines the aggregation relationship going from the USER STORY to each of them. Further, the USER STORY is connected to two other deliverables, namely JOB and LIST OF USER STORIES. In order to implement a given USER STORY a JOB is specified from each. Each JOB then contains a STATUS of the workload being developed. During the Daily meeting activity, the concept DEVIATION is defined for each of the JOBs and outlines any deviations from the original development schedule. Additionally, the collection of different USER STORYs is modelled as an aggregation to the LIST OF USER STORIES, which in turn forms the concept RELEASE DEFINITION. This concept is at the end of the process used for validating the definition of the SOFTWARE RELEASE, to make sure the released software is developed to the correct specifications as defined in the RELEASE DEFINITION. 3

Figure 4: Extreme Programming PDD 4

Going one step further, there is also the concept of CODE REPOSITORY. Beck (1999), defines this concept as a system, but however due to the aggregation relationship between concepts UNIT TEST, FUNCTIONALITY, AND TEST RESULT, the test CODE REPOSITORY is used. The main reason for this is the fact that the three mentioned concepts are essentially individual parts of the system, however they are grouped in the repository before the system is actually constructed. Furthermore, during the activities of Continuous Integration (CI) and Refactoring, the concepts UPDATED CODE and STRUCTURED CODE are derived as the output of these activities. Both of these are modelled as the association relationship, since they continuously structure and update the code found in the CODE REPOSITORY. Lastly, in the final stage of Finish sprint, the execution of Acceptance test produces the ACCEPTANCE TEST RESULTS DOCUMENT, and is modeled as an closed concept. The reason for modelling it as closed concept instead of open one, is seen in the lack of information for this deliverable. There is little information available that would clearly indicate what properties and potential sub-activities are part of this concept, thus modelling as closed complex activity is best suited in this scenario. Finally, once the SOFTWARE RELEASE is finished, the system is implemented at a customer site, however this was not modelled in the actual PDD. Table 1: Activity table 4. Activity table Activity Sub-activity Description Initiation Define user stories The customer writes different system usage scenarios which result in an USER STORY. This must describe a desired feature in detail through different properties such Planning game Estimate development workload Estimate development cost Establish project scope Sort user stories as name and information about the proposed functionality. Based on the defined USER STORY, the development team starts the estimation activity. Here the team makes an analysis of the stories, and based on previous experience defines the workload estimation for each. The development team further uses the defined workload estimation of USER STORY to define an estimate of the development cost associated with implementing the USER STORY. The customer determines the actual SCOPE of the project. In other words, this means the customer sets the project boundaries in terms of development time and cost, as well as the amount of stories to be implemented. The development team must then sort the customerdefined USER STORY by their ADDED VALUE and RISK. Firstly, the sorting process focuses on the ADDED VALUE, starting with the highest value first. It then sorts the USER STORY based on the RISK estimation values, which results in the STORIES list. Finally the STORIES are then prioritized based on the sorting process mentioned. 5

Conduct daily meeting Select relevant user stories Define release definition Update development status Define job deviation Development Write unit test Develop user story functionality Execute unit test Perform CI The defined priority for STORIES dictates which should be selected for the current development sprint, based on the development workload limit of the specific sprint cycle. The development team thus selects the most suitable STORIES in this activity. Once the STORIES are selected, the development team defines the RELEASE DEFINITION. This is completely based on the activities previously described and establishes the scope of the development iteration or sprint. The next main activity in the XP process is the daily meeting. Each day of the sprint the team must meet in order to continuously evaluate the current status of the development. In terms of XP, the implementation of USER STORY is called a task or a JOB. For each of the JOBs being developed, the team must assign a STATUS description. The STATUS outlines the work done, problems that have occurred, and the development schedule for the next development day. Further, during the daily meeting, a job DEVIATION is defined, which outlines potential DEVIATON in the USER STORY implementation, and further defines the next USER STORY to be implemented. Before developing the USER STORY functionality, the development team must write up the UNIT TEST. This test examines the proposed USER STORY in terms of its functionality, problems, bugs and other potential problems that the system might encounter. In this activity the actual development of the USER STORY is performed, which results in a given system FUNCTIONALITY, which is added to the shared CODE REPOSITORY. Once the FUNCTIONALITY has been submitted to the shared CODE REPOSITORY the previously defined UNIT TEST is executed by the system (CODE REPOSITORY). This is normally an automated process, which takes place as soon as the FUNCTIONALITY is committed to the CODE REPOSITORY. The execution of the UNIT TEST results in a TEST RESULT, which defines if the implemented FUNCTIONALITY meets the set criteria. If the criteria is not accepted the team must go back to the Develop user story functionality activity. If accepted however, the next activity can begin. This activity is one of the main principles behind extreme programming, and agile development in general. The main aim is of this is to continuously generate UPDATED CODE, which is committed to the CODE REPOSITORY. This ensures the CODE REPOSITORY is kept up to date with all the new FUNCTIONALITY. 6

Finish sprint Perform refactoring Execute acceptance test Release finished software Another key principle is the refactoring activity. This produces STRUCTURED CODE, which means the CODE REPOSITORY becomes structured with individual FUNCTIONALITY, which provides a good overview of the current system. This activity begins the last phase of the XP process. The acceptance test is defined in terms of meeting the desired system FUNCTIONALITY. Executing this activity produces ACCEPTANCE STATUS which determines if the proposed SOFTWARE RELEASE meets the customer requirements. If the test is rejected, the team must go back to the Develop user story functionality activity and repeat the process. If accepted however, the final step of the sprint may begin. This is the last activity in the sprint, which results in the SOFTWARE RELEASE based on the CODE REPOSITORY containing all the individual FUNCTIONALITY. This ends the current sprint and the constructed software is ready for implementation at the customer s side. Table 2: Table of concepts and definitions 5. Table of concepts Concept USER STORY ADDED VALUE RISK SCOPE LIST OF USER STORIES RELEASE DEFINITION JOB STATUS Definition A USER STORY is a a representation of use requirements in terms of its functionality, which provides a value or addresses the need of a customer (Cohn, 2004). ADDED VALUE is associated with the USER STORY in terms of the functionality benefit, which is the ultimate goal of the customer or and end user (Beck, 1999) RISK is an uncertain event or condition that, if it occurs, has a positive or negative effect on a project's objectives (Project Management Institute, 2008). SCOPE is defined as the work that must be performed to deliver a product, service, or result with the specified features and functions (Project Management Institute, 2008). LIST OF USER STORIES is defined as a collection of user stories based on their added value, risk and cost (Beck, 1999). RELEASE DEFINITION is a collection of the selected stories, which contain all individual user stories with its properties. The release definition defines the scope of a specific sprint cycle, thus segregating the workload into many different sprints (Beck, 1999) JOB or a task is a specific measurement unit of software development activity, which is derived from the user story description, and defines the work to be carried our by the development team (Beck, 1999). STATUS is the status as the current job status in terms of the achieved goals (Beck, 1999). 7

DEVIATION UNIT TEST DEVIATION is described by International Organization for Standardization (2010) as a departure from a specified requirement. UNIT TEST is defined by International Organization for Standardization (2010) as execution of individual code parts and modules of the proposed software. This is normally done by the developer or a tester. In other words, it is a test of individual programs or modules which must ensure errors-less code. FUNCTIONALITY FUNCTIONALITY is defined as the features or capabilities of an application as seen by the user (International Organization for Standardization, 2010). CODE REPOSITORY TEST RESULT UPDATED CODE STRUCTURED CODE ACCEPTANCE TEST RESULT DOCUMENT SOFTWARE RELEASE CODE REPOSITORY (also system) is defined as the collection of individual unit tests and functionalities, where all the individual development iterations are together, forming a complete system to be developed (Beck, 1999). The TEST RESULT is the output the system generates when executing the specific unit test (Beck, 1999). The UPDATED CODE is the main output of the process Continuous Integration (CI), which ensures the new code is updated in the code repository as soon as it passes the unit testing activity (Beck, 1999). STRUCTURED CODE is the process of refactoring to ensure the code is structured and thus providing a complete flow of different modules in a code repository (Beck, 1999). ACCEPTANCE TEST RESULT DOCUMENT is defined as the testing conducted to determine whether a system satisfies its acceptance criteria and to enable the customer to determine whether to accept the system (IEEE, 2008). SOFTWARE RELEASE is defined as activities surrounding the release of one or more versions of software to one or more customers, including identifying, packaging, and delivering the elements of a product (International Organization for Standardization, 2010). 8

6. Related literature 6.1. Origins of Extreme Programming There are a number of agile methods, that have been developed by experienced practitioners, and can be seen as a replacement to traditional development methods. Erickson et.al (2005) defined agility as means to strip away as much of the heaviness, commonly associated with the traditional software development methodologies, as possible to promote quick response to changing environments, changes in user requirements, accelerated project deadlines and the like. (p. 89). XP follows this idea, by primarily focusing on best practices for software development (Dyba & Dingsoyr, 2008) and was evolved from the problems occurring from long software development life cycles (Beck, 1999). The original XP method was initially developed by Kent Beck and others in 1999, during one of the Object Oriented software development projects (Beck 1999). Stepleton (2003) suggests that XP was developed as the second formal agile method, right after Dynamic Systems Development Method (DSDM). Beck (1999) defines XP as a collection of ideas and practices, which have emerged from existing development methodologies (Figure 4). The author further suggests that there are no practices that fit every scenario or a project, but the individual practices and processes should be tailored to specific needs of individual projects. Figure 5: Roots of Extreme Programming (Abrahamsson et. al., 2002, p23) 6.2. Positioning and Application of Extreme Programming It has been suggested by Abrahamsson et. al. (2002) that XP is the most documented of the different agile methods. In turn this has triggered new research and practical experience, with providing insight into the specific areas of XP. It has been reported by Maurer and Martel (2002), that the average increase in lines of code produced by XP is around 66%, 302.1% increase in the new methods developed during a XP project, and a 282.6% increase in the number of development classes implemented with the same development effort. Jeffries et. al. (2002) suggests that XP should be considered in situations where rapid changes can be expected on daily basis, user requirements are uncertain and most likely to change periodically, and the value of teamwork overcomes the value of individual power. Furthermore, the author suggests the XP is suitable to perform true rapid development, supports continuous integration, and provides extensive support for complex domain models. Finally, the key feature of XP, according to Abrahamsson et. al (2003), is refactoring, which allows for ongoing redesign of the system to improve its performance and to be fully responsive to ongoing change. This is further supported with results presented by Williams (2010). In the article, the author presents the beneficial results of the XP method and pair programming, in both industrial and educational setting. The results obtained reveal the XP method requires more effort and time; however, the level of quality is seen to increase on average for more than 40% during a full scale software development project. One example of such project is the Chrysler Comprehensive Compensation System (C3) (Andres & Beck, 2004). 9

7. References Abrahamsson, P., Warsta, J., Siponen, M., & Ronkainen, J. (2003). New directions on agile methods: A comparative analysis. 25th International Conference on Software Engineering, 2003. Proceedings., 244-254. Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile software development methods: Review and analysis. ESPOO 2002. VTT Publications, 478. pp. 107 Andres, C., & Beck, K. (2004). Extreme Programming Explained: Embrace Change. Reading: Addison-Wesley Professional. Beck, K. (1999). Embracing change with extreme programming. IEEE Computer, 32 (10), 70-77. Retrieved from: http://faculty.salisbury.edu/~xswang/research/papers/serelated/xp/rx070.pdf Beck, K., & Fowler, M. (2001). Planning extreme programming. Boston: Addison-Wesley Professional. Cohn, M. (2004). An Overview. In M. Cohn (eds.), User stories applied: for agile software development (pp. 3-12). Boston: Addison-Wesley Professional. Retrieved from http://books.google.nl/books?id=dhzp_yl3fxyc&printsec=frontcover&dq=cohn+ 2004&hl=nl&sa=X&ei=bCyIT4ngKIKg0QWT2PXpCQ&redir_esc=y#v=onepage&q &f=false%20link Dyba, T., & Dingsoyr, T. (2008). Empirical studies of agile software development: A systematic review. Information and software technology, 50(9), 833-859. Erickson, J., Lyytinen, K., & Siau, K. (2005). Agile modeling, agile software development, and extreme programming: the state of research. Journal of database Management, 16(4), 88-100. 10

IEEE Computer Society. (2008). IEEE Standard for Software and System Test Documentation Retrieved from http://dis.unal.edu.co/~icasta/ggs/documentos/normas/829-2008.pdf International Organization for Standardization (ISO). (2010). IEEE, Systems and Software Engineering--Vocabulary. ISO/IEC/IEEE 24765: 2010 (E)) Piscataway, NJ: IEEE computer society. Retrieved from http://us13.listmanage1.com/track/click?u=8af85296631b8bb9ee15cc940&id=cbd2e3 f3ca&e=2c7512bebf Extreme Programming: A Gentle Introduction. (n.d.). Retrieved from http://www.extremeprogramming.org/map/images/codesml.gif Jeffries, R., Anderson, A., & Hendrickson, C. (2001). Extreme programming installed. Boston: Addison-Wesley Professional. Manifesto for Agile Software Development. (n.d.). Retrieved February 16, 2016, from http://www.agilemanifesto.org/ Maurer, F., & Martel, S. (2002). Extreme programming: Rapid development for web-based applications. IEEE Internet computing, 6(1), 86-90. Object Management Group. (2004). UML 2.0 superstructure specification (Technical Report ptc/04-10-02) Project Management Institute (corporate author) (2008). A Guide to the Project Management Body of Knowledge (PMBOK Guide). Project Management Institute. Retrieved from http://www.cs.bilkent.edu.tr/~cagatay/cs413/pmbok.pdf Stapleton, J. (2003). DSDM: Business focused development (2nd ed.). London: Addison- Wesley. Weerd, I. van de, & Brinkkemper, S. (2008). Meta-modeling for situational analysis and design methods. In M.R. Syed and S.N. Syed (Eds.), Handbook of Research on 11

Modern Systems Analysis and Design Technologies and Applications (pp. 38-58). Hershey: Idea Group Publishing. Williams, L., Kessler, R. R., Cunningham, W., & Jeffries, R. (2000). Strengthening the case for pair programming. IEEE software, 17(4), 19. Williams, L. (2010). Pair Programming. Encyclopedia of Software Engineering, Taylor & Francis Group. 12