Algunas de sus afirmaciones:
Pregunta: De dónde viene Lean?
Mary: Lean comes from the Toyota Production System which was invented at Toyota for automotive manufacturing in the late 1940s, 1950s, 1960s. We didn’t actually discover how it was working in the US until perhaps the early 1980s, when the idea of "Just-In-Time" manufacturing started competing against other US products, so we started seeing Toyota and other Japanese cars taking market share away. In my industry, which was 3M, we were making video cassettes and all of a sudden we found that Japanese competitors were selling video cassettes for a third of what we could selling for, and less than we could make them for. We were trying to figure out what caused that. It turns out that this concept of Just-In-Time manufacturing was strongly behind what was going on, and later the concept became known as Lean manufacturing.Ante la pregunta de qué es Lean, Mary lo explica en su aplicación original en la industria:
Mary: We’ll talk about Lean in general. The Lean history starts over here in manufacturing. Here the first thing Lean was known as was "the Toyota Production System" (it was the way Toyota learned how to manufacture cars). That became known as Just-In-Time and that how it was known when it came to the US and Europe. Then, in 1990 a book was published "The Machine that Changed the World" - the Story of Lean Production. That’s where the word Lean production came from. They’re all basically the same thing. They’re a way of thinking about manufacturing that allows you to do rapid manufacturing with very low inventory and high variability. Then, if we come down this path there’s something in logistics (warehousing, moving materials between companies) called supply chain management (SCM). SCM is the way that you use Lean in the logistics area. And if we come over here there’s a whole other area which I’ll call Product Development, which is very different than manufacturing and logistics. We now apply Lean thinking principles (not the practices, but the principles) from manufacturing and logistics into Product Development. When you apply Lean into Product Development you get a different way of looking at it. And I believe that software development is a subset of, is like, it’s part of Product Development. When you apply Lean to software development you take the general principles of Toyota production system or Lean and you apply them into the Product Development environment but you don’t use the exact practices that you would use in manufacturing. You have to go back to the first principles of what you’re trying to accomplish and move those into software development.Qué significa "Inventario" aplicado al desarrolo de software:
(...) The main principles behind Lean were articulated by Taiichi Ohno, the person at Toyota who invented the Toyota Production System. The first principle would be the idea of Flow (or Low Inventory, or Just-in-Time). The second one is what I would have to call "expose problems" or "no workarounds". The idea is that you have flow and you have low inventory: it’s like you have a boat on the water and your boat is sailing above these big rocks, which are problems. This is your inventory level here. If you lower your inventory level, at some point you’re going to run into a rock rock and your boat is going to come down and bump into this rock. If you don’t get rid of these rocks when you lower your inventory you’re going to bump into rocks, and crash and burn. The first thing you’re doing is lower your inventory to expose those problems so that you can get rid of them. If you don’t expose problems and stop and fix your problems, then lowering your inventory is just going to crash your boat. You have to do two things: you have flow but you also have no tolerance for abnormality. You just don’t allow defects into your system; you don’t allow things to go wrong. When something wrong happens you stop, you figure out what is causing it, you fix it rather than continuing on and just ignoring it or working around it. These are the two basic principles.
(...) I have seven principles that are the foundation of the way to look at it Lean in software development. The first principle is to eliminate waste. The second is to amplify learning. The third is to delay commitment. The forth is to deliver fast. The fifth is to build integrity into the product. You can’t test it in later; you have to build it with integrity in the first place. The sixth is to engage the intelligence of the people who are doing the work. The last is to optimize the whole system, not just part of it.
Mary:In software development inventory is anything that you’ve started and you haven’t gotten done. It’s "partially done" work. In manufacturing if you start making something and it is in-process, it’s not sold, it is inventory. In development it’s the same thing. If you started developing something and it’s not done, it is inventory. What you’re trying to do Lean software development is the least amount of "partially done" work as possible. You want to go from understanding what you’re supposed to do to having it done and deployed and in somebody’s hands as rapidly as possible.Qué significa "desperdicio" en el desarrollo de software:Tom: "Done" means coded, tested, documented, integrated, "Done", so there’s no more work to do. It is one of the main reasons why Lean approach gives you a more reliable delivery, a more trustworthy delivery. So that instead of finishing activities like requirements, which doesn’t tell you much about how far you are along overall, each piece of work that you do is completely done.
Waste is anything that the customers do not value. If you’re doing something and in the end the customers don’t think it is important for them, then it is waste. There are lots of ways to look at waste. One is: partially done work is waste. Just like in manufacturing, inventory is waste; in software development partially done work is waste. Also, extra features you don’t need right now is waste; stuff that causes delays is waste; things that get in the way of a rapid flow of product are waste. Because customers, when they have a problem they want the problem solved now, and stuff that delays that is waste.Qué significa "demorar el compromiso" (delayed commitments):
En el reportaje hay más: una comparación con XP, con RUP y con CMM, que merecen ser leídas.[1. Anticipado al discutir su método aplicado:]
Well, when you have requirements churn, meaning you’ve done some requirements work and then it needs to be changed, that means you’ve written your requirements too soon. If you don’t wait until it’s time to write those requirements (that’s what I mean by "delayed commitment") that’s when you’re going to have a lot of changes in requirements. On the other hand say you get to testing and you find errors - oh my goodness! Now you have to go back and code-and-fix, and code-and-fix. If you have that cycle in your value stream you’re testing too late. The idea is to move the detailed requirements closer to the coding, the testing closer to the coding, and do it in smaller chunks.
[2. Contestado específicamente:]
Mary: The idea of delayed commitments is not to decide until you have the most information that you possibly can have. Then you make decisions based on that. It’s the idea that (not that you procrastinate and never make decisions) but that you schedule decisions for when you have the most information. For example, pilots are trained that when they have to make a taught choice, they should decide when they have to decide, and not to decide until then because that’s when they have the most information. The military paradigm: when you’re threatened decide when you need to respond and don’t respond ahead of that, wait until that time because then you have the most information. But don’t wait any longer than that. So, it is the idea of scheduling decisions until the last moment when they need to be made, and not making them before that, because then you have the most information.
For example, let’s take user interface. When do you really need to design a user interface? Oftentimes it drives the whole design, but in fact you don’t really need it until you’re about to do your first alpha test. Before that you can be designing the business layer and you can actually put testing in below the user interface and you can be designing all of the other business logic; you can get that done with any kind of interface and in fact you ca drive testing with a automated interface, and then just before you go to alpha testing you decide what you want for your user interface. Then you take it off and at that point in time you figure it out. But up until that point in time you don’t need that. And there are many pieces of decision in software development, where there’s this idea that we have to design the whole thing before we get started. But the fundamental Lean principle in product development is that we should not make any design decisions until we absolutely have to. We really do not want to have decided anything until we need to; and so at the point it time of the decision we should still have 3 options. Still have a couple of middleware options, or still have not decided how we’re going to do the user interface. You wait until you know the most possible information before you make decisions. So, the idea of having a complete detailed spec at the beginning is the exact opposite of the Lean commitment.Tom: At the beginning is the time of maximum ignorance about what you really need. It is hardly the time to make your key commitments. Most of the cost is incurred when you make the first commitments. If you can delay that, you can do a much better job.
Mary: You want irreversible decisions, decisions which you can’t change, to be made as late as you possibly can. Otherwise, if you make them early you’re going to lock in the decision, because you’re going to build stuff on it, and you didn’t need to make it yet. And if you wait, you leave options open so that you can chose later exactly what you need to do. That’s just basically a good design heuristic.
Más aún, pueden además buscarse las respuestas que Mary da a doce preguntas de lectores consultados por Abilla.
[1] La referencia a la versión inglesa de Wikipedia, más completa que la castellana.
No hay comentarios.:
Publicar un comentario