Category: extreme Programming

Extreme Programming – Tools ”; Previous Next In this chapter, we will learn about some tools used in Extreme Programming. ExtremePlanner ExtremePlanner is a browser-based Agile Project management solution that is designed specifically to support Agile methods including Scrum and Extreme Programming. ExtremePlanner concentrates on planning and tracking the progress of features (or user stories) that have actual business value to customers. The key features of ExtremePlanner are − Supports the whole team including project managers, developers, QA, tech support, and stakeholders. Estimates and plans software releases with drag and drop ease. Manages features, defects, test cases and development tasks in one place. Has an integrated issue tracking to manage customer requests from start to finish. Provided the latest changes with email notifications and project activity reports. For more Information − www.extremeplanner.com Project Planning and Tracking System PPTS is a Web-based environment supporting teams who have chosen to develop Software according to the Agile Methodologies Scrum and/or Extreme Programming. PPTS functionality includes − Administration of project, iteration and resource attributes Product backlog that can be prioritized Work breakdown structure (sprint backlog) Metrics (velocity and estimated/spent effort) Burndown and progress charts Calendars Resource allocation Fine grained access to information based on overall role (administrator or user) or role in project (project leader, developer or customer) Customization of menus and language (both English and Dutch available) Interfacing with PR/CR tools For more Information − http://ses-ppts.sourceforge.net/ Targetprocess Targetprocess is a Visual project management software that enables you to visually manage complex work and focus on the things that matter. Targetprocess gives the visibility and transparency you need across your organization. From Kanban and Scrum to almost any operational process, Targetprocess flexibly adapts to your management approach and organizational structure. Targetprocess provides − Boards for planning and progress tracking. Board view gives many options to handle a large amount of cards seamlessly. Boards that can be shared with any person to broadcast information outside. They are flexible. Multiple cards can be moved with drag and drop. Lists for project hierarchy and manage backlogs with ease. Full customization, inline edit and beautiful design. Graphical reports. Timelines. Custom views. Dashboards. For more information − www.targetprocess.com Plone Extreme Management Tool Plone Extreme Management tool provides project administration which supports the Extreme Programming methodology. Plone Extreme Management tool provides − Content types − Project − Project Managers can add multiple projects. For each project, iterations and stories can be added by both the customers and employees. Iteration − The project will be planned with iterations. An iteration is a period of 1 to 3 weeks in which a number of stories will be implemented. Offer − Contains the stories that a customer wants in this project. It is used as a way to bundle the wishes of the client and give a first indication of the size of a project. Story − The customer can define new features by describing these feature in a story. Task − The employees can estimate the story by defining tasks. Booking − While working on tasks the employees can track time and easily book those at the end of the day. Workflow. Time tracker. Release plan. Iteration roundup. XP Tools for Java Developers The following table gives a list of tools for Java developers for related activities. Java Extreme Programming Tools Activity Maven and AntHill Project management and continuous integration. Ant and XDoclet Automated building and continuous integration. AntHill and CruiseControl Automating continuous integration . IntelliJ Idea, Xrefactory, DPT, Jfactor, Jrefactory Java refactoring. JUnit Automated Java testing. Cactus Automated Servlet, JSP, and other J2EE testing. Jemmy, JFCUnit, and Abbot Automated swing testing. XP Tools for .Net Developers In lines with Java, .Net has NAnt, NUnit, CruiseControl.NET. Visual Studio has many refactoring tools. Adopting XP in your Organization If you are planning to adopt Extreme Programming in your organization, first you select a project suitable for Extreme Programming and a team. Get an experienced coach. Get the team accustomed to the Extreme Programming practices, estimation and team communication. Initiate the project with the minimal essential Extreme Programming rules for the project. Allow the rules to evolve for better implementation. Take into consideration the synergies across the Extreme Programming practices. Allow sufficient time for the team to scale the learning curve. Manage the team culture and change. It is advised to take an internal project at first. Once you successfully implement that project, you will have the team and the management to stand by you for the extension to other suitable projects. Print Page Previous Next Advertisements ”;

