Observing and describing quality 如何观测以及描述质量
This text will describe how I want us to deal with system quality from a user perspective. The question I will talk about is how to describe real system quality.
希望通过这篇文章大家可以了解我期望大家怎样从用户的视角去审视质量。这里我想谈的问题是我们如何描述一个真实的系统质量。
Ideally we would like to be able to state that we know that the system works well in all the configurations and in all the scenarios the customer plans to use the system when we are ready to deliver. We would also like to be able to describe performance for all the configurations to be used.
理想状态下，我们应该在准备交付产品时有能力保证系统在客户将要用到的所有配置及所有场景下正常工作。而且，我们也应该能够清楚的描述系统在这些配置下的性能。
In the real world things are never that ideal. During ongoing development we need to know the status of our product/system being developed. When deciding whether to deliver or to delay the delivery we need to understand how well the system would work in the customer environment. Before the intended time of delivery we need to know how well the system works in order to decide what to focus on in the project. In order to manage the project well we need to know the quality of the system being developed all the time during the ongoing project.
而当我们回到现实世界的时候，事情往往没那么完美。 在开发过程中，我们需要了解的是正在开发的系统/产品的状态。当我们要对交付或延迟交付做出决策的时候，我们需要非常清楚系统在客户环境下运行会有多好。在预期交付日期之前我们需要理解系统运行情况，以便能确定我们在项目中关注什么。 为了管理好项目，我们需要在整个项目进展过程中清楚我们所开发系统的质量情况。
Our language uses words like "we have tested ...." where we really should say "we know the following ....". The inverse is saying "we have not tested ...." where we should say "we do not know ....".
我们描述系统的时候总是说“我们已经测试了XX…”，而我认为正确的说法应该是“对于这个系统/产品，我们了解如下情况：...”反之，当我们说“我们对XX还没测试”的时候，其实我们应该说“对于系统的XX方面，我们还不清楚。”
（译注说明：这里意思是说，对于质量，我们不能说我们测试了什么就算完成了，就算质量好了。而是应该以可以真正的了解系统某些功能特性是否可以正常运行来衡量质量情况。）
But in the real world saying that we have tested something does not really mean that we know. In the same way we can truly say that we do know certain things without having tested them.
在现实中，做了测试并不代表我们就对这部分系统真正了解了。同样的道理，对于系统的某些部分，即使不测试我们也非常清楚他们的质量。
The most common case is a project that starts with a legacy system that we know quite well. By knowing it well I mean that we know what is does well and we know its weaknesses. It also means that we know how well different scenarios are handled by the system as well as different configurations.
最常见的例子是我们在原有系统基础上启动新项目，理论上说我们应该对原有的老功能很了解。我说说的很了解是指，我们很清楚这个系统的哪些功能运行良好和哪些功能有弱点。也是说，我们知道对于不同场景、不同的配置下系统是否可以很好的运行。
However the truth is that we know little or nothing about scenarios that do not appear in customer networks as well as about configurations that are actually not used. Even worse is that we too often do not really know which the unused scenarios and the unused configurations really are. We may know some of them but not all. Most often if they do not cause problems in the customer networks we assume that they are used and that they work well! The truth is instead that many scenarios and many configurations do not cause trouble because they are simply not used.
然而，事实是我们对那些在客户网络不会出现的场景以及不会被真正使用的配置知之甚少或全然不知。更差的是我们经常都不知道哪一个是真正不被使用的场景和配置，我们可能知道一些但不了解全部。 经常发生的是，如果他们没有在客户网络中产生问题，我们就会假设他们已经被使用并运行良好！真实情况是相反的，很多场景和配置没有带来问题因为他们完全没有被使用。
Healthy project should focus on two different areas, improving the existing system and adding new features. Good engineers make sure we know all the changes we make and how we make them. When this is true we can make good decisions about how to verify the result of the project which is the same as saying making sure we know the quality of the new system. What we decide to test and how we decide to test is purely based on good judgment by good engineers who know the baseline system, who understand the new features and how they will be used and who know the people who make the changes in the system.
一个健康运作的项目应该关注两件事：改进已有系统和增加新特性。优秀的工程师会确保自己对系统的所有更改以及如何更改了如指掌。如果是这样，我们就能作出好的决定来如何验证项目的结果，也就是说可以保证我们了解新系统的质量。 “如何测”，“测什么”，这些问题的答案都依赖于优秀的工程师的准确判断，这些工程师了解我们系统的基线，理解新需求以及这些需求将会被如何使用，知道哪些人对系统引入了变更。
The final verdict about system quality comes from the combination of facts from testing and knowledge that good engineers have about the legacy system and about the project (people and ways of working). Even the so called facts from testing are also built on judgment from good engineers about what needs to be tested and how we need to test it. If these engineers do not have good judgment their conclusions about system quality have little value. They may have bad judgment because they have too little experience, because they do not know the system and its use well enough, because they do not know the project and its people or they are simply not good engineers although they have lots of experience. All those cases are common.
对一个系统的质量的最终判定来自于三方面的综合审视，分别是测试结果，优秀的工程师对系统的了解，以及他们对项目的了解（项目中成员和工作方式等）。而测试结果其实也是基于我们优秀的工程师的判断：他们会决定“测什么”，“怎么测”。 如果这些工程师们的判断出现问题，那么他们对系统质量的结论其实也并没有什么价值。 错误的判断可能是因为他们经验不足或者对系统不了解，也有可能是他们对项目不了解，甚至有可能他们根本不是优秀的工程师，即便有些人有很多年的工作经验。所有这些都是经常发生的
Facts about a system are not only found out through testing. Another way is through interviewing the designers checking what they intended to make the system do. Systems do not really take care of cases or configurations they were not intended to care of. Interviews can find misunderstandings of specifications as well as intended deviations from specifications.
了解系统的真实情况并不只是通过测试，另一个方式是询问设计人员来检查他们打算让系统做什么。系统对付不了那些没有打算让系统去处理的场景和配置。访谈可以发现对规格的误解以及对规格的背离偏差。
Also in some cases code reviews will reveal facts about what the design intended to achieve or did not intend to achieve. Both reviewing the code and reading the comments in the software modules may reveal a lot of interesting facts. Some of these findings may need to be supported by testing or they can help us indicate important test cases to run. A lot of important facts about a system is simply not described in the documentation but some of it can be found by reading source code.
同样在进行一些代码review时，也将会暴露出关于系统设计想要达成以及不想达成的情况。通过检视代码和阅读模块的注释文档都可能发现很多有趣的事实，一些发现需要来自于测试的支持，让他们来帮助我们提供重要的测试用例并运行。很多重要的系统真相不能简单的通过文档来进行描述，期中一些可以通过阅读源代码的方式帮助我们发现出来。
During a project we make decisions about changes or additions that will improve or ruin the system. Many of the decisions introduce risk and this risk has to be controlled making sure that the end result is good. As a project moves forward we need to monitor the result of all the changes made. As we come into system level testing we start building knowledge about the final system. During this final phase which is rather long in a well planned project we need to keep describing what we know and what we do not know about what works well or as intended. In short we need to describe more or less continuously how well the system presently works or, put differently, how well it would work in a customer network in case we would deliver to customers now.
在项目进行的过程中，我们对变更和增加做决策，有些决策会提升系统能力，有些则起破坏作用。有些决策会给项目带来风险，所以我们需要对这些风险进行控制以确保最终的结果是好的。随着项目的行进，我们要跟踪对所有变更所导致的结果。系统测试阶段，我们便开始构建对整个系统的理解。对于一个有着很好计划的项目，这个最后阶段会比较长，我们需要开始持续描述我们了解或不了解系统中哪部分是按预想正常工作的，哪部分并没有达到预期结果。我们需要或多或少地持续描述我们系统目前运行情况，变个说法，如果我们现在向客户交付，系统在客户网络中的表现怎么样。
Our testers need to know our systems. They also need to know our system designers and developers to make good cooperation possible.
我们的测试人员应该了解我们的系统，他们也需要了解我们的系统设计和开发人员，以进行可能好的合作。
I expect both testers and system engineers to know our systems well. It is not sufficient that testers know the results of the test cases that have been run. It is not sufficient that system engineers know how the features were intended to work. When a system is delivered they must know very well how the features and the complete system actually works. I also expect developers to get the opportunity to learn about how well the system works to be able to move on be testers or system engineers as well as to do a better job as developers.
我期望测试人员和系统工程师都非常了解我们的系统。测试人员知道已经运行测试用例的执行结果并不是足够的。系统工程师了解特性预想如何工作并不是足够的。当一个系统交付之后，他们必须非常清楚特性和系统真正运行的情况。我也期望开发人员也可以通过获取机会去做测试或SE来更加了解系统运行情况，这样也可以更好的做好一个开发人员。
Quality of a system is about what works well and how well it works in what configurations and in what scenarios, not about the number of defects and certainly not about the number of defects testers have chosen to document.
系统的质量而在于让大家知道系统哪些地方能正常工作，性能如何，在哪些场景/配置下能正常工作，并不在于缺陷的数量，当然更不在于那些被测试人员选择被记录的缺陷数量。
Budgeting ! 项目和资源预算管理
Assigning a budget for a line unit is a way of deciding how many people to use and what other costs will be accepted for the project.
预算分配是一种为某个资源部门决策为项目可以接受要使用多少人力和多少其他成本的方法。
Assigning a budget for a project means deciding what the project is allowed to cost.
为项目分配预算意味着决策项目所允许的成本。
Project budgets:
These are in a well working company used as a way to assign people into the future for different projects and for estimating what can be achieved in the near future. Every company has limited resources (people with the right competence). If the sum of the project budgets for the next year exceed the existing resources (line budgets) there will be problems. The projects (or at lest some of them) will fail because we do not have enough able people.
项目预算：
这是一个运作良好的公司所使用的方式，将人力分配到未来不同的项目中，也意味着估计未来将会达成什么情况。每个公司都有有限的资源（有相应能力的人员）。如果下一年项目预算的总和超过了已有资源（资源预算）将会出现问题，项目（或至少一些项目）将会失败，因为我们没有足够有能力的人员。
In not very smart organisations budgets are assigned by counting people, only numbers matter. In smarter organisations budgets contain names and consider the availability of key people. Very few organisations do this, maybe actually no big organisations, although we know the limitations of what can be achieved in a large organisations is not about number of people but about what people we choose.
在不太聪明的组织中，预算由会计计算人员分配，只有数字。在更聪明的组织中，组织预算中包括名字并考虑到关键人员是否可以到位。很少的组织会这样做，或许实际没有大组织能这样做，尽管我们明白在大型组织获得成功的前提条件是选择关键正确的人员而非一些数字。
In the development world it is said that estimations of development projects are often very inaccurate since history tells us that the cost of the project of the project often turned out to be three , five or ten times as large as estimated. I will name only a few reasons for the deviation from the original estimate. One reason is managers keep adding requirements to projects long after the estimations were made. Secondly system engineers tend to add complexity for some good and some bad reasons making the task more difficult thereby adding work to the project. Thirdly estimations are often made assuming we can use the best people we have for the project. If these people are switched for more beginners the amount of people and time needed will increase enormously. Fourthly many managers have their own ambitions, wanting to implement certain products or features, so they fake the estimations to present something more attractive. They know they will be able to find lots of excuses when the outcome is a much larger project than estimated. Also very often the responsibility will have been transferred to some other manager who will have to take care of the results of the bad estimations when the project is finally finished! My experience tells me many estimates are not so bad but project implementations either deviate a lot from the original basis for estimation or/and projects are badly run (very, very common).
在产品开发的世界中，开发项目的估计经常是不准确的，因为历史告诉我们，项目的实际成本会是估计成本的三倍、五倍或大到十倍。我这里给出一些偏离估计的原因：第一，管理者在项目估计之后很长时间里，持续的增加需求。第二，系统工程师处于一些好的或不好的原因，打算增加一些复杂性，由于项目任务难度增加导致工作增加。第三，我们在估计时是基于我们能使用最好的人员这样的前提假设，如果这些人员被其他的新人替换，那么我们所需的人员和时间就会急剧增加。第四，很多管理者有着自己的野心，打算实现某些产品或特性，所以他们伪造估计来表现的更加有吸引力。他们知道当结果超出预算估计时，很多时候他们能够找到很多借口，而且当项目最终结束后，责任往往会转移到其他的管理者身上，其他的管理者身将不得不对糟糕的估计预算结果负责。我的经验告诉我，有些项目的初始估计可能不是很糟糕，但要么是后来执行中和原始估计偏差很多，要么项目运作的非常的糟糕。（very, very common）
In a well working project the involved people will make an estimation they believe in. In a well working environment people outside the project will have very little influence on the estimations because they will not work in the project. In such an organisation managers will assign individuals (not numbers of people) and they will keep these people in the project. If outside managers try to steal their people for saving other projects there will be violent protests. In such a well working organisation the capable people will make estimates of number of work hours but they will take into account available people, complexity and other things and their estimates will be followed. Higher level managers can not override their estimates.
在一个运作良好的项目中，项目相关人员会基于信任进行估计。在这样的项目中，那些不在这个项目里实际工作的人的意见将不会得到倾听，因为他们不会呆在项目里，所以他们不是值得信任的。在这样的项目中，管理者会分配个体人员（不是数字），并且保持这些人员呆在项目里。如果外部管理者想偷走这些人员以挽救其他项目，这些人将会得到强有力的保护。在这样一个运行良好的团队中，有能力的人员将估计完成工作所需要的工作小时数，但他们同时会考虑到可以投入的人数，复杂度，以及其他的一些约束条件。高层管理者不能对他们的估计结果置之不理或取而代之。
When higher level managers override estimates, saying we have to do it at a lower cost, and saying we have to deliver on time the solution is lagomising. In such a situation product management can usually not be involved because they are usually cowards. It must be the development project defining a simpler product, giving a small enough project making it possible to deliver the product with excellent quality on time. THIS I HAVE DONE SO MANY TIMES!
当高层管理者不理会有能力的人员的估计，说我们不得不要在一个低成本的情况下完成，而且还要我们按时交付，遇到这种情况时，解决方案就是lagomising，在这种情况下，产品管理人员一般不被引入，因为他们通常是懦夫，一定是开发项目来定义一个简单的产品，给出一个足够小的项目并且保证能够按时交付高质量的产品。这就是我做过多次的方法！
In not so well working organisations what happens when too low budgets and not enough good people are allocated to a project is that system quality will suffer.
在运作不太好的组织中，当给项目太少的预算和分配不太好的人员时只能忍受系统的质量低下。
The project management must have a lot of courage to do lagomising and they need to be supported by their line managers. Managers who are cowards we can not have!
项目管理人员应该经常被鼓励去Lagomising，而且他们需要得到资源线的支持。我们不能有懦夫一样的管理者。
In line organisations where several projects are being run it is usually impossible to follow up project costs because the internal accounting systems in most companies are not good enough and also people do not really report well what they do. People who are assigned to one main project keep reporting that they work on this project although they may help colleagues half a day now and then. People usually focus on getting the job done, not on reporting time correctly!
在资源线，当有多个项目同时运作时，通常不太能够跟踪项目成本情况，因为大多数公司的内部统计系统都不是足够好，而且人们通常也不能很好的汇报他们所做的事情。被分配到某个主要项目的人员虽然持续汇报他们正工作于这个项目，但实际上经常会出现去帮助其它项目的同事半天之类的情况。人们通常都是把精力聚焦于完成工作，而不会是正确的记录和汇报用在每件事情上的时间！
I have seen cases where line managers who are responsible for finishing one project and for starting another project tell their people to report time on the new project although they still work on the old project when the old project has exceeded its budget.
我看到过很多案例，负责完成一个老项目和启动一个新项目的资源线主管会告诉他的人员在新项目里报告消耗的工时，尽管他们还仍然工作于上一个早就超出预算的老项目。
Also accounting systems have such a large delay that the accounting reports are useless for running projects - I never used them at all! The only case when a project accounting report can have some value is when numbers say that less effort than planned is going into the project. On the other hand if the responsible managers do not already know it when the numbers say so they need to find another job!
而且统计系统有着巨大的延迟，所以统计报告对运作项目没有任何作用。我从来没有使用过！项目统计报告唯一有价值的情况是，当数字说明少于计划的人力进入了项目当中。换句话说，如果一个承担责任的管理者如果在数字报告出现之前还不知道项目的情况，那他就应该卷铺盖走人了！
The only two important things to follow and to control in a project are product quality and delivery time! The only way to stay reasonably within budget is to deliver on time!
在项目中唯一两样重要的东西，一个是产品质量，一个是交付时间。保持在合理预算范围内的唯一方法是按时交付。
I want the project manager to focus on product quality and delivery time and the line manager to focus on balancing the budgets between ongoing projects making it possible for all projects to be successful.
我希望项目经理能够聚焦于产品质量和交付时间，资源经理能够聚焦于平衡不同进行中项目的预算，以保证所有项目得以成功。
Line budgets:
Line budgets need to be based on products or product areas and the responsible PDU or similar level managers can move people freely with his line organisation. On a lower level than the PDU we need to set budgets as a basis for recruiting but at an operating level they mean nothing. Line managers are free to move people between different projects and between different activities like support and development as long as the responsible project or line managers agree to the changes, otherwise not!
资源预算：
资源预算需要基于产品或产品族，责任PDU或者类似层面的管理者能够在他的组织范围内随意调配人员。在低于PDU的层面，需要为招募人员设置基线预算，但在实际操作层面这些没有什么意义。资源主管只有在项目主管等人同意的情况下，才能把人在不同的项目或工作（如支持或开发）之间调配，否则不能这样！
Most line budgets really mean how many people the unit has. Following up line budgets is usually easy and meaningless!
大多数资源预算真实的意味着这个资源团队有多少人。跟踪资源预算通常很容易但没有意义！
I do not want us to have project managers buying people from line managers. To me it feels like slavery. Also it would probably go against all that is good in Huawei. One of those issues is flexibility. We need to remain flexible. With contracts for paying for people I believe we would only create a lot of useless administration only making work more difficult. On the other hand if project managers pay for people they must pay for individuals not for number of people.
我不想让项目管理人员从资源管理人员手里购买人员。对我来说，这好像是奴隶。而且可能和华为内部好的方面都有所冲突。其中之一的问题是弹性，我们需要保持弹性，我相信利用承包合同为人员买单的方式将会产生很多无用的行政管理，只会让工作变的更难。另一方面，即使让项目经理为人员买单，那么他应该为具体的个体人员买单而不是为数字买单。
However we need to improve our ability to define projects, estimate projects and run projects to reduce the need for so much flexibility. I want us to make our managers be flexible and helpful to another. If we focus very much on keeping budgets and formality around this the managers will spend less time and effort on helping the project and more on pretending to be successful - I do not want this to happen in Huawei! I HAVE SEEN THIS HAPPEN!
当然，我们需要改进我们定义项目、估计项目和运作项目的能力，来减少对过多弹性的需要。我希望让我们的管理者能够具备弹性并对他人有帮助。如果我们非常聚焦于保持预算并拘泥于此，那么管理者将会减少时间和工作量来帮助项目，甚至会妨碍项目的成功。我不希望这些在华为发生！我已经见到过类似的情况！
Adapting project budgets over time:
Managers ask how to change project budgets on a monthly basis. The answer is project plans shall be followed. A good project plan means we have planned thoroughly what people to use when until the project is ready. These plans shall not be changed all the time. Adding or reducing budgets for a project causes a lot of damage to the project. Project management should not have to spend time on preplanning the project and remaining it when managers have stolen their people. Project managers should also not have to waste a lot of time in meetings defending their project against theft of people from other projects.
调整项目预算：
管理者经常问如何基于月度更新项目预算，答案是要跟随项目计划。一个好的项目计划意味着我们彻底的计划了当项目ready时人们将要使用什么功能，这些计划不应该老是被改变，增加或减少预算都会给项目带来很多困难，项目管理人员无法在其他管理者偷走他们的人员后继续重新计划和保持这个计划，项目经理也不应该浪费大量时间在会议室里来保卫他的人员不会其他人和项目偷走。
I understand in Huawei we do not ruin projects by cutting budgets. We use much more sophisticated methods. Management tells the project manager that he/she keeps his/her budget but some of the good people are stolen and replaced by beginners. Since the budget is the same the project manager is supposed to deliver on time and with good quality. This I think is playing games. We should not do this!!!
我了解在华为里，我们几乎不会因为裁剪预算而影响项目，我们有更老练的方法，管理层告诉项目经理将会保持他/她的预算，但一些优秀的人员会被偷走，然后以新人取而代之。由于预算还是一样，所以项目经理还是要按时交付高质量的产品。我感觉这就是在玩游戏，我们不应该这样做！！！
When there are very good reasons to make changes in a project we should do it through the people in the project. Projects must not be changed many times. I think the fact that people are used to frequent changes explains why no project planning is well done. It is useless since management will ruin everything many times during project execution. Planning is considered just a waste of time. This must stop!!!
当有较好的变更原因时，我们可以通过项目里的人员进行这样的变更。但项目必须不能变更很多次。我感觉事实上，人们已经习惯于频繁的变更，并可以解释为什么我们没有一个很好的计划。在项目开发过程中，如果管理层给项目多次变更将会打乱一切，所有的努力也就成了泡影，做计划也就成了浪费时间而已。这些一定要stop！
Let the line managers follow up budgets and project managers drive projects!
让资源经理跟踪预算，让项目经理驱动项目！
Following up customer responses on products and project delivery is everything!
在产品和项目交付中跟随客户响应才是最重要的事情！
A true story about real quality management
这里是Jack讲述的多年前自己负责的一个项目，如何进行具体操作和管理的，希望对大家有参考借鉴价值：
A true story about real quality management
This is a story about a radio base station project several years ago. Actually it was a complete system project but my focus was on the radio base station. The project developed a new generation of base stations where basically all the hardware and all the software was new - the most terrible kind of project. What made it even worse was that the mobile standard was also new and untried.
这里给大家讲述一个关于无线基站项目的故事，事实上，这是一个关于整个无线系统的项目，而我主要关注于基站项目。这个基站项目需要开发新一代的基站，并且几乎所有的硬件和软件都是新的——这是最严峻的一种项目类型，并且，由于所采用的移动标准是最新并无人尝试过，导致情况更加严峻。
The project was from the start a very challenging one with a very demanding customer and a very short time from project start to delivery. Many people thought the whole project was impossible but top management decided to do it!
这个项目启动时，已经是一个非常有挑战性的项目了，面对非常强势的客户，并且从启动到交付只有非常短的时间。很多人都认为这个项目是不可能完成的，但高管们最终还是决定要去做这个项目！
This story will talk about a small part of the project developing the operation and maintenance software for the base station. Some time into the project it was found that this sub project was about to risk the whole project because their time schedule did not meet the needs. The company asked all the different teams to put together schedules they believed in and in this case the result was far from acceptable.
这个故事将会讲到这个项目中基站的OM部分功能的开发过程，当时很多人都认为这个OM子项目会引起整个项目的风险，因为他们的时间周期无法满足需求。公司当时召集所有团队把他们相信的时间计划放在一起进行分析，结果发现，周期短的简直无法接受。
I was asked to leave my present task and take over this sub project to make sure they would not ruin the whole project. The whole project had been planned based on a system anatomy using organic integration as the planning principle. I found out that this team had not really understood how to do the planning. Even more they did not think organic integration was possible or a good idea. Like so many people I have met they only believed in ways of working they had seen before which was really waterfall development. This was in the early days of using anatomy and organic integration so it was understandable that not everyone understood how to do it and that not everyone thought this was a good way of running projects.
当时，我被要求离开当时的岗位去接手这个OM子项目，以保证这个项目不会影响整个大项目。整个项目通过使用Anatomy进行计划，并使用有机集成（Organic Integration）作为计划的准则。开始，我发现这个团队还没有明白怎么做计划，他们甚至不相信有机集成是可能达成的并且是一个好点子。就像我见过的很多人一样，他们只相信他们已经见过的工作方式——瀑布开发。不过这是可以理解的，在最开始使用Anatomy和有机集成的日子里，不是每个人都明白如何使用或了解其好处。
The development team had approximately fifteen developers and one team leader. There were no testers and no quality people. The team leader was thrown out (replaced by me) when I came in. A few of them were experienced developers but several were beginners.
开发团队大概有15个开发人员和1个team leader。没有测试人员，也没有质量人员。我进入团队后team leader被置换出去了，团队成员中一部分是有经验的，一部分是新人。
I started working with the experienced ones to explain the organic integration. Initially they resisted strongly but after several days of discussions and actual planning they started to accept that my ideas were at least possible. Thinking about the actual coding work they started seeing that dividing the coding work based on the anatomy would mean a very nice structuring of the work. When they said this I knew I had convinced them. Together we made a very clear and detailed plan based on the organic integration plan which was the integration plan for the whole base station project as well as for the whole system project.
我开始和有经验的人员进行解释有机集成，最开始他们有很强的抵触心理，但经过一些日子的讨论之后，他们开始认可我的想法是至少可行的了。他们发现将他们的编码工作按照Anatomy的方式进行拆分，意味着工作有一个更好的结构，当他们这么说的时候，我知道我已经说服他们了。接下来，我们一起基于有机集成的方法制作了整个项目详细计划，还有整个基站的计划，还有整个系统的计划。
The plan had five deliveries to base station integration. The small team had very little time for doing coding, reviewing and basic test. Normally we would make a plan involving every piece of code being reviewed by one or two other developers more than once before testing. Also each piece of code would be tested by the developer and the test plan would be reviewed by another developer. As already said in this team we had no testers. The testing would be done by the developers.
这个计划当中，针对基站的集成有5次交付。基于交付压力，这个小团队只有很少的时间进行编码、检视和基本功能测试，一般情况下，我们会制定一个计划，包括每块代码在测试之前要由1-2名其他开发人员进行多于1次的检视，而且每块代码也会由该开发人员进行测试，当然他的测试方案和计划也会被其他开发人员检视。如前所述，我们没有测试人员，所以测试工作由开发人员完成。
We decided to break all the rules. First the code written by the experienced developers would not be reviewed at all. The experienced developers would focus on helping the beginners do a good job. The experienced developers would not test their own code at all. The beginners would be doing some testing but the main effort to secure quality was to have the experienced developers review the code written by the beginners. In the cases (many) where the code was found to be of low quality the experienced developers would simply rewrite it partly or all of it. This was a crisis project, not a people evaluation project.
我们决定打破所有规则。首先，有经验的开发人员编写的代码完全不用检视，有经验的开发人员会聚焦于帮助新人更好的完成工作，有经验的开发人员将完全无需测试他们自己的代码。新人会进行一些测试，但主要保证质量的方法还是让有经验的开发人员review新人的代码。这样就多次出现这样的情形，有经验的开发者发现质量低下的代码，然后重写部分或是所有。这是一个处于危机时刻的项目，并不是由某个人来评估的项目。
During the months I was responsible for this sub project I was at work every day, not all day during week-ends , but I was there every day. That is how I know that the best of the developers were also there every day. They worked most evenings and they worked all week-ends. It was a very hard working team. I visited the development offices and after the first delivery to base station integration I went to visit the test lab every single day. I knew exactly how well the system worked every day, not from reading statistics but from taking part in testing and talking to testers. So my developers always knew that I knew.
在几个月的时间里，我一直负责这个子项目，包括周末在内的每天都在工作现场，这也是为什么我知道最好的开发人员也天天在工作现场的原因，他们几乎每天晚上和周末也都在工作，这是一个非常辛勤工作的团队。我会去开发的办公室，并且在完成第一个交付之后，我每天也都会去测试的办公室，我每天都精确的知道系统的运行情况，不是通过统计数字了解，而是通过具体参与测试和与测试人员沟通来了解。所以我的开发人员总是知道我是了解具体情况的。
We did not waste any time on reporting. We had short meetings while doing the job but no written reports. The only reporting done was things written on our walls, things that everyone in the team could see.
我们没有在汇报上浪费任何时间。我们会举行短会，但不会写报告。唯一有报告的情况就是在我们的墙上，这样每个人都能看到。
Every time we delivered new functionality to base station integration quite a large number of faults were found but they were always very quickly corrected and very correctly corrected. We established very fast feed-back loops and made sure we delivered corrections instantly, normally within hours. My developers spent time in the base station lab every day to help with trouble shooting to be able to deliver solutions to problems very quickly. At the same time they were supposed to design new functionality which was very hard but necessary.
每次我们交付一些新功能进行集成测试时，总会有相当多的缺陷被发现，但是我们总是可以快速的修复并且正确的修复，一般几个小时内就可以完成。我们的开发人员总是呆在实验室里，来帮助迅速找到解决疑难问题的方案，同时他们还要设计开发新特性，这是相当困难的，但却是非常必要的。
The project had a daily Systemakut going through every single fault found making sure they every would be correctly corrected quickly in the whole base station project. Every time the proper System Engineer would check that the system design was not wrong and when it was he would quickly offer an improved system design.
这个项目每天进行Systemakut。来跟进每个发现的问题，并且保证每个都能得到正确的修复。每次合适的SE人员将检查是否是系统设计的问题，如果是系统设计的问题，他将会快速提供一个更合理的系统设计。
My sub project however had a much faster correction loop. Whenever a fault was suspected in the lab someone from my team would be called to come and investigate and normally a solution would be delivered within an hour or two. We also checked with the system engineer as fast as we could working very well together with the testers and the system engineers.
我的项目无论如何都会有一个快速解决问题的过程，不论什么时候在实验室发现了一个问题，我的团队就会被叫到实验室，研究问题原因，一般1-2个小时就会提供一个解决方案。我们也尽快和SE进行确认沟通，我们可以很好的与测试人员、SE一起配合工作。
When all the software had been delivered from all the teams my team had not once caused any delay, nor had they caused any problems by delivering bad quality. In fact faults were always corrected so well and so quickly that noone got the impression that we delivered low quality although our initial quality probably was rather low. Every time we delivered I reported that we delivered what we were supposed to deliver. The project was very happy.
当其他所有团队完成软件的交付时，我的团队一次也没有引起过交付延迟，他们也没有引起任何影响交付质量的严重问题。事实上，由于我们总是可以快速正确地修复问题，导致没有人感觉我们交付的质量不好，尽管最开始我们的质量可能相当不好。在每次交付的时候，我总是可以说我们按时交付了原计划交付的内容，项目相关人员就非常高兴。
In the whole project we never checked how many faults had been made by each developer, each team or each subsystem. We never checked how many faults each tester reported or anything like that. All we checked was if we achieved progress in terms of the planned test cases being approved on time.
在整个项目中我们从来没有检查过每个开发人员、每个团队或每个子系统引入了多少缺陷。我们从来没有检查过每个测试人员发现多少缺陷或者类似的事情。我们所检查的只有查看测试用例通过情况来看我们是否按进度计划进行而已。
The whole system was later delivered to the customer as planned and launched successfully as planned. The customer paid the full amount in accordance with the contract because he was happy. The country we delivered to was Japan.
这样，整个系统按照原计划交付给了客户，并且成功运行。客户按照合同进行全额付款，因为他们很happy。这里所交付给的国家是日本。
I was happy to be working together with a very hard working team where I am sure everyone learned very much from this project.
我也为能与辛勤工作的团队一起合作而感到非常happy，我相信每个人都从这个项目中收获良多。
Improving CI 改进持续集成
Testing new builds well is not primarily about having many test cases. More important is to have good test cases. How do you evaluate the test cases you have today? One way is to review the test cases that never find any faults. Try to understand why. Maybe they are checking the same things other test cases check. Maybe they are not really checking anything. Maybe they run a scenario but do not check correctness well. Speed is a good thing with CI tests. Do not waste time running useless test cases. Also always complement auto tests with manual tests chosen based on what changes have been made to the build. This means that developers must always communicate what they put into every new build. I see this often not happening in our company. This must be done! Developers must declare all changes put into every new build so that testers have a chance to select test cases that can check all the changes.
如果你要很好地测试新的Build，最重要的并不是有很多测试用例，而是要有好的测试用例，你当前如何评估你已有的用例呢？一个方式是review那些从来没有发现过问题的用例，来理解为什么没有发现问题，可能是这些用例和其他用例检查了相同的地方；或许根本就没有检查任何东西；或许运行了一个场景但没有检查正确性。利用CI测试带来的速度是件好的事情，但不要浪费时间跑无用的用例。也要经常基于对版本引入的变更情况，利用手工测试来补充自动测试用例，但我在我们公司却很少看到。但这是一定要做的！开发人员必须在转测试前说明该版本引入的所有变更，这样测试人员就有机会选择用例以此检查所有变更。
Review the test cases that never find faults!
去Review那些从没有引入缺陷的用例吧！
Always complement auto tests with manual tests!
总应该用手工用例来补充自动用例！
Developers always tell testers what has been added and changed in each build!
开发人员总是要告诉测试人员在每个版本里引入了哪些变更！
