Category: extreme Programming

Extreme Programming – Values & Principles ”; Previous Next XP sets out to lower the cost of change by introducing basic values, principles and practices. By applying XP, a system development project should be more flexible with respect to changes. Extreme Programming Values Extreme Programming (XP) is based on the five values − Communication Simplicity Feedback Courage Respect Communication Communication plays a major role in the success of a project. Problems with projects often arise due to lack of communication. Many circumstances may lead to the breakdown in communication. Some of the common problems are − A developer may not tell someone else about a critical change in the design. A developer may not ask the customer the right questions, and so a critical domain decision is blown. A manager may not ask a developer the right question, and project progress is misreported. A developer may ignore something important conveyed by the customer. Extreme Programming emphasizes continuous and constant communication among the team members, managers and the customer. The Extreme Programming practices, such as unit testing, pair programming, simple designs, common metaphors, collective ownership and customer feedback focus on the value of communication. XP employs a coach whose job is to notice when the people are not communicating and reintroduce them. Face-to-Face communication is preferred and is achieved with pair programming and a customer representative is always onsite. Simplicity Extreme Programming believes in ‘it is better to do a simple thing today and pay a little more tomorrow to change it’ than ‘to do a more complicated thing today that may never be used anyway’. Do what is needed and asked for, but no more. ””Do the simplest thing that could possibly work”” The DTSTTCPW principle. Implement a new capability in the simplest possible way. Also known as the KISS principle ‘Keep It Simple, Stupid!’. A coach may say DTSTTCPW when he sees an Extreme Programming developer doing something needlessly complicated. Refactor the system to be the simplest possible code with the current feature set. This will maximize the value created for the investment made till date. Take small simple steps to your goal and mitigate failures as they happen. Create something that you are proud of and maintain it for a long term for reasonable costs. Never implement a feature you do not need now i.e. the ‘You Aren’t Going to Need It’ (YAGNI) principle. Communication and Simplicity support each other. The more you communicate the clearer you can see exactly what needs to be done, and you gain more confidence about what really need not be done. The simpler your system is, the less you have to communicate about the fewer developers that you require. This leads to better communication. Feedback Every iteration commitment is taken seriously by delivering a working software. The software is delivered early to the customer and a feedback is taken so that necessary changes can be made if needed. Concrete feedback about the current state of the system is priceless. The value of the feedback is a continuously running system that delivers information about itself in a reliable way. In Extreme Programming, feedback is ensured at all levels at different time scales − Customers tell the developers what features they are interested in so that the developers can focus only on those features. Unit tests tell the developers the status of the system. The system and the code provides feedback on the state of development to the managers, stakeholders and the customers. Frequent releases enable the customer to perform acceptance tests and provide feedback and developers to work based on that feedback. When the customers write new features/user stories, the developers estimate the time required to deliver the changes, to set the expectations with the customer and managers. Thus, in Extreme Programming the feedback − Works as a catalyst for change Indicates progress Gives confidence to the developers that they are on the right track Courage Extreme Programming provides courage to the developers in the following way − To focus on only what is required To communicate and accept feedback To tell the truth about progress and estimates To refactor the code To adapt to changes whenever they happen To throw the code away (prototypes) This is possible as no one is working alone and the coach guides the team continuously. Respect Respect is a deep value, one that lies below the surface of the other four values. In Extreme Programming, Everyone respects each other as a valued team member. Everyone contributes value such as enthusiasm. Developers respect the expertise of the customers and vice versa. Management respects the right of the developers to accept the responsibility and receive authority over their own work. Combined with communication, simplicity, and concrete feedback, courage becomes extremely valuable. Communication supports courage because it opens the possibility for more high-risk, high-reward experiments. Simplicity supports courage because you can afford to be much more courageous with a simple system. You are much less likely to break it unknowingly. Courage supports simplicity because as soon as you see the possibility of simplifying the system you try it. Concrete feedback supports courage because you feel much safer trying radical modifications to the code, if you can see the tests turn green at the end. If any of the tests do not turn green, you know that you can throw the code away. Extreme Programming Principles The values are important, but they are vague, in the sense that it may not be possible to decide if something is valuable. For example, something that is simple from someone’s point of view may be complex from someone else’s point of view. Hence, in Extreme Programming, the basic principles are derived from the values so that the development practices can be checked against these principles. Each principle embodies the values and is more concrete, i.e. rapid feedback − you either, have it or you do not. The fundamental principles of Extreme Programming are − Rapid feedback Assume simplicity Incremental change