Extreme Programming – Pair Programming ”; Previous Next Pair programming is a style of programming in which two programmers work side-by-side at one computer, sharing one screen, keyboard and mouse, continuously collaborating on the same design, algorithm, code or test. One programmer, termed as the driver, has control of the keyboard/mouse and actively implements the code or writes a test. The other programmer, termed as the navigator, continuously observes the work of the driver to identify defects and also thinks strategically about the direction of the work. When necessary, the two programmers brainstorm on any challenging problem. The two programmers periodically switch roles and work together as equals to develop a software. Pair Programming – Advantages The significant advantages of Pair Programming are − Many mistakes are detected at the time they are typed, rather than in QA Testing or in the field. The end defect content is statistically lower. The designs are better and code length shorter. The team solves problems faster. People learn significantly more about the system and about software development. The project ends up with multiple people understanding each piece of the system. People learn to work together and talk more often together, giving better information flow and team dynamics. People enjoy their work more. Pair Programming Experiments Use of pair programming practice has been demonstrated to improve the productivity and quality of software products. Pair Programming research reveals that − Pairs use no more man-hours than singles. Pairs create fewer defects. Pairs create fewer lines of code. Pairs enjoy their work more. University of Utah conducted experiments on pair programming. The results revealed that − Pairs spent 15% more time on the program than individuals. Code written by pairs consistently passed more test cases than code written by individuals. Pairs consistently implemented the same functionality produced by individuals in fewer lines of code. Learning how to program in an environment where there are rapidly tangible results is fun and allows one to learn faster. Adapting to Pair Programming Most programmers are used to solitary work and often resist the transition to pair programming. However, with practice they can ultimately make this transition. According to Laurie A. Williams and Robert R. Kessler, in their book, ‘All I Really Need to Know about Pair Programming I Learned in Kindergarten’, it is well explained of how to nurture the skills that we all have learnt in Kindergarten to establish team cohesion, in general and pair programming in particular. The transition and on-going success as a pair programmer often involves practicing everyday civility. The following sections are an excerpt of this publication that help you in becoming effective pair programmers. Kindergarten lessons In Kindergarten, we have learnt the following − Share everything Play fair Do not hit people Put things back where you found them Clean up your own mess Do not take things that are not yours Say you are sorry when you hurt somebody Wash your hands before you eat Flush Warm cookies and cold milk are good for you Live a balanced life – learn some and think some and draw and paint and sing and dance and play and work every day some Take a nap every afternoon When you go out into the world, watch out for traffic, hold hands and stick together Be aware of wonder Next, we look at the principles of Pair Programming in the context of the above given teachings. Share everything In pair programming, Two Programmers sit together and jointly produce one artifact (design, algorithm, code, etc.) One person is typing or writing, the other is continually reviewing the work. Both Are equal participants in the process Responsible for every aspect of the artifact Own everything Play fair In pair programming, One person drives, i.e. has control of the keyboard or is recording design ideas, while the other is continuously reviewing the work. They switch these roles periodically, even when one of them is significantly more experienced than the other, to ensure equal participation. While the person who is driving is thinking about implementation, the other continuously reviews code, thinks about a possible simpler design that is possible, how the current development fits in the overall system as of date. Do not hit your partner In pair programming, Ensure that your partner stays focused and on-task. You stay focused and on-task. Ensure your partner follows the prescribed coding standards and thus maintains the commitment to the rest of the team. In the pair programming survey, it is found that tremendous productivity gains and quality improvements are realized. This is because − Each one keeps their partner focused and on-task with no possibility of slack off. Each artifact is reviewed continuously as it is being produced ensuring quality. Put things back where they belong In Pair Programming, You need to believe in your skills and your partner’s skills as well. Any negative thoughts in this aspect are to be put in trash can. You have to be sure that you express what you know and are open to learn from your partner when required. You can learn from your partner by observing him or taking his feedback instantly. You need to have the confidence that − Wherever there is a possibility of lagging, you can immediately pick up from your partner. Together as a pair, you can solve problems that you could not solve alone. You can help improve each other’s skills. Clean up your mess In Pair Programming, with the ‘watch over the shoulder’ technique, You will find that it is amazing to know how many obvious but unnoticed defects are noticed by your partner. You can remove these defects without the natural animosity that might develop in a formal inspection meeting. Characterizing defect prevention and defect removal efficiency. Do not take things too seriously Having a partner to review design and coding continuously and objectively is a very beneficial aspect of pair programming. In pair programming, you need to ensure that you work without

