Extreme Programming Explained: Embrace Change

by Kent Beck

XP embraces five values to guide development: communication, simplicity, feedback, courage, and respect.

What is most important is aligning team behavior to team values. If you do that you can minimize the waste that comes from trying to maintain multiple sets of values simultaneously.

One is that no matter what the client says the problem is, it is always a people problem.

If the team members’ sense of safety is tied to having their own little space, removing that sense of safety before replacing it with the safety of shared accomplishment is likely to produce resentment and resistance.

People need a sense of “team”: We belong. We are in this together. We support each others’ work, growth, and learning.

Make your workspace about your work. An interested observer should be able to walk into the team space and get a general idea of how the project is going in fifteen seconds. He should be able to get more information about real or potential problems by looking more closely. Many teams implement this practice in part by putting story cards on a wall. Sorting the cards spatially conveys information quickly. If the “Done” area isn’t collecting cards, what does the team needs to improve in its planning, estimation, or execution?

mwr drH

The workspace (Figure 5) also needs to provide for other human needs. Water and snacks provide comfort and encourage positive social interactions. Cleanliness and order leave minds free to think about the problems at hand.

Another implementation of the informative workspace is big, visible charts. If you have an issue that requires steady progress, begin charting it. Once the issue is resolved, or if the chart stops getting updated, take it down. Use your space for important, active information.

myteam mwr

insight comes to the prepared, rested, relaxed mind.

In my own case I think I turn to long work hours as a way of grabbing control in a situation in which I am otherwise out of control. I can’t control how the whole project is going; I can’t control whether the product sells; but I can always stay later. With enough caffeine and sugar, I can keep typing long past the point where I have started removing value from the project. It’s easy to remove value from a software project; but when you’re tired, it’s hard to recognize that you’re removing value.

You can make incremental improvements in work hours. Stay at work the same amount of time but manage that time better. Declare a two-hour stretch each day as Code Time. Turn off the phones and email notification, and just program for two hours. That may be enough improvement for now and may set the stage for fewer hours at work later.

If it’s hard to write a test, it’s a signal that you have a design problem, not a testing problem.

Tools like static analysis and model checking could be used test-first style.

In XP, this is the process for responding to a defect:

A plan in XP is an example of what could happen, not a prediction of what will happen.

If you plan to process images, you should be able to process an image at the end of the first week.

mydocs. a feature slice should be a finished piece from customer perspective. We shouldn't quibble about degree of usefulness too much... just make it as useful as practical. for example, an exam may start with one piece of data... dare of service... hardly an exam, but clearly building toward practical value (here's the key) from a feature (customer's) perspective... so.. it my not be fully practical value yet (for the customer) but should be toward practical value… for the customer

I trust two metrics to measure the health of XP teams. The first is the number of defects found after development.

The second metric I use is the time lag between the beginning of investment in an idea and when the idea first generates revenue.

If the manuals are online at your site, then you can monitor usage. If users never look at a certain kind of documentation, stop writing it.

Plan at every timescale with these four steps:

Sometimes you will be in the middle of a cycle with progress slower than planned. Look for ways to realign with the plan. Have you been distracted by less important issues? Have you been lax on a practice that could help you? If no process change is going to restore the balance between plan and reality, ask the customers to choose which stories they would like to see completed first. Work on those to the exclusion of all else.

A distributed system might use remote procedure calls as its initial communication technology. As experience with the system grows, the team can see how to improve the system by moving to CORBA. A year later the team replaces CORBA with a message queue.

mwr mystudy. know well

Steve McConnell in Code Complete

toread

The instructions to auditors such as DO-178B explicitly allow software development lifecycles other than a strict waterfall.

The echoes can also be heard when an “elite” architecture or framework group prescribes precisely how work should be done by someone else.