[1/2] Extreme programming: setting the process (Extreme Programming Applied: Playing to Win) (Category Engineering)

Today I decided to remember a book about extreme programming. (XP) from the start of my career (She appeared in Russian. 20 years ago, and in English a couple of years earlier.). In this book, the authors analyze what XP is and, most importantly, how to apply it in practice. Most XP practices have become the de facto standard and don’t even need to be sold now, as they are considered to be some baseline for engineering practices. But in the early 2000s, XP lost the marketing war to other Agile approaches like Scrum and its variations - engineers didn't sing as beautifully as those who like to talk about processes and rituals, so scrum was much more famous than XP:)

Let’s move on to the book itself.

Introduction: Playing to Win The authors say that software is a volatile entity and we need to be ready for modifications of our system, and for this we need to take into account the cost of changes. And the old approaches. (waterfall and heavy planning, design, etc.) The cost of changes in the process of creating the system increased exponentially, so the changes were avoided. But in XP, everything is done to smooth out the cost of change. This is what the authors proposed to use as the main argument. XP in summary Here the authors talk about the key values of XP and the basic principles that are revealed further in the pages of the book and explain how to apply them in practice, as well as sell them to colleagues to implement changes. The core values of XP are

1. Communication (Communication) Working in the style of XP is impossible to avoid communication
2. Simple. (Simplicity) XP always offers to solve the problem in the easiest way.
3. Feedback (Feedback) Frequent and high-quality feedback will keep the product/project on track.
4. Courage (Courage) It takes courage to move at maximum speed. Plus, you have to win. sunk cost fallacy

Next, the authors refer to the main practices that 12 But later in the book, they divide them into six starting ones and the rest that need to be implemented in the second place, so I'll start with the first one. 6 1) Planning game Here the authors talk about the planning and evaluation of labor costs. In fact, the following frequency of release planning is proposed. (quaterly) -> Iteration planning (2 weeks) -> Standup meetings (everyday). The authors note the importance of assessing labor costs in order to discuss with the customer at the level of priorities of tasks and the cost of their implementation. This is similar to the current practice. 2) Frequent releases (Small releases) The frequency of releases and their small size fit very well into lean practices and allow incremental gain of value. And from the point of view of engineering, this allows you to maintain the desired pace and not take too much risk during each release - I recommend reading the book "Accelerate" in more detail. (see mine posture) about DORA metrics. It's a de facto standard. 3) Testing In fact, the authors are talking about TDD They explain why we need tests in complex systems. That's the de facto standard. 4) Pair programming - here we are talking about working in pairs at one computer while implementing one task. This practice has not become generally accepted, but instead it is customary to make a design review before the task is implemented, as well as code review after its implementation. 5) Refactoring Here the authors recall Martin Fowler and his classic book Refactoring, and the approach itself is now the de facto standard in the industry. 6) Continuous integration Authors sell the importance of integrating the project and running tests as often as possible, such as several times a day. Since then, tuning around CI has improved a lot and we collect applications and run tests on each commit. Plus, it's customary to use TBD (trunk based development)It brings the idea of continuous integration to its logical conclusion.

Continuation in next post

#Management #Software #Engineering #SoftwareDevelopment #Processes #Devops #SRE