Scrum + Extreme Programming ”; Previous Next Extreme Programming is one of the earliest agile methodologies that came into existence and is continuously evolving. Kent Beck, who evolved Extreme Programming, developed it with the premise to use best programming practices and take them to the extreme. Extreme Programming in the current scenario focuses on the best practices that are prevailing in the industry as of now and takes them to the extreme. The most prevalent examples are Test Driven Development, Whole Team Approach, Sustainable Pace, etc. XP – Flexibility as Technique One of the reasons Extreme Programming is so popular is its flexible nature. Further, Extreme Programming is more about technique than process and hence merges well with the process-centric approaches. So, you can easily combine features of extreme programming with other ideas, wherever Some of the Extreme Programming practices are complimentary in the process. Extreme Programming by itself is not suitable for implementation. However, remember that any of the Extreme Programming Practices that you choose should be implemented to its core. Otherwise, you cannot claim that you are using Extreme Programming. In fact, this is true for any process that you take up. Mix-and-match is allowed, but only when you are using complimentary features and you are not compromising on the values of the features being used. The most popular Extreme Programming hybrid that is currently in use is Scrum + Extreme Programming hybrid. We will start with the basic and still prevalent Software Development Methodology – Waterfall Model. Waterfall Model In Waterfall model, the development progresses in phases and no phase can begin before the completion of the earlier phase. Waterfall Model is still in use in several organizations though some perceive it as a traditional methodology. It is an established and effective methodology if the requirements are completely known before the development starts. The process is straightforward and does not require any training or mentoring. What you need to remember is that no methodology is ideal for every situation and every methodology will have its own merits and demerits. Hence, you have to understand which methodology suits your context, your environment and your customer interests. Let us have a look at the shortcomings of the Waterfall methodology − As all the requirements are to be known before the initiation of development, it is not suitable when the requirements are incomplete or vague. As the methodology is forward facing in one direction, feedback from any phase cannot be taken back into any of the earlier phases, though more clarity is obtained regarding the end product. Testing is taken up only after the completion of development, with a team of developers who were not involved in the earlier phases, such as requirements gathering or development. This test-last approach often leads to defect containment, high defect rates, high delivered defects that are uncovered by the customer. The working product will not be available till the end of development and hence nobody will have a clue on whether the right thing is being built though it is being developed rightly. Defect fixes and changes to the requirements are difficult to be absorbed as there is a high chance of breaking the design and also the costs incurred are high. If you predict such conditions in your development, the Agile methodologies are the most suited. Agile Methodologies Agile Methodologies advocate − Frequent releases of working product increments, enabling feedback to flow in at right time. Team-centric approach to make everyone responsible and accountable for the end product. Flexible planning that focuses on the delivery of value to the customer, meeting customer expectations, return on investment. Readiness to accept changes at any point of development so that the end product that is delivered is not obsolete. Several Agile methodologies came into existence, of which Scrum has become more popular and is being widely used. How Scrum makes the Difference? In Scrum, projects are broken down into releases and time-boxed short sprints. For every sprint, you will take up only the required and sufficient functionality that is prioritized by the customer and that you can deliver in a sprint. At the end of each Sprint, you will have a working product that could be released. The requirements are called backlog items, the iterations are called sprints. Continuous Testing with test-first approach will be adapted. The developers and the testers also participate in the user story writing which are the backlog items. This gives an upfront view of the product’s behavior to everyone in the team and also helps in arriving at the acceptance criteria at the beginning of the sprint itself. Scrum, by its definition, again as we stated earlier, is effective in certain situations, but has its own shortcomings as with any other development methodologies. The time-boxed sprints will not allow any flexibility in the release schedule that hampers both development and testing. Scrum, on its own do not give directions for development. Hence, Scrum is usually combined with other Agile methodologies that focus more on the development strategies. Scrum + Extreme Programming Hybrid Scrum is being used quite frequently incorporating Extreme Programming practices that are complimentary, with Extreme Programming focusing on the engineering aspects such as continuous communication, frequent feedback loops, refactoring, collective ownership, continuous integration, test-driven development, etc. and scrum focusing on the fixed scope for sprints, burn-down charts, etc. As Scrum is a defined methodology, it is easier to adapt from day-one of the project. As Extreme Programming is more towards communication and team cohesion, the team is more focused on the development. Thus, a Scrum + Extreme Programming hybrid is found to be effective. Tools for Scrum + XP Hybrid Projects Tools such as SpiraTeam and Rapise are meant for Scrum + Extreme Programming Hybrid Projects.SpiraTeam provides reporting dashboards of key project quality and progress indicators in one consolidated view that is tailor-made for Scrum and Extreme Programming projects. Some of the indicators are − Requirements Test Coverage Task Progress Project Velocity Top Risks and

