The beauty of lean is better than that of passque (from Chapter 2nd of the path to code)

Pastrami is the proprietary name of this kind of meat. It is a kind of smoked beef, which is generally made from the meat of the shoulder of the ox. Chinese wholesalers generally call it pepper smoked beef and ham .)

Once walking in a public place, such as an airport entrance or park, suddenly a group of crazy people rushed to you to persuade you, or threaten you, or attack your ignorance.Talking to any one of them makes no sense in both logic and reasoning. In their eyes, there is only crazy faith and irrefutable truth. Even if you fully agree with them, you still have no chance to ask questions or analyze them. You must be convinced that you cannot ask questions, even if you only ask one small question.

This makes me very uncomfortable! I mean, I'm really upset! I have my own mind, and I want to use my own mind completely. It is not just for parties or social occasions, but for all theme and behavior that I care about. I am keen to ask "why" and figure out how the transaction works. This is the real thing for me.

You may think that my sensitivity is a standard for software developers because they cannot debug what they don't understand. But some people who are devoted to religion, political struggle, and environmental protection have also adopted fashionable development practices, such as extreme programming (XP, extreameprogramming), under the guidance of some developers), agile methods and team software processes (TSP, Team Software Process ). They have the same enthusiasm!

Everything should be moderate

I really like the many ideas and methods proposed by these development examples. But in the face of a devout follower, if I ask why I want to do something specific, or when I suggest making a small change to the rules or practices, so that it is more suitable for my actual work, so be careful! This is like putting a magic ring in front of the hobbyist-he suddenly pointed out his teeth, his hair root erected. For some developers, eXtreme Programming and agile declarations have become an offering. For other developers, the Team Software Process is a measure of loyalty-You are an enemy of us.

Forgive me for being pragmatic. Forgive me for using my own mind. Forgive me for not superstitious about magic, but insist on doing useful things. I won't do it because you have. My behavior principle is that I want to succeed in doing so, and other methods will fail, both of which can be well justified.

Otherwise, no renewal is performed.

This aroused my interest in lean. Yes. Please refer to the title of this article. Although there are many wonderful things in extreme programming, agile methods, and team software processes, there is at least one concept that they share:Reduce waste of work. This is precisely the focus of lean design and manufacturing, and lean is derived from a concept of Toyota Motor Corporation, which is 30 years earlier than the extreme programming, agile methods and team software processes. When eXtreme Programming, agile approaches, and team software processes try to solve this problem in different ways, we can use lean models to better understand what they have taken.

As a result, let's take a look at the danger of getting angry with some sensitive enthusiasts. Lean focuses on delivering as much value as possible to customers with minimal waste of work. To achieve this, it adopts a pull model and continuous improvement. Pulling the model is easy to say, "You don't have to start your work if you don't have a requirement ." This reduces useless, unnecessary, and valuable work. Continuous improvement focuses on reducing waste and establishing a smooth customer value stream.

Lean defines seven types of waste that undermines customer value streams:

1. Excessive Production
2. Transportation
3. Additional actions
4. Wait
5. Improper Process
6. Inventory
7. Defects

These are obviously manufacturing terms, right? They cannot be associated with software, right? Obviously you are too young to know. All seven waste types are directly related to software development. They are seven sins of software development. Next I will "pronounce them one by one" and point out how extreme programming, agile methods, Team software processes, and general knowledge can circumvent them.

Excessive Production

The first extreme waste is too much production, exceeding the amount actually needed. I hope this will never happen. Is there a product that has not been removed from any defined and implemented functions before shipment? Is there a product that customers will never use before shipment? The product is too complex, comprehensive, scalable, fancy, cumbersome, and confusing ...... Excessive production is so horrible that it can lead to incredible waste.

Extreme Programming solves this problem through short and compact iterations. It maintains continuous communication with customers and developers. This ensures that everyone knows what others are doing, and customers always have a high degree of recognition. As a result, almost all finished work is valuable to the customer.

Agile methods are a collection of lean practices, including extreme programming. Because agile is more of a kind of consortium, it is not a specific method, but provides many interesting methods for development. One of them is the project management practice called "scrum" ("scrum" is named based on Rugby terminology ). The development team often meets with customer representatives, usually every 30 days, to demonstrate the work progress, reschedule the work priority and improve the process. Like eXtreme Programming, team members also hold meetings every day to update their respective progress and discuss obstacles to their work.

