- 1 What is Extreme Programming Practice?
- 1.1 Core XP Practices
- 1.1.1 Fine Scale Feedback
- 1.1.2 Continuous process improvement
- 1.1.3 The reason why XP is “extreme”
- 1.1.4 XP Roles
- 1.2 Share and Enjoy !
What is Extreme Programming Practice?
Extreme programming is another kind of Agile strategy. It is utilized alongside the scrum structure to make a mix of both engineering and the management rehearses in Agile Projects. The XP as a term conceptualized from the execution of conventional programming designing practices at the extraordinary (extreme) level.
Extreme Programming is known for its specialized technical practices that cause designers to construct excellent programming all the more productively.
For small – to – medium-sized teams developing software with vague or rapidly changing requirements coding is the key activity throughout a software project. So Extreme programming recommends shorter sprints(1-4 weeks) inclusive of having project artifacts (like- story cards, code, Unit testing etc).
The activities of XP are
- Communication among teammates is done with code.
- Life cycle and behavior of complex objects defined in test cases – again in code.
XP consists of various best practices like
- test-driven development.
- code review
- Pair programming
- Refactoring etc
XP (Extreme Programming) component
XP consists of four basic components. They are:
- Fine-scale feedback.
- Continuous process improvement
- Shared Understanding of the project or product
- Programmer welfare
Core XP Practices
Fine Scale Feedback
Fine Scale feedback is divided into –
- Planning Game
- Pair Programming
- Test-driven Development
- Whole Team
Planning game determines the scope of the next release by combining business priorities and technical estimates. It is the main planning process for Extreme Programming. It suggests that the work or tasks are planned incrementally well ahead.
Planning Game can be further divided into two parts:
- Release Planning
- Iteration or Sprint Planning
Release Planning is an arranged and planned meeting to shortlist necessities in the form of requirements to be incorporated into the release planned and course of events of each release.
Iteration or Sprint Planning
Sprint planning is the planning meeting by the group to settle on the assignments (popularly known as tasks) and exercises(popularly known as different activities) to achieve necessities (requirements)got ready for the cycle(iteration).
|Release Planning||User story creation|
|Sprint Planning||Task card creation|
All production code is written with two programmers at one machine. Pair programming is where coding is done trailed by a survey or review. In an extraordinary case, coding and review can occur in parallel.
It prompts that two coders should code all the while. While one will code concentrating on the code and program level subtleties, the other coder will ceaselessly survey(review) the code remembering the master plan.
The set of coders are not fixed and continually changing with the goal that everyone can mindful about the whole framework, project, product, system.
In Test-Driven Development, designers and developers compose the automated test cases before real application code. Automated test cases(unit) ought to definitely fizzle(fail) for the first time of execution.
On the off chance that it doesn’t fail, it demonstrates the component as of now exists or there are a few issues with the Automated test case.
At that point, the real application code is composed and the Automated suit is run once more. In light of the outcome, the genuine application code is altered or refactored further. The units are normally kept littler and the code is refactored as and when required.
In extreme programming, the entire group works overall as a unit and as a whole. Group members are urged to be more summed up or generalized than particular or specialized.
Customer is defined as a user of the team and available full – time to answer questions. Customers are made available to respond to the queries during the whole XP process.
Continuous process improvement
Continuous process improvement can be divided into –
- Continuous Integration
- Small release
integrate and build the system many times a day – – every time a task is completed. In Continuous Integration, the code base is incorporated consistently from the beginning of the development process. It is an automatic procedure where builds are made from the source code repository.
Nonstop Continuous Integration helps in recognizing integration issues much ahead in the development cycle and thus lessens a great part of the system cost.
There are several tools available to encourage the CI procedure by tolerating the checked-in most recent code, prepare to build, build duration and build issues.
programmers continuously restructure the system without changing its behavior to remove duplication and simplify. Refactoring improves the current design, current plan, and code without influencing the usefulness.
Agile way of developing gets improved from regular and frequent release over a range of time while group presents structure flaw, duplicate code or different issues. Refactoring improves the quality of the code.
Small releases put a simple system into production, then release new versions in a very short cycle. Continuous and small releases is a typical and compelling routine with regards to XP.
The general programming of whole software doesn’t occur in one single go. littler releases are arranged which gives the client the certainty of the general advancement and progress towards the overall goal. It additionally encourages the client to give recommendations to any progressions and meets the general objective of the project or product.
Shared understanding can be further divided into
- Coding standard
- Collective ownership
- Simple design
programmers write all code in accordance with rules emphasizing communication through the code. So as to stay away from imperfections or decrease defects in coding, conventions comprising of style and format for the source code are settled upon by the group. Guidelines should be according to the standard characterized by language sellers as well as tweaked by the group.
Anyone can change any code anywhere in the system at any time. Since the group is cross-functional and the whole group works two by two(pair programming mode) which continue changing, all pieces of the code are known to everyone.
If there should be an occurrence of the defect, any software engineer is permitted to change the code. It might likewise present a mistake as a result of unanticipated conditions. To deal with such issues, there should be comprehensive very much characterized unit tests available.
The system is designed as simply as possible (extra complexity removed as soon as found). Extreme programming prescribes the basic and most ideal approach to actualize code. Refactoring likewise encourages this procedure of accomplishing the basic plan and simple design.
All development is guided by a simple shared story of how the whole system works. Metaphor representation is generally a naming convention, which makes every one of the partners(project stakeholders) comprehend what the usefulness is about in subtleties in details.
- 40 – hour week – work no more than 40 hours a week as a rule. So it provides a sustainable pace to meet the project deadline. Otherwise, this may create noise in repeatable, predictable and consistent delivery.
The reason why XP is “extreme”
Commonsense practices taken to extreme levels like-
- If code reviews are good, review code all the time (pair programming).
- If testing is good, everybody will test all the time.
- If simplicity is good, keep the system in the simplest design that supports its current functionality. (the simplest thing that works).
- If the design is good, everybody will design daily (refactoring).
- If architecture is important, everybody will work at defining and refining the architecture. (metaphor)
- If integration testing is important, build and integrate test several times a day.(continuous integration).
- If short iterations are good, make iterations really, really short (hours rather than weeks)
Extreme programming advocates the below roles-
Customer- Who needs the software?
Roles of a customer are given as:
- Create customer story/stories for each release.
- Create the priorities for the stories for each release.
- Alternation(addition,deletion,modification) of the userstory for each release.
Programmer- Who develop the Software?
Roles of a developer are given as:
- Estimate the effort details of the story given by the customer along with the whole development team.
- Build the user story to a workable software.
- The software should abide by the standards.
Coach – Who facilitate the developers?
Roles of a coach are given as:
- Mentor the team members.
- Do not directly involve in the project.
- Mentor XP processes.
- Help in issue resolution.
Tracker- Who checks the milestone of the deliverables?
Roles of a tracker are given as:
- Mentor the team towards the goal.
- Alert the stakeholders