Extreme Programming – Useful Resources ”; Previous Next The following resources contain additional information on Extreme Programming. Please use them to get more in-depth knowledge on this. Useful Video Courses Javascript Object oriented programming Course – Build Quiz App 61 Lectures 8 hours DigiFisk (Programming Is Fun) More Detail Industry 4.0 – Automation & Applications 35 Lectures 2.5 hours J Aatish Rao More Detail Java Courses in Tamil 188 Lectures 11.5 hours Programming Line More Detail Python for Beginners with Real world applications in Hindi 54 Lectures 8 hours Saurabh Dubey More Detail Data Science and Machine Learning with R from A-Z Course [Updated for 2021] 81 Lectures 28.5 hours Packt Publishing More Detail Internet of Things (IoT) Automation using Raspberry Pi 2 23 Lectures 39 mins Venkatesh Varadachari More Detail Print Page Previous Next Advertisements ”;

Discuss Extreme Programming ”; Previous Next Extreme programming (XP) is a software development methodology, which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent “releases” in short development cycles, to improve productivity and introduce checkpoints at which new customer requirements can be adopted. Print Page Previous Next Advertisements ”;

Extreme Programming – Rules ”; Previous Next Consider any sport that you play. You need to abide by the rules of that sport or game. In a similar way, in Extreme Programming as the entire project is driven by collaboration among the team members and with the business (who represents the customer), certain rules for the project need to be laid out at the beginning itself. These rules should be at par with the Extreme Programming practices. The rules provide a common reference for everyone on the team so that they remind everyone of what and how they need to do when things go smoothly and also when they are not going well. The game that we refer to in the Extreme Programming is Planning Game. Rules of Planning Game In Extreme Programming, the planning game begins with the first-release planning meeting and ends with the final release. You must define the rules of the Planning Game in line with the Extreme Programming practices before the first release planning meeting and familiarize the rules to the business and the team. You must manage the project ensuring that the rules are adhered to. However, in software development, there is no way that a simple set of rules apply in every project. They may have to vary according to the business and the team, not compromising on the Extreme Programming practices. Hence, a set of rules with the necessary goals can initially be put in place and they can be modified as the development progresses only if required. The goal of the game is to maximize the value of software produced by the team. From the value of the software, you have to deduct the cost of its development, and the risk incurred during development. The strategy for the team is to invest as little as possible to put the most valuable functionality into production as quickly as possible in conjunction with the design and coding strategies to reduce risk. In view of the technology and business lessons of this first working system, it becomes clear to business what is now the most valuable functionality, and the team quickly puts this into production. This process continues with iterations and releases till the entire development is complete. The basic rules of planning game can be categorized into the following areas − Planning Managing Designing Coding Testing Planning Planning is done during release planning and iteration planning. The rules are same for both. In Release planning, Business and the team are the players. Story cards are used. User stories are written by the customer on story cards. User stories are written by the customer on story cards. Business is decided on the priority of the functionality for implementation. Estimates are given by the team based on the story cards. Short (frequent small) releases are to be planned Release schedule is to be created with mutual agreement. The next release is to be divided into iterations. Iteration planning starts each iteration. In Iteration planning, The team members are the players. Task cards are used. For each story selected for the iteration, the task cards are produced. The team members have to estimate the tasks based on the task cards. Each team member is assigned with task cards. Each team member has to then re-estimate based on his or her assignment, for Accepting the work. Taking responsibility of the completion of the work. Getting feedback about the actual time taken. Improving the estimates. Respecting those estimates. Thus, the rules for who can make and change the estimates are clear. Final assignment is done assuming 40-hour week and load factor. Managing The team is given a dedicated open workspace. Each workstation is to be arranged such that two developers can sit side by side and easily slide the keyboard and mouse. Sustainable pace is to be set (40-hour week and no overtime for more than one week) and managed. Enforce the rules of the planning game. Fixing any extreme programming practice when it breaks. Ensure Communication among the Team. Discourage Communication that is − not helpful not at the right time done in great detail Make people move around. Measure the actual times and convey to team periodically so that each team member will know the performance as against prediction. This ensures that the team member improves in estimating. Make food available to the team as and when required. Designing The rules of designing are − Choose a metaphor for the system and evolve it as development progresses. Keep the design simple. No functionality is added early. Put as much architecture in place now as you need to meet your current needs, and trust that you can put more in later Refactor whenever and wherever possible. Coding The rules of coding are − The business (who represents the customer) should always be available. Developers should write all the code in accordance with rules emphasizing communication through the code. Pair programming should be ensured. Coding standards are to be followed. All code must have unit tests. Write a unit test first, before the code is written for each piece of the system so that it is much easier and faster to create your code. The combined time it takes to create a unit test and create some code to make it pass is about the same as just coding it up straight away. It eases regression testing. When you are coding you should be wearing only one of the following four hats − Adding new functionality, but only changing the implementation. Adding new functionality, but only changing the interface. Refactoring code, but only changing the implementation. Refactoring code, but only changing the interface . A dedicated integration workstation is provided for the entire team. Only one pair integrates code at a time and ensures all the tests are passed. Integration should be done often. Collective ownership should be used. Testing The rules of testing are − All codes must pass all unit tests before

