RDP technique

RDP Practice is a technique for tailoring Extreme Programming. This practice first time proposed as a [http://portal.acm.org/citation.cfm?id=1370143.1370149&coll=ACM&dl=ACM&CFID=69442744&CFTOKEN=96226775, long research paper] in APSO workshop at ICSE 2008 conference and yet it is the only proposed and applicable method for customizing XP. Although it is specifically a solution for XP but this practice have the ability of extending to other methodologies.

History

Extreme Programming or XP is a software engineering methodology (and a form of agile software development) "Human Centred Technology Workshop 2005", 2005, PDF webpage: [ftp://ftp.informatics.sussex.ac.uk/pub/reports/csrp/csrp585.pdf Informatics-UK-report-cdrp585] .] prescribing a set of daily stakeholder practices that embody and encourage particular XP values (below). Proponents believe that exercising these practices—traditional software engineering practices taken to so-called "extreme" levels—leads to a development process that is more responsive to customer needs ("agile") than traditional methods, while creating software of better quality. "Design Patterns and Refactoring", University of Pennsylvania, 2003, webpage: [http://www.cis.upenn.edu/~matuszek/cit591-2003/Lectures/49-design-patterns.ppt UPenn-Lectures-design-patterns] .] "Extreme Programming" (lecture paper), USFCA.edu, webpage: [http://www.cs.usfca.edu/~parrt/course/601/lectures/xp.html USFCA-edu-601-lecture] .] "Manifesto for Agile Software Development", Agile Alliance, 2001, webpage: [http://agilemanifesto.org/ Manifesto-for-Agile-Software-Dev] ] Proponents of Extreme programming and agile methodologies in general regard ongoing changes to requirements as a natural, inescapable and desirable aspect of software development projects; they believe that adaptability to changing requirements at any point during the project life is a more realistic and better approach than attempting to define all requirements at the beginning of a project and then expending effort to control changes to the requirements. However, XP has been noted for several potential drawbacks, as compared to more document-based methodologies, including problems with unstable requirements, no documented compromises of user conflicts, and lack of an overall design spec or document. Although software projects can benefit from XP practices, but all projects can not directly adopt it. Characteristics of some projects make it difficult to use XP thoroughly; therefore, the need of tailoring XP to the local conditions, contexts and the size of projects is inevitable. the valuable concepts behind RDP practice, in a short time provide the rational for applicability of it in industries.RDP Practice tries to customize XP by relynig on XP Rules.

XP values

Extreme Programming initially recognized four values in 1999. A new value was added in the second edition of "Extreme Programming Explained". The five values are:

*Communication
*Simplicity
*Feedback
*Courage
*Respect

Communication

Kent Beck, says that: Problems with projects can invariably be traced back to somebody not talking to somebody else about something important. Sometimes a programmer doesn't tell someone else about a critical change in the design. Sometimes a programmer doesn't ask the customer the right question, so a critical domain decision is blown. Sometimes a manager doesn't ask a programmer the right question, and project progress is misreported.Bad communication doesn't happen by chance. There are many circumstances that lead to a breakdown in communications. A programmer tells a manager bad news, and the manager punishes the programmer. A customer tells the programmer something important, and the programmer seems to ignore the information. XP aims to keep the right communications flowing by employing many practices that can't be done without communicating. They are practices that make short-term sense, like unit testing, pair programming, and task estimation. The effect of testing, pairing, and estimating is that programmers and customers and managers have to communicate.

implicity

Extreme Programming encourages starting with the simplest solution. Extra functionality can then be added later. The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next month. Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system; their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that might change before they become relevant. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed. Related to the "communication" value, simplicity in design and coding should improve the quality of communication. A simple design with very simple code could be easily understood by most programmers in the team.

Feedback

Within Extreme Programming, feedback relates to different dimensions of the system development:
*Feedback from the system: by writing unit tests, or running periodic integration tests, the programmers have direct feedback from the state of the system after implementing changes.
*Feedback from the customer: The functional tests (aka acceptance tests) are written by the customer and the testers. They will get concrete feedback about the current state of their system. This review is planned once in every two or three weeks so the customer can easily steer the development.
*Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement.

Feedback is closely related to communication and simplicity. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break. The direct feedback from the system tells programmers to recode this part. A customer is able to test the system periodically according to the functional requirements, known as "user stories". To quote Kent Beck, "Optimism is an occupational hazard of programming, feedback is the treatment."Fact|date=June 2007

Courage

Several practices embody courage. One is the commandment to always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. Courage enables developers to feel comfortable with refactoring their code when necessary. This means reviewing the existing system and modifying it so that future changes can be implemented more easily. Another example of courage is knowing when to throw code away: courage to remove source code that is obsolete, no matter how much effort was used to create that source code.Also, courage means persistence: A programmer might be stuck on a complex problem for an entire day, then solve the problem quickly the next day, if only they are persistent.

Respect

The respect value manifests in several ways. In Extreme Programming, team members respect each other because programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers. Members respect their work by always striving for high quality and seeking for the best design for the solution at hand through refactoring.

Adopting four earlier values led to respect gained from others in team. Nobody on the team should feel unappreciated or ignored. This ensures high level of motivation and encourages loyalty toward the team, and the goal of the project. This value is very dependent upon the other values, and is very much oriented toward people in a team.

XP Rules

The first version of XP rules was proposed by [http://www.rolemodelsoftware.com/moreAboutUs/publications/rulesOfXp.php Ken Auer] in XP/Agile Universe 2003. In short, he said: XP's values make it agile. XP's practices do not define XP; XP is defined by its rules. Because defining XP by the practices have at least two problems:

*Some practices are fuzzy in definition.
*It's commonly understood we can be doing XP without doing all of the practices

He finally conclude that we should not define XP merely by its values or its practices. We should define XP by its rules. Ken Auer in his version of XP Rules defined two categories of rules"Rules of Engagement" which dictate the environment in which software development can take place effectively. They then discuss the "Rules of Play" which define the minute-by-minute activities and rules within the framework of the Rules of Engagement.

1. The Rules of Play are what make XP unique.2. Following the Rules of Play is Extreme Programming.3. Following the Rules of Play and the Rules of Engagement is Extreme Software Development.

After [http://www.rolemodelsoftware.com/moreAboutUs/publications/rulesOfXp.php Ken Auer] , in APSO workshop at ICSE 2008 Conference, [http://portal.acm.org/citation.cfm?id=1370143.1370149&coll=ACM&dl=ACM&CFID=69442744&CFTOKEN=96226775, Mehdi Mirakhorli] proposed the new version of XP Rules, he had provided some changes in the firs version of XP Rules. Because he believed that the rules must satisfy the essence of agility and XP. When you choose rules for defining XP, you should be independent of any practices as much as possible. With regard to Ken’s results and according to his experiences he propose a more precise and comprehensive definition for the rules of engagement and play.

Rules of Engagement

In [http://portal.acm.org/citation.cfm?id=1370143.1370149&coll=ACM&dl=ACM&CFID=69442744&CFTOKEN=96226775, Mehdi Mirakhorli] literature "Rules of Engagement" are those that make you agile, these rules are similar to [http://agilemanifesto.org/principles.html agile principles] :

Business people and developers Joint work

*Business people and developers must work together daily throughout the project

Our highest priority is customer satisfaction

*The customer must set and continuously adjust the objectives and priorities based on estimates and other information provided by the developers or other members of the team. Objectives are defined in terms of what not how.

Deliver working software frequently

*Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale (Timeboxing).

Working software

*Working software is the primary measure of progress

Global Awareness

*At any point, any member of the team must be able to measure the team’s progress towards the customer’s objectives and the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The team must act as an Effective Social Network

this means

*Honest communication leading to continuous learning and an emphasis on person-to-person interaction, rather than documentation.
*Minimal degrees of separation from what is needed by the team to make progress and the people/resources that can meet those needs.
*Alignment of authority and responsibility.

Rules of play

"Rules of play" that make XP unique are defined below these rules are based on XP’s values (Communication, Simplicity, Feedback, Courage)

Continuous Testing

*Work produced must be continuously validated through testing.

Clearness and quality of codes

*All codes written for potential use in the software product must clearly express every concept and have clarity, contain(s) no duplication and no superfluous parts and pass all the unit tests.

Common Vocabulary

*There is a sketch of the product guide all development with a simple shared story of how the whole system works. So everyone involved could grasp the essence of the project in a term universally understood.

Everybody has the authority

*Everybody has the authority and at least two people have the understanding necessary to do any task

RDP Practice

RDP technique occurs in a brainstorming session that uses rules of XP and some cards, similar to CRC cards. Using these cards in a brainstorming session team members try to customize XP and identify the best suitable and applicable practices (Minimum set of applicable practices).In order to customize XP, the team focus on XP rules. They identify and select practices that can well enough, satisfy the rules. The core practices are XP’s 12 and additional practices (e.g. their best practices) can be used. The criteria of choosing each practices, besides satisfaction of the rules, depends on the project’s size, context and the capability of our team. in order to benefit from key concepts behind RDP technique, index cards which are similar to CRC cards are recommended. the technique is called RDP: Rule-Description-Practices Cards. In a RDP card, the Rule name can be written at the top of the card, descriptions listed down the left side, practices satisfying the rule are listed to the right of the descriptions.In this brainstorming session, two types of cards are prepared, E and P cards: E denotes the rules of engagement cards and P rules of play cards. At the top of each E card the name of engagement’s rule is written and at the left side a simple description of that rule. Similarly for P cards you do this. All members of the team take part in this session, every one can feel free to explore ideas, make suggestions from the most logical to the most ridiculous, and the team gets to start working by suspending judgments.

At the beginning of RDP cards process new aspect of project is identified and presented, so whole team get a common understanding of the project and get familiar with each aspect of the . In this productive thinking, for each rule written on a RDP card, all members try to identify a set of practices that satisfy that rule, and refine them according to the project context and team conditions. Certainly, there may be your best practices in addition to the core practices of XP.

Roles

Roles that participate in this technique are: 1-Customer2-Tracker3-Leader4-Process Observer

the following Table shows a description of these roles, along with a set of desirable characteristics for each.E and P cards are simultaneously played and refined. Finally local set of practices that you identified for a specific project makes "YourXP" software development process. Table2 shows the steps of RDP technique concisely.

Steps

Benefits

There are numbers of advantages that make RDP technique a suitable practice for XP:Proposed practice is based on rational paradigm of defining XP by its rules. When you look at the Rules of XP ( [http://portal.acm.org/citation.cfm?id=1370143.1370149&coll=ACM&dl=ACM&CFID=69442744&CFTOKEN=96226775 Redefined Version] ), it is much easier and rational to identify what XP is rather than trying to define it by the 12 or more practices. In this way, you are not so much concerned about relationships and highly coupling between practices. Because you do not tailor the graph of interconnected practices, just you identify and select practices that could help you to be agile and to be extreme programming. Another benefit of this method is that you can consider your own best practices except the original ones of XP.This tailoring practice is based on CRC technique which is a long live and attractive technique in software engineering. So the proposed practice is valuable because it advocate team work and productive thinking. Along this practice, every one is involved in writing things down, deciding about how to do XP, so no one has time to be bored its really a fun that actually speed up the work. Brainstorming and seeing problems open up is rewarding, help develop a dynamic that ties team members together and unifies their approach to problems. Difference in perspective can be a source of knowledge and of humor. Finally, RDP cards are easy-to-use, portable and “Rule‏-driven” which emphasizes productive thinking (brainstorming) and team work.

References

"General"
* Harvard reference
surname1 = Larman | given1 = C. | authorlink = Craig Larman
surname2 = Basili | given2 = V.
title = Iterative and Incremental Development: A Brief History
journal = Computer | volume=36 | number=6 | year=2003
date= June, 2003 | issn = 0018-9162 | pages = 47-56
url = http://doi.ieeecomputersociety.org/10.1109/MC.2003.1204375
publisher=IEEE Computer Society | places=Los Alamitos, CA, USA
* [http://groups.google.com/group/comp.software.extreme-programming/about comp.software.extreme-programming]
* [http://www.ics.uci.edu/~ses/teaching/ics121/histories/hherela/ Chrysler Comprehensive Compensation System] - link no longer accessible 1 October 2006 ( [http://web.archive.org/web/20051121172415/http://www.ics.uci.edu/~ses/teaching/ics121/histories/hherela/ Archive.org link] )
* Harvard reference
surname1=Waldner | given1=JB. | authorlink=Jean-Baptiste Waldner
title = Nanocomputers and Swarm Intelligence
year = 2008 | isbn = 9781847040022 | page=225-256
url = http://www.iste.co.uk/index.php?f=a&ACTION=View&id=194
publisher = ISTE | places = London, UK

"Pro-XP"
*Kent Beck: "Extreme Programming Explained: Embrace Change", Addison-Wesley, ISBN 0-201-61641-6
*Kent Beck and Martin Fowler: "Planning Extreme Programming", Addison-Wesley, ISBN 0-201-71091-9
*Martin Fowler: "Refactoring: Improving the Design of Existing Code", Addison-Wesley, ISBN 0-201-48567-2
*Ken Auer and Roy Miller: "Extreme Programming Applied: Playing To Win", Addison-Wesley, ISBN 0-201-61640-8
*Ron Jeffries, Ann Anderson and Chet Hendrickson (October, 2000), "Extreme Programming Installed", Addison-Wesley, ISBN 0-201-70842-6
*Kent Beck and Cynthia Andres: "Extreme Programming Explained: Embrace Change, Second Edition", Addison-Wesley, ISBN 0-321-27865-8

*Mehdi Mirakhorli: "RDP technique: a practice to customize xp", International Conference on Software Engineering, Proceedings of the 2008 international workshop on Scrutinizing agile practices or shoot-out at the agile corral, Leipzig, Germany 2008, Pages 23-32, ISBN:978-1-60558-021-0

"Nuanced opinion or Anti-XP"
*Matt Stephens and Doug Rosenberg (July, 2003), "Extreme Programming Refactored: The Case Against XP", Apress, ISBN 1-59059-096-1
* Harvey Herela, [http://calla.ics.uci.edu/histories/ccc/ Case Study: The Chrysler Comprehensive Compensation System] , last update April 21, 2005; Galen Lab, U.C. Irvine.