Екстремальне програмування

XP відрізняється від інших гнучких методологій тим, що застосовується виключно в області IT технологый, на відміну. від scrum, kanban або lean. Тому цю концепцію буде простіше зрозуміти тим хто з IT, бо описані специфічні для розробки ПО кейси. Та й написано жаргоном, що спрощує розуміння. Для мене це влеикий плюс.

не плутати з книгою "Test Driven Development" (на російській "Экстремальное программирование. Разработка через тестирование") та "Extreme Programming Explained" (на рос:

Экстремальное программирование) https://worksection.com/ua/blog/extreme-programming.html

Я вже десь 3 роки програмував до того як наткнувся на цю книгу. І вона відкрили мені очі. Я самоучка і знання "основ основ" — не моя сильна сторна. Вчився на помилках, але подумав і порадах більш досвідчених. ПОчав помічати що часто з'являється безлад у кода, а це шанс отримати "баг", постало питання "а як же правильно?". Так як я робив вже не хочу, бо бачу що ні до чого гарного , а як потрібно — не знав. То почав шукати літературу, і нактнувся на цю

І мені пощастило. Книга може здатися застрарілою, дивлячись на те що навколо всі говорять про скрам і аджайл

As we mentioned above, XP is part of the agile methodology. It shares the main agile principles, i.e., frequent releases, short development cycles, constant communication with the customer, cross-functional teams, and so on. For this reason, XP is often confused with other popular Agile such as Scrum, Kanban, and Lean. Check our detailed whitepaper to get more in-depth information or the infographics for a quick summary of the main agile methods. Here, we’ll briefly compare them and see what the main differences are.

But before we dive in, it’s important to note that XP is not really a project management framework, even though a lot of its practices overlap with those from the project management domain. So, its primary focus is on the technical aspects of development and the implementation of specific practices rather than the management and organizational sides.

Values of extreme programming

XP has simple rules that are based on 5 values to guide the teamwork:

1. Communication. Everyone on a team works jointly at every stage of the project.
2. Simplicity. Developers strive to write simple code bringing more value to a product, as it saves time and effort.
3. Feedback. Team members deliver software frequently, get feedback about it, and improve a product according to the new requirements.
4. Respect. Every person assigned to a project contributes to a common goal.
5. Courage. Programmers objectively evaluate their own results without making excuses and are always ready to respond to changes.

Principles of extreme programming

Most researchers denote 5 XP principles as:

1. Rapid feedback. Team members understand the given feedback and react to it right away.
2. Assumed simplicity. Developers need to focus on the job that is important at the moment and follow YAGNI (You Ain’t Gonna Need It) and DRY (Don’t Repeat Yourself) principles.
3. Incremental changes. Small changes made to a product step by step work better than big ones made at once.
4. Embracing change. If a client thinks a product needs to be changed, programmers should support this decision and plan how to implement new requirements.
5. Quality work. A team that works well, makes a valuable product and feels proud of it.

Kent Beck is one of the most influential person in our industry. Patterns, refactoring, TDD, XP. Our industry would never be like what we know it without him. His pragmatic view is awesome, his experience is tremendous.

Even that the book seemed just OK, I still will recommend it to every modern developer: this was super interesting journey in the past, to see how agile was born and how it's different from what we see and use today.

However, again as a novice programmer, I believe I could not fully make sense of a lot of the practices, or the rationale behind the practices, for I find it hard to relate to any practical experience in a software team. Probably best right before or during practice as an software engineer that adopts XP.

Long Forgotten Values

Did you know XP also describes 5 values and 14 principles? In Kent Beck’s seminal book Extreme Programming Explained – Embrace Change, all of these values and principles are described in detail before even mentioning a single technical practice! Beck makes the point that values are important because, without them, the XP practices are performed for their own sake while lacking purpose and direction.

While values are not necessarily actionable like practices, they provide overall guidelines for our behaviors and actions. Values describe the fundamental beliefs within our team and extend to how we deal with other teams and organizations.

Let’s focus on the 5 Extreme Programming values: communication, simplicity, feedback, courage, and respect. Unfortunately, these values have been largely forgotten by the development community as we pursue excellence in our technical practices. It is now time to reclaim the understanding and overall context these values provide. By paying attention to these values, your team can achieve higher levels of agility and productivity.