Extreme Programming – Activities & Artifacts ”; Previous Next In this chapter, we will understand the Extreme Programming activities and artifacts. XP – Activities In Extreme Programming, the four basic activities are − Coding Testing Listening Designing Coding In pair programming, coding is considered the heart of development. You code because if you do not code, at the end of the day you have not done anything. Testing In pair programming, testing needs to be done to ensure that the coding is done. If you do not test, you do not know when you have finished coding. Listening In pair programming, you listen to know what to code or what to test. If you do not listen, you do not know what to code or what to test. Designing In pair programming, you design so that you can keep coding and testing and listening indefinitely, as good design allows extension of the system, with changes in only one place. These activities are performed during − Release Planning Iteration Planning Implementation Release Planning In Release planning, both the customer and the developers jointly arrive at the plan for the next release, agreeing on the user stories for the release and the next release date. Release Planning has three phases − Exploration Phase Commitment Phase Steering Phase Release Planning – Exploration Phase In Exploration phase − The customer provides a shortlist of high-value requirements for the system. The developers gather requirements and estimates the work impact of each of those requirements. The Requirements are written down on user story cards. For writing a story, the customer will come with a problem in a meeting with the developers. Developers will try to define this problem and get requirements. Based on this discussion, a story will be written by customer, pointing out what they want a part of the system to do. It is important that the developers have no influence on this story. Active Listening is significant in this phase, as The Developers need to understand “What the customer is asking for” and “What requirements are of high value”. The customer needs to understand along with the developers about what scenarios contribute to these values to write the story. Though the customer writes the requirements on user story cards, you need to listen to Obtain clarity Avoid ambiguity Express yourself if there are possible gaps in understanding This is possible only with verbal communication. Release Planning – Commitment Phase In Commitment phase, the customer and developers will commit themselves to the functionality that will be included and the date of the next release. This phase involves the determination of costs, benefits, and schedule impact. In this phase, The customer sorts the user stories by business value. The developers sort the stories by risk. Developers determine the effort and duration (estimates) required for implementation of the stories. The user stories that will be finished in the next release will be selected. Based on the user stories and the estimates, the release date is determined. Active listening is significant in this phase, as − The developers need to understand what functionality they need to code for the current release and the effort and duration (estimates) required to deliver this functionality. The customer and the developers need to understand the feasibility for commitment on the date of next release. Release Planning – Steering Phase In Steering phase the customer and developers “steer” − To make changes in individual user stories and the relative priorities of different user stories. To adjust the plan. If estimates were proved wrong. To accommodate the changes. Active listening is significant in this phase, To understand − The new requirements to be added. What changes needs to be done for existing requirements. The impact on the existing system if any of the existing requirements is removed. Arrive at the estimates required to adjust the plan, considering The work done so far. The new requirements to be added. Existing requirements that have to be changed or removed. Iteration Planning In Iteration Planning, the developers are involved to plan the activities and tasks for the iteration. In this, the customer is not involved. Iteration Planning has three phases − Exploration phase. Commitment phase. Steering phase. Iteration Planning – Exploration Phase In Exploration phase, Requirements will be translated to different tasks. The tasks are recorded on task cards. The developers estimate the time it will take to implement each task. If the developers cannot estimate a task because it is too small or too big, they need to combine or split the task. Iteration Planning – Commitment Phase In Commitment phase, The tasks is assigned to the developers. The developer accepts the tasks for which he or she takes responsibility. The developer estimates the time it takes to complete the task because the developer is now responsible for the task, and he or she should give the eventual estimation of the task. Load balancing is done after all the developers within the team have been assigned tasks. A comparison is made between the estimated time of the tasks and the load factor. The load factor represents the ideal amount of hands-on development time per developer within one iteration assuming a 40-hour week. Then the tasks are balanced out among the developers. If a developer is overcommitted, other developers must take over some of his or her Tasks and vice versa. Iteration Planning – Steering Phase In Steering phase, The developer gets the task card for one of the tasks to which he or she has committed. The developer will implement this task along with another developer following the pair programming practice. Implementation The implementation of the tasks is done. The implementation includes design, writing unit tests, coding, unit testing, refactoring, continuous integration to the code base, integration testing and acceptance testing based on the task card and user story card. Extreme Programming Artifacts Extreme Programming is not anti-documentation, but encourages doing the least amount that is really needed. The document when

