Extreme Programming and Agile Methods

Extreme Programming and Agile Methods
Submitted By:
Adnan Qutubuddin
Independent Study Report
Abstract
Programming methodologies have always been refined further with time. Extreme Programming (XP) is widely used these days that is one of the agile programming methodologies. It produces quick results with less effort. Extreme Programming begins by first planning the project which predicts the completion of task and determines the next task. Small releases are made for evaluation by the customer. Metaphor gives a broader perspective of the overall project and requirements are divided into small parts called stories. Design of functionality is kept simple and the coding is performed keeping the code re-usable. Programming is practiced by first unit testing (testing a unit of functionality) and then coding, which produces a code that should work. Pair programming assures fewer mistakes and serves as a backup plan and also introduces collective code ownership because of which any code can be modified anytime. Extreme Programming also assures that the system is integrated at all times. Developer needs to work forty hour per week and no overtime is required. Customer is satisfied because he is always kept involved which shows the work is being done. Coding standards are properly maintained keeping the code easy to understand for anyone. The following study is an attempt to understand Extreme Programming (XP) in a much broader way by comparing it with other agile programming methodologies, highlighting its pros and cons and concluding with suggestions that may refine it further.
II
Table of Contents
Preface..............................................................................................................................II Acknowledgement............................................................................................................III Certificate.........................................................................................................................IV Certificate.........................................................................................................................V Abstract............................................................................................................................VI
Chapter 1
Introduction
1.1 Agile Software Development...................................................................................1 1.2 History.....................................................................................................................2 1.3 Agile Manifesto.......................................................................................................3 1.3.1 Principles Behind the Agile Manifesto............................................................3 1.4 Extreme Programming............................................................................................4 1.4.1 Extreme Programming Rules and Practices..................................................5 1.4.1.1 Planning.............................................................................................6 1.4.1.1.1 User Stories........................................................................6 1.4.1.1.2 Release Planning................................................................6 1.4.1.1.3 Small Releases...................................................................7 1.4.1.1.4 Project Velocity...................................................................7 1.4.1.1.5 Division into Iterations.........................................................7 1.4.1.1.6 Iteration Planning................................................................8 1.4.1.1.7 Move People Around..........................................................8 1.4.1.1.8 Stand Up Meeting...............................................................9 1.4.1.1.9 Fix XP.................................................................................9 1.4.1.2 Designing...........................................................................................9 1.4.1.2.1 Simplicity............................................................................. 9 1.4.1.2.2 System Metaphor................................................................9 1.4.1.2.3 CRC Cards.........................................................................9 1.4.1.2.4 Spike Solutions.................................................................10 1.4.1.2.5 No Functionality is Added Early........................................10 1.4.1.2.6 Re-factoring 10 1.4.1.3 Coding..............................................................................................11 1.4.1.3.1 On Site Customer.............................................................11 1.4.1.3.2 Coding Standards 11
III
1.4.1.3.3 1.4.1.3.4 1.4.1.3.5 1.4.1.3.6 1.4.1.3.7 1.4.1.3.8 1.4.1.3.9
Tests First.........................................................................11 Pair Programming.............................................................12 Sequential Integration.......................................................12 Integrate Often..................................................................12 Collective Code Ownership..............................................13 Optimization......................................................................13 40 Hours Week.................................................................13
Table of Contents
1.4.1.4 Testing..............................................................................................14 1.4.1.4.1 Unit Tests..........................................................................14 1.4.1.4.2 Pass Unit Tests.................................................................14 1.4.1.4.3 Create Tests for each Bug................................................14 1.4.1.4.4 Acceptance Tests.............................................................14
Chapter 2
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9
XP and Agile Methods
XP Vs. Scrum........................................................................................................15 XP Vs. Crystal.......................................................................................................15 XP Vs. FDD...........................................................................................................15 XP Vs. ASD...........................................................................................................15 XP Vs. DSDM.......................................................................................................16 Software Development Life Cycle.........................................................................16 General Features..................................................................................................17 XP Pros.................................................................................................................19 XP Cons................................................................................................................19
Chapter 3
Literature Research
3.1 Research Material Summary................................................................................20 3.2 Existing Model.......................................................................................................27 3.3 Suggestions..........................................................................................................28 References......................................................................................................................29
IV
List of Figures
Figure 1 Evolutionary Map of Agile Methodologies.........................................................2 Figure 2 Extreme Programming Project..........................................................................4 Figure 3 Planning.............................................................................................................6 Figure 4 Iteration Planning...............................................................................................8 Figure 5 Development...................................................................................................11 Figure 6 Collective Code Ownership.............................................................................13 Figure 7 SDLC Support.................................................................................................16 Figure 8 XP Life Cycle...................................................................................................27
List of Tables
Table 1 General Features..............................................................................................17
Chapter 1
Introduction
1.1 Agile Software Development
Agile software development refers to a group of software development methodologies that include: Extreme Programming (XP) Scrum Crystal Feature Driven Development (FDD) Lean Development Adaptive Software Development (ASD) Dynamic Systems Development Method (DSDM) [1]
Agile software development methodologies follow the principle of rapid delivery of high quality software with process of frequent adaptability, inspection, teamwork, self organization, accountability and customer-developer partnership throughout the life cycle of the project. Agile practices are often considered favorable for most of the businesses because it reduces cost and time which reduces the overall effort involved in developing a reliable software product. The best fact is that even if the effort is reduced the quality of the product is not compromised. It requires less planning and less documentation which keeps the overall team in high spirits. Each agile software development methodology carries iterative approach. Each iteration is re-evaluated and goes through the complete SDLC (Planning, Analysis, Implementation and Maintenance) which keeps the project adaptable. Some agile methods emphasize on face-to-face communication or short meetings rather than over written documents to get the overall progress of the project. It also resolves any problem that is hindering in the way which may be overlooked in the documents. Team members are assigned tasks and they each develop in their own way, which are
VI
then integrated. Customers are kept involved during the development to highlight the overall project progress or any ambiguity or any priorities that are to be set. There are two kinds of techniques involved during agile software development: Test Driven Development (TDD) Behavior Driven Development (BDD)
In test driven development tests are written prior to coding and in the behavior driven development collaboration is maintained between developers, quality assurance and customers (non-technical) in order for each one to talk in their own language. TDD focuses on code that must be written in order to pass the test and BDD focuses on why the code should be written.
1.2 History
VII
Figure 1. Evolutionary Map of Agile Methodologies
[5]
1.3
Agile Manifesto [8]
VIII
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
1.3.1 Principles Behind the Agile Manifesto

Highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
1.4
Extreme Programming (XP)

IX
Extreme Programming was introduced by Kent Beck in 1996 while working on Chrysler Comprehensive Compensation System (C3) payroll project. He wrote a book in 1999 named as Extreme Programming Explained. Extreme Programming is one of the agile software development methodologies. It provides high quality software within a short period of time. It reduces the cost and time of a project which reduces the overall effort. It also promotes teamwork with customer involvement and less documentation reduces frustration allowing a greater productivity by the developers. The two major practices of extreme programming are unit testing and pair programming through which extreme programming has gain popularity.
Figure 2. Extreme Programming Project [9]
1.4.1 Extreme Programming Rules and Practices

The rules and practices for the Extreme Programming (XP) are as follows:
Planning Write user stories Schedule is created by release planning (Practice: Planning Game) Small releases are made frequently (Practice: Small Releases) Measurement of the project velocity Project is divided into iterations Iteration planning starts each iteration (Practice: Planning Game) Move people around A stand-up meeting starts each day Fix XP when it breaks
Designing Design is kept simple (Practice: Simple Design) A system metaphor is chosen (Practice: System Metaphor) CRC cards are used for design sessions Spike solutions are created to reduce risk No functionality is added early Re-factor whenever or wherever possible (Practice: Re-factoring)
Coding The customer is always available (Practice: On Site Customer) Agreed upon, coding standards are maintained (Practice: Coding Standards) Unit test is coded first (Practice: Unit Testing / TDD) All production code is pair programmed (Practice: Pair Programming) Code is integrated by only one pair at a time Integrate often (Practice: Continuous Integration) Use collective code ownership (Practice: Collective Code Ownership) Leave optimization till last No overtime (Practice: 40-Hour Week)
Testing All code must have unit tests All code must pass all unit tests before it can be released Tests are created when a bug is found Acceptance tests are run often and the score is published.
1.4.1.1
Planning XI
Figure 3. Planning [9]
1.4.1.1.1 User Stories User stories depict the user requirements. In other words they are high level definition of requirements, similar to use cases but less in detail. [2][9] Their purpose is to estimate the effort (time parameter) required to implement a requirement. User stories are written by customers (in XP project stakeholders are called customers) and not by the developers, hence it is in a non-technical language. The larger requirement documents are shortened down, which saves a lot of time. It focus is on user needs rather than technical or GUI aspects. Ideal time to implement a story is within 1 to 3 weeks [2] without any distraction i.e. if you are working on one week iteration plan a story must take one week worth of work. If it takes more than three weeks then the story should be broken down further and if less than one week then you need to get some detail. About 60-100 stories are feasible to create a reliable release plan. 1.4.1.1.2 Release Planning After user stories have been written, customers and developers plan the releases in order with the set of user stories that must be implemented first. The main reason of planning is to estimate the ideal time required to complete a story. By ideal it is meant that no other work during the implementation of a story excluding tests. The stories are then prioritized by the customer. Planning is done keeping in view two
XII
parameters, either by time (long a set of stories will take to finish [9]) or by scope (how many iterations till the release is ready [9]). Planning By Time: Project Velocity x No. of Iterations Planning By Scope: Total Weeks Estimated / Project Velocity It is not a good idea to change the final release plan as it may cause problems for the iteration planning. Each iteration plan is created just before its implementation. During release planning four variables need to be considered for the projects, which are scope, resources, time and quality. Three of these variables are chosen by the management and the rest is kept for the development. Scope of the project is that how much work needs to be done. Resources are the number of people working on the project. Time for the project is when the project or release is to be completed. Quality is how good or reliable the software will be. 1.4.1.1.3 Small Releases Small releases are made often so that the customer is satisfied that the work is being done and can give the feedback. Feedback is necessary so that the idea may be developed, what the customer is thinking. If no feedbacks are entertained the customer may ask in the end to make many changes that could be frustrating for the developers. 1.4.1.1.4 Project Velocity Project velocity is the measure of the work for the project being done in an estimated time. Project Velocity: Sum of estimates for user stories or Sum of tasks finished during the iteration. [9] With each iteration you get a good estimate of the projects velocity and in this way you can easily estimate the velocity for the next iteration and the no. of user stories chosen by the customers to be implemented in the next iteration. Initial estimate for the project velocity is not that easy, it is better to guess rather than collecting lots of details to estimate it, which is a guess too. Estimating project velocity with the exploration of initial iteration is the best idea. The time it would require to collect details would be the more or less performing the initial iteration with a guess. 1.4.1.1.5 Division Into Iterations Iterations are the part of all agile software development methodologies. XP teams build software in two-week iterations, delivering running useful software at the end of each iteration. [10] It is called the heart beat of the project. [9] Iteration is planned just before the iteration is to begin; it is never planned in advance which keeps it easy to adopt any change in user requirements. Iteration deadlines should be maintained strictly, if it is not being followed then it is better to call a meeting for re-estimation.
XIII
1.4.1.1.6 Iteration Planning
Figure 4. Iteration Planning [9]
During Iteration Planning, the Customer presents the features desired for the next two weeks. [1] Release plan is reviewed in order to choose user stories that need to be implemented, keeping in view the previous iterations velocity that must not exceed. Bugs are fixed iteration by iteration and then passed through the re-created acceptance tests. Just like user stories index cards are used by developers (not customers) to agree upon those tasks and estimate the time required in its implementation which must be no longer than 3 days , otherwise the task is broken down further or the user story must be snow plowed (keeping the task for later iteration). Focus is on what is needed by the customer today and implementing only those tasks that are required today rather than tomorrow as the requirement may change the other day. 1.4.1.1.7 Move People Around Moving people around to different tasks in each iteration is a good practice in extreme programming. In this way the overall productivity of the team increases and dependency on an individual is resolved. If only one person has the expertise in a specific area then the overall team may be dependent on that person which could slow down the progress of the project. [9] For this reason trainings should be conducted for the team members so that if somehow the expert leaves the other person may take over the tasks and challenges.
XIV
Moving the people around also provides that each individual may get the overall picture of the system and the tasks being carried out. It reduces the load of work in hottest part of the system from an individual to the overall team rather than overloading few people and the rest of the team sitting idle. Pair programming is useful in that sense where a member from the pair can be switched to a different task if desired. 1.4.1.1.8 Stand-up Meeting To keep everyone synchronized, most XP teams have a brief, daily meeting. [2] On the other hand long meetings producing no results would waste a lot of time. In extreme programming only the team members attend the meeting, which is short and gives the overall progress and any problems or solutions are discussed about the project. Stand-up meetings are really helpful for the management as they get to know each and every progress that is being made everyday. 1.4.1.1.9 Fix XP Extreme programming rules must be followed strictly and if the developers tend to deviate then the management must motivate them and ensure that they abide to rules. However if the rules dont seem to work for the team they can be changed as each team has its own capability.
1.4.1.2
Designing
1.4.1.2.1 Simplicity A simple design is always easy to implement and change if required and takes less time. Complexity always raises confusions and may even degrade performance and would take a lot of time. Complexity may also create problems for other team members because they may have to work on it anytime. Do the simplest thing that can possibly work means to change as little as possible to incorporate a new feature, may result in a bad design. [6] 1.4.1.2.2 System Metaphor System metaphor is really important to maintain standards. Objects must be named in such a way that each member of team may understand the code. A common system of names [10] should be chosen for the objects so that everyone can understand. 1.4.1.2.3 CRC Cards Class, Responsibilities and Collaboration cards are used for system design in which all the members participate and the ideas given by them are incorporated. Classes are written on the top of the card, responsibilities on the left and collaboration classes on the right of each responsibility.
XV
The process starts by writing cards and moving them around. After sometime, only class names are written and no card is written in full virtually. [9] Objects communication and any problems in the proposed design are considered. These cards can be kept as documents for the design which also saves documentation time. 1.4.1.2.4 Spike Solutions Spike solutions are developed to solve any technical or design difficulties. The developed system only addresses the problem under consideration. It reduces the technical risks. 1.4.1.2.5 No Functionality Is Added Early During iteration only those tasks should be targeted which are chosen by the customer and no functionality is added early. Sometimes it happens that it is easy to add a specific functionality at the very moment which may be useless to the customer resulting wastage of time and if somehow the change is needed, that functionality implemented in advance may be no more useful. 1.4.1.2.6 Re-factoring The much the code or design is clean and simple the better it is. XP uses a process of continuous design improvement called Re-factoring. [10] When the design seems to become obsolete re-factoring should be done the very moment and should be practiced from the beginning otherwise the design gets unmanageable and it is difficult to re-factor it afterwards. It seems really easy and requires less effort when the design is extended or modified over an obsolete one but with time as it is extended further or modified, it becomes frustrating for the developer to work on the unmanageable design. Refactoring often saves time when extension or modification is needed in the design.
XVI
1.4.1.3
Coding
Figure 5. Development [9]
1.4.1.3.1 On-site Customer Customer should be always available at the site and an expert in its area so that any details required can be gathered. Stories belong to the customer [2] and he/she should be available if any change in the release plan is to be negotiated. They are helpful for the developers as they can communicate face to face and any ambiguities may be resolved which saves a lot of time. They are also needed for functional testing so that the system may be released or if necessary, changed or stopped. 1.4.1.3.2 Coding Standards Any person from the entire team may be assigned to work on another individuals code. Coding standards should be maintained to keep the code understandable by the other members. 1.4.1.3.3 Tests First Testing first is one the major practice in extreme programming. Tests should be created prior to coding so the developer may know what needs to be implemented. Developer must only write the code to pass the test and can save a lot of time by avoiding extra coding. It is same as coding first and then testing, in fact is a time saving approach. Considering the scenario in which the developer codes first
XVII
requires re-writing the code if any bug is found, while test first approach only needs the code that must pass through it. After the code is passed we know that the task is completed. Tests written first are also helpful when another member starts working on the code written by some other member. The person knows that these tests have been passed and for the rest what code should be written and the time is saved in explaining whats happening. 1.4.1.3.4 Pair Programming Pair programming is one of the other major practices through which extreme programming gained popularity. Two people working with each other side by side on a single computer saves time. One person types and thinks tactically about the method being created, while the other thinks strategically about how that method fits into the class. [9] If one person somehow leaves the other is ready to take over the system. 1.4.1.3.5 Sequential Integration Integration is often a critical part in extreme programming. Integration may introduce bugs that are never been identified because each of the module is tested by its own tests and not for the whole project. There may be an addition to the problem if no proper versions of the code and test are maintained. A configuration management tool can be used as a repository which even handles the locking making developers able to work concurrently. Integration is done in FIFO fashion. 1.4.1.3.6 Integrate Often Integration is often done so that the latest version of the code is available. It should be done within every few hours and not later than the end of the day. It assures that the other person has the very latest copy of the code and may be 100% working copy. Usually the latest working copy of the code is updated.
XVIII
1.4.1.3.7 Collective Code Ownership
Figure 6. Collective Code Ownership [9]
By collective code ownership it is meant that a single person must never own the code. Code must be owned by each team member equally. The project is wholly planned by all the team members including developers and customers, so ethically it is the right of each developer to own any section of the project anytime. By owning it means that any pair of programmers can change any section of the code anytime [1] if required. A particular section should not be dependent on an individual, so that if that person leaves no bottleneck is created. 1.4.1.3.8 Optimization Optimization is done in the end when the whole project is ready. 1.4.1.3.9 40 Hours Week Developers are required to work 40 hours a week. Overtime really frustrates the team. Release plan may be negotiated if extra time is required.
XIX
1.4.1.4
Testing
1.4.1.4.1 Unit Tests Test driven development makes extreme programming really useful. Unit test frameworks may be used to create test suites. Unit test frameworks are helpful in creating automated unit test suites, thus saving time. Unit tests are also updated with the code in the repository. Code without tests neither is integrated nor released. Unit tests are also helpful in re-factoring. Changed code is tested with the test suite to identify any bugs introduced. 1.4.1.4.2 Pass Unit Tests All code must pass the unit tests before it can be released. 1.4.1.4.3 Create Tests For Each Bug When a bug is reported, a test is created for that bug. An acceptance test is written to protect the source from that bug. Developers create unit tests from those acceptance tests to target a specific code. When the unit tests have been passed, the code is passed through the acceptance test to check if the bug is fixed. 1.4.1.4.4 Acceptance Tests Previously called functional tests are often used to check the functionalities of the system. Acceptance tests are derived from the user stories and are tested at the end of user story completion. It is the black box testing of the system [9] and the results produced are verified by the customer.
XX
Chapter 2
XP and Agile Methodologies
2.1 XP VS. Scrum
XP and Scrum practices overlap each other. Scrum focuses on management processes while XP emphasizes on engineering practices. Scrum is used where better business engagements and collaboration are required, while XP is used where the productivity must be high maintaining software quality. People usually merge Scrum processes with XP practices. Iteration in Scrum is called Sprint which usually lasts approximately 30 calendar days [4] and takes one week if the system is simple and easy. In Scrum if a change is required the change is implemented after the iteration which is quite long while in XP it requires only a week. Teams in Scrum are self organized focusing on the ROI. On other hand XP focuses on tasks to be carried out productively. There is no estimation in Scrum where as in XP estimation is really important to carry out the iteration. XP follows TDD where as Scrum does not.
2.2 XP VS. Crystal

