Roy W. Miller (RMiller@rolemodelsoft.com) Software Developer, Rolemodel Software, Inc. 2003 March
Before the XP lecturer and developer Roy Miller explains the "hot" XP practice, he will show you how to transform your ideas so that you can start using XP. This is not a relaxed task - XP needs a way of thinking with most programmers and business people. If you are facing this problem, then Roy will help you solve this problem.
Programmer training I have no computer scientific degree, so I can't discuss the "traditional" training obtained by most programmers from the perspective of direct experience. More specifically, I have worked with many programmers and business people in multiple software development projects. So I think I can wise how to think when they try to develop software, and how to do it. Let me first talk about the programmer, because I am one of them.
Understanding your father is a doctor. He has repeatedly told me (I can't remember the number), "I went to study the medical school. After graduation, I will study my doctor in the internship." I think, the graduates of most computer science majors are similar. They have a lot of theoretical knowledge (some of which are good and help) left the school, but don't know how to write good code. Since I don't have a computer scientific degree, there is no major theoretical knowledge. Sometimes this will make me very sad, but most of the time will not.
When I started programming, I was 22 years old and just came out of school. Andersen Consulting trained me, the teachers got me in the door, and I was very difficult to "Mong Mong" passed. Most people have experienced this process: they learn to program in the process of work, and most people are usually in the company environment. Unfortunately, their master and teacher are also like this. Customary, terminology and preferences (most of them are not very good) passed down. Finally, most programmers learned how to complete the work as quickly as possible.
There seems to be four behaviors in programmers:
The programmer does not know how to communicate well with business decision makers. Programmers expect to have a textbook problem. Programmers like to work alone. Programmers believe that testing is encoded.
Business training business staff have their own training, but it has a huge difference with the training accepted by programmers. However, the result is similar: business personnel are accustomed to work with the way to endanger their software projects.
The cost of conducting business is responsible for the budget business personnel all day in calculating business costs, but they don't seem to know how to consider why they need software. Typically, their business priority for features, or those characteristics have no practical concepts for currency (direct or indirect) of their business. This is understandable for lower-level project managers and corporate leaders.
In many corporate environments (especially large companies), it is easy to see how the underlying underlying will be managed by the high-level management personnel through the rules and regulations. The high level conveys some commands, as long as the underlying subordinate is executed. People who are responsible for managing projects know to do, not to do it. Usually the company does not encourage them to think. Therefore, when a command is reached, they only need to obey, and why they should or should not do more details can only be those who are considering those enterprises.
However, I am afraid that the decision made by the high-level English people is always correct. Many business decisions are determined based on what "hot" or what is the most capable of most of the press. "If all other companies are doing, we should also do". This is called "with a large current effect." The problem is that the company's leadership is wrong to the understanding of the software. They think it is cost overhead, rather than spending some costs. They think it is "unavoidable disaster", or the means of production, not the strategic advantage. I don't want to participate in the tendency to further "participate in" software projects. Usually they are not too participating in these items at all. Software developers may occasionally ask them some problems, but the process really does not make sense. The project is usually starting from the analysis design, even if the development team does not use the waterfall model variant. This is the stage that requires business people to participate in the statement. But technical teams usually want business people to answer all questions. "Tell me now, this software needs to do anything within a year. We will tell you that you can change your ideas in the future, but this is just a joke. Any decision you do now is a hammer sound."
No wonder business staff will be very nervous. They have to make a clear statement on what they don't know. This makes them almost inevitably communicate with the IT team, in which business people throw the material into the wall, I hope that developers will solve problems. Coordinated innovation activities have no secrets, is it?
Anyone who has a strong boycott of the constraint. As a project management person, your boss pushes you a lot of piles, but he doesn't matter. You must be earned in everyone, including your system must have the staff of other departments to deal with them, whether they are senior staff or ordinary staff. You will definitely get sin in someone and make some people dissatisfied.
Breaking mode Over time, most companies are "falling into" this behavior. The result is that the software project makes people exhausted, but when the project is completed, it usually does not satisfy anyone.
Is it not unable to save? Are you not always in trouble? Yes, if you don't start taking other actions. I am not an expert in thinking; I can only provide some experiences. Sometimes, I think you should try to change a thinking and then affect your behavior. However, most of this don't work for me. I have to take different actions first. My idea can come. For me, the best way is to consciously change the method of thinking about the problem in adopting different actions. This is what XP can help you.
XP needs to be different from standard training. To understand the best possible results generated, and whether it is suitable for you and your organization, the only way is to use as much (best all) practices in a period of time. Let you and your team in the world to explore their effectiveness, and make people engage in developing software to develop better habits.
XP practices can help people change thinking, but only when they start to use these practices. This requires a transformation of the belief, or at least a temporary conclusion is required. XP does not "ordinary", so you will feel hard to use when you start. Maybe it will never be suitable for you. Maybe it will never be suitable for your company, but if you don't try it, you will not know this. Experiments are appropriate. Try to spend a few weeks using XP, keeping in keeping two points during this process:
Don't give up, even if you feel lonely or unfriendly. Consciously treat your work in different ideas.
The first commitment is obvious. The second commitment needs to be described. Different ideas requires different ideas for programmers' XP practices (such as XP, Pair Programming) and XP practices for business people (such as taking details) to better work. It is impossible to think with different ideas, but you can pretend to do this.
Excellent camouflage people When you encounter an unfamiliar practice, you need to pretend in two ways:
Pretend that you like this task - pretend that you really like it. Pretend that you think about the different ideas of this practice.
Of course, if you really like this practice, you don't have to pretend. But if you don't like it, you must sit down and study it, just like you really like the same. This practice is to be used. It is impossible to pretend that it cannot be encoded. If you hate this practice (most programmers are not love is to hate "controversial" practices, such as the programming), if necessary, vent it, but to overcome it. Don't doubt, no matter how you want it. This is the behavior of the test will. If you only make you angry or taking boycott behavior because your bias or your intentions or experience is best not to do.
So why do you want to think with different ideas? It is said that it is very. Ron Jeffries tell this question in an article, and he doesn't even know it. He talked about YAGNI ("You Aren't Gonna Need IT, you don't need it"), to remind us to change a thinking of thinking:
As a technical expert, most people in us are self-dealing with complexity, and they love to understand the latest things. What we need to remind is that our work is to generate simple, maintainable procedures, soon you can get it, rather than build huge enterprise software to support a few web pages.
He also said that YAGNI reminds us that as a programmer, do not add these characteristics to the software before you need some features. why? Because this behavior should actually be driven by the business, and because we often make the "need" to make a wrong judgment, if we are using other fair practice, then when we need some functions in the future You can add it without additional cost. YAGNI let us focus on simplicity. This is part of the new idea required for XP. Here is some other examples suitable for programmers:
In terms of programming, you know that "three stinkkers, top to get a Zhuge Liang". It is unfair to privately think that other people are fools. Does he have a knowledge gap? If you make up the gap, don't devalue him in private. You will never know that "fool" may also see some things you have not perceived, even high. Test priority development requires you vision. When there is only one class, you can of course scream no test. Its code is quite simple. However, what happens when you have 100 classes and suddenly appear an error? The test can be separated by a very fast speed. If you don't test, you will make you subjected to hours of debugging. First writing tests, you need to accept the fact that you are not fast: You are not all or not. Inform the details, you need you to believe that your customers will drive this software, I refer to truly drive it. You can't make some things, no matter how cool it.
Below is a few examples of business people:
Tell details You need to believe that you can also drive the software. You must think so, "This is my software. I'd better tell people what it should do." The frequent distribution needs you to think "Only better", feedback from the actual user is "driving" project The best way to develop in the direction of your final hope. You must think so, it is very good to publish it to the real need before the software is complete, although some parts may still look very difficult. User testing requires you to believe that allowing you to spend an extra work to write these tests worthwhile. Yes, it will take some time. Do you want the project to succeed? So, when your developer "complete" a feature, let them test to prove that you are very satisfied. Don't seem to be ignorant. Below is an example, showing all of these pretending might look like anything. If you are a programmer, let the user driver, even if you are very disgusted. Unless otherwise telling you how to "tell details", and have a test test that tells you when to complete, don't write a point code. If you disagree with the user's wise requirements, just take a question, let users think about what he is doing. Don't trust the river to comment on how stupid it is. Every developer in the team is required to do this. If you are a customer, don't hurry to give a fuzzy definition, and you want the programmer to explain them clearly. Do your best to write the best demand, you can know that you can ask the right to change the idea later. So I deliberately change my thoughts - this is not big. If you are a programmer, don't bargain, but do not have a good response when your customers change their ideas, but it is what you want.
This pretend will begin to cultivate your habits. These habits will change your thinking. Therefore, you will start thinking that they are natural.
Things focus on value in the final doing seem to be crazy. Your team's business personnel ask you to do our best (meter) for each feature (or more likely to be each group of features). This is a commercial case for software, it may be worthy of writing another article in this column (I will let the reader will decide whether to write or write, so please provide your opinion). At present, I briefly talk about what I mean. For each feature of your team being developed, you should try to answer the following two questions:
This feature will provide what needs (ie, which costs will be reduced, or which income will be improved)? How much does it take to implement this feature?
It is not always answered these questions, I first agreed to this point. Don't answer these questions, don't be nervous, but don't want to answer these questions before you try. As a request, it is important to understand why it is important to understand why they need them. Some people will buy this software. They should know what they will get after spending money.
Brain turn uses XP development software usually requires you to change your ideas, but there are a few new ways of thinking. Please pay close attention to the following points:
Customers need to drive software development at time, not just the development person to make him do this. Developers need to treat customers as part of their team. Customers need to see themselves as part of the team. Customers should be driven by business needs, rather than arbilation pressure from the boss. Customers must convert business needs into very specific features. Otherwise, the programmer will not know how to encode. Customers (possibly in other people's help) must specify an acceptance test that informs developers when they complete each requirement. If the customer does not tell the developer to add features to the developer, the developers cannot do this. Developers must write programmers test at all times.
These points are completely different. They all need discipline constraints. In most cases, the rewards generated by discipline will be to continuously improve the success rate of the project. Adhere to your position. In my future articles, I will tell specific recommendations on how to change my thinking mode. Changes must affect the second point of the higher-level first section may make you a bit difficult to understand. "Customers should be driven by business needs, rather than from the boss's arms stress." I have heard you in a pleasant, "Forget it, Roy. Please don't be so true. The boss will always give you pressure. Pressure It is a level of level 1. "Good, but must change the reaction to this.
Remember the programmer practice? If the content of the customer is twice the content that will be performed once, and he is raised yesterday, then what programmers can say? Say it, or say it, then make changes. They certainly disagreed to work for 100 hours a week. Business people also need to start the same job. This will definitely spread all the way to the high level of the organization. Everyone needs this action. Any other things are unrealistic.
I am happy to say that you want to change from the high level, but it is usually not the case. Sometimes change must be done. This way, because the subordinates do not want to lie to the upper division in order to alleviate short-term pressure. Otherwise, you have to hide the anger in your stomach when you can't deliver the product. To be honest: "No, we can't do that. I think we can do this, that is what we will do." This may make you more troublesome. I don't want to happen. But as Martin Fowler said, "If you can't change your organization, then change it." Find out other ways to fit the actual method. The only reason why things do not have changed is that we refuse to change them.
The next month customer role is the most effective aspect of XP, and the customer role is independent of most IT organizations. Its method is too "informal" and too "mandatory", so that most people feel uncomfortable. However, it is critical to the success of XP projects. The XP project without a customer is destined to far from the end of the user wants to see at the end of the project. Next month, we will discuss that for XP teams, what different changes are needed in psychology and organization to win customers.
Reference
Participate in the Forum on this article. (You can also click on the top or bottom of the article to access the forum.) Read all articles in the Demystifying Extreme Programming Series. Please read the earliest "XP Distilled" (DeveloperWorks, March 2001). "Extreme Programming With IBM Visualage for Java" (April 2001) describes best practices using the leading Java IDE using XP. See "Misconceptions About XP" in Ron Jeffries to get some ideas for XP ideas. This is another good article on the benefit of the false benefits as well as RON: "Pretennd You're NOT AFRAID." In the developerWorks Java technology area, hundreds of other Java related technologies can be found.
If you learn more about XP knowledge, be sure to review the following books:
Extreme Programming Explored, William Wake the (Addison-Wesley, 2001 years) Extreme Programming Applied: Playing to Win, Ken Auer and Roy Miller with (Addison-Wesley, in 2001) Planning Extreme Programming, Kent Beck and Martin Fowler with (Addison- Wesley, 2000) Extreme Programming Explained: EMBRACE CHANGE, KENT BECK (Addison-Wesley, 1999) About the author ROY W. Miller as a software developer and technical consultant for almost 10 years, initially for Andersen Consulting (now ACCENTURE is now effective for Rolemodel Software, INC. (Located in North Carolina). He uses overweight methods and agile methods, including XP. He is an AdDison-Wesley XP family (Extreme Programming Applied: Playing to win) books, and a book on complexity, sudden and software development is currently being prepared. You can contact ROY with RMiller@rolemodellsoft.com or roy@roywmiller.com. You can also visit his personal website www.roywmiller.com.