Extreme Programming – Roles ”; Previous Next In Extreme Programming, the emphasis is on the collaboration of the whole team, collocated and is in continuous communication. However, certain roles are required for an extreme programming project to work and the persons who take these roles take the corresponding responsibilities and are accountable for their contribution to these roles. It is advised to allocate the right people for the roles rather than trying to change the people to fit into those roles. Roles in Extreme Programming The Roles that have been found effective in Extreme Programming are − Developer (also called Programmer by some teams) Customer Manager (also called tracker) Coach Developer The role of developer is the most important one in Extreme Programming. To be a developer in Extreme Programming, you need to be accustomed with the following − Developer Rights You have the right to know what is needed, with clear declarations of priority. You have the right to produce quality work at all times. You have the right to ask for and receive help from peers, superiors, and customers. You have the right to make and update your own estimates. You have the right to accept your responsibilities instead of having them assigned to you. Major responsibilities that you will be accountable for − Estimate stories Define tasks from stories Estimate tasks Write unit tests Write code to pass the written unit tests Perform unit testing Refactor Integrate continuously Developer Skills Pair Programming Communication – that is necessary and to the sufficient detail Always use the metaphor to use the right names Code only what is required. Maintain simplicity Collective Ownership If someone changes the code that you wrote, in whatever part of the system, you have to trust the changes and learn. In case the changes are wrong-headed, you are responsible for making things better, but be careful not to blame anyone. Be prepared to acknowledge your fears. Remember that you are part of a team and courage is required for the success of Extreme Programming. Wear different hats as a developer in the team such as − Programmer. Architect and designer. Interface architect/UI designer. Database designer and DBA. Operations and network designer. Sometimes one of the developers has to wear the hat of a tester. Help the customer choose and write functional tests. Run the functional tests regularly. Report the test results. Ensure the testing tools run well. Customer In Extreme Programming, the customer role is as crucial as the developer role as it is the customer who should know what to program, while the developer should know how to program. This triggers the necessity of certain skills for the customer role − Writing required stories to the necessary and sufficient detail. Developing an attitude for the success of the project. Influencing a project without being able to control it. Making decisions that are required time to time on the extent of functionality that is required. Willing to change decisions as the product evolves. Writing functional tests. In Extreme Programming, the customer is required to be in constant communication with the team and speak as a single voice to the team. This is required since − Customer could be multiple stakeholders. Customer could be a community. Customer is not always the PRINCIPAL (proxies). Customer can be a team with the following potential members − Product Managers Marketing, Sales Business Analysts End Users, their Managers Business/System Operations The Major Responsibilities of the Customer are − Write user stories Write functional tests Set priorities on the stories Explain stories Decide questions about the stories The customer is accountable for these responsibilities. Manager In Extreme Programming, the major responsibilities of the manager are − Define the rules of planning game. Familiarize the team and the customer on the rules of the planning game. Monitor the planning game, fix any deviations, modify the rules if and when required. Schedule and conduct release planning and iteration planning meetings. Participate with the team while they estimate in order to provide feedback on how reality conformed to their prior estimates, both at team level and individual level that eventually help them to come up with better estimates next time. Ensure that the team is working towards the next release as they progress through the iterations with committed schedule and committed functionality. Track functional testing defects. Track the actual time spent by each team member. Adapt an ability to get all the required information without disturbing the team’s work. The Manager is Accountable for these Responsibilities. Coach Extreme Programming is the responsibility of everyone in the team. However, if the team is new to Extreme Programming, the role of a coach is crucial. The responsibilities of the coach are − Understand, in depth, the application of Extreme Programming to the project. Identify the Extreme Programming practices that help in case of any problem. Remain calm even when everyone else is panicking. Observe the team silently and intervene only when a significant problem is foreseen and make the team also see the problem. See to that the team is self-reliant. Be ready to help. Print Page Previous Next Advertisements ”;

