The problem of communication(zz)
讲述交流在项目开发过程中的重要性。推荐。Submitted by danbunea on Mon, 07/11/2005 - 15:52.
1. Introduction
A lot of waste and rework is done because of bad communication. In fact, communication is the main factor in a project success or failure. And that does not refer only to software. Alistair Cockburn, wrote an entire book about the importance of communication and builds a methodology around improving communication: the crystal family
2. The big misunderstanding: improving means increasing quantity
The great misunderstanding: improving communication means increase quantity: more meetings, more documentation, more emails and more phone calls. This is profoundly wrong: Communication can only be improve by quality and in many cases improving quantity means increasing the communication problem and not solving it.
One of the most important principles in software is in my opinion looking back to what you did , so you can learn what was good and what was bad, and find ways to improve your activity. This is emphasized in the principles behind the agile manifesto as:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
In a project we did recently we looked back with the customer and we noticed that the bad things in a project developed were mostly caused by bad communication. By bad communication I mean much time needed to get questions answered, ambiguous requirements, not completely specified parts of the system, etc. The immediate answer was that we need to improve communication. For that the answer was that more emails will be sent, more meetings will be help, more conference calls will be held, the specification document will be even larger.
The immediate problem was overcommunication: we held meetings for the sake of having meetings, without a real need, which was in my opinion a great waste of valuable time. We wrote more emails, we held more conference calls, where we discussed about the weather or other pointless things and usually the discussions were very high management level, like are you confident with the plan, with statistics, with waste of time. There were gains, but unfortunately they were shadowed by the new problems.
I realized that people , no matter where they are from, treat the problem of communication not seriously enough. They just say we will do more, when more means quantity instead of quality. But quality is not an easy matter when it comes to communication.
Can communication be improved? What is quality in communication?
What is quality in communication? In seems that Alistair Cockburn discovered a way, based on his long and great experience, to measure communication quality. He says:
Interactive, face-to-face communication is the cheapest and fastest channel for exchanging information (see 1.)
Following Alistair’s advice we need to speak more in front of a whiteboard. Why in front of a whiteboard? Because sometimes, a picture is worth a 1000 words, and this applies to software very well.
Going even further, I have found that a very practical way to improve the quality of communication is visual communication. I noticed that when describing bugs and ways to reproduce then, we or our clients have trouble describing then and describing a step by step process to reproduce them. For this one of the things I did was to ask that customers and others, when reporting bugs even changes, enhancements to include screenshots.
A single screenshot can show even the context in which the bug appeared and give you a great deal of information about the user actions. Screenshots are very cheap, and communicate a lot of information. They can even be automated into the software, so whenever you have a bug, the software takes a screenshot and sends it to you by email along with the last x lines in the log.
Many times, I am just lazy and I don’t want to read. Joel (www.joelonsoftware.com) says in his book: (Users Don't Read the Manual). Well that is very true. I want to use a new technology but I am too lazy to read the help files or the documentation. But wait, a new way of improving communication, emerged: small flash movies, showing you , visually what you need. They seem to pop everywhere. Just take a look at Ruby On Rails This can be done for bugs, for help, for a lot of things. And they are easier to do and send then writing a step by step document.
3. Communication divided by direction.
If we consider ourselves and the team the center of the communication, and we consider where the source and target of communication is, we can divide communication in:
- Communication within organization, team etc
- Communication outside with other stakeholders
3.1 Communication inside the team and organization
Depending on what needs to be communicated, the agile methodologies have ways to deal with communication inside the organization. In my opinion communication inside the team can be divided into two categories: project related and team performance related.
3.1.1 Project related
The project related information must go very fast inside the team. Crystal calls this osmotic communication and it is at the very core of the methodology. It says that people working on the same project need to be able to use the best communication technique: face to face communication , with and without a whiteboard. For this the best technique is to have the entire team collocated, in the same room as much as possible , all facing each other, to be able to ask each other questions and to enable others to hear discussions etc. The team must also have a whiteboard close.
Extreme Programming goes even further, addressing the communication problem mainly with user stories written on pieces of paper and stuck to the wall, and with writing all the business code by pair programming. This means that two programmers, work together at the same computer, understanding 100% of what’s done, and not 50% as if they were doing it separately.
The techniques above and others mainly address communication when time is crucial, but there are other problems of communication within the organization, where time is not that crucial. This is best described by a situation, where you have a team developing a program for a few months, delivering it to the client. Now the client wants to continue the program, add extensions to it etc, but the team that built it is not available anymore or it is available partially. How will the new programmers that come in contact with the program understand what was required, what was done, and how it was done.
Extreme Programming comes up and says that the best way to document a computer program is the code itself and the automated tests, it has and not documents describing what was done, as these documents need to be written by someone who is costly and become obsolete very soon. In most cases, I find this approach very good, as I noticed that recently whenever I download an open source framework or look at code written in the past, the first thing I instinctually do when I want to learn how to use it, I look at the unit tests. They show me how the software can be used, and which are the limitations, in the same language I want to use it: code.
3.1.2 Team performance related
We all want to improve our skills. Many times, we don’t have the information or the time to explore it. A learning environment has been clearly specified as a way to keep programmers motivated on the long term. In fact, this is one of the 7 principles of lean software development (see 3)
It has been proven that pair programming can help a less experienced programmer that is paired with a more experienced one move very fast ahead. The same result is achieved when the team is collocated and the less experienced can hear and see at the whiteboard the more experienced doing something, being able to ask and be given answers very fast.
One great technique, described by Alistair Cockburn is information radiators. These are things you would like to be communicated to others. These can be of help both in project, as you might have the stories stuck on the wall, divided in iterations and in sections: done, in progress and not done. Whomever goes by can see which are done, which are not, very easily without the need of asking anyone about the progress. Ron Jeffries wrote a great article about how to use the walls to communicate about progress, called Big Visible Charts. (see 4)
The information radiator are usually characterized by being pieces of paper with information that are put in places that readers might find them and read them. Usually, after reading a book, in order to get the others to read it, I cut some of the paragraphs I liked most, print it on pieces of paper and put it all over the working environment: on the walls, where people take breaks and smoke cigarettes, in places they feel comfortable. Usually after sticking them on the walls I hear the others referring to them in our conversations. It is also a very good way to speak to managers, with notes stuck on the walls.
Another technique, I found very valuable, to get people to move ahead, improve fast is what I call school like meetings. I have described them in : Self Training. This is mainly , an hour where we take a subject and all read it, then based on some questions we discuss it so we can make sure everyone understands it. This is done within working hours, usually at the first hour in the morning. We have read even a book, chapter by chapter in this manner. It has proven an enormously healthy practice. Let me give you an example.
We started using an ORM framework. I started using it in a project where I teamed up with another developer. I had more experience with ORMs and I showed him a few tricks. At some time, I moved to another project and he was on his own. Then a new project was started and the ORM was used, then another all by other people. After about 4 months I looked into the code of one and I was very badly surprised that is was completely misused. People even were complaining about using this ORM because it is not of any real help. I decided to go to the bottom of the problem and I noticed that the second project was started, having the first project as an example. The mistakes from the first project that my colleague did were moved to the second and taken from granted. The third even more. A lot of people were using the ORM, but the level of knowledge after 4 months was very low.
I had to do something. I immediately gathered everyone, in that afternoon, took the documentation of the ORM and we stopped work and everyone had to read the documentation. I established a set of questions, so I can discover if the technology was reasonably well understood and we started reading. To read, answer the questions it took 4 hours. It took 4 hours to get everyone to understand how this technology. Four hours of no work, a time that could be used to build software. But those for hours proved later one of the best well spent hours in our activity. By understanding the technology in 4 hour they avoided hundred of hours of misusing it and building code that was just reinvented or badly written. Countless hours of debugging were avoided by understanding the ORM and using it right, which decreased the quantity if code by up to 75% and by having a smaller code, less bugs were produced and debugging was a lot easier.
3.2 Communication outside with other stakeholders
The usual stakeholders in a software project are: the customer, the management and the programmers. The management and the programmers can be considered either inside or outside the same circle, so both techniques are applicable. One of the very effective, silent techniques of communicating with management inside is by using the big visible charts that Ron Jeffries describes. Management can be considered depending on specific contexts both inside the programming environment and outside.
Communicating outside the programming environment is divided in my opinion in 2 sections:
1. From outside the team to programmers
2. To outside by programmers
The first can be further divided between:
1. From outside at the beginning, when code is to be written according to what is communicated
2. From outside at the end or after some code is delivered, commonly known as feedback
The software industry seems to consider that the first forms of communication from outside, about what needs to be coded are the requirements document or functional specifications.
Are functional requirements a good way to tell programmers what to build?
In a project we did before, we joined another company to develop it, having developers from the two companies developing the project. With the other company not being an agile oriented company, but more like waterfall process oriented, they came to us with a big functional specification of more then 100 pages. This was later estimated by us to be included in the first 3 week iteration.
The interesting part is that usually when people see such a nicely layout with so much information about screens, user interaction , use cases, their first thought is that this is such a good document with all the information captured and put where it belonged. Everyone looks up to those that did it. It makes some people just say: now this is how things get done properly. But are they?
My first thought was, if we develop this part of the software in 3 weeks, how many weeks was the functional spec written on? I just hoped it was clear so it does not need even more time to be invested in it. Another reaction I saw in my colleagues was that because the document was so big the tended to overlook some of the content. It was too much text. What a mistake that was, because we missed some well hidden big requirements, that were missed in the estimate, but were required at the end of the iteration.
So, now the conclusion: although big functional specification documents seem very good to the untrained eye:
- They are very costly to build (how much time do you need to write 100 pages of text?),
- They might miss important aspects of the program. As Alistair already pointed out, they are not very good at communicating things. They are indirection. The writer cannot capture whatever he needs to capture and the one that reads tends to imagine the rest. Imagination is good, but not in this case because in this case is very costly. This is a problem with alternative means of capturing requirements like direct talk, stories and acceptance tests but the main difference is the amount of time needed to spot those misunderstandings.
- They tend to push the customer proxy, which is the root of all evil. The more indirection, the more misunderstandings. When the information needs several nodes to be transmitted from the ones that knows the business to the one that builds the program, important time is lost, and important precision.
- Big documents are hard to read. Someone might say it is important to capture everything there otherwise programmers would complain about not being complete, but over completing it is just as bad
- What if something changes? What if at the time the doc was written there was one situation and it just changed? What do you do? Throw up the part or the entire document? If you wrote it in 1 month, and it cost you x, you have just lost a 10-20-30-...100% of x and need to pay again for the new one.
My belief is that big functional documents are written to replace trust between the parties involved. We need to write everything in the spec and cast it in stone, so it can't change and we can't be attacked by the customer later. My belief is that where there isn't trust, there isn't good business. Lack of trust is usually compensated with enormous overhead and cost. But after all, not everyone is to be trusted.
Although they are not evil, I am trying to show that big requirements documents are just not the answer in most projects, anymore. We need to move faster and for that the communication needs to be efficient and light. All agile methodologies say that you should have the customer (or customer representative) with you while developing. That enables the most efficient way to communicate. Direct, face to face talk, in front of the running program and in front of the whiteboard. But in order to be organized and not to replace big heavy, beaurecratic methods to communicate to chaos, we still need to have something written so we can organize, plan light. This text that is being written needs only to remind us of a thing that the customer needs implemented. It needs to be able to be written fast, so in case changes come up can be thrown away with no remorse, can be estimated and have business value. This is what is known as a user story.
In the wonderful book ‘User Stories Applied’ of Mike Cohn he defines these characteristics of a user story:
- Independent
- Negotiable
- Valuable to users or customers
- Estimable
- Small
- Testable
To demonstrate a way of improving quality vs quantity in communicating what needs to be done, agile methodologies (re)invented acceptance tests. Instead of making the customer describe what he wants you ask him: “how will I know that what I did is according to what you want?”. And he will start saying what needs to be done to be able to know if what was requested was build and finished or not. Instead of heavy descriptions, two purposes are achieved: you know how you can test and what needs to be done at the same time. Also, ambiguity tends to be dissolved by acceptance tests, because a man in order to know how to test something he must have a very intimate knowledge and understanding of that thing.
Feedback
One of the Extreme Programming values is feedback. If the customer knows how to specify how you can test that you’re done building what he requested, after delivering how can you really be sure? You need his input after seeing and testing the program.
Improvement can only be done as a result of feedback. You write a program, the customer sees it and tells you if that program is good or not. He can also tell you what would be even better to improve the program’s quality.
The virtual nature of software makes it very hard for customers to understand how it’s build and done, so it is very hard for them to communicate you what they really want. To address this extremely important problem, software should be shown very often to the customer. This has two very important benefits:
- he can see where you are, the real progress, and this increases his trust that you’re doing what you were planning to do and that his money is not wasted
- he can see if something is not what he wanted and tell you, so you can fix it or after seeing it he can start to ‘feel’ the software and be able to give you much better information about what he wants. The smaller the delivery cycles, the better.
The small delivery cycles are incredibly important in a project’s communication. They are called within agile communities, iterations and it has been proven that it is best to be between one and 4 weeks in length. As previously stated they give you one very good technique to avoid derailing the project and they embrace changing requirements.
In the past there have been projects, in which we worked for 4-6-8 months and then one day, it was the big day: the software was presented to the client. That day was one of the most stressful situations I and the other programmers could be in. It feels just like waiting in the court of law for the verdict to be pronounced. And the stress is as big as the risk is. What if the customer says that that is not what he wanted? The losses for your company’s 4 months of development are big, and redoing the software is something any business can very hardly cope with. With iterative development, showing the customer the result of the latest iteration, can mean in the worst scenario, that 2 weeks of work are useless. But 2 weeks is much easier to solve then 4 months or more. It is much easier to put one wagon on the rails again, then the whole train.
When the first requirements are being gathered from the customer, you explain him how something can be done, but it is very easy for him to imagine a completely different thing. It is also very hard for him to understand what can be and what cannot be done. What costs more or what costs less. After you deliver the first result of an iteration, he can see a computer program, and everything seems to take shape in his mind. He can use this as a basis for future requirements, and can see about how much time one thing or another takes to be implemented. The second iteration is even better and as the project progresses, the dark foggy unknown that software seemed for him in the beginning is stating to become more easy to control, more clear and he becomes less and less stressed. He starts to understand how things are done and he sees real progress. There is nothing more honest then showing the customer the real program from which he can see the progress.
If feedback is the base for all improvement, how about the internal quality of a project. What we discussed earlier about feedback is the external quality that can be improved, the part that the customer understands and helps improving, but what about internal quality. But what is internal quality in a software project?
A project in my opinion is of high internal quality if it can be tested and debugged easily and it can changed with very few effort. Being able to be changed easily assures the program a much longer life in production, which makes it more cheaper. If the customer pays $1.000.000 for a software and the software is used for 5 years, it will cost $200.000 every year. If the same software can be fixed, readapted and maintained longer in usage, for instance for 10 years, it costs $100.000 per year. Twice cheaper. Well, customers love that.
But how can you make the software give you feedback about its health? In agile methodologies the best technique for receiving feedback from the code itself about its health are automated tests. They can detect problems very early and report them to you so you can act very fast on them. I call my automated tests, break detectors. They help me by giving me fast feedback about things that broke in my software. If I can detect them fast, I can fix them fast and that allows me a great flexibility. I make a change in the software, even in code I didn’t write. Then I run the tests. If they detect a break, I know and I can choose either to reverse the change or repair the affected part. A big problem in a program’s flexibility is that if it becomes big, it is very rigid, and making a change can affect parts of it that you cannot know of. So you are afraid to change it. So the project starts to be doomed. The hardest it is to be changed, the hardest it is for it to cope with the market requirements so the shorter its life will be.
If I were to make a comparison, I would say that If I were the general and my code the army fighting the requirements, my automated tests would be my intelligence center. The bigger my army would get, and the larger the war zone, the hardest it would be for me to know what’s happening in all areas and be able to adapt my strategy to the new conditions. But If I have the break agents placed with the different parts of the army they can report to me about problems and defeat situations very fast. The more agents, the largest the areas of coverage, from where I can receive information from and act upon it.
Feedback is the one thing that corrects and improves the software.
Communicating with the outside
Before starting a project, teach your customer about the importance of good communication and how that is achieved in software and with you in particular. Show a very honest plan, of how the project will be build.
On misunderstanding with agile methodologies, is that it is believed that it is not well planned and to the uninformed this seems like cowboy programming, where everyone takes arbitrary decisions and wait to see what happens. In fact, agile software methodologies are very well planned. They plan light, having the possibility of change in their minds, making the plans simple and very easy to change. The plans are built together with the customers, management and the programmers, on very honest and proved facts, both at a high level, called release planning and at low level called iteration planning.
Projects in Extreme Programming for instance, are divided into releases, which are to be delivered to the real users, or that are going ‘live’ and usually take one to four months to develop and they are also divided into iterations that are between one and four weeks in length and which need to deliver a tested, production ready system to the customer that is in charge of developing the software.
When making the big, release plans, the customer tells the programmers about what he wants as small sentences written on small paper cards, called user stories. All these are gathered from the customer and then estimated roughly by the customer. After being estimated, the customer can see their cost, and then be able to prioritize them. After the prioritization is done, the user stories are put in the iterations, to be developed. Well, this isn’t very different from traditional planning, excepting the level of detail of the user stories. But wait, I forgot to tell you that the plans can be updated after each iteration. This gives great flexibility in what is being built, and it also gives the customer great control on how and what is being built. He is in charge. After all, if you planned to release the software after three months with the customer, and after one month he realized that he misspecified what he wanted, or the business conditions changed, he can turn the direction very easily to the new one. This gives agile project great adaptability which can deliver the customer a much better product, as it can be easily changed and the control is in his hands.
After each iteration, the customer sees the software planned and developed in that iteration, and can readapt according to what he sees. He can reprioritize, give up some features and add new ones. If the plan is light, it can be easily changed and readapted. He receives the best feedback about what you’re doing for him by seeing the software and this gives him the possibilities to tell you how to improve it, by giving you feedback.
Showing the customer, the product instead of reports, in the middle of the production, is a great way to communicate and build a product of much bigger value to the customer.
Conclusion
Although, maybe what I have said earlier might need a level of knowledge about agile technologies, I hope it can also open an interest in those that have not used them , by showing different strategies on how the problem of communication is addressed by agile methodologies. This really can improve products, customer satisfaction, can decrease costs and in all improve the way we do business.
Charging the customer for miscommunication, is the worst way to address the communication problem, however it is still extensively used. This makes software more expensive, and generates new problems and new stresses that can be pushed to programmers or customer. Just as a simple example, if it costed me x+something to build the detailed requirements documents, and the customer doesn't want to pay more then I'll just get the programmers to build the software in less time with less people. Guess how much programmers under stress cost?
[ Last edited by connie on 2005-11-8 at 13:13 ]
Ding
I remember that I got this question in an interview. The question is "Why are the communication skills very important when you are working in a QA team?"...I was lost... 我周末翻译一下这篇文章,不晓大家是否有异意. 支持！加油！
不好意思
上周特忙，这一周末还要忙，所以翻译得推迟了，希望大家谅解！ to jody:never mind.
恰好自己在交流上有问题，所以就翻译了。第一部分
The problem of communication交流
1. Introduction
1.引言
A lot of waste and rework is done because of bad communication. In fact, communication is the main factor in a project success or failure. And that does not refer only to software. Alistair Cockburn, wrote an entire book about the importance of communication and builds a methodology around improving communication: the crystal family
由于交流得不通畅，我们浪费了大量的时间，做了很多重复的工作。其实，交流是决定任何一个项目成败的主要因素，且不仅局限于软件开发项目。Alistair Cockburn曾专门就交流的重要性写了一本书，围绕如何改善交流提出了一套方法，称作“水晶家庭”。
2. The big misunderstanding: improving means increasing quantity
2.一个很大的误解：改善交流就意味着增加交流次数
The great misunderstanding: improving communication means increase quantity: more meetings, more documentation, more emails and more phone calls. This is profoundly wrong: Communication can only be improve by quality and in many cases improving quantity means increasing the communication problem and not solving it.
一个很大的误解就是改善交流意味着增加交流的次数：多开会，多写文档，多发email，多能电话。这样做是绝对错误的，因为只能通过提高交流的质量来改善交流，并且很多情况下增加交流的次数就等于加大交流问题的难度而不是在解决问题。
One of the most important principles in software is in my opinion looking back to what you did , so you can learn what was good and what was bad, and find ways to improve your activity. This is emphasized in the principles behind the agile manifesto as:
在我看来，软件开发中的最重要的原则之一就是重新审视已经做过的东西。这样你可以看到哪些是好的，哪些是不好的，从而找到改善你的行动的方法。这一点在后面的软件开发原则中加以强调。先来看一个简短的表述：
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
通常，团队先对如何让工作更有效做出反应，然后依次调整自己的行为。
In a project we did recently we looked back with the customer and we noticed that the bad things in a project developed were mostly caused by bad communication. By bad communication I mean much time needed to get questions answered, ambiguous requirements, not completely specified parts of the system, etc. The immediate answer was that we need to improve communication. For that the answer was that more emails will be sent, more meetings will be help, more conference calls will be held, the specification document will be even larger.
在最近做的一个项目中，我们和客户一起检查所做的工作，发现其中做得不好的部分大都是由交流不好造成的。这里说交流不好，我是指回答提问需要很多时间，需求有歧义，还有系统中设计得不完善的部分，等等。当时首先想到的就是我们需要改善交流，进一步的回答就是应该多发一些邮件，多开一些会，多进行一些电话会议，设计说明书要写得更详细一些。
The immediate problem was overcommunication: we held meetings for the sake of having meetings, without a real need, which was in my opinion a great waste of valuable time. We wrote more emails, we held more conference calls, where we discussed about the weather or other pointless things and usually the discussions were very high management level, like are you confident with the plan, with statistics, with waste of time. There were gains, but unfortunately they were shadowed by the new problems.
这样做的直接的问题就是交流过度：仅仅为了开会而开会，根本不是实际需要。在我看来这极大地浪费了宝贵的时间。我们比以前发了更多的邮件，我们搞了更多的电话会议，却是去讨论天气或是其他没有意义的事情。进行的讨论经常是在非常高的管理层面上的，比如：你是否确信这个计划，是否相信这些统计数据，是否认为浪费了时间。这固然有所收获，但这些收获又被新的问题埋没了。
I realized that people , no matter where they are from, treat the problem of communication not seriously enough. They just say we will do more, when more means quantity instead of quality. But quality is not an easy matter when it comes to communication.
我觉得无论是客户还是开发者，他们都没有足够认真地对待交流的问题。他们只是说我们会交流得更多，这里的多是指数量的多而非质量的好。但是谈及交流的质量绝不是件容易的事。
Can communication be improved? What is quality in communication?
可以改善交流吗？交流的质量是指什么？
What is quality in communication? In seems that Alistair Cockburn discovered a way, based on his long and great experience, to measure communication quality. He says:
什么是交流的质量？Alistair Cockburn通过他的长期且丰富的经历，似乎发现了一个方法，用以衡量交流的质量，他说：
Interactive, face-to-face communication is the cheapest and fastest channel for exchanging information (see 1.)
互动式的，面对面的交流是传递彼此信息的共最低廉最快捷的途径。
Following Alistair’s advice we need to speak more in front of a whiteboard. Why in front of a whiteboard? Because sometimes, a picture is worth a 1000 words, and this applies to software very well.
根据 Alistair的建议，我们需要更多地在书写板前进行交流。为什么要在书写板前交流呢？因为有时一个图比1000句话更管用，这很适用于软件开发工作。
Going even further, I have found that a very practical way to improve the quality of communication is visual communication. I noticed that when describing bugs and ways to reproduce then, we or our clients have trouble describing then and describing a step by step process to reproduce them. For this one of the things I did was to ask that customers and others, when reporting bugs even changes, enhancements to include screenshots.
再进一步说，我已经发现可视化的交流是提高交流质量的一种非常实用的手段。我发现在描述个bug以及复现bug的方法时，我们或我们的客户就遇到了描述的难题，很难把bug和复现方法说清楚。为此，我做的一件事情就是要求客户或是其他人在报告bug甚至改变时同时提供屏幕截图。
A single screenshot can show even the context in which the bug appeared and give you a great deal of information about the user actions. Screenshots are very cheap, and communicate a lot of information. They can even be automated into the software, so whenever you have a bug, the software takes a screenshot and sends it to you by email along with the last x lines in the log.
仅仅单独的一张屏幕截图就能说明bug出现的环境而且给出了很多有关用户操作的信息。屏幕截图代价低廉，而且提供了大量的可用于交流的信息。我们甚至可以在软件中自动产生屏幕截图。所以当你遇到一个bug后，软件就会产生一个屏幕截图，并通过email将运行日志的最后几行一同发送给你，
Many times, I am just lazy and I don’t want to read. Joel (www.joelonsoftware.com) says in his book: (Users Don't Read the Manual). Well that is very true. I want to use a new technology but I am too lazy to read the help files or the documentation. But wait, a new way of improving communication, emerged: small flash movies, showing you , visually what you need. They seem to pop everywhere. Just take a look at Ruby On Rails This can be done for bugs, for help, for a lot of things. And they are easier to do and send then writing a step by step document.
很多时候，我都懒得去看写出来的东西，Joel (www.joelonsoftware.com)在他的著作《用户不会阅读手册》如是说。哎，这句话太对了。我想去用一个新的东西，却懒得去看什么帮助文件或使用手册。但是别急，一种新的改善交流的方式出现了：小小的flash影片把你所需要的展示给你看。好像flash影片到处都很流行。只要看一下Ruby On Rails吧。这种方式可以用于bug报告，可以用于软件的帮助，可以用于很多事情。比起一步一步进行描述的文档来，flash影片制作和发布都容易得多。
第二部分
3. Communication divided by direction.3.交流的分类（按交流对象分）
If we consider ourselves and the team the center of the communication, and we consider where the source and target of communication is, we can divide communication in:
如果我们把我们自己和团队作为交流的中心，考虑交流的对象，我们可以把交流分为：
- Communication within organization, team etc
- Communication outside with other stakeholders
－公司或团队内部的交流
－与外界其他人士的交流
3.1 Communication inside the team and organization
3.1 团队或公司内部的交流
Depending on what needs to be communicated, the agile methodologies have ways to deal with communication inside the organization. In my opinion communication inside the team can be divided into two categories: project related and team performance related.
根据需要交流的内容，公司内部的交流可以有很多快捷的方法。在我看来，团队内部的交流可以分成两类：与项目相关的，与团队表现相关的。
3.1.1 Project related
3.1.1与项目相关的交流。
The project related information must go very fast inside the team. Crystal calls this osmotic communication and it is at the very core of the methodology. It says that people working on the same project need to be able to use the best communication technique: face to face communication , with and without a whiteboard. For this the best technique is to have the entire team collocated, in the same room as much as possible , all facing each other, to be able to ask each other questions and to enable others to hear discussions etc. The team must also have a whiteboard close.
在团队内部，与项目有关的信息必须传递得非常快。“水晶家庭”交流法把这种交流方式称作渗透式交流，并把这种方式作为核心方式。渗透式交流认为，工作在同一个项目中的人员必须能够使用最有效的交流手段：面对面交流，使用或不使用书写板。为此，最佳的做法是尽可能将整个团队的人员都安置到一个房间里，都能互相看到对方，都能互相提出问题，都能使其他人听到讨论，等等。附近还要有书写板。
Extreme Programming goes even further, addressing the communication problem mainly with user stories written on pieces of paper and stuck to the wall, and with writing all the business code by pair programming. This means that two programmers, work together at the same computer, understanding 100% of what’s done, and not 50% as if they were doing it separately.
终极规划法要求得更严格，此法要求交流问题主要依靠写在纸上且粘在墙上的用户笔记，要求通过组对编程的方式来编写所有的商业代码。组对编程的意思是两名程序员使用同一台电脑进行工作，要100%地知晓所做的工作，而不能只达到50%，就像他们各自独立进行工作一样。
The techniques above and others mainly address communication when time is crucial, but there are other problems of communication within the organization, where time is not that crucial. This is best described by a situation, where you have a team developing a program for a few months, delivering it to the client. Now the client wants to continue the program, add extensions to it etc, but the team that built it is not available anymore or it is available partially. How will the new programmers that come in contact with the program understand what was required, what was done, and how it was done.
上面提到的以及其他的方法主要针对时间是首要因素情况下的交流。然而当时间不是首要的因素时，一个公司内部的交流会遇到其他问题。这一点最好举个例子来说明。假如你有一个团队，他们用几个月的时间开发项目，然后把产品交付客户。现在客户要求继续进行这个项目，同时要扩展这个项目。但当初启动这个项目的团队人员找不到或找不全了。那么新的接触该项目的编程人员如何了解客户需求，应该做什么，应该怎么做？
Extreme Programming comes up and says that the best way to document a computer program is the code itself and the automated tests, it has and not documents describing what was done, as these documents need to be written by someone who is costly and become obsolete very soon. In most cases, I find this approach very good, as I noticed that recently whenever I download an open source framework or look at code written in the past, the first thing I instinctually do when I want to learn how to use it, I look at the unit tests. They show me how the software can be used, and which are the limitations, in the same language I want to use it: code.
极限编程站出来说帮助了解一个计算机程序的最好的说明文档就是代码本身以及自动化测试。程序本身就已经说明了要做什么，无需编写说明文档。因为额外的说明文档是需要花钱找人来写的，而且不久就会变成开发的阳关大道。大多数时候，我发现这种方法很有效。因为我注意到每当我下载了开源的框架或是阅读过去写的代码而想要知道怎么使用这程序的时候，这种方法是我下意识做的第一件事。我去看那些单元测试用例，这些测试用例向我展示应该怎么使用那个软件，什么是限制做的。在同一种语言中我想使用它：代码。
第三部分
3.1.2 Team performance related3.1.2 与团队表现相关的交流
We all want to improve our skills. Many times, we don’t have the information or the time to explore it. A learning environment has been clearly specified as a way to keep programmers motivated on the long term. In fact, this is one of the 7 principles of lean software development (see 3)
我们都想提高自己的技能。我们却常常没有时间或资料去研究。作为长期保持程序员动力的一个学习环境已经建立起来了。事实上，这是快速软件开发的七项原则之一。
It has been proven that pair programming can help a less experienced programmer that is paired with a more experienced one move very fast ahead. The same result is achieved when the team is collocated and the less experienced can hear and see at the whiteboard the more experienced doing something, being able to ask and be given answers very fast.
经过验证，与编程老手组对时，组对编程可以帮助新手快速提高编程能力。当团队成员安置在一起工作时会取得同样的效果，新手可以直接听到，可以通过书写板直接看到老手的工作，可以向老手提问并能很快得到回答。
One great technique, described by Alistair Cockburn is information radiators. These are things you would like to be communicated to others. These can be of help both in project, as you might have the stories stuck on the wall, divided in iterations and in sections: done, in progress and not done. Whomever goes by can see which are done, which are not, very easily without the need of asking anyone about the progress. Ron Jeffries wrote a great article about how to use the walls to communicate about progress, called Big Visible Charts. (see 4)
Alistair Cockburn描述了一个很好的交流手段：信息辐射物。这是指你愿意同其他人交流的事情。因为你可能有贴在墙上的笔记，这些事情对分割成几个周期的项目和分阶段（已做，正做，未做）的项目都很有帮助。有人走过这个贴在墙上的小纸片时，不用问别人进展情况就能把什么已经做完，什么还没做看得清清楚楚。Ron Jeffries写过一篇好文章，叫Big Visible Charts，介绍如何使用墙壁来交流项目的进展情况。
The information radiator are usually characterized by being pieces of paper with information that are put in places that readers might find them and read them. Usually, after reading a book, in order to get the others to read it, I cut some of the paragraphs I liked most, print it on pieces of paper and put it all over the working environment: on the walls, where people take breaks and smoke cigarettes, in places they feel comfortable. Usually after sticking them on the walls I hear the others referring to them in our conversations. It is also a very good way to speak to managers, with notes stuck on the walls.
信息辐射物通常是写有某种消息的小纸条，被人粘贴在别人能看到的地方。我在读完一本书后，为了让别人也能读一读，我通常会把里面我最喜欢的一些段落截下来打印上纸条上，然后在工作区里到处帖：墙上，休息或抽烟的地方，在别人感觉方便阅读的地方。常常是把小纸条贴到墙上以后就能听到别人在谈话中议论上面的内容。对管理者来说这也是一个非常好的方法，只需把通知贴在墙上。
Another technique, I found very valuable, to get people to move ahead, improve fast is what I call school like meetings. I have described them in : Self Training. This is mainly , an hour where we take a subject and all read it, then based on some questions we discuss it so we can make sure everyone understands it. This is done within working hours, usually at the first hour in the morning. We have read even a book, chapter by chapter in this manner. It has proven an enormously healthy practice. Let me give you an example.
另一种我觉得有价值的交流方式被我叫做上课式的会议，可以让人进步，加快工作速度。这种方式我已经在《自我训练》中讲过了。主要思路是在一个小时的时间内，我们来共同阅读一个话题，然后根据一些问题讨论这个话题，这样可以保证每一个人都理解了这个话题。这种方式要在工作时间进行，通常选择早晨的第一个小时时间。我们已经用这种方式一章接一章地阅读完了一本书。这方式带给我们大量有效的实践经验。我来给你们讲个例子吧。
We started using an ORM framework. I started using it in a project where I teamed up with another developer. I had more experience with ORMs and I showed him a few tricks. At some time, I moved to another project and he was on his own. Then a new project was started and the ORM was used, then another all by other people. After about 4 months I looked into the code of one and I was very badly surprised that is was completely misused. People even were complaining about using this ORM because it is not of any real help. I decided to go to the bottom of the problem and I noticed that the second project was started, having the first project as an example. The mistakes from the first project that my colleague did were moved to the second and taken from granted. The third even more. A lot of people were using the ORM, but the level of knowledge after 4 months was very low.
当初我们开始使用一个ORM框架。在由我和另一名开发人员组成一队的一个项目里，我开始使用ORM框架。那里我对ORM已经很有经验了，所以我向他演示了一些技巧。有一段时间，我去了另一个项目而他独自做那个项目。然后一个新的项目开始了，并且要使用ORM框架。后来又开始了个新的项目，也要用ORM框架，是由其他人去做。大约4个月后我去检查一个项目的代码。我万分吃惊地发现项目里的ORM框架完全用错了。开发人员甚至开始抱怨不该用这个ORM框架，因为它没有任何帮助。我决定找到问题的根源，结果发现第二个项目开始后拿第一个项目当作参照。第一个项目里我同事犯的错误被认为理所当然地挪到了第二个项目里。第三个项目更差劲。一大堆人都在使用ORM，但4个月后，ORM的掌握水平还是很低。
I had to do something. I immediately gathered everyone, in that afternoon, took the documentation of the ORM and we stopped work and everyone had to read the documentation. I established a set of questions, so I can discover if the technology was reasonably well understood and we started reading. To read, answer the questions it took 4 hours. It took 4 hours to get everyone to understand how this technology. Four hours of no work, a time that could be used to build software. But those for hours proved later one of the best well spent hours in our activity. By understanding the technology in 4 hour they avoided hundred of hours of misusing it and building code that was just reinvented or badly written. Countless hours of debugging were avoided by understanding the ORM and using it right, which decreased the quantity if code by up to 75% and by having a smaller code, less bugs were produced and debugging was a lot easier.
我必须做点什么了。在那天下行，我立刻招集了所有的人，把有关ORM的资料都拿了来，我们放弃了正在进行的工作，所有以都必须阅读资料。我设计了一系列的问题，这样我能发现大家是否充分地正确地理解了这项技术。然后我们开始阅读资料。我们花了4个小时来阅读资料和回答问题。我们花了4个小时让每一个人都理解这项技术到底是怎么回事。4个小时，没有做什么任何工作，这时间本来可以拿来开发软件的。但这四个小时后来证明是我们的工作中利用得最充分的时间。通过4个小时的对这项技术的理解，他们避免了对这项技术的数百个小时的错误使用，重复编程，或是粗糙编程。通过对ORM的理解和正确使用，无数小时的调试过程被避免了。这直接节省了多达75%的代码量，而且由于代码量少了，开发过程中产生的bug也减少了，调试程序也容易子多了。
第四部分
3.2 Communication outside with other stakeholders与外部的其他相关人士交流
The usual stakeholders in a software project are: the customer, the management and the programmers. The management and the programmers can be considered either inside or outside the same circle, so both techniques are applicable. One of the very effective, silent techniques of communicating with management inside is by using the big visible charts that Ron Jeffries describes. Management can be considered depending on specific contexts both inside the programming environment and outside.
通常一个软件项目的相关人士有：客户，项目管理层和编程人员。项目管理层和编程人员既可以看作是开发环境内部的也可以看作是外部 的人士，所以内部交流和外部交流这两种方式都可适用于他们。与内部管理层交流的一个非常有效且安静的方式是使用Ron Jeffries描述的醒目图表。项目管理层可以根据开发环境内部的和外部的特定情形加以考虑。
Communicating outside the programming environment is divided in my opinion in 2 sections:
我认为在开发环境外部的交流可以分为两个部分。
1. From outside the team to programmers
2. To outside by programmers
1.从团队外部到编程人员
2.从编程人员到团队外部
The first can be further divided between:
第一部分可以进一步划分为：
1. From outside at the beginning, when code is to be written according to what is communicated
2. From outside at the end or after some code is delivered, commonly known as feedback
1.开发之初的交流，此时正要根据所交流的内容进行代码的编写。
2.开发结尾，或一些代友发布以后的交流，通常叫做反馈。
The software industry seems to consider that the first forms of communication from outside, about what needs to be coded are the requirements document or functional specifications.
关于所需要编写的代码，软件行业似秋把来自外部的第一种交流方式看作是需求文档或功能设计。
Are functional requirements a good way to tell programmers what to build?
要告诉编程人员应该做什么，功能需求文档是一个好的方式吗？
In a project we did before, we joined another company to develop it, having developers from the two companies developing the project. With the other company not being an agile oriented company, but more like waterfall process oriented, they came to us with a big functional specification of more then 100 pages. This was later estimated by us to be included in the first 3 week iteration.
我们以前做过一个项目，是和另外一家公司合作开发，就是说来自两家的开发人员共同开发这个项目。那家公司不是使用快速原型模型的公司，倒更像使用瀑布模型，所以他们一开始就带给我们100多页的功能需求说明文档。后来我们估计这些功能需求要花掉最开始的三个星期的时间。
The interesting part is that usually when people see such a nicely layout with so much information about screens, user interaction , use cases, their first thought is that this is such a good document with all the information captured and put where it belonged. Everyone looks up to those that did it. It makes some people just say: now this is how things get done properly. But are they?
有趣的是当人们看到这样一个包括界面，用户交互对话框还有使用案例的如此众多信息的文档，通常他们的第一反应就是这是一个多好的文档，所有该有的信息都有了。每一个人都赞许那些写这文档的人。有些人直接说：这个文档就指明了工作应该怎么做。但真是这样吗？
My first thought was, if we develop this part of the software in 3 weeks, how many weeks was the functional spec written on? I just hoped it was clear so it does not need even more time to be invested in it. Another reaction I saw in my colleagues was that because the document was so big the tended to overlook some of the content. It was too much text. What a mistake that was, because we missed some well hidden big requirements, that were missed in the estimate, but were required at the end of the iteration.
我的第一个想法就是，如果我们在三个星期内开发软件的这个部分，那么功能说明要写多少个星期呢？我只是希望功能需求很清楚，这样就不用花费太多时间了。我在我同事中间发现的另一个反应是，因为这文档篇幅很长，他们跳过了其中的一些内容。里面的文字太多了。这样所犯的错误是，由于我们漏掉了一些隐藏在大需求中的需求，这些需求就会在需求评估的时候漏掉，但在开发周期的结尾又需要了。
So, now the conclusion: although big functional specification documents seem very good to the untrained eye:
所以现在的结论是：尽管用非专业的眼光看，长篇幅的功能说明文档非常好，但是：
- They are very costly to build (how much time do you need to write 100 pages of text?),
－书写这些文档开销很大（写一篇100页的文字材料你需要多长时间？）
- They might miss important aspects of the program. As Alistair already pointed out, they are not very good at communicating things. They are indirection. The writer cannot capture whatever he needs to capture and the one that reads tends to imagine the rest. Imagination is good, but not in this case because in this case is very costly. This is a problem with alternative means of capturing requirements like direct talk, stories and acceptance tests but the main difference is the amount of time needed to spot those misunderstandings.
－这些文档可能会遗漏项目的重要方面。正如Alistair已经指出的，交流一些事情，长篇文档并不很好。因为解决问题不直接。写文档的人不能把他所有要写的东西都写出来，看文档的人总是去猜测没写出来的东西。猜测是好的，但不能用在这里，因为这种情况下猜测的代价太大了。较之说明需要的其他一些方法，如直接交谈，用户笔记和验收测试，这就是一个问题。但主要的不同点在于发现误解所需要的时间的长短。
- They tend to push the customer proxy, which is the root of all evil. The more indirection, the more misunderstandings. When the information needs several nodes to be transmitted from the ones that knows the business to the one that builds the program, important time is lost, and important precision.
－这些说明文档会迫使客户做代言人，这是这些文档最可恶之外。交流得越不直接，误解就越多。如果一条信息需要很多中间人才能从知道事情的人传到编写程序的人，这就失去了宝贵的时间，也失去了消息的准确性。
- Big documents are hard to read. Someone might say it is important to capture everything there otherwise programmers would complain about not being complete, but over completing it is just as bad
－长篇的文档读起来很困难。也许有人会说，把所有的事情都说到是很重要的，否则开发人员会抱怨说写得不完整，但过分的完整也不是好事。
- What if something changes? What if at the time the doc was written there was one situation and it just changed? What do you do? Throw up the part or the entire document? If you wrote it in 1 month, and it cost you x, you have just lost a 10-20-30-...100% of x and need to pay again for the new one.
－如果一些需求变化了怎么办？如果正在写文档的时候出现了一种新的需求要怎么修改文档呢？你会怎么办呢？舍弃部分或是全都不要了吗？如果你在一个月内写那文档，花费共计x，那么此时你已经失去了x的10-20-30-直至100%，而且还需要为新的文档重新花费。
My belief is that big functional documents are written to replace trust between the parties involved. We need to write everything in the spec and cast it in stone, so it can't change and we can't be attacked by the customer later. My belief is that where there isn't trust, there isn't good business. Lack of trust is usually compensated with enormous overhead and cost. But after all, not everyone is to be trusted.
我坚信长篇功能说明文档的撰写会破坏软件项目有关人士间的信任。我们需要在说明文档中写那些一成不变的东西，这样我们就不会在以后受到客户的揆情度理了。我坚信没有信任就没有好的商业事务。信任的缺失往往要由大量的管理费用和开发费用来补偿。但毕竟不是所有的人都可信。
Although they are not evil, I am trying to show that big requirements documents are just not the answer in most projects, anymore. We need to move faster and for that the communication needs to be efficient and light. All agile methodologies say that you should have the customer (or customer representative) with you while developing. That enables the most efficient way to communicate. Direct, face to face talk, in front of the running program and in front of the whiteboard. But in order to be organized and not to replace big heavy, beaurecratic methods to communicate to chaos, we still need to have something written so we can organize, plan light. This text that is being written needs only to remind us of a thing that the customer needs implemented. It needs to be able to be written fast, so in case changes come up can be thrown away with no remorse, can be estimated and have business value. This is what is known as a user story.
尽管长篇文档并不是非常可恶，我还是想证明长篇的文档已经不再是大多数项目所需要的了。我们需要快速的进展因此交流也需要高效而简捷。所有的快速原型模型的方法告诉我们，当你开发的时候，应该让客户（或客户代表）在你身边。我们需要直接的，面对面的交谈，而且是在运行程序时，在书写板前进行交谈。但为了组织开发要素并且也不舍弃那些用来解决争端的大规模的部门级交流方式，我们仍然需要撰写一些文档以便我们能快捷地组织与计划项目。所写的文字仅仅是提醒我们客户要求实现的东西。这个文档应该能够快速地写好，以便需求发生了变化就可以马上报废而不用我们心疼。这个文档还应能够被评估而且有商业价值。这就是所谓的用户笔记。
In the wonderful book ‘User Stories Applied’ of Mike Cohn he defines these characteristics of a user story:
- Independent
- Negotiable
- Valuable to users or customers
- Estimable
- Small
- Testable
Mike Cohn的书《用户笔记应用》中定义用户笔记有以下性质：
－独立
－可以协商
－对用户或客户有价值
－可以评估
－小巧
－可以评测
第五部分
To demonstrate a way of improving quality vs quantity in communicating what needs to be done, agile methodologies (re)invented acceptance tests. Instead of making the customer describe what he wants you ask him: “how will I know that what I did is according to what you want?”. And he will start saying what needs to be done to be able to know if what was requested was build and finished or not. Instead of heavy descriptions, two purposes are achieved: you know how you can test and what needs to be done at the same time. Also, ambiguity tends to be dissolved by acceptance tests, because a man in order to know how to test something he must have a very intimate knowledge and understanding of that thing.改善交流的质量还是提高交流的数量，我们需要做什么呢？为了说明途径，快速原型模型提出了（或者说“重新提出了”）验收测试的概念。不用客户描述他想要什么，相反，你要问他：“我怎样才能知道我做的就是你想要的？”然后他为了能弄清楚他要求做的是否已经开始做或已经做好了，他就会跟你讲需要做些什么。这样就省去了繁琐的叙述，而且同时达到了两个目的：你知道了你能怎么去测试，还有需要去做什么。同样，通过验收测试，一些不清楚的地方地慢慢地得以消除。这是因为一个人为了测试某种东西他必须有非常丰富的相关知识而且对那样东西非常了解。
Feedback
反馈
One of the Extreme Programming values is feedback. If the customer knows how to specify how you can test that you’re done building what he requested, after delivering how can you really be sure? You need his input after seeing and testing the program.
极限编程的价值之一就是信息的反馈。如果客户明白如果说明你可以用什么方法去测试按他要求所做的东西，那么当你把初样给他以后，你需要的就是他在看完和测试结束后的反馈信息了。
Improvement can only be done as a result of feedback. You write a program, the customer sees it and tells you if that program is good or not. He can also tell you what would be even better to improve the program’s quality.
只有在反馈信息后，才能去谈改善程序的质量。你写了一个程序，客户看过以后告诉你这个程序好还是不好。他也会告诉你该怎么做得更好才能去改善程序的质量。
The virtual nature of software makes it very hard for customers to understand how it’s build and done, so it is very hard for them to communicate you what they really want. To address this extremely important problem, software should be shown very often to the customer. This has two very important benefits:
软件的实质决定了客户很难理解理解是怎么被创建出来的，他们也很难跟你说清楚他们究竟想要什么。为了解决这个极端重要的问题，你应该经常向客户演示所做的软件。这样做有两个非常重要的好处：
- he can see where you are, the real progress, and this increases his trust that you’re doing what you were planning to do and that his money is not wasted
－客户可以清楚你到底进展到什么地步了，这样可以增加他的信任感。他明白你正在按计划行事，他的钱没有白废。
- he can see if something is not what he wanted and tell you, so you can fix it or after seeing it he can start to ‘feel’ the software and be able to give you much better information about what he wants. The smaller the delivery cycles, the better.
－客户会看到有些东西是不是他想要的，他会告诉你，这样你可以去修改软件；或者在见到软件后他可以开始“体验”这个软件，因而能就他的需求给你提供更好的信息。信息传递的周转时间越短越好。
The small delivery cycles are incredibly important in a project’s communication. They are called within agile communities, iterations and it has been proven that it is best to be between one and 4 weeks in length. As previously stated they give you one very good technique to avoid derailing the project and they embrace changing requirements.
在项目的交流中，信息传递周转时间短无疑是非常重要的。在快速原型模型中信息传递周转时间被称为信息传递周期。已经证明信息传递周期最佳的是在1至4周。如前所述，信息传递周期为你提供了避免项目偏离目标的好的办法，而且信息传递周期也适合快速变化的需求。
In the past there have been projects, in which we worked for 4-6-8 months and then one day, it was the big day: the software was presented to the client. That day was one of the most stressful situations I and the other programmers could be in. It feels just like waiting in the court of law for the verdict to be pronounced. And the stress is as big as the risk is. What if the customer says that that is not what he wanted? The losses for your company’s 4 months of development are big, and redoing the software is something any business can very hardly cope with. With iterative development, showing the customer the result of the latest iteration, can mean in the worst scenario, that 2 weeks of work are useless. But 2 weeks is much easier to solve then 4 months or more. It is much easier to put one wagon on the rails again, then the whole train.
过去曾有一个项目，我们为之工作了4至6到8个月的时间，然后有一天，在那重要的一天软件被提交给了用户。那天是我和其他编程人员压力最大的一天。感觉就像正坐在即将宣判的法庭里。当时的压力和风险一样大。如果用户说那不是他想要的该怎么办？你的公司的4个月的开发的代价是巨大的，而且重做软件是任何一家公司都难以应付的。在周期式的开发中，最糟糕的情况就是向客户演示最新一轮的开发结果却被指出2周的工作是没有用的。但2周的问题比4个月或更长时间产生的问题解决起来要容易得多了。把一节车厢移回轨道总比把整列车厢移回轨道要容易得多。
When the first requirements are being gathered from the customer, you explain him how something can be done, but it is very easy for him to imagine a completely different thing. It is also very hard for him to understand what can be and what cannot be done. What costs more or what costs less. After you deliver the first result of an iteration, he can see a computer program, and everything seems to take shape in his mind. He can use this as a basis for future requirements, and can see about how much time one thing or another takes to be implemented. The second iteration is even better and as the project progresses, the dark foggy unknown that software seemed for him in the beginning is stating to become more easy to control, more clear and he becomes less and less stressed. He starts to understand how things are done and he sees real progress. There is nothing more honest then showing the customer the real program from which he can see the progress.
当从客户那里收集来第一批的需求后，你会向客户解释一些功能应该怎么做，但对客户来说要想出一个完全不同的功能是很容易的事。让他理解什么东西可以实现什么东西不可以实现是很困难的事。让客户明白什么东西花费多什么东西花费少也是很困难的。而当你把第一个周期的开发结果交给客户后，他可以看到一个电脑程序，里面的每一个东西都在他脑中形成印象。他可以把这印象作为将来需求的一个根据。而且他能明白一个功能实现需要多长时间，另一个功能又需要多长时间。开发的第二个周期就会更好地进行了，并且随着软件项目的进展，最初笼罩在客户头上的对软件的迷雾会变得越来越淡，他对软件的认识会越来越清楚，他的压力也变得越来越轻。他开始理解工作是怎样开展的，他可以看到真正的开发过程。这是向客户展示项目进展的最好的方法。
[ 本帖最后由 brilliantking 于 2006-4-27 17:24 编辑 ]
第六部分
If feedback is the base for all improvement, how about the internal quality of a project. What we discussed earlier about feedback is the external quality that can be improved, the part that the customer understands and helps improving, but what about internal quality. But what is internal quality in a software project?如果把信息反馈作为所有的软件改进的基础，那么项目内部的质量又怎样呢？我们刚才关于信息反馈的讨论是可以得到改善的外部的质量，是客户可以明白而且可以帮助改进的，但是内部质量又该如何改进呢？软件项目内部的质量又指什么呢？
A project in my opinion is of high internal quality if it can be tested and debugged easily and it can changed with very few effort. Being able to be changed easily assures the program a much longer life in production, which makes it more cheaper. If the customer pays $1.000.000 for a software and the software is used for 5 years, it will cost $200.000 every year. If the same software can be fixed, readapted and maintained longer in usage, for instance for 10 years, it costs $100.000 per year. Twice cheaper. Well, customers love that.
在我看来，如果一个软件项目可以很容易地进行测试和调试，而且花很少精力就可以修改，那它一定要有很高的内部质量。能够容易地修改保证了软件产品会用更长的生命，这一点使软件产品更便宜。如果客户为软件花费了一百万美元，而这软件能用5年，那么每年的花费就是20万美元。如果这个软件可以被修复，修改，维护以便用得长一些，可以保证用10年的话，那么每年只要花费10万美元。噢，客户当然喜欢那样了。
But how can you make the software give you feedback about its health? In agile methodologies the best technique for receiving feedback from the code itself about its health are automated tests. They can detect problems very early and report them to you so you can act very fast on them. I call my automated tests, break detectors. They help me by giving me fast feedback about things that broke in my software. If I can detect them fast, I can fix them fast and that allows me a great flexibility. I make a change in the software, even in code I didn’t write. Then I run the tests. If they detect a break, I know and I can choose either to reverse the change or repair the affected part. A big problem in a program’s flexibility is that if it becomes big, it is very rigid, and making a change can affect parts of it that you cannot know of. So you are afraid to change it. So the project starts to be doomed. The hardest it is to be changed, the hardest it is for it to cope with the market requirements so the shorter its life will be.
但是你怎样让软件向你反馈它的健康状况呢。在快速原型模型方法中，从代码本身得到健康状况反馈中最好的方法就是自动化测试。自动化测试可以提早发现问题，并将问题报告给你，所以你可以非常迅速地对这些问题做出反应。我把我所进行的自动化测试叫做缺陷检测器。这些检测器通过向我迅速报告软件中损坏的东西来帮我的忙。如果我能快速找到缺陷，我可以迅速修复它们，这使我拥有了很大的灵活性。我先修改下软件，甚至在不是我所写的代码里作一修改，然后我运行测试用例，如果这些用例检测出一个缺陷，我就会立刻知道，我可以选择取消这个改变，或是选择修改受的影响的部分。软件灵活性的一个大问题是，如果软件规模大，软件就会不灵活，并且所做的改变会影响你不可预知的某些部分。所以你为怕修改这样的软件。这样软件项目会开始变得一成不变。软件越难做改变，它就越难适应市场的需求，软件的寿命也会变得越短。
If I were to make a comparison, I would say that If I were the general and my code the army fighting the requirements, my automated tests would be my intelligence center. The bigger my army would get, and the larger the war zone, the hardest it would be for me to know what’s happening in all areas and be able to adapt my strategy to the new conditions. But If I have the break agents placed with the different parts of the army they can report to me about problems and defeat situations very fast. The more agents, the largest the areas of coverage, from where I can receive information from and act upon it.
如果我来做个比喻的话，我就把自己当成统帅而我的代码就是与需求作战的军队，而我进行的自动化测试就是我的智囊团。我的军队的规模越大，战场就越大，我想知道哪里发生了什么战事以及如何将战略拿来应对新局面就会越难。但是如果我把我的缺陷检测器放到军队的不同部分，它们就会向我报告战事并且能很快的抵御局面。检测器越多，所覆盖的区域就越大，我就可以接收那里传来的信息，并对其做出反应。
Feedback is the one thing that corrects and improves the software.
信息反馈是修正与改进软件质量的一种方法。
第七部分
Communicating with the outside与外部交流
Before starting a project, teach your customer about the importance of good communication and how that is achieved in software and with you in particular. Show a very honest plan, of how the project will be build.
在项目开始前，请先让你的客户了解到有效交流的重要性，让客户明白在软件项目里怎样做到有效交流，以及在特殊情况下怎样与你有效地交流。列出关于项目如何开展的一个非常诚恳的计划。
On misunderstanding with agile methodologies, is that it is believed that it is not well planned and to the uninformed this seems like cowboy programming, where everyone takes arbitrary decisions and wait to see what happens. In fact, agile software methodologies are very well planned. They plan light, having the possibility of change in their minds, making the plans simple and very easy to change. The plans are built together with the customers, management and the programmers, on very honest and proved facts, both at a high level, called release planning and at low level called iteration planning.
对快速原型模型方法的一个误解是，认为这种方法没有很好的计划，并且对那些消息不灵通的人来说，就像牧童在编程，每一个人都随意做出决定，然后等着看会发生什么。事实上，快速原型模型的软件方法论是有非常好的计划的。这些方法论做出的计划很简短，在计划中有对变化的考虑，这让计划变得很简化并且很容易做出改变。项目的计划是由客户，项目管理层和编程人员共同制定的，都是基于非常诚恳和可信的事实，并且兼具高层次计划（叫做发布计划）与低层次计划（叫做周期计划）。
Projects in Extreme Programming for instance, are divided into releases, which are to be delivered to the real users, or that are going ‘live’ and usually take one to four months to develop and they are also divided into iterations that are between one and four weeks in length and which need to deliver a tested, production ready system to the customer that is in charge of developing the software.
举例来说，使用终极编程模式的项目被分成几个发布，这些发布提交给真正的用户，或是这些发布持续“存活”并通常花费1到4个月的时间进行开发。项目也可以分成几个周期，长度在1至4周之间。这些周期需要把一个经过测试的，在生产上完备的系统交给管理软件开发的客户。
When making the big, release plans, the customer tells the programmers about what he wants as small sentences written on small paper cards, called user stories. All these are gathered from the customer and then estimated roughly by the customer. After being estimated, the customer can see their cost, and then be able to prioritize them. After the prioritization is done, the user stories are put in the iterations, to be developed. Well, this isn’t very different from traditional planning, excepting the level of detail of the user stories. But wait, I forgot to tell you that the plans can be updated after each iteration. This gives great flexibility in what is being built, and it also gives the customer great control on how and what is being built. He is in charge. After all, if you planned to release the software after three months with the customer, and after one month he realized that he misspecified what he wanted, or the business conditions changed, he can turn the direction very easily to the new one. This gives agile project great adaptability which can deliver the customer a much better product, as it can be easily changed and the control is in his hands.
在制定大的发布计划时，客户会把他要求编程人员做的事用几个简短的句子写在小纸片上，这叫作用户笔记。所有这些用户笔记都从客户那里收集过来，然后由客户粗略地估算一下。通过估算，客户可以得到这些用户笔记的预期花费并且可以决定执行这些用户笔记的先后顺序。在确定了先后顺序后，这些用户笔记就进入各个周期来进行开发了。哦，这与传统不计划并没有很大的不同，除了用户笔记的详细程度。不过请注意，我忘了说在每一个周期结束后这些计划是可以修改的。这就为当前要做什么带来了很大的灵活性，并且也让用户在很大程度上可以控制要做什么，怎么去做。他是有这个权力的。总之，如果你和客户计划在三个月后发布这个软件，而一个项目进行一个月后，客户发现他把他的需求设计错了，或者是商务环境发生了变化，客户就可以很容易的制定一份新的计划。这就给了快速原型模型项目以给大的适应性，要吧把一个好得多的产品提交给客户，因为软件产品可以轻易地修改，而控制权在客户的手里。
After each iteration, the customer sees the software planned and developed in that iteration, and can readapt according to what he sees. He can reprioritize, give up some features and add new ones. If the plan is light, it can be easily changed and readapted. He receives the best feedback about what you’re doing for him by seeing the software and this gives him the possibilities to tell you how to improve it, by giving you feedback.
每一个开发周期结束后，客户可以看到那个周期中计划和开发的软件并可以根据他所看到的情况调整软件。他可以重新制定各用户笔记的先后顺序，放弃软件的某些功能而加上新的功能。如果计划很简短，就可以容易地进行修改和调整。通过检视软件，，客户可以得到最好的关于你正在为他做的事情的反馈。而且他也可以通过给你反馈来尽可能地告诉你怎样改进软件。
Showing the customer, the product instead of reports, in the middle of the production, is a great way to communicate and build a product of much bigger value to the customer.
开发一个很大价值的软件产品时，与客户交流的一个好方法，就是在开发的过程中让用户去看正在开发的产品而非报表。
Conclusion
结论
Although, maybe what I have said earlier might need a level of knowledge about agile technologies, I hope it can also open an interest in those that have not used them , by showing different strategies on how the problem of communication is addressed by agile methodologies. This really can improve products, customer satisfaction, can decrease costs and in all improve the way we do business.
我刚才所讲的东西可以需要读者具有一定的快速原型模型的知知识，但我还是希望上面讲的能给那些没有用过快速原型模型的读者带来兴趣。我向大家讲了快速原型模型处理交流问题的不同的策略。上面讲的的确可以改进产品质量，提高用户的满意度，可以减少做业务的方式的花费。
Charging the customer for miscommunication, is the worst way to address the communication problem, however it is still extensively used. This makes software more expensive, and generates new problems and new stresses that can be pushed to programmers or customer. Just as a simple example, if it costed me x+something to build the detailed requirements documents, and the customer doesn't want to pay more then I'll just get the programmers to build the software in less time with less people. Guess how much programmers under stress cost?
为不良的交流而向客户要钱，是处理交流问题的最差劲的手段，尽管这种手段仍然在越来越多的使用中。这种手段会全软件变得很昂贵，并且会产生新的问题。编程人员或是客户会受到新的压力。举个简单的例子。如果撰写详细的需求文档会花费我x和一些东西，但客户不想花那么多钱，那么我只能要求编程人员用更少的时间和更少的人力来开发软件。你估计在这样重压下的程序员要花多少钱？
[ 本帖最后由 brilliantking 于 2006-4-27 17:23 编辑 ]
翻译结束了！
好累啊，呵呵。总体感觉原作者太啰嗦了。
正如倒数第二段里说的，要阅读这文章需要有一定的快速原型模型的知识。不幸的是我大学里的软件工程课没好好学。所以翻译得跌跌撞撞。万望各位测试审校一二。 辛苦啦，由于这篇文章比较长，按两篇翻译加分鼓励:)。 谢谢斑竹了！我希望大家赶紧来挑错，呵呵。
brilliantking ,我看我是不得不佩服您的能力和信心
有你的邮箱吗或QQ？想单独请教一下您。不知道可以吗？谢谢 thanks! ding !
页:
[1]
