RDP technique
![]() | This article was nominated for deletion. The discussion was closed on 14 March 2009 with a consensus to merge the content into the article Extreme Programming. If you find that such action has not been taken promptly, please consider assisting in the merger instead of re-nominating the article for deletion. To discuss the merger, please use the destination article's talk page. (March 2009) |
![]() | This article has no links to other Wikipedia articles. (October 2008) |
RDP Practice is a technique for tailoring Extreme Programming. This practice was proposed for the first time as a research paper in an APSO workshop at ICSE 2008 conference. Although it is specifically a solution for customising XP this practice it could be applied to other methodologies.
Context
Extreme Programming or XP is a software engineering methodology (and a form of agile software development)[1][2][3] 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.[2][3][4] 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,[5] 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[clarification needed].
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
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've identified for a specific project makes "YourXP" software development process. Table 2 shows the steps of RDP technique concisely.
Role | Responsibility | Desirable characteristics |
---|---|---|
Leader | Sets up and manage the session; Present RDP technique to attendance | with managerial skills; good understanding of XP: Usually Coach;
able to tell when protracted discussion is leading to a valuable discovery or when it is pointless and should be redirected |
Customer | To present a system overview from his(her) perspective and answers questions | Real customer: who will actually use the system being developed |
Tracker | In refinement process: To Scrutinize chosen practices to see whether or not they satisfy rules according to the project’s conditions and investigate players for reasons. | Good understanding of XP; good insights into the needs of stakeholders; experience with systems in similar domains; unafraid to bring up contentious issues and pursue them; familiar with attributes of concern |
Process Observer | Keeps notes on how RDP technique could be improved or deviated from;
after the session, reports on how the process went and lessons learned for future improvement; |
Thoughtful observer; knowledgeable in XP; should have previous experience in the RDP technique |
Steps
Steps | Short description |
---|---|
1. Present RDP card technique | The leader presents the RDP card technique to all members and describes the steps and outputs of the technique. |
2. Present project and business | The tracker and customer present a system overview from their perspective.
The presenter is asked to describe the following:
|
3. Brainstorm Rules and identifying practices that needed | Preparing RDP cards and identifying essential practices that satisfy E&P rules according to the project’s context in a brainstorming session |
4. Present results | Presenting elicited practices and documenting YourXP, Organizing development team |
Benefits
There are numbers of advantages that make RDP technique a suitable practice for XP [clarification needed]: Proposed practice is based on rational paradigm of defining XP by its rules[clarification needed]. When you look at the Rules of XP (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[clarification needed]. In this way, you are not so much concerned about relationships and highly coupling between practices[clarification needed]. 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[clarification needed]. This tailoring practice is based on CRC technique which is a long live and attractive technique in software engineering[citation needed]. 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
- ^ "Human Centred Technology Workshop 2005", 2005, PDF webpage: Informatics-UK-report-cdrp585.
- ^ a b "Design Patterns and Refactoring", University of Pennsylvania, 2003, webpage: UPenn-Lectures-design-patterns.
- ^ a b "Extreme Programming" (lecture paper), USFCA.edu, webpage: USFCA-edu-601-lecture.
- ^ "Manifesto for Agile Software Development", Agile Alliance, 2001, webpage: Manifesto-for-Agile-Software-Dev
- ^ "Extreme Programming", Computerworld (online), December 2001, webpage: Computerworld-appdev-92.
General
- Template:Harvard reference
- comp.software.extreme-programming
- Chrysler Comprehensive Compensation System - link no longer accessible 1 October 2006 ( Archive.org link)
- Template:Harvard reference
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, Case Study: The Chrysler Comprehensive Compensation System, last update April 21, 2005; Galen Lab, U.C. Irvine.