Extreme programming pocket guide

Metadata

• Author: Chromatic
• Full Title:: Extreme Programming Pocket Guide
• Category:: 📚Books
• Finished date:: 2023-02-02

Highlights

a little bit of planning, a little bit of coding, and a little bit of testing let you decide if you’re right or wrong while it’s still cheap to change your mind. You still need some idea where you’re going, but you don’t have to commit to an exact itinerary. (Location 40)

Kent Beck introduced XP in Extreme Programming Explained (Addison-Wesley) (Location 43)

XP is ideal for a small group of developers within a company, writing software for that company. (Location 57)

makes a different claim: it’s possible to keep the cost of changing software from rising dramatically with time. (Location 116)

Increasing quality can decrease pressure on time or resources. (Location 167)

XP suggests a different strategy. Agree as a team — including the customer — on an acceptable level of quality. Agree to consider that time and resources are fixed. The only remaining question is that of scope. What will be delivered? When will it be delivered? The customer will set priorities for individual features. You will work on them in turn. The software will always be kept in a releasable state. (Location 175)

XP recommends adjusting scope regularly, even daily. (Location 178)

predictably. (Location 181)

The customer sees the team’s progress every day and can adjust the work schedule as needed. The customer works with developers to produce tests to verify that a feature is present and works as expected. (Location 200)

A five-minute, face-to-face conversation peppered with body language, gestures, and whiteboard drawings communicates more than an email exchange or a conference call can. (Location 202)

• Note: Socorro… No creo nada en esto

Though planning ahead can avoid some mistakes, it’s only through actual work that you can understand your real obstacles. (Location 214)

• Note: Pero puedes por ejemplo tener feedback mas rapido con docs o mocks…

work at your normal pace. The amount of work you can do is constant (Location 245)

To do this, you must be able to estimate accurately the amount of work you can actually do. The customer must be able to identify the most important work that can be done. (Location 249)

• Note: Pero el software es un proceso de discovery… No entiendo

Refine your estimates by comparing them to the actual time spent on the tasks. (Location 259)

XP ensures that the cost of change remains constant over time. In other words, it will cost about as much to add a feature next year as it would to add that feature today. If this is true, you can defer features until they’re really necessary, without worrying about the cost of waiting. (Location 265)

A group of average developers who are dedicated and committed to producing good software can become a highly productive team. (Location 280)

XP’s practices form a network of checks and balances. (Location 281)

Estimates are soon explored, leading to better accuracy. (Location 285)

• Note: ???

By agreeing to adjust the scope dial while leaving time alone, XP avoids overwork (Location 288)

assumes that the entire team — managers, developers, and customers — has the freedom to experiment. (Location 292)

“What can we stop doing and still succeed?” There is no reward without risk. (Location 293)

Picking and choosing a few practices without appreciating how they support each other can lead to dramatic failures (Location 308)

This focus worries many people, who fear that XP is the domain of cowboy coders who jump headfirst into hacking without planning. This is not the case. XP uses working code to validate and to evaluate its plans. (Location 325)

Flexibility is the goal. Simplicity is the means to that end. Simple designs are easier to understand and to explain. Simple code is easier to test, maintain, and change. (Location 333)

• Note: Id say they are opposites

XP spends comparatively little time creating designs before writing code, preferring to let the design emerge as the system grows. (Location 335)

• Note: Let the design emerge… Thats not design. It reminds me of the “default arch = no arch” of the software arch book

It’s a gamble that the customer will ask for a feature exactly as you imagine it now. (Location 340)

The desire to add them comes from the fear that future changes will be difficult and expensive. (Location 343)

Collective code ownership, because of its simplicity (Location 352)

After finishing a task, take a few moments to do a little house cleaning. (Location 366)

XP’s approach of letting design emerge as the project grows could produce unruly, brittle code if left unchecked. (Location 372)

After you complete a task and verify that it works, clean up a couple of the design issues you noticed. (Location 375)

• Note: Y luego que ocurre con el efecto este de sentirse attached a los artefactos?

Don’t spend all of your time looking for the best possible design, though. Make it work, make it simpler, and move on. Balance refactoring with adding features for the customer. (Location 387)

Develop a Common Vocabulary (Location 440)

The test must fail to validate that the test can fail. (Location 501)

initial shock of test-driven development and to continue testing even when it seems difficult. (Location 542)

Pairs generally work together for just one task, perhaps an entire afternoon, (Location 547)

The person with the keyboard — the driver — focuses on the details of the task. He thinks tactically. The other person — the navigator — keeps the entire project in mind, ensuring that the task fits into the project as a whole and keeping track of the team guidelines. (Location 550)

