online shoes store xkshoes,here check the latest yeezy shoes click here.

know more about 2020 nike and adidas soccer cleats news,check shopcleat and wpsoccer.

Learning from Lean
Kent Beck, Three Rivers Institute

Summary

Both Lean Production and Lean Product Development have lessons for software developers. This paper examines one principle, waste, shows how it is expressed differently in production and product development, and how those lessons translate to software development.

Introduction

I first read Taiichi Ohno's Toyota Production System on a trans-Atlantic flight on my way to XP 2002. As the water flowed far beneath our wings I thought (and, judging from the reaction of my seatmates, said), "Right on! Exactly! You tell it!". Once at the conference, Professor Zaninotto gave a keynote that was a model of clarity and depth relating the economics of lean production to the economics of software development (I couldn't find the slides to reference), reinforcing my sense that the ideas Ohno described could be instrumental in improving software development. But which ideas?
    The aspects of the Toyota Production System (TPS) that first appealed to me were those that focused on the social purpose of work. Software development often seems to occur in a purely technical context devoid of business or social purpose. Questioning why the code I am writing today is good or valuable helps me focus my development and avoid wasted effort.
    When I got to Alghero for the conference, I started talking about Ohno and TPS. I immediately encountered Tom and Mary Poppendieck. I didn't know them except by reputation at that time but I found we agreed on the importance of the social message in TPS. It was when we started to explore the practical implications of TPS for software that I got a shock.
    I explained that software development was like a lean production line. The repetitive "standard work" consists of tasks like writing a test, refactoring, planning, and building. TPS suggested ways of smoothing and accelerating these processes.
    "No, no," Mary said, "The real lessons of TPS for software are in the way Toyota develops new products, not the way it manufactures." When Mary speaks, it's a good idea to listen. In this case, though, I wasn't convinced.
    Five years on I think I have a more balanced perspective. I am right that lean manufacturing has valuable lessons for software and Mary is right that lean product development has valuable lessons for software. In this paper I intend to show how the same lean production principle can offer different but valuable lessons for software when seen through the lenses of manufacturing and product development. The key is the persistent application of consistent principles.
    A full explanation of TPS as applied to software would take books. This paper is limited to showing how both metaphors, software development as lean manufacturing and software development as lean product development, can yield valuable insights. In the interest of space and time, exploring the whole landscape of lean ideas will have to wait.

Waste

One key principle of TPS is the elimination of waste. Rather than focus directly on increasing productivity, in TPS productivity is a trailing indicator: get rid of waste and productivity will rise as a consequence.
    This principle plays out differently in manufacturing and product development. On the production line, Ohno lists seven wastes, headed by the waste of over-production. Each item created has two sources of value: the intrinsic value that someone else will pay for the item and the information value, feedback about the making of the object. Over-production creates the illusion of value by making more things that are potentially salable, but by not using or selling them immediately the information value of the items evaporates. If an upstream machine needs adjustement but the parts it produces aren't used immediately, no one will notice the problem until much later when many more defective parts have been created. Producing only what is needed when it is needed gives you the information necessary to run production smoothly.
    Traditional software development is rife with over-production: too many requirements to implement this release, too much architecture for the current needs of the system, too much code to be adequately tested, too many features for customers to use. Most of this excess work is done, ironically, in the name of efficiency, but by producing more than we can consume we lose the information value of our work, concealing the information needed for large-scale improvement.
    TPS has a large and sophisticated set of techniques for throttling production back to actual use. Many of these have analogs in Extreme Programming. Practices like Test-Driven Development encourage developers to code to today's needs, not uncertain future requirements. If the requirements and design aren't done first, their work must be spread across development, a shift which is supported by incremental design and the social practices that help the team maintain a shared understanding of the system.
    That's waste as applied to software through the lens of manufacturing: produce only what you can consume and use the information generated for improvement. Toyota has been careful to apply the same principles to all aspects of its business, while recognizing that different contexts require different application. Eliminating waste is a key principle in Toyota's product development process. However, in product development you deal with a wide range of problems and tasks. Over-production would be wasteful, but in practice it is not the biggest waste in product development. The biggest waste in product development is re-learning.
    Product development teams are large and diverse. When someone on the team learns something, that knowledge needs to spread quickly to the whole team. Otherwise, someone else could learn an opposing truth and the two people could begin working at cross purposes. The re-learning process can also span time. What one part of the team learns earlier in the development process could become important to another part of the team later. Spending time and money learning the same thing multiple times is a waste of opportunity and a potential source of contradictory decisions.
    Some of the techniques used to promote efficient learning at Toyota are also found in Extreme Programming, like the "try it and see" attitude. Others, like the appointment of Chief Engineers, are not common on XP teams.
    So here is a single principle, eliminating waste, that brings different insights to software development depending on the metaphor. If software development is lean manufacturing, software development should aim to produce decisions at the same rate as it consumes them. If software development is lean product development, software development should strive to retain and disseminate learning. Both lessons can positively influence software development.

Conclusion

The lessons of TPS can be applied to software through both metaphors--software development as product development and software development as lean production. Which metaphor is most helpful depends on perspective. I encourage you to try them both and see what you find.