1. Communication

Communication is key to any high-performing Agile team. Team awareness and problem resolution are heightened when each team member communicates well. Communication extends well beyond our team into the overall organization and our communities of practice.

I recall a time early in my career where my team and I were surprised to learn that a different team was building the exact same functionality we were building. How many problems and wasted money are caused by this dreaded “lack of communication”? My gut tells me most of them. Beck states “… motion without communication is not progress.” If we are progressing well, are we also communicating well?

As Agilists, we need to err on the side of over-communication. We need to create a culture of high communication and honest transparency about our successes, failures, and plans.

2. Simplicity

I once had a boss whose favorite saying was “simple is hard.” In my experience, this is so true. Not everyone can do it. As humans, we have a natural proclivity towards over-engineering (guilty as charged) and adding complexity (simply because it can be done). Beck calls simplicity “the most intensely intellectual of the XP values.”

YAGNI: You Aren’t Gonna Need It.

I once had a VP of Product Management for a trip planning system who insisted that our team spend valuable time structuring our software so that it would be “easy to add in trip plan variations–just in case”. Despite my cries of “YAGNI”, he persisted and we added this capability at the expense of other more basic functionality. We also slipped the launch date by 2 months. Guess what? Seven years later and still no new types of trip plans needed.

As Agilists, we need to resist the temptation to structure our work products for the future. There, I said it. Focus on today only. The future will take care of itself. While there is always a healthy balance between simple and well-structured, we should bias our thinking towards the elimination of wasteful complexity. YAGNI is a good thing – embrace it!

3. Feedback

For Agile teams, feedback is at the heart of welcoming change and inspecting and adapting. It can come in many different forms such as end-user reaction, stakeholder demo comments, recommendations from other teams, QA opinion, and improvement ideas generated in a Sprint Retrospective.

The tighter the feedback loop the better. This allows us to make agreed-upon changes in shorter amounts of time so that the potential benefit derived over time from the change is maximized. In an environment of innovation and experimentation, feedback is how we determine next course of action–whether to persevere, pivot, or pause.

As Agilists, we must continually ask ourselves “How can we get more feedback?”. Reacting to feedback helps to drive down risk, removes assumptions, and most importantly helps ensure that we are truly building the right product.

4. Courage

Have you ever been in a situation where team members were scared to speak their minds? I have and I’m not proud of it. The result – better ideas not being shared for fear of ridicule or polite dismissal. Forget “wisdom of the crowds”. If team members are not courageous, you will have “wisdom of the anointed few”. This will hurt your team’s’ ability to make the right decisions and also crush the spirit of the non-anointed ones. Who wants to work in this environment? Lack of courage is a hallmark of low-performing teams.

Courage supports all other XP values. Be courageous in speaking the truth, pleasant or unpleasant, as this will increase trustful communication. Discard failing solutions and seek new ones as this will increase simplicity. Instead of saying “we have no access to our end users”, demonstrate the courage to figure out a way to get their feedback.

As agilists, it is our job to help cultivate the safe environment where every team member feels like they can share their thoughts in a family-type setting. I always like to say “we can disagree, but in the end – just like family – we will continue to love and support each other.”

5. Respect

Beck’s second edition book adds Respect as a first-order XP value. Respect lies below the surface of all other XP values. It is an innate belief that every single person is important in their own way. I cannot say it any better than Beck, “Every person whose life is touched by software development has equal value as a human being.”

As Agilists, we need to call out situations where lack of respect occurs. Our underlying assumption should be that everyone is trying their best.

Wrap

Think about your Agile team and how it stacks up against the Extreme Programming values above. Ask questions such as:

• Do we communicate honestly at all times, or do we tend to hide non-flattering work?
• What complicates our work (processes, code areas, etc.), and how can we simplify?
• Are there opportunities for feedback that we are missing?
• Do we truly allow for courage, or are team members overly careful in speaking their mind?
• Do we always exhibit respect for each other, or do we sometimes make fun of people behind their backs?

As a starting point, consider adopting the XP values. Adjust as you see fit. Have open discussions about the meaning of each value and how the team can improve within each. For extra credit, try mapping your current technical practices back to a specific value.

Values put our principles and practices in context. Don’t forget this important step in your Agile journey!

amazon | epub (ru) | pdf (eng) |