Extreme Programming – Supporting Practices ”; Previous Next The Extreme Programming practices if implemented in isolation can be weak and thus, can fail. In Extreme Programming, all the practices need to be considered as a whole, so that they support each other. The weakness of one is covered by the strengths of others. In this chapter, we will focus on the possible weakness of each practice if implemented in isolation. We will see how Extreme Programming can support this practice to overcome the weakness when implemented in conjunction with other practices. The Planning Game – Support from other XP Practices In this section, we will see the weaknesses of the Planning Game are and how the other XP practices support it. The Planning Game – Disadvantages The disadvantages of the Planning Game are that you cannot possibly start development with only a rough plan and you cannot constantly update the plan as it would take too long and upset the customers. The Planning Game with other XP practices The other XP practices support the planning game in the following way − In planning game, the customer is also involved in updating the plan, based on the estimates provided by the developers. You make short releases so that any mistake in the plan would have at the most a few weeks or months of impact. Your customer sits with the team, so they could spot potential changes and opportunities for improvement quickly (on-line customer). Continuous testing helps the developers and the customer to decide what is required immediately. Thus, you can start development with a simple plan, and continually refine it as you go along. Short Releases – Support from other XP Practices Short Releases – Disadvantages You cannot possibly go into production after a few months. You certainly cannot make new releases of the system on cycles ranging from daily to every couple of months. This is because you take time to absorb new requirements, changes into the current code. Short Releases with other XP practices. The other XP practices support Short Releases in the following way − The planning game helps you work on the most valuable stories, so even a small system will have business value. Continuous integration makes the cost of packaging a release minimal. Testing reduces the defect rate enough so that a lengthy test cycle is not required before a release. You can make a simple design, sufficient for this release, not for all time. Thus, you can make Short Releases, soon after the development begins. Metaphor – Support from other XP Practices You cannot possibly start development with just a metaphor. It may not have enough details there, and you may be wrong. Metaphor with other XP practices The other XP practices support Metaphor in the following way − With pair programming, you will have quick concrete feedback from the implemented code and tests about whether the metaphor is working fine. Your on-site customer is comfortable talking about the system in terms of the metaphor. Continuous refactoring allows you to refine your understanding of what the metaphor means in implementation. Simple design helps you to have a mapping with the metaphor. Thus, you can start development with just a metaphor. Simple Design – Support from other XP Practices Simple Design − Disadvantages You cannot possibly have just enough design for today”s code and your design may not continue to evolve the system. Simple Design with other XP practices. The other XP practices support Simple Design in the following way − Refactoring allows you to make changes. With an overall metaphor, you are sure that the future design changes would tend to follow a convergent path. Pair programming helps you to be confident that you are making a simple design that works. 40-hour week helps you to be focused on the right design. Continuous unit testing and customer testing ensures that your simple design is on the track. Thus, you can do the best possible design for today, without speculation. Testing – Support from other XP Practices Testing – Disadvantages You may think that − You cannot possibly write all those tests. It can take too much time to write the tests. Developers will not write the tests. Testing with other XP practices The other XP practices support Testing in the following way − Simple design makes writing tests easy. Refactoring allows you to decide on what tests are necessary. With pair programming, even if you cannot think of another test, your partner can. You can allow your partner to run the tests handing over the keyboard and you feel confident when you see the tests all running. Collective ownership ensures that a developer with required skills is working on any complex part for coding and testing. Continuous integration and immediately running the tests for every set of changes made by a pair ensures − That the new code works if 100% tests pass, or That if any test fails, it is that pair’s code that is failing the system so that the changes can be immediately reversed and the pair can start afresh with coding with the clarity on the feature they are implementing. Short releases ensure that a working system is available for the customer to run the tests and give feedback. On-line customer will have time to run all the tests and provide feedback immediately on the working system. Planning game ensures to take the feedback from the customer after testing to plan for the next release. Thus, the developers and the customers will write tests. Further, the tests are automated to ensure the working of the rest of the Extreme Programming. Refactoring – Support from other XP Practices Refactoring – Disadvantages You cannot possibly refactor the design of the system all the time. It would − Take too long. Be too hard to control, and Most likely break the system. Refactoring with other XP practices The other XP practices support Refactoring in the following way − With

