More on this book
Kindle Notes & Highlights
by
James Shore
Read between
May 9, 2016 - September 14, 2018
If people won’t take responsibility, perhaps you’re being too controlling.
weekly status meeting,
Unfortunately, this response ignores the reality of Murphy’s Law. If something can go wrong, it will. People are, well, people. Everybody makes mistakes. I certainly do. Aggressively laying blame might cause people to hide their mistakes, or to try to pin them on others, but this dysfunctional behavior won’t actually prevent mistakes.
Rather than blaming people, I blame the process. What is it about the way we work that allowed this mistake to happen?
I like to chip away at the biggest problem while simultaneously picking off low-hanging fruit.
Before changing the process, ask yourself whether the problem is common enough to warrant the overhead.
Keep in mind that lectures and punitive approaches are usually ineffective. It’s better to make it difficult for people to make mistakes than to expect them always to do the right thing.
How to Conduct an Iteration Retrospective
para esfera
Mute mapping
Sometimes I like to imagine software development as a pulsing web of light, with blips of information flowing along lines from far-flung points. The information races toward the development team, which is a brilliant, complex tangle of lines, then funnels into a glowing core of software too bright to look at.
Trust is essential for the team to perform this well. You need to trust that taking time to help others won’t make you look unproductive. You need to trust that you’ll be treated with respect when you ask for help or disagree with someone.
Don’t wait for them to realize how your work can help them. Show them.
Show Some Hustle
Even scrupulously honest teams can run into this problem. In a desire to look good, teams sometimes sign up for more stories than they can implement well. They get the work done, but they take shortcuts and don’t do enough design and refactoring. The design suffers, defects creep in, and the team finds itself suddenly going much slower while struggling to improve code quality.
“Forming, Storming, Norming, and Performing.”
“Past studies have indicated that less than 30 percent of a programmer’s time is spent on traditional programming tasks and less than 20 percent of the time is spent on coding. The rest of the time is spent on meetings, problem resolution with the team, resolving issues with customers, product testing, etc.”
Be careful about sitting together if programmers don’t pair program. Solitary programming requires a quiet workspace. Pair programming, on the other hand, enables programmers to ignore the noise.
Outsourced Custom Development
This is more than learning the domain to write the software; this is reflecting in code how the users of the software think and speak about their work. By encoding your understanding of the domain, you refine your knowledge and — due to code’s uncompromising need for precision — expose gaps in your knowledge that would otherwise result in bugs.
This will probably require a conversation to resolve any conflicts. Embrace that!
Keep out programmer jargon — you can help domain experts refine their understanding of complicated corner cases, but don’t replace their language with your own.
Combine brevity with an unhurried calm.
Don’t get me wrong: a consistent formatting standard is good. If you can agree on one, do! However, when you’re putting together your coding standard, don’t fall into the trap of arguing about formatting. There are more important issues.
Coding standards are, in many ways, an aesthetic choice: it doesn’t really matter what the standard is, as long as it’s consistent and thoughtful. One of the marks of a professional is the willingness to put aside personal aesthetics for a team aesthetic.
Dealing with Disagreement
No coding standard can substitute for professional judgment. Try not to get too upset when you see people deviating from the standard.
ask yourself whether the coding standard was really a team effort.
Programmers need discipline to keep the code clean so they can continue to make progress. Customers need discipline to fully understand and communicate one set of features before starting another.
When schedule problems occur (they always do),
The problem may be as simple as trying to do too much work.
If a story isn’t “done done,” don’t count it toward your velocity.
Next, add extra bugs by mixing in concurrent programming.
They supplied the Java multithreading library with bugs for years!
Take your ingredients — C, real-time embedded systems, multitasking, and don’t forget the novices — add a little assembly for seasoning, shake well, and bake for three years. (I do love me a bug pie.)
What configuration issue springs up to waste a few hours every week?
truck number.
Necesitamos que Marian T. haga programación en pareja
You don’t need to know exactly what’s happening in every line of code. In a well-designed system, all you need to know is what each package (or namespace) is responsible for.
Task-switching has a substantial cost: “[T]he minimum penalty is 15 percent... Fragmented knowledge workers may look busy, but a lot of their busyness is just thrashing” [DeMarco 2002]
How to Release Frequently
Releasing frequently doesn’t mean setting aggressive deadlines. In fact, aggressive deadlines extend schedules rather than reducing them [McConnell 1996] (p. 220).
Don’t worry too much if you have trouble making your stories perfectly releasable. It takes practice. Releasable stories give you more flexibility in planning, but a few story clumps in your plan won’t hurt much. With experience, you’ll learn to make your plans less lumpy.
Some people try to fix the release date and features. This can only end in tears; given the uncertainty and risk of software development, making this work requires adding a huge amount of padding to your schedule, sacrificing quality, working disastrous amounts of overtime, or all of the above.
“Done done” applies to release planning as well as to stories. Just as you shouldn’t postpone tasks until the end of an iteration, don’t postpone stories until the end of a release.
In practice, this means that the further away a particular event is, the less detail your release plan needs to contain.
in a “Risky” approach, you have a 10 percent chance of finishing according to your estimated schedule. Doubling your estimates gives you a 50 percent chance of on-time completion, and to be virtually certain of meeting your schedule, you have to quadruple your estimates.
Many organizations have acclimated to slipping delivery dates. Managers in these organizations intuitively apply an informal risk multiplier in their head when they hear a date. In this sort of organization, applying a large risk multiplier might make the schedule seem ridiculously long.
Most importantly, iterations counter a common risk in software projects: the tendency for work to take longer than expected.
The Iteration Schedule
La agenda de la iteración
I prefer iterations that start on Wednesday morning. This allows people to leave early on Friday or take Monday off without missing important events. It also allows the team to conduct releases before the weekend.
How to Plan an Iteration
