Amplify learning

린 소프트웨어 개발의 원칙 중 하나

Development is an exercise in discovery:

Development is an exercise in discovery, while production is an exercise in reducing variation, and for this reason, a lean approach to development results in practices that are quite different than lean production practices. … The best approach to improving a software development environment is to amplify learning. —pxxv, xxvi, Introduction, Lean software development (book)

Do it right the first time?

One of the interesting features of the scientific method is that if your hypothesis is always correct, you are not going to learn very much. The maximum amount of information is generated when the probability of failure is 50 percent, not when the hypotheses always correct. It is necessary to have a reasonable failure rate in order to generate a reasonable amount of new information. —p19, Chapter 2, Lean software development (book)

Iterative development:

Three fundamental principles:

First, as we will see in Chapter 4, Queuing theory, small batches moving rapidly through a system lead to all manner of good things. Small batches enforce quality and worker-level communication while allowing for greater resource utilization. They provide short feedback loops, which enhances control. For this reason, short, complete iterations are fundamental to Lean software development as small batches are to Lean manufacturing.

Second, short iterations are an options-based approach to software development. They allow the system to respond to facts rather than forecasts. There are few endeavors in which it is more important to keep options open than in software development. In Chapter 3, Decide as late as possible, we see that options-based approaches are fundamentally risk-reduction strategies, and as counterintuitive as it may sound, you actually reduce your risk by keeping options open rather than freezing design early.

Finally, iterations are points of synchronization across individual and multiple teams and with the customer. Iterations are the points when feature sets are completed and the system is brought as close as possible to a releasable or shippable state - even if it will not actually be released. Thus, iterations force decisions to be made. Frequent points of synchronization allow teams to work independently yet never stray far from the work of other teams of the interests of customers and users —p28, Lean software development (book)

Can iterative development process converge on a solution?

Consider a thermostat. It does not turn on the furnace the moment the room temperature falls below the setpoint, and then turn it off the moment the temperature rises to the setpoint. If this happended, the furnace would cycle on and off constantly, something that is not good for furnaces. Instead, the thermostat turns on heat when the temperature falls a couple of degrees below the setpoint and leaves the furnace on until the temperature is a degree or two above the setpoint.

An iterative development process achieves this same effect by limiting customer requests for feature changes to the beginning of each iteration. During the iteration, the team concentrates on delivering the features it ommitted to at the beginning of the iteration. If the iterations are short - 2 to 4 weeks - the feedback loop is still quite short. —p31, Lean software development (book)