Crystal family includes number of different methodologies (Crystal Clear, Crystal Orange and Crystal Orange Web). [4] The methods are tailored in order to get the best out of its family. Each method is marked with a color indicating its heaviness. Dark color methods are considered to be heavy. Each method is differentiated by the projects size and its criticality. Crystal uses incremental approach with several iterations within an increment that is of 4 months usually where as XP uses iterative approach. Milestones are set for delivery while XP uses release planning and iteration planning. XP uses stand-up meetings where as Crystal progress is monitored and measured by milestones.
2.3 XP VS. FDD

FDDs main focus is on the design and building phases. Iteration in FDD emphasis on the features while in XP user stories are used. In XP and FDD iteration usually requires 1 to 3 weeks. One person is responsible for the design of the overall system while XP incorporates ideas of all the team members. No collective code ownership is observed in FDD.
2.4 XP VS. ASD

ASD is used where systems are large and complex. XP can handle small projects to large projects. ASD uses a three phase cycle and focuses on components to be
XXI
implemented rather than tasks in XP. Like XP, ASD does not focus on the use of colocated teams.
2.5
XP VS. DSDM
DSDM calls iterations as timeboxes and duration is of few days to few weeks. Prototypes are developed in DSDM and goes through heavy documentation. Technical coordinator is responsible for defining the system architecture. Each team should at least have a developer and user. XP incorporates ideas of all the team members and avoids documentation.
2.6 Software Development Life Cycle Support
Figure 7. SDLC Support
[4]
XXII
2.7 General Features
XXIII
Table 1. General Features
[4]
XXIV
2.8 XP Pros
Customer is happy because he is always involved and receives progress at the end of each iteration. Re-factoring keeps the design consistent and manageable. The simple the design the more it is easy to understand and implement and xp assures that. By defining metaphor the system is easy to understand by all members. Members can easily get a picture of the class functionality. Quick and quality productivity is guaranteed by short iterations. Unit testing saves the time to code.
2.9 XP Cons
Design is not properly documented. Metaphor does not cater enough information and might produce ambiguity. Complex Systems are usually not implemented through XP. Does not provide enough support for distributed teams. Customer may not be always available which may lag the iteration process. Usually 40-hour week is not enough to produce quality software. Integrating often may consume a lot of time and may introduce bugs. There isnt much time to write all the tests and if the test is wrong the code may be wrong too. Re-factoring requires a lot of time incase if the working code breaks. In pair programming a lack in ones partner performance can degrade the performance of the other too. The partner may be sleepy. Code being changed by anyone at any time may be frustrating for the developer previously working on that code if it needs to work on it again. It is often time consuming and confusing to understand the other persons code.
XXV
Chapter 3
Literature Research
3.1 Research Material Summary
Extreme Programming: Agile Project Management Advisory Service White Paper
Jim Highsmith (http://www.cutter.com/content-and-analysis/resource-centers/agile-projectmanagement/sample-our-research/ead0002/ead0002.pdf) This Paper focuses on the components involved in the extreme programming technique. The components that were discussed are, the planning game, small releases, metaphor, simple design, re-factoring, testing, pair programming, collective ownership, continuous integration, 40 hour week, on-site customer and coding standards. The planning game: predicting completion of task by the due date and determining the next task. Small releases: Small releases can be made in two ways. One, on the customer side for evaluation and other, for the end users. Metaphor or Story: The metaphor describes the broad sweep of the project while stories describe individual features. Simple design: Simple design keeping in view the current functionality. Re-factoring: Making code re-usable. Testing: Can be unit (test and then code) or functional. Pair programming: One person is coding and other is reviewing. Collective code ownership: Any member of the team can change any code anytime. Continuous integration: Keep system integrated all times. 40 hour week: No overtime, only 40 hours of work. On-site customer: Involve the customer.
XXVI
Coding standards: Coding standards to be maintained in support of collective code ownership.
SDLC on a Diet (2001)

Ronald G. Wolak (http://www.itstudyguide.com/papers/rwDISS725researchpaper1.htm) The paper discusses the traditional SDLC with the new methodologies. The methodologies that are discussed are Adaptive Software Development (ASD), Agile Software Process (ASP), Crystal, Dynamic System Development Method (DSDM), Extreme Programming (XP), Feature Driven Development (FDD), Rational Unified Process (RUP), SCRUM, and Whitewater Interactive System Development with Object Models (Wisdom). ASD: ASD has three complex adaptive components: the Adaptive Conceptual Model, the Adaptive Development Model, and the Adaptive (leadership-collaboration) Management Model. ASP: It is time based and quickly delivers the software product and provides evolutional delivery. It is a software process architecture that integrates concurrent and asynchronous processes. It also provides process-centered software engineering environment. Crystal: It classifies the project types along two lines: the number of people on the development team and the amount of risk involved. DSDM: It consists of three cycles i.e. functional model iteration, design and build iteration, and implementation. XP: It is the best known lightweight methodology. FDD: It consists of five processes: develop an overall model, build a features list, plan by feature, design by feature and build by feature. RUP: It is a process framework and can be used with both traditional and lightweight methodologies. SCRUM: It is best for projects where requirements are ambiguous and hectic conditions are anticipated. WISDOM: It comprise of three major workflows: requirements workflow, analysis workflow, and design workflow
XXVII
A new method of Software Development: Extreme Programming (2002)

Csar F. Acebal and Juan M. Cueva Lovelle (http://www.upgrade-cepis.org/issues/2002/2/up3-2Acebal.pdf) XP has four measures for any software project which is cost, time, quality and scope. These four variables are made visible to everyone i.e. customers, programmers and project managers. Three of the values are established by the project managers and customers. If the quality of the project is maintained it means that the project can be completed in less time because as soon as the development team does the intensive testing and if coding standards are being followed, the project will start to progress much faster than before. The projects quality will still remain 100% assured because of the tests, which in turn will instill greater confidence in the code and, therefore, cost of change decreases. The practices that are involved in extreme programming are the planning game, small releases, metaphor or story, simple design, re-factoring, testing, pair programming, collective code ownership, continuous integration, 40 hour week, on-site customer and coding standards.
XP in Complex Project Settings: Some Extensions (2002)

Martin Lippert, Stefan Roock, Henning Wolf and Heinz Zllighoven (http://www.upgrade-cepis.org/issues/2002/2/up3-2Lippert.pdf) The report discusses splitting customer roles into user and client roles. The user role is concerned with the domain knowledge and client role is concerned with the business goals and financial resources. The roles that are defined for XP development process are as follows: Programmer: Writes the source code. Customer: Gives the requirements to programmer to what to program. Tester: Writes the functional tests. Tracker: Tracks the facts and records of the project to maintain a deadline. Coach: Observes if the team is moving off the track and puts it back in the direction. Consultant: Shares knowledge to solve to the problems faced by the team. Big Boss: Manger of the project. User: The user is the domain expert which is supported by the XP team during system development. User provided the functional requirements. Client: Focuses on business needs and financials. Client is the goal owner and gold donor. Story cards are written by the developers assessed by the users and selected by the clients. For complex projects story cards are unable to show the whole picture of the project, therefore two additional document types are used i.e. project stages and base lines.
XXVIII
A Framework for Understanding the Factors Influencing Pair Programming Success (2005)
Mustafa Ally, Fiona Darroch, and Mark Toleman (http://search.arrow.edu.au/main/redirect_to_title?identifier=oai%3Aarrow.nla.gov.au %3A120886027320749) The reports focuses on literature analysis of one of the components of extreme programming technique i.e. pair programming and compares it with Delphi (Consensus of experts opinions) study. Some comparison concepts between literature analysis and Delphi include: Quality: Pair programming ensures quality because of one programming and other observing. Team Building and Pair Management: Because programming work in pairs it builds up the spirit of team building and pair management. Pair Personality: Both personnel have different ideas and suggestions that can give a successful solution. Threatening Environment: One may have threat from another for feeling stupid or sharing any idea. Project Management: It is easy to mange the task because of both developers have equal share on the code and not depending on only one of them. Design and Problem Solving: Design and problem solving improves due to share of opinions. Programmer Resistance: Some of the programmers resist in doing pair programming because of threats. Communication: Intra-team communication increases. Knowledge Sharing: Knowledge is shared producing fruitful results. Mentoring: Mentoring improves the skills of the junior programmers. Environment Requirements: Physical accessories in the environment may produce a problem. Effective Pairs: Many pairs may not be effective, so it needs to be considered. Shared Responsibility: Halves the decision making and work load. Human Resource Management: New recruitment and management strategies should be made in order to make pair programming effective.
XXIX
Attitude: Programmers attitude can be changed to work as team. Productivity: May decrease because of one always keeping lions share letting down the morale of other.
Toward a Framework for Evaluating Extreme Programming (2004)

Laurie Williams, William Krebs, Lucas Layman, Annie I. Antn, Pekka Abrahamsson (http://agile.csc.ncsu.edu/lmlayma2/papers/WKL04.pdf) This report discuss about evaluation of efficacy of extreme programming. It also provides ontology-based framework called XP-Evaluation Framework. XP-EF comprise of three parts: XP Context Factors (XP-cf): Factors such as, team size, project size etc. XP Adherence Metrics (XP-am): Metrics, if the team adheres to the pure extreme programming practices. XP Outcome Measures (XP-om): Measure the outcome of the team. The ontology-based framework was developed by Kitchenham et al for four reasons: to allow researchers to provide a context within which specific questions about maintenance can be investigated to help understand and resolve contradictory results observed in empirical studies to provide a standard framework to assist in reporting of empirical studies in such a manner that they can be classified, understood, and replicated and to help industrial adoption of research results to provide a framework for categorizing empirical studies and organizing them into a body of knowledge Six criteria were proposed by Schneiderwind to validate software metrics i.e. association, consistency, discriminative, power, tracking, predictability and repeatability. Triangulation combines two or more different quantitative methods to study the factors.
Formal Agility. How much of each? (2003)

Angel Herranz and Juan Jose Moreno-Navarro (http://babel.ls.fi.upm.es/papers/finalcopy-jisbd2003.ps.gz) This report discusses formal agile methodologies practices being integrated in extreme programming and what benefits can we get. XP emphasis on being quick and light and deemphasizes documentation or specification.
XXX
Unit Testing: It is somewhat similar to specification in formal methods. First writing test and then coding is same as first writing specifications and then coding. But tests do not tell programmers that a particular specification is needed, it only tells what will happen. Incremental Development: If the specification needs a change because of the additional requirements, the requirements are added incrementally. However it is a heavy process, but it is needed for the correct implementation. Previous requirements must still hold. Re-factoring: Generic patterns may be applied in order to reduce the cost of change similar to detailed specification of each module in formal methods.
Extreme Programming Considered Harmful for Reliable Software Development 2.0 (2003)
AVOCA GmbH (http://avocallc.com/downloads/ExtremeProgramming.pdf) This report focuses extreme programming reliability. Testing has always been one of the mandatory practices for which extreme programming is known. But frequent changes can overwhelm testing effort. The dubious values and practices involved in extreme programming reliability are as follows: Embrace change value: Assuming that changes are easy, has always been reason in software troubles. Practice of re-factoring: Re-factoring will always require extra effort with embrace change. Simplicity value: In order to keep the design simple may increase complexity for development. Pair programming: Pair programming may decrease the productivity; in fact researches have proven it to be an unsuccessful practice. But it may be useful in some cases. Practice of having an on-site customer: It is always difficult to access a customer. Mostly it does not exist. Practice of having no documentation: Documentation is ignored to be cost effective which leads to problem. Practice of having 40-hour week: It is hardly implemented. Practice of collective code ownership: It depends on the team. If team breaks it is of no use.
XXXI
Everything-is-in-the-code attitude: the code documents itself, but the software is more than a code. test cases are requirements-recommendation: Substituting test cases with requirement documents is not feasible as explained above. People Orientation: People are mostly the source of problems for a project.
XXXII
3.2 Existing Model
Figure 8. XP Life Cycle
[4]
XXXIII
3.3 Suggestions
XP Drawbacks have already been discussed. The following are some of my suggestions for those drawbacks: Instead of CRC cards time can be given to system metaphor to document functionalities each class carries. Spike solutions may be documented too. If stories are given more time XP can handle complex systems. Distributed teams can be managed if particular types of tasks are assigned and shared with others in order to decrease the communication gap. An agreement should be made with the customer so that he is always available. Overtime should be paid fairly so that the developers may be motivated and not forcing developers to do overtime. Coding and testing and distribution of tasks should be managed in such a way that integration does not cause any problem which can save time. Referenced architectures and patterns may be used to avoid re-factoring. While one person is writing code the other must test it logically so that code is directed towards the tests. Thinking logically may also overcome wrong tests. Previous code should not be modified instead a class or method should be implemented and then integrated with the continued task so that the code is understandable by previous developer.
XXXIV
References
[1] Lowell Lindstrom, Extreme Programming and Agile Software Development Methodologies, 2003. [2] Steve Hayes, Martin Andrews, An Introduction To Agile Methods, 2003. [3] Till Schmmer, Jan Schmmer, Support for Distributed Teams in eXtreme Programming, 2001. [4] Pekka Abrahamsson, Outi Salo, Jussi Ronkainen, Agile Software Development Methods, 2002. [5] Pekka Abrahamsson, Juhani Warsta, Mikko T. Siponen, Jussi Ronkainen, New Directions on Agile Methods: A Comparative Analysis, 2003. [6] Grrel Hedin, Lars Bendix, Boris Magnusson, Introducing software engineering by means of Extreme Programming, 2003. [7] Robert L. Glass, Extreme Programming: The Good, the Bad, and the Bottom Line, 2001. [8] Agile Manifesto, http://agilemanifesto.org [9] Extreme Programming: A Gentle Introduction, http://www.extremeprogramming.org [10] XProgramming, http://www.xprogramming.com
Websites:
http://www.agile-software-development.com/2008/04/extreme-programming-versusscrum.html http://www.ferolen.com/blog/xp-vs-scrum/ http://www.approximity.com/cgi-bin/blogtariAgile/index.rb/XP_agile/XPvsXCRUM.txt http://newton.cs.concordia.ca/~paquet/wiki/index.php/Extreme_programming http://members.cox.net/cobbler/XPDangers.htm http://search.arrow.edu.au/ http://en.wikipedia.org/wiki/Extreme_Programming http://en.wikipedia.org/wiki/Extreme_Programming_Practices
XXXV

Extreme Programming and Agile Methods

Caricato da

Informazioni sul documento

Copyright

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Extreme Programming and Agile Methods

Caricato da

Copyright:

Extreme Programming and Agile Methods

Independent Study Report