XP overview
XP is a lightweight (agile), efficient, low-risk, flexible, predictable, scientific, and fun way to develop software. In previous development, many rules were hard to follow, many processes were complex and difficult to understand, and the documentation process on many projects was spiraling out of control. Attempts to come up with a more comprehensive and better package, or hope for more complex and powerful auxiliary development tools (CaseTools), often fail, and development specifications and processes become increasingly complex and difficult to implement. XP was born out of this situation as a clever, lightweight approach to software development that bypassed complex processes and documentation and developed around lightweight frameworks and ideas of limits.
Extreme programming here is more like a set of theoretical knowledge, guidance for developers, and even an ideological indicator to assess the quality or excellence of developers. While the following theory may seem boring, those who really want to learn something about Agile development need to read it. I personally feel that some of XP’s values, principles, and practices can be used to train new developers into a set of theoretical guidelines. Of course, such guidelines still need to be adapted to the situation, rather than mechanically applied.
The four values
communication
The XP methodology holds that collaboration is impossible without continuous, uninterrupted communication between team members, and from this perspective, communication through artifacts such as documents and reports is severely limited. So XP combines best practices such as programming to encourage verbal communication to solve problems and improve productivity.
simple
The XP methodology calls for taking a “good enough” approach to your work, which means keeping it as simple as possible and doing what is good enough today, regardless of new problems you may discover tomorrow. This may seem easy, but it’s really hard to do the job of keeping it simple. Because in traditional development methods, people are required to do some planning for the future, in order to leave some room for expansion of possible changes in the future.
feedback
Feedback is very important in the team, not only is a feedback between clients and project director, should also include the developer, do all relevant project realizing feedback, let people know the project schedule, each developer task progress and result to do everybody can timely know the situation of the project, the situation of the personnel. In this way, everyone can have a clear idea of the situation, so as to achieve mutual cooperation and effective communication.
The courage to
Want to know, XP is advocated embrace change, to actively responding to change would require the relevant personnel, especially the developers have the courage to face the rapid development, redevelopment, refactoring, etc., rapid development need courage to face more h3ug, some h3ug until the next version, development and dare to be abandoned before trying again, Don’t use something just because it’s already developed even if it doesn’t work. Refactoring is about changing the status quo and making the code look different.
Five principles
Quick feedback
Get feedback promptly and quickly, and put the knowledge learned into the system as soon as possible. This means that developers should quickly understand whether the current product meets customer needs through short feedback loops. We need to continue to deliver and tweak functionality, which complements the value of feedback. Quick feedback also applies to developers, team members, timely feedback, effective communication.
Simplicity hypothesis
Similarly, the simplicity hypothesis is a further complement to the value of simplicity. This principle requires developers to think of every problem as easy to solve, that is, to think only for this iteration, not for what may be needed in the future, and to trust in the ability to increase the complexity of the system as necessary in the future, which is a call to good work on today’s tasks. More on this later.
Gradually change
Just like driving a car with a steering wheel, don’t make a big change at once, it will make the control worse. The same is true in software development, where any problem should be solved with a series of small changes that make a difference.
Advocate changes
In software development, try to prepare for the next change as you solve the most important problem. Constant development, H3UG, we have to understand from the heart, H3UG is impossible to have a completely modified day, so we need to constantly change, do not stick to the original plan, dare not do any changes, to be ready for the changes may come at any time.
High quality work
In practice, it is common to see that many developers like to leave minor problems to be solved later. For example, the interface button has some uneven, because it does not affect the use of the first ignore; If one or two member functions are not used for the time being, do not write them first. This is a bad habit, and when it comes to code quality, it’s a bad habit. In THE XP methodology, the development principle of “small steps” is implemented, so the quality of work should never be compromised, usually using test-first coding to provide support.
High quality work that is a matter of people conscientiously, especially reflect the personal qualities of developer, and leave the problem often appear in the case of progress compared to catch, but PM or leader can’t compromise on this also, and generally this kind of problem will not consume a lot of development time, is a word or two code, sometimes it’s just too lazy to modify developers. Once compromised, the situation is bound to repeat itself. In addition to the implementation of the developer, the gradual change also needs to be coordinated by the PM, which is fine-tuned in the iteration to keep the change under control without causing too much impact.
13 best implementations
Plan the game
The main idea of a planning game is to create a quick outline plan and then refine the plan as the details of the project become clearer. The result of planning a game is a set of user stories and a summary plan for one or two subsequent iterations.
Write a story: the customer or PM talks about what the system should do and identifies requirements.
Estimate: The developer estimates each user story, starting with the highest priority. If you feel that some stories are too big to estimate, or that your estimate is more than 2 people/week, break them down into 2 or more stories.
Iteration cycle: The next step is to determine the iteration cycle, which can be determined according to the actual situation, but the best iteration cycle is 2-3 weeks.
Small releases
The XP methodology is guided by the philosophy of “continuous integration, small steps, fast steps”, which means that each release should be as small as possible, provided that each release is commercially worthwhile.
Because small releases result in more frequent integrations, more frequent intermediate results for the customer, and more frequent feedback, the customer is able to keep track of the project’s progress in real time and have more comments to plan for in the next iteration. To achieve higher customer satisfaction.
metaphor
Create unspoken words and examples to make communication more vivid and interesting. Metaphors can sometimes help people understand you faster and better than a bunch of arcane jargon.
Simple design
The simple design implementation is a misleading one, and one that has been criticized by many critics, because it takes a “good enough” approach, keeping it simple, as long as it is good enough today, without considering the new problems that will be discovered tomorrow. Why not consider tomorrow’s problems when it is embracing change? In traditional development, we need to think about what needs to be done later. Making our code highly extensible requires us to think about what needs to be done later. In this way, it seems that traditional development is closer to the idea of embracing change than XP is in this respect, but let’s take a closer look.
The simple design here is no duplication of code, as few classes and methods as possible, use Demeter’s rule and so on, just for today, don’t add a class or method that isn’t used now because it might be used later, rather than not doing extensibility, the two are not in conflict. Even if extensibility isn’t as good as it should be without much thought, XP advocates refactoring to take extensibility up a notch and make it more precise and appropriate for today’s needs. The traditional way of thinking about everything in place does not necessarily mean that scalability is perfect. After all, change is unpredictable, and the scalability considered now may not be needed in a few months, so it will have to be refactored.
A simple design is essentially scalable, like a blank sheet of paper. You can draw it any way you want, depending on how deep you feel about it.
Test-driven development
This is the conventional thinking difficult to understand the concept, test first, the program has not written, how to test? The resources example is very good:
Craftsman 1: first draw a horizontal line. When laying each brick, compare it with the horizontal line so that each brick is level.
Craftsman 2: first finish a row of bricks, and then pull up a horizontal line to see which bricks have problems, and make appropriate adjustments to the bricks that have problems.
Craftsman 1 represents the test-driven development approach, and of course to implement it effectively, we need to use some automated testing tools.
XP encourages programmers to be willing to write tests before they even write programs, so it offers a few reasons:
If you’ve kept your design simple, writing test code isn’t hard at all.
If you’re programming in pairs, then if you come up with a good test code, your partner will do it.
When all the tests pass, it’s nice to never have to worry about writing code that will “stab you in the back” later.
When your customers see that all the tests pass, they will feel more confident about the application than ever before.
Testing your code gives you more courage when you need to refactor, because all you need to test is a button.
It takes courage to try, and this is the core value of XP. If you don’t really use it and understand it, most people will think it’s crazy.
refactoring
Refactoring is a technique for making improvements to code without compromising functionality, and XP requires developers to have the courage to refactor code when it smells bad. The purpose of refactoring is to reduce the risk of change and make code optimization easier. Refactoring sometimes doesn’t require a lot of change, it’s nothing to sneeze at, and for XP it’s just a routine operation.
Pair programming
Simply two people sitting down to write a program, pair programming is also viewed with suspicion as too labor-intensive and frowned upon by self-respecting developers.
Of course pair programming also has the benefits of pair programming:
Make sure that all design decisions are not made by one person.
Any part of the system must be familiar to at least two people.
It’s almost impossible to have a test item or other task that both people miss
The dynamic nature of pair combination is a good way for enterprise knowledge management.
Code is always guaranteed to be reviewed.
And other best practices of XP methodology integration can make pair programming easier:
Coding standards can eliminate unnecessary differences.
Metaphors can help couples communicate better.
Simple design allows pairs to know more about what they are doing.
Pair programming still needs to be used according to the situation, and it is not always applicable if there is theoretical support. If it is not efficient to use pair programming, the Leader can audit the code instead.
Collective code ownership
Because the XP methodology encourages teams to pair program, it is believed that pair programming combinations should be matched dynamically, optimally based on different tasks and expertise. Since everyone is bound to encounter different code, ownership of code is no longer suitable for private ownership, as it would be a huge inconvenience to modify.
That is, every member of the team has the right to make improvements to the code, everyone owns all of the code, and everyone is responsible for all of the code. At the same time, XP stresses that whoever broke the code (that is, changed it and broke it) should fix it.
Because integration is a constant task on XP projects, when someone changes the code and causes integration problems, they are quickly discovered.
Since there is a test code for each class, whoever modifies the code needs to run the test code, so the probability of accidental damage is low.
Because every code change is thought through by a pair of programmers, the changes are usually good for the system.
Because everyone sticks to the same coding standards, the code is more readable, more modifiable, and less prone to frequent code changes due to naming, indentation, and other minor issues.
Continuous integration
Continuous integration means that the team integrates the code as many times as possible every day to ensure that the code acquired by the team is the recently unified code, so as to avoid conflicts caused by too many inconsistencies. The small releases mentioned above are more test releases, intermediate releases, for the customer or PM to review, to make sure that there are no errors in the feature development. We need to introduce code management tools, version control tools.
Sustainable rate
In a nutshell, it’s about avoiding overtime, keeping the schedule within a reasonable range, and keeping the developers in a healthy and productive state.
Make sure developers enjoy development, not suffer.
On-site customer
In order to ensure that the development results are close to the customer’s expectations, the XP methodology believes that the most important thing is to bring the customer to the development site. As mentioned in the planning game, in AN XP project, the customer should always be responsible for business decisions and the development team for technical decisions. Therefore, having customers on hand to define user stories and make business decisions is very important for XP projects. Especially after an intermediate version is released, customers need to experience it to ensure that the service functions are correct.
Coding standards
If your team already has a coding standard, use it directly and refine it along the way. If not, then you can code first, and then gradually summarize the coding rules in the process, while doing while forming. Of course, in addition to this literal specification, you can also use methods such as automatic formatting code tools. In fact, you just need to implement the other practices well and follow through, and coding standards will emerge easily.
Coordination is key
In the classic phrase “1+1>2” that best expresses XP’s point of view, Kent H3eck believes that the greatest value of the XP methodology lies in applying 12 best practices across a project, rather than individually. You can certainly use some of these practices, but that doesn’t mean you’re using the XP methodology. To be truly effective, the XP methodology must apply 12 practices in their entirety. You can even jump out of XP and combine it with other development methods, as long as they follow the Agile manifesto, there must be something in common and something that works better with each other.