Extreme Programming – Additional Features ”; Previous Next In this chapter, we will learn about some additional features of Extreme Programming. Feedback Loops The charm of Extreme Programming is continuous feedback that keeps everyone focused and development continues in the right direction without any delays. In Extreme Programming, feedback is accomplished at different levels, to the required and sufficient detail. This is done continuously and constantly across the iterations and releases as well. The following table illustrates the feedback events and the feedback duration. Feedback Event Feedback Duration Pair Programming Seconds Unit Testing Minutes Clarifications among Team and with the Customer Hours Progress In a Day Acceptance Testing Days Iteration Planning Weeks Release Planning Months Project Management In Extreme Programming, Project Management is not given emphasis and the manager role performs the minimal and the most essential management activities. However, these activities embed the project management requirements. Release Planning Scope is defined by user stories in story cards. Estimates are story estimates, that can be in story points. Delivery milestones are captured by release plans. Release is divided into iterations. Iteration Planning Stories are blown into tasks in task cards. Estimates are task estimates. Allocation of tasks done by balancing load factor across the team. Task acceptance is by team commitment and accountability. Tracking Velocity in terms of story points from actual time for implementation done at project level. Productivity in terms of task estimates from actual time for implementation done at developer level. Defect tracking Extreme Programming – Industry Experiences From the Extreme Programming projects executed across the industry, there are certain learnings useful for the teams. Learnings from the XP Practices In the following sections, you get an understanding of these learnings. Simple Design − A simple design is efficient, easy to build and maintain. Metaphor − The main intention of using metaphor is to use domain specific names throughout development and that enables the customer also to actively participate in the development. Collective Ownership − Each one is proud of their good code. By working together, each one is proud of everyone”s code. Planning − In case the team completes many user stories in an iteration, make the iterations smaller. Have the team consensus to alter a plan. Scaling Extreme Programming Initially, Extreme Programming was perceived to be effective in smaller teams, with a team size up to 12-16 developers. Later, it was observed that it is possible to scale Extreme Programming up to teams of 40-50. However, it is recommended to do the scaling by building recursive teams. Build a small team first, grow the team incrementally, using the first team to seed recursive teams. Documentation Extreme Programming is not against any documentation. It encourages documenting what is required, when it is required and only to the required and sufficient Detail. This may differ from project to project and it is for the project to decide on the extent of documentation. However, skipping documentation is not allowed by the Extreme Programming practices. Advantages of applying XP Extreme Programming is found to be advantageous when applied in − Environments that are highly uncertain Internal projects Joint ventures Disdvantages of applying XP Extreme Programming is found to be disadvantageous when − The environments are large and complex. The requirements are well understood. The customer is at a distance or unavailable. Misconceptions of XP There are some misconceptions about Extreme Programming. The following table gives the clarifications of the misconceptions that exist. Misconception Clarification No written documentation Minimal and sufficient documentation needs to be there. However, there are no formal standards for how much or what kind of documents are needed. No design Minimal explicit and up-front design needs to be there that evolves as the development progresses. Extreme Programming is just pair programming and easy Pair Programming is just one of the Extreme Programming practices. It requires great discipline and consistency that is achieved in conjunction with the other Extreme Programming practices. Extreme Programming is the one, true way to build software Extreme Programming is effective only in certain type of projects. Print Page Previous Next Advertisements ”;