Through monthly rearrangement of work priorities and daily re-organization of work, a scrum Team focuses on what is important to the customer. Almost no work is wasted. By focusing on regular process improvements, value streams can be optimized on a regular basis.

Go deep

Of course, you may not be able to use scrum and extreme programming locally: You first work on the "infrastructure" and let customers wait for the value they want. To get frequent feedback from customers, there is a basic premise for fast iteration: development should be "depth first", rather than "breadth first ".

In the extreme case of breadth first, each function is defined, each function is designed, each function is encoded, and all functions are tested together. In extreme cases, deep precedence means that a single function is fully defined, designed, encoded, and tested. Only when this function is complete can you perform the next function. Of course, the two extremes are not good, but the depth priority is much better. For most teams, an advanced breadth design should be done, and then immediately jump to the underlying Design and Implementation of depth first.

This is exactly how Microsoft's office function team works. First, the team plans what features they need and how to put them together. Then everyone is divided into several small and multi-job teams, each team is responsible for only one function from start to end. As a result, a complete and stable value is delivered to the customer for demonstration in a much shorter cycle.

In depth, priority is given to reducing excessive production by focusing on the work that will be used, rather than the "infrastructure" that may never be followed by customers or that will hardly be stabilized. Another outstanding deep-first development method is "test-driven development" (TDD, test-driven development), but I want to discuss it again in the "improper process" section.

Transportation

The second extreme waste is waiting for something that has not yet arrived. In manufacturing, this usually refers to the transportation of parts. For software, this "Shipping" refers to the delivery of deliverables between teams. There are three sources of annoying transportation problems: Build, branch, and e-mail.

*Build ):The longer the build takes, the more time it will waste. What I need to tell you is that both eXtreme Programming and agile methods are built every day. But for Giant teams, building every day is becoming increasingly unrealistic. This is indeed a big problem. It cannot be ignored!

*Branch ):Microsoft uses source depot. It has great value for the entire company. But it is also as cute as a pet: It is cute when it is still small, but after a few years, you will often feed it and serve it, your activity is restricted. Creating code branches is a good idea, so many large teams have done this. Now suppose you are in a2.b3. work on the C1 branch, and your partner works on a3.b1. c2 implements a key function or fixes a major bug. He needs to reverse the code changes from C2 to B1 and then integrate from B1 to A3, then you need to integrate the changes from A3 to A2, to B3, and finally to C1. Oh, my God !!! After all these integrations are completed, the progress will soon grow. The recommended solution is to build the same level branch for your current product line during the renewal period.

*E-mail:The last transport nightmare is the E-mail Notification: the project manager told the developers and testers that the specifications are ready, and the Development told the test that the encoding is complete; the test tells developers that their work is blocked by a bug; the development tells the project manager that their work is blocked by a design change; and my personal preferences: any communication between the customer and the dependent party or the seller, especially the Overseas communication. Extreme Programming and agile methods solve this e-mail notification problem by abolishing roles and setting up a daily meeting system. However, this does not work for remote vendors and dependent parties. At present, we must rely on automatic notifications as much as possible. If necessary, we should use live meeting. If we use e-mail, we should also clearly provide the expected response from the recipient in e-mail, reduce the spread of e-mail.

Additional actions

The third extreme waste is taking time to find something. In the manufacturing industry, this is a waste of Mechanical and human actions. In the software world, it refers to the time spent figuring out what to do, where to go, and how to solve it. Poor search technology is a typical example of waste of action. Code that cannot be tested, maintained, or managed is also a waste.

Using assertions and verification input parameters helps you quickly discover bugs and reduce the waste of action. Design Review, code review, code analysis, and unit test can all reduce the waste. Pair programming is even recommended for extreme programming, but I personally think, this is a waste of resources (unless developers are learning a new code library together ). The Team Software Process Measures all your activities and defects, and you can clearly understand how your time is spent, so you can greatly reduce your unnecessary actions.

A particularly annoying but unavoidable redundant action is to copy bug fixes for code comments, source depot, product studio, and code check-in emails. Everyone is wasting their actions to manage multiple copies of bugs and project progress data. There are some tools that can make such things simple. Information can be automatically transmitted to all other places only once it is entered. These tools should be used to reduce extreme waste of action.

Wait

The fourth extreme waste is the waiting for work. The transport issues mentioned above only cover a majority of the waits for construction, branch integration, and timely communication. But waiting is far more than that. The most common dead zone is that the team fails to reach an agreement on the priority order of the function, or fails to implement it in the established order even if an agreement is reached. That is to say, if the product manager writes the specification book randomly, the developer has to wait. If the developer does not implement the function in order, the tester can only wait. The tester does not perform the test in order, then everyone must wait.