Extreme Programming – Process Cycle ”; Previous Next Extreme Programming is an Agile process. Extreme Programming is an Agile process because it − Emphasizes plenty of communication and feedback − Within the team (pair programming, collective code ownership, simple design) With the customer (on-site customer and acceptance testing) For release planning (with customer and developers participating in estimation) Extreme Programming employs a coach whose job is noticing when people are not communicating and reintroduce them. Embraces change with − Frequent iterations (short releases) Designing and redesigning easily (simple design) Coding and testing continuously (pair programming) Keeping the customer constantly involved (on-line customer) Delivers working product to the customer in short iterations (short releases). Eliminates defects early, thus reducing costs (pair programming) Code reviews Unit testing Integration for every set of changes and testing Extreme Programming Process Cycle Extreme Programming is iterative and incremental and is driven by Time-Boxed Cycles. Therefore, the rhythm of the Extreme Programming process is crucial. Extreme Programming has the following activity levels − Product Life Cycles Releases Iterations Tasks Development Feedback Each of the activity levels provides the minimal inputs required for the next level. They are − Product life cycle activities provide inputs for release cycles. Release planning sessions provide inputs for iteration cycles. Iteration planning sessions provide inputs for task cycles. Task development provides inputs for development episodes. Development produces the product. Feedback is a continuous activity throughout the project and across all the above activity levels. Product Life Cycles This is also referred to as the Exploration phase. It involves feature set definition and planning. The customer arrives at high value requirements and the requirements are given as user stories. Stories are the primary deliverable of this level activity. Releases This is also referred to as the Commitment phase. In this activity − The whole team gathers so that − Progress is reviewed. New requirements can be added and/or existing requirements can be changed or removed. Customer presents stories. Stories are discussed. The developers determine the technical approach and risk. They provide first-level estimates and options. The customer prioritizes the stories and chooses target release time box. The customer and developers commit themselves to the functionality that are to be included and the date of the next release. The developers − Arrange stories into probable iterations. Include defect fixes from acceptance testing of the previous release. Begin the iterations. Release plan is the primary deliverable of this level activity. Iterations This is also referred to as the Steering phase. The whole team gathers so that the progress is reviewed and the plan can be adjusted. The customer presents stories for the iteration and the stories are discussed in greater detail. The iteration Plan is the primary deliverable of this activity. The developers − Determine detailed technical approach. Create task list for each story. Begin the development. Deploy the system as far as Deployable System is the final deliverable of this activity. Tasks The developers Sign-up for the tasks and begin development episodes to implement the stories. They ensure the tasks for the iteration are complete. The developers also ensure that the stories for the iteration are complete with acceptance tests. Development The developers form pairs, which can be a continuous and dynamic activity. Each Pair − Verifies their understanding of the story. Determines detailed implementation approach, ensuring simple design. Begins test-driven development, i.e., write unit test, implement code to pass the unit test, refactor to make the code simple. Integrates their code to the system code base at appropriate intervals. Reviews the progress frequently. Feedback Pairs constantly communicate within themselves and outward to the team as well. On-line customer is also involved in the communication on a continuous basis. Certain teams resort to daily stand-up meetings to discuss the overall team status quickly and the possible re-synchronization and micro-planning if necessary. The iteration and release reviews provide overall status and points for process adjustment and improvement. Development episodes may cause rethinking of tasks. Task development may cause rethinking of stories. Story re-estimation may cause iteration changes or recovery. Iteration results may cause changes to release plan. The Extreme Programming process cycle is illustrated below. Print Page Previous Next Advertisements ”;

