More on this book
Kindle Notes & Highlights
by
James Shore
Read between
May 9, 2016 - September 14, 2018
Figure 1-1. Types of success
Agile methods also set expectations early in the project, so if your project won’t be an organizational success, you’ll find out early enough to cancel it before your organization has spent much money.
there’s more to programming than writing code,
The real deployment work happens when we update our deployment scripts,
self-organization is a hallmark of agile teams.
If the customers won’t move to the team, move the team to the customers.
software development is very expensive. If the software isn’t valuable enough to warrant the time of a good product manager — a product manager who could mean the difference between success and failure — perhaps it isn’t worth developing in the first place.
include at least one senior programmer, designer, or architect who has significant design experience and is comfortable working in a hands-on coding environment.
If the customers’ job is to maximize the value of the product, then the programmers’ job is to minimize its cost.
One of the most important things the coaches can do is to help the team interact with the rest of the organization.
Take extra care to identify your executive sponsor
Fractional assignment is dreadfully counterproductive.
Fragmented knowledge workers may look busy, but a lot of their busyness is just thrashing”
typically represent one or two days of work.
What should the nonconstraints do in their spare time? Help eliminate the constraint.
if you present them with a constrained world, they’ll look at constraints we take for granted, consider them to be unessential, and create a world without them.
Patience with lowered productivity while the team learns
Teams with fewer than four programmers are less likely to have the intellectual diversity they need. They’ll also have trouble using pair programming, an important support mechanism in XP.
If your team is larger than seven programmers...
If your team is smaller than four programmers...
Recommendation #2: Strong Design Skills
You can recognize a leader by her influence — regardless of her title, people turn to a leader for advice.
The best coaches are natural leaders
Other than working more closely together, the biggest changes will be to planning.
Dedicated design phases often lead to complex designs, so minimize the amount of time you spend on upfront design if you can.
How can you tell if you’re doing it properly? The ultimate measure is the success of your project,
Sometimes the biggest gains in productivity come from stopping to think about what you’re doing, why you’re doing it, and whether it’s a good idea. The best developers don’t just find something that works and use it; they also question why it works, try to understand it, and then improve it.
XP doesn’t require experts. It does require a habit of mindfulness.
If you’re an experienced agile practitioner, review Chapter 11 and use this étude to consider how you can go beyond the practices in this book.
Pair Programming
para probar en SOU
As you pair, switch roles frequently — at least every half hour, and possibly every few minutes. If you’re navigating and find yourself telling the driver which keys to press, ask for the keyboard. If you’re driving and need a break, pass the keyboard off to your navigator.
Give everyone a chance to be an expert.
Isn’t it wasteful to have two people do the work of one? In pair programming, two people aren’t really doing the work of one. Although only one keyboard is in use, there’s more to programming than that. As Ward Cunningham said, “If you don’t think carefully, you might think that programming is just typing statements in a programming language.”[14] In pair programming, one person is programming and the other is thinking ahead, anticipating problems, and strategizing.
If you’re bored while pairing, consider how you can make your design less repetitive.
Peer Reviews in Software: A Practical Guide
I enjoy programming. I enjoy solving problems, writing good code, watching tests pass, and especially removing code while refactoring.
Yet put me on a team with unclear goals, little collective responsibility, and infighting, and I’ll wake up dreading going into work.
Isn’t it much more satisfying to leave on time at the end of the day, knowing that you accomplished something solid and useful?
Go home on time.
It’s particularly useful when you’re not at your best: pairing with someone who’s alert can help you stay focused.
When I notice a pair of programmers whispering to each other, I ask how long it’s been since their last passing test. I often get a sheepish reply, and that’s when I remind them to take a break.
If you’re practicing test-driven development and continuous integration, your code should be ready to check in every few minutes.
If you dread going to work in the morning, you aren’t energized.
Sprinting to the finish line is one thing; sprinting for miles is another.
The choice between quality of life and career advancement is a personal one that only you and your family can make.
“In our experience, the one common characteristic among death-march projects is low expected value. They are projects aimed at putting out products of monumental insignificance. The only real justification for the death march is that with value so minuscule, doing the project at normal cost would clearly result in costs that are greater than benefits... if the project is so essential, why can’t the company spend the time and money to do it properly?”
A healthy project is energized. There’s a buzz in the air — not tension, but activity.
You can never have too many whiteboards.
Whiteboard design sessions labelled “Do Not Erase”
It’s possible that the team is passively-aggressively ignoring the chart rather than telling you that they don’t want it.