Extreme Programming, agile methods, and team software processes all emphasize that the Team should prioritize and be signed and approved by the customer or their representatives, and then work in that order, until they decide to review the priority. The team's software process is especially rigorous in this regard, but there is no flexible leader, and there is a lack of iteration in the plan.

In addition, unstable code also causes waiting. As long as the code is unstable, the test team has to wait, and other mechanisms used to receive feedback from customers have to wait. Extreme Programming and agile methods focus especially on verifiable and stable code, which is another key aspect of a deep priority strategy.

Improper Process

The fifth extreme waste is excessive engineering. As you can see, they are usually shown in the following form: developing extremely complex features continues to improve performance where they are good enough or are not the real bottleneck, it also adds unnecessary generalization or scalability. This waste is related to excessive production, but it is more important to implement specific functions.

Prescription: Test-driven development ). This is a method that provides eXtreme Programming and agile methods for implementation design. As a by-product, this method also produces a unit test that completely overwrites the code. The process is quite simple:

1. Define your application interface or public class method.

Note: This is a dispute between me and some members of the agile community: Do you write application interfaces or public methods before writing unit tests? This is what I think is to be written before the crazy talk. The two are different: the degree of preliminary design and the relationship between you and external organizations dependent on your code. I believe that moderate preliminary design at the 0.1 million code line level is a key element of success.

2. Write a unit test according to the needs of an application interface or class.

3. Compile and build your program, then run the unit test and confirm that it fails. (If it succeeds, skip step 1 .)

4. Write enough code to pass the unit test. (At the same time, ensure that all previous unit tests still pass .)

5. Repeat steps 2nd to 4th until all requirements of the application interface or class are tested.

Naturally, you can write multiple unit tests for multiple requirements at a time after you have mastered this method. But when you are just getting started, you 'd better do only one job at a time. In this way, we can develop good habits.

When you use a test-driven development method, you do not need to write more code than you absolutely need. You naturally get code that is easy to test, and the code is usually strongly cohesive, loosely coupled, and less redundant-all of which are really good. Oh, I once mentioned that you can also get a unit test with full code coverage? Are you satisfied with anything else?

Inventory

The sixth extreme waste is the undelivered work and products. This is related to the function reduction, but it also includes the work in progress. When you adopt a width-first development method, all your work is carried out at the same time until the code is compiled and stabilized. All completed specification books, designs, and code waiting for passing tests are in stock. Their value has not yet been realized.

The unrealized value is a waste because you cannot present the value to customers and partners. You cannot get their feedback. You cannot improve or optimize customer value streams. Of course, if the product plan changes, these unrealized inventory will usually become a huge waste of work.

The lean PULL model emphasizes only what needs to be done, so its result is low inventory, which is well verified in scrum and test-driven development methods. Scrum pays special attention to ongoing work and keeps track of and tries to reduce it from time to time. Scrum also uses regular opportunities to improve and optimize the way you deliver value. The test-driven development method requires that you only implement the code that meets your needs, and do not implement it a little more.

Defects

The seventh extreme waste is rework. This is the most obvious one and the one that I criticized most in the past. Extreme Programming and agile methods reduce bugs and rework through a variety of methods, including test-driven development, daily build, continuous code review, and design review.

However, eXtreme Programming and agile methods also reduce bugs in a more subtle way-by building a framework that allows you to learn while walking. By using the deep-priority development method, you can understand all the parts of the project at before you design and code the entire product. This avoids serious architecture problems, which are often hidden deeply. It is too late to be adjusted when it is discovered. Sounds familiar, right?

Defect Reduction is the team's software process expertise. Teams using this method can reduce their bug rate to 1‰ of the industry average. Although the Team Software Process is not lean in nature, it does not reject the development method with deep priority.

Combined Application

It's time for me to get angry with devout followers of extreme programming, agile methods, and team software processes. There is no reason to say that you cannot combine these methods to achieve better results. Use scrum to drive a lean, in-depth, flexible, and optimized development plan. Use the test-driven development method to create a lean implementation. Using the team software process to analyze your defects and work can result in a significant reduction in bugs and waste of work. These may sound strange to some people, but it seems reasonable to me.

It seems that I have just found a delicious sparque beef.

the beauty of lean is better than that of passque (from Chapter 1 of "code path")