But first, the bibliography:
Beck, Kent; Andres, Cynthia (2004-11-16). Extreme Programming Explained: Embrace Change (2nd Edition) (Kindle Location 2899). Pearson Education (USA). Kindle Edition.
Lowering the quality of your work doesn't eliminate work, it just shifts it later so delays are not clearly your responsibility. You can create the illusion of progress this way, but you pay in reduced satisfaction and damaged relationships. Satisfaction comes from doing quality work.
You can't get software out the door faster by lowering quality. Instead, you get software out the door faster by raising quality.
How do you implement daily deployment when you have projects that take weeks or months before they are usable? There are many tasks involved in a big project: restructuring the database, implementing new features, and changing the user interface. As long as you don't change the user's experience of the system, you can deploy all the rest of that work. On the last day you put the "keystone", the change to the user interface, in place.
Planning in XP is an activity, not a phase.
If everyone is trying to make sure his function is not seen as the constraint, no change will happen. If the developers say, "Yes, writing automated tests would be 'A Good Thing', but it will slow me down and I'm overloaded as it is," then nothing will change regardless of how beneficial the change would be to the organization and thus to the individuals in it. The reward system and culture need to align with overall throughput instead of individual productivity for the change to stick.
One of the objections to pairing is that pairing cuts effective programming in half. In my experience, pairs are more than twice as effective. The actual time required for me to complete tasks solo versus paired, accounting for debugging time, is more than double; so by pairing you actually come out ahead in completed, clean code. When comparing the value of pairs to individuals, you need to include both time and productivity in deployable code. The goal is valuable software development delivered on time and in budget. The numbers in the plan matter, but only in service of this goal. In planning, you need to include all the relevant numbers in your calculations.
The first edition of Extreme Programming Explained had a more abstract estimation model, in which stories cost one, two, or three "points". Larger stories had to be broken down before they could be planned. Once you started implementing stories, you quickly discovered how many points you typically accomplished in a week. I prefer to work with real time estimates now, making all communication as clear, direct, and transparent as possible.
More time at the desk does not equal increased productivity for creative work.
most defects end up costing more than it would have cost to prevent them.
The team's goal is to eliminate all post-development testing and shift testing resources to more highly leveraged parts of the development lifecycle.
XP teams prefer simple solutions where possible. Here are four criteria used to evaluate the simplicity of a design:
1. Appropriate for the intended audience.
It doesn't matter how brilliant and elegant a piece of design is; if the people who need to work with it don't understand it, it isn't simple for them.
2. Communicative.
Every idea that needs to be communicated is represented in the system. Like words in a vocabulary, the elements of the system communicate to future readers.
3. Factored.
Duplication of logic or structure makes code hard to understand and modify.
4. Minimal.
Within the above three constraints, the system should have the fewest elements possible. Fewer elements means less to test, document, and communicate. Projects that move toward simplicity improve both the humanity and productivity of their software development.
Software development is full of the waste of overproduction: fat requirements documents that rapidly grow obsolete; elaborate architectures that are never used; code that goes months without being integrated, tested, and executed in a production environment; and documentation no one reads until it is irrelevant or misleading. While all of these activities are important to software development, we need to use their output immediately in order to get the feedback we need to eliminate waste.
The challenge of XP is to encourage deep change, to renew individual values and mutual relationships to give software a seat at the table for the next fifty years. Unleashing the potential of the human spirit will lead to a future for computing that we can't yet imagine.
No comments:
Post a Comment