More on this book
Kindle Notes & Highlights
by
James Shore
Read between
May 9, 2016 - September 14, 2018
(This translates into about two to six hours of estimated effort.)
Estimate the tasks in ideal hours. How long would the task take if you had perfect focus on the task, suffered no interruptions, and could have the help of anybody on the team? Estimate in person-hours as well: a task that takes a pair two hours is a four-hour estimate.
Dealing with Long Planning Sessions
Planificaciones largas
“With true timeboxing, the software is either accepted or thrown away at the timebox deadline. That makes it clear that the quality level must be acceptable at all times. The success of timeboxing depends on being able to meet tight schedules by limiting the product’s scope, not its quality”
Rather than doing the bare minimum necessary to keep your head above water, be generous in refactoring and cleaning up technical debt in existing code.
I notice technical debt most when I navigate during pair programming. When a problem slows us down and I find myself feeling irritated, that inspires me to suggest that we fix it.
A good rule of thumb is to spend 10 percent of the iteration on technical debt.
Research Time
Dedicated research time is an excellent way to encourage learning and add additional slack into your iterations.
Reducing the Need for Slack In my experience, there are two big sources of randomness on XP teams: customer unavailability and technical debt. Both lead to an unpredictable environment, make estimating difficult, and require you to have more slack in order to meet your commitments.
never incur technical debt in the name of slack.
Everything that stakeholders want the team to produce should have a story,
¿qué es una story?
Although stories are short, they still have two important characteristics:
Stories
Make your estimates in terms of ideal engineering days (often called story points), which are the number of days a task would take if you focused on it entirely and experienced no interruptions.
Remember that velocity is for predicting schedules, not judging productivity.
How long will the story take if you experience no interruptions, can pair with anyone else on the team, and everything goes well?
An expert is just a beginner with lots of experience.
To help address these issues during the estimation phase, ask leading questions. For example: Do we need a customer huddle on this issue? Should we mark this “??” and come back to it later? Should we make a spike for this story? Do we have enough information to estimate this story? Will that information change your estimate? We’ve spent five minutes on this story. Should we come back to it later?
Preguntas para estimar
How do we deal with technical dependencies in our stories?
Dependencias entre stories
Imagine you’ve given up the world of software to become a master chef. After years of study and practice, you’ve reached the top of your profession. One day you receive the ultimate invitation: to cook for 500 attendees at a $10,000-a-plate fundraiser. A limo takes you from your chartered plane to the venue, and you and your cooks walk confidently into a kitchen... only to stop in shock. The kitchen is a mess: rotting food, unwashed cooking implements, standing water in the sinks. It’s the morning of the event. You have 12 hours. What do you do? You roll up your sleeves and start cleaning. As
...more
Figure out what a story means to you and how you’ll know it’s finished slightly before you ask programmers to estimate it.
You can start using TDD today. It’s one of those things that takes moments to learn and a lifetime to master.
Programmers new to TDD are often surprised at how small each increment can be. Although you might think that only beginners need to work in small steps, my experience is the reverse: the more TDD experience you have, the smaller steps you take and the faster you go.
La clave para TDD
The RuntimeException was worse; it’s better to throw a custom exception. In this case, though, the Java convention is to return null rather than throw an exception. I already had a note that I should test the case where name isn’t found; I revised it to say that the correct behavior was to return null.
Qué? The java convention es devolver null?
Speed Matters
It’s possible to spend too much time refactoring. You don’t need to refactor code that’s unrelated to your present work. Similarly, balance your need to deliver stories with the need to have good code. As long as the code is better than it was when you started, you’re doing enough. In particular, if you think the code could be better, but you’re not sure how to improve it, it’s OK to leave it for someone else to improve later.
are there similarities between the code you’re implementing and other code in the system? Are class responsibilities clearly defined and concepts clearly represented? How well does this class interact with other classes?
Note Avoid creating TODO comments or story/task cards for postponed refactorings. If the problem is common enough for you or others to notice it again, it will get fixed eventually. If not, then it probably isn’t worth fixing. There are always more opportunities to refactor than time to do it all; TODOs or refactoring cards add undue stress to the team without adding much value.
Tremenda nota!!
if you eliminate duplication and embrace simplicity.
For stories that you can’t estimate accurately, an alternative to scheduling a spike story is to provide a high estimate. This is risky because some stories will take longer than your highest estimate, and some may not be possible at all.
Historias que aún no ser pueden estimar
Improve the Process, Rely on People, Eliminate Waste, Deliver Value, and Seek Technical Excellence.
Simplicity To discard the things we want but don’t actually need
One of the seemingly inviolate rules of XP is that you always keep code quality high.
Almost every challenge in building great software is, in some way, a people problem.
Let the Right People Do the Right Things
taking the interrupter to the board, move their current in-progress card back to the todo area of the cork board. Only then would they go and solve the new problem.
If you could predict to the hour how long your project would take, know what risks would and wouldn’t happen, and completely eliminate all surprises, you wouldn’t need agility — you would succeed with any development method.
It’s doing what the customer needs when the customer needs it.
This clever name for a well-known principle comes from Dave Thomas and Andy Hunt. Don’t Repeat Yourself is more than just avoiding cut-and-paste coding. It’s having one cohesive location and canonical representation for every concept in the final design — anything from “the way we interface with a database” to “the business rule for dealing with weekends and holidays.”
Delaying optimization can be scary. It feels unprofessional to let obviously slow designs slide by. Still, it’s usually the right choice.
Despite our best intentions, technical debt creeps into our systems. A lot of it — perhaps most of it — is in our designs. This bit rot slowly saps the quality of even the best designs. Eliminating technical debt through continuous code maintenance and refactoring has only recently been recognized as a design principle, and some people still question it. It’s no less essential for the controversy. In fact, it may be the most important of all the design principles. By focusing on removing technical debt, a team can overcome any number of poor design decisions.