Extreme Programming – Practices ”; Previous Next There are four basic activities in Extreme Programming. They are − Coding Testing Listening Designing These four basic activities need to be structured in the light of the Extreme Programming principles. To accomplish this, the Extreme Programming practices are defined. These 12 Extreme Programming practices achieve the Extreme Programming objective and wherever one of the practices is weak, the strengths of the other practices will make up for it. Kent Beck, the author of ‘Extreme Programming Explained’ defined 12 Extreme Programming practices as follows − The Planning Game Short Releases Metaphor Simple Design Testing Refactoring Pair Programming Collective Ownership Continuous Integration 40 hour Week On-site Customer Coding Standards Four Areas of Extreme Programming The Extreme Programming practices can be grouped into four areas − Rapid, Fine Feedback − Testing On-site customer Pair programming Continuous Process − Continuous Integration Refactoring Short Releases Shared Understanding − The Planning Game Simple Design Metaphor Collective Ownership Coding Standards Developer Welfare − Forty-Hour Week In this chapter, you will understand the Extreme Programming practices in detail and the advantages of each of these practices. Extreme Programming Practices at-a-glance The following diagram shows how Extreme Programming is woven around the Extreme Programming practices − The Planning Game The main planning process within extreme programming is called the Planning Game. The game is a meeting that occurs once per iteration, typically once a week. The Planning Game is toqQuickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan. Business and development need to make the decisions in tandem. The business decisions and the development’s technical decisions have to align with each other. Business people need to decide about − Scope − How much of a problem must be solved for the system to be valuable in production? The businessperson is in a position to understand how much is not enough and how much is too much. Priority − If you are given an option, which one do you want? The businessperson is in a position to determine this, more than a developer with inputs from the customer. Composition of releases − How much or how little needs to be done before the business is better off with the software than without it? The developer”s intuition about this question can be wildly wrong. Dates of releases − What are important dates at which the presence of the software (or some of the software) would make a big difference? Technical people need to decide about − Estimates − How long will a feature take to implement? Consequences − There are strategic business decisions that should be made only when informed about the technical consequences. Development needs to explain the consequences. Process − How will the work and the team be organized? The team needs to fit the culture in which it will operate. The software must be written well rather than preserve the irrationality of an enclosing culture. Detailed Scheduling − Within a release, which stories should be done first? The developers need the freedom to schedule the riskiest segments of development first, to reduce the overall risk of the project. Within that constraint, they still tend to move business priorities earlier in the development, reducing the chance that important stories will have to be dropped towards the end of the development of a release due to time constraints. Thus, plan is a result of collaboration between the customer, businessperson and the developers. The Planning Game – Advantages The Planning Game has the following advantages − Reduction in time, wasted on useless features Greater customer appreciation of the cost of a feature Less guesswork in planning Short Releases You should put a simple system into production quickly, and then release new versions in very short cycles. Every release should be as small as possible, so that it is − Achievable in a short cycle Contains the most valuable and immediate business requirements A working system The duration of the short cycle may vary with the software that needs to be built. However, it needs to be ensured that the minimum possible duration is chosen. Short Releases – Advantages The advantages of Short Releases are − Frequent feedback Tracking Reduce chance of overall project slippage Metaphor According to Cambridge online dictionary- A Metaphor is an expression, often found in literature that describes a person or object by referring to something that is considered to have similar characteristics to that person or object. For example, ‘The mind is an ocean’ and ‘the city is a jungle’ are both Metaphors. You should guide the entire development with a simple shared story of how the whole system works. You can think of metaphor as the architecture of the system to be built in a way that it is easily understandable by everyone involved in the development. The metaphor consists of domain specific elements and shows their interconnectivity. The language used is the domain language. To identify the technical entities, the words used in the metaphor need to be taken consistently. As the development proceeds and the metaphor matures, the whole team will find new inspiration from examining the metaphor. The goal of a good architecture is to give everyone a coherent story within which to work, a story that can easily be shared by both the business and the technical members.Hence, in Extreme Programming, by asking for a metaphor, we are likely to get an architecture that is easy to communicate and elaborate. Metaphor – Advantages The advantages of Metaphor are − Encourages a common set of terms for the system Reduction of buzz words and jargon A quick and easy way to explain the system Simple Design The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered. The right design for the software at any given time is the one that − Runs all the