produces code through conversation. (Location 554)

Having a partner present reduces the temptation to skip testing, refactoring, or simplifying. (Location 557)

• Note: Hawthrow effect again

Pairing is highly informal. (Location 562)

Pairing can be uncomfortable at first, but it supports most of the other practices. For example, it decreases feelings of individual code ownership (Location 566)

a rule, peers tend to mentor each other. (Location 573)

When you see the opportunity to refactor, take it, even if it means changing code beyond the current task. (Location 605)

the end of a day, either integrate your current work or discard it. (Location 632)

Throwing out work can seem scary, but keeping tasks small and manageable (see Business Practice 2: Play the Planning Game) reduces the risks of starting over too often. (Location 635)

customer tests should be automated as soon as possible. (Location 679)

The customer provides a business perspective to evaluate the project. She has the responsibility for adjusting the project’s scope. When you discover that you’ve committed to too few or too many stories (Location 681)

Some teams elect a customer proxy to act as an authoritative, (Location 688)

• Note: Can a product manager be that voice?

Tasks should be sufficiently detailed that you can start the test-code-refactor cycle to gauge when the task is finished. (Location 720)

• Note: Who breaks stories into tasks and how?

Working at a sustainable pace will keep your productivity high. A tired programmer is tempted to take shortcuts (Location 785)

The iteration planning meeting brings the customer and developers together to reassess the project and to schedule the upcoming iteration. This meeting is customer driven. The customer sets priorities for the developers, choosing features to be implemented and delivered during the iteration. (Location 810)

All stories should represent a few days worth of work at most. (Location 819)

Ask the customer to elaborate or to split one story into smaller stories. (Location 820)

These estimates are simply educated guesses (Location 829)

Story estimates help the customer set iteration priorities. (Location 835)

Choosing high-risk stories up front leaves easier stories for later, when there may be less time, fewer resources, or less need. (Location 839)

Yesterday’s Weather (Location 844)

Estimates aren’t so large that they’re just wild guesses. (Location 853)

XP has no separate design stage, preferring to mix design with the other practices. Writing task cards from stories requires some high-level design work. (Location 881)

• Note: Pero de nuevo, si requiere diseño pero no hay fase de diseño… Entonces qué?

Each developer has his own velocity, measured in the same way as the team velocity. (Location 887)

Tackle the most important and the riskiest tasks at the start of the iteration. (Location 890)

• Note: Incentivo para no hacerlo

The Tracker (see The Tracker in Part V) keeps tabs on each developer’s progress. (Location 903)

• Note: Again… Incentives for low hanging fruit.

XP preaches “traveling light,” preferring conversations, (Location 930)

Start with the most important stories immediately instead of trying to identify all possible stories (Location 958)

Developers write tasks during the iteration planning meeting (Location 971)

Given a story card, developers break it into tasks, sketching out its implementation details. (Location 971)

too hard to implement, experiment with a spike solution. In a spike solution, one or two developers write a little bit of code to explore the problem. There’s no need to be formal or clean — you’ll throw away the code. (Location 974)

pair programming and constant communication. (Location 983)

XP recommends working in a single, wide-open room called the bullpen or war room. (Location 984)

• Note: Pero bueno… Si hay hasta datos de que esto no funciona…

Overheard conversations often become informal brainstorming sessions, where everyone has the chance to share a bit of expertise. (Location 990)

• Note: …

An XP customer relies on several pieces of information. He must understand the business problem to be solved even as it changes over time. (Location 1030)

This is best done in person, as informally and comfortably as possible. Honesty is vital on the part of developers, and the tracker should be nonjudgmental. (Location 1098)

• Note: JAaajaaaj… HOW

It’s okay to settle for simple enough, especially since you will refactor later. (Location 1132)

XP practices continual design, letting you make design decisions at any time. With every new story, you’ll see the design more clearly. With every implemented task, you’ll have more fuel for refactoring. (Location 1146)

• Note: At the expense of being heavily invested in what you did

XP produces systems that can be changed easily not by being complex enough to handle every possibility, but by being simple enough to be changed. (Location 1149)

Trust and honesty will dispel many fears that would otherwise slow or sink the project. (Location 1225)

An effective test suite gives you the confidence to make bigger changes. (Location 1262)

Developers of extraordinary discipline may write elegant, well-tested code all the time. The rest of us sometimes need positive peer pressure and reinforcement. (Location 1305)

Tweak XP to your advantage. (Location 1315)