Crystal Light Methods: Comments by Alistair Cockburn
轻量级的Crystal方法
Editor's note: In the early 1990s, Alistair Cockburn was hired by the IBM Consulting Group to construct and document a methodology for OO development. IBM had no preferences as to what the answer might look like, just that it work. Cockburn's approach to the assignment was to interview as many project team members as possible, writing down whatever the teams said was important to their success (or failure). The results were surprising. The remainder of this section was written by Cockburn and is based on his "in-process" book on minimal methodologies.
编者注：在九十年代早期，Alistair Cockburn IBM顾问组工作时，为OO（面向对象）的开发制订了一套工作方法。IBM认为不管白猫黑猫，抓的到老鼠就是好猫。Cockburn 深入接触许多开发小组，写下了他们认为导致项目成功或者失败的关键之处。结果让人大吃一惊。以下内容是由 Cockburn写的，基于他的含有极少方法论的"实战工作"书 。 In the IBM study, team after successful team "apologized" for not following a formal process, for not using a high-tech CASE tool, for "merely" sitting close to each other and discussing as they went. Meanwhile, a number of failing teams puzzled over why they failed despite using a formal process - maybe they hadn't followed it well enough? I finally started encountering teams who asserted that they succeeded exactly because they did not get caught up in fancy processes and deliverables, but instead sat close together so they could talk easily and delivered tested software frequently.
在IBM的研究组里，开发小组要向以前成功的小组"道歉"，因为他们没有遵守一道正式的工序， 因为他们没有用一个高科技的CASE工具，又或者"仅仅"因为他们坐在一起，讨论他们下步 该怎么做。 同时，一些失败的小组觉得非常迷惑，尽管他们使用了正式的工序，他们还是 失败了--也许是遵守这些工序还遵守的不够好？后来我开始碰到一些成功的小组，他们宣称 正是因为没有陷于花里胡哨的过程和可发布性，而是大家坐在一起，从而使得他们可以 更容易的加以讨论并且经常交换测试后的软件，最终才得以成功。
These results have been consistent, from 1991 to 1999, from Hong Kong to the Americas, Norway, and South Africa, in COBOL, Smalltalk, Java, Visual Basic, Sapiens, and Synon. The shortest statement of the results are:
这些结论从 1991 到 1999，从香港到美国, 挪威, 和南非,在COBOL, Smalltalk, Java, Visual Basic, Sapiens, 和 Synon都是一贯坚持 , 这些结论的最短描述是：
To the extent you can replace written documentation with face-to-face interactions, you can reduce reliance on written work products and improve the likelihood of delivering the system.
尽可能在你的范围内，用面对面的沟通来代替写文档，从而可以减少对写好了的工作产品的依赖，并 增大发布系统的可能性
The more frequently you can deliver running, tested slices of the system, the more you can reduce reliance on written "promissory" notes and improve the likelihood of delivering the system.
越是经常发布正在运行着并且经过测试的系统片段，就越能让你减少对写好的"约定"标记的依赖，越能增大最终发布系统的可能性
People are communicating beings. Even introverted programmers do better with informal, face-to-face communication than with paper documents. From a cost and time perspective, writing takes longer and is less communicative than discussing at the whiteboard.
应当以人性的方式加以沟通。即使是对内向的程序员来说，采用不拘礼节的面对面的交流，都比采用写在纸上的文档进行沟通效果要好。从成本和时间上来看，写文章总比在白板上讨论耗费更多的时间，而且沟通的效果也更差。
Written, reviewed requirements and design documents are "promises" for what will be built, serving as timed progress markers. There are times when creating them is good. However, a more accurate timed progress marker is running tested code. It is more accurate because it is not a timed promise, it is a timed accomplishment.
那些写好的而且评审过的需求和设计文档，只是"承诺"了要做什么，我们可以将其作为项目进度的标志 使用。有很多进度标志在最初设立时是好的。然而，更准确的进度标志应该是运行测试后的代码。因为这不是预先承诺的标志，而是真正完成的标志。
Recently, a bank's IT group decided to take the above results at face value. They began a small project by simply putting three people into the same room and more or less leaving them alone. Surprisingly (to them), the team delivered the system in a fine, timely manner. The bank management team was a bit bemused. Surely it can't be this simple?
最近，一个银行的IT部决定小试一下以上结果。他们启动一个小项目，使用简单的把三个人放在一个房间里的方法，让他们自生自灭。令人惊奇的是，这个小组及时的、优秀的发布了系统。银行的管理层觉得有点困惑。一定不会这么简单的吧？
It isn't quite so simple. Another result of all those project interviews was that: different projects have different needs. Terribly obvious, except (somehow) to methodologists. Sure, if your project only needs 3 to 6 people, just put them into a room together. But if you have 45 or 100 people, that won't work. If you have to pass Food & Drug Administration process scrutiny, you can't get away with this. If you are going to shoot me to Mars in a rocket, I'll ask you not to try it. We must remember factors such as team size and demands on the project, such as:
当然不是如此简单。另外一个采访了所有其他项目后得到的结论是：不同项目有不同的需要。这是非常明显的不依赖于方法论的（不知道怎的）。当然，如果你的项目只需要3到6个人，只要让他们在一个房间里就可以了。但如果你有45或者100个人，这就没用了。如果你要通过食物药品管理部门的过程检验，你就不能这样开始。如果你想把我用火箭发射到火星上去，我建议千万不要尝试。我们必须记住团队的大小和项目的需求这类因数：
As the number of people involved grows, so does the need to coordinate communications.
随着参与人数的增长，协调沟通的需求也更多
As the potential for damage increases, the need for public scrutiny increases, and the tolerance for personal stylistic variations decreases.
随潜在的破坏性的增长，对于公开检查的要求也在不断增加，而同时对由于个人风格的不同所导致差异的可容忍程度也在降低
Some projects depend on time-to-market and can tolerate defects (Web browsers being an example); other projects aim for traceability or legal liability protection.
一些项目依赖市场方面所确定的发布时间，而且对于一些缺陷能加以容忍（WEB浏览器就是这样一个例子）；其他的一些 项目致力于条理性和法律责任。
The result of collecting those factors is shown in Figure 6. The figure shows three factors that influence the selection of methodology: communications load (as given by staff size), system criticality, and project priorities.
根据收集到的有关因素总结出的结论如图Figure 6所示。它显示了影响选择不同方法论的三个因数：沟通难度（由成员的数量决定），系统关键程序，以及项目的优先级。
Figure 6 -- The family of Crystal methods.
Locate the segment of the X axis for the staff size (typically just the development team). For a distributed development project, move right one box to account for the loss of face-to-face communications.
根据成员数量确定在X轴上的部分（通常的只是开发组）。如果是一个分布的开发项目，因为面对面沟通的机会减少，向右移动一格。
On the Y axis, identify the damage effect of the system: loss of comfort, loss of "discretionary" monies, loss of "essential" monies (e.g., going bankrupt), or loss of life.
在Y轴上，确认系统损坏的影响：舒适程度下降，明显的经济损失，根本性的经济损失（比如破产），或者丧命。
The different planes behind the top layer reflect the different possible project priorities, whether it is time to market at all costs (such as in the first layer), productivity and tolerance (the hidden second layer), or legal liability (the hidden third layer). The box in the grid indicates the class of projects (for example, C6) with similar communications load and safety needs and can be used to select a methodology.
在顶层的不同的飞机（板块panel？）反映了各种项目的不同重点，所耗费的是否是上市时间（就象在第一层），效率和兼容性(隐藏的第二层)，或者法律责任（隐藏的第三层）.网格中的格子决定了在相似沟通难度和安全需求下的项目的类型（例如C6），你可以用来选择方法论。
The grid characterizes projects fairly objectively, useful for choosing a methodology. I have used it myself to change methodologies on a project as it shifted in size and complexity. There are, of course, many other factors, but these three determine methodology selection quite well.
这个网格显示了项目的特性，对选择一个方法论很有用。我自己在项目的大小和复杂程度改变的时候，用来改变我的方法论。当然还有其他的因素，但这三个用来决定选择什么方法论是很好的。
Suppose it is time to choose a methodology for the project. To benefit from the project interviews mentioned earlier, create the lightest methodology you can even imagine working for the cell in the grid, one in which person-to-person communication is enhanced as much as possible, and running tested code is the basic timing marker. The result is a light, habitable (meaning rather pleasant, as opposed to oppressive), effective methodology. Assign this methodology to C6 on the grid.
假定现在要选择项目的方法论。得益于上面所提到的对有关项目的访谈，你可以把建立一个最轻量级的方法论，想象成按照网格中的格子工作，在这里，尽量提高人和人之间的交流，运行测试后的代码是最基本的进度标志。结果是一个简单的，符合人的习惯的（意味着更让人愉快的，反对压抑人的）高效率的方法论。在网格上指定这个方法论到C6。
Repeating this for all the boxes produces a family of lightweight methods, related by their reliance on people, communication, and frequent delivery of running code. I call this family the Crystal Light family of methodologies. The family is segmented into vertical stripes by color (not shown in figure): The methodology for 2-6 person projects is Crystal Clear, for 6-20 person projects is Crystal Yellow, for 20-40 person projects is Crystal Orange, then Red, Magenta, Blue, etc.
重复这些所有的格子，产生一个轻量级的方法的家族，根据他们对人们的信心，沟通，和发布运行代码的频率。我叫这个家族为Crystal Light方法论族。这个家族用颜色（在图上没画）分成不同的竖直的条纹：2-6个人的项目的方法论叫 Crystal Clear ，6-20人的项目的方法论叫 Crystal Yellow , 20-40人的项目的方法论叫 Crystal Orange,然后是 Red，Magenta，Blue，等等。
Shifts in the vertical axis can be thought of as "hardening" of the methodology. A life-critical 2-6-person project would use "hardened" Crystal Clear, and so on. What surprises me is that the project interviews are showing rather little difference in the hardness requirement, up to life-critical projects.
垂直方向间的切换在方法学上被称为强化。一个短生命期的2到6个人的项目应该使用强化了的Crystal Clear或其派生方法来管理。使我惊喜的是，在这样的 项目中几乎看不到增加需求和按时完成项目之间的矛盾。
Crystal Clear is documented in a forthcoming book, currently in draft form on the Web. Crystal Orange is outlined in the methodology chapter of Surviving Object-Oriented Projects (see Editor's note below).
Crystal Clear出自一本即将出版的书，现在网上已经有草稿。在《Surviving Object-Oriented Projects》一书的方法论一章中描述了Crystal Orange的轮廓。
Having worked with the Crystal Light methods for several years now, I found a few more surprises.
在采用Crystal Light方法多年以后，现在我发现了更多的惊喜。
The first surprise is just how little process and control a team actually needs to thrive (this is thrive, not merely survive). It seems that most people are interested in being good citizens and in producing a quality product, and they use their native cognitive and communications abilities to accomplish this. This matches Jim's conclusions about adaptive software development (see Resources and References, page 15). You need one notch less control than you expect, and less is better when it comes to delivering quickly.
第一个惊喜是，一个开发队伍成功（不仅仅是幸存）并不需要太多的管理和控制。大部分开发人员都乐于专心工作和写出好的软件，他们会使用自己的理解能力和沟通能力去 完成这一切。这和Jim做出的关于自适应软件开发的结论完全一致(参见"资源和参考"，第15页)。你需要比你预计的要少得多的控制，尤其是当你希望能尽快发布软件时，越 少就越好。
More specifically, when Jim and I traded notes on project management, we found we had both observed a critical success element of project management: that team members understand and communicate their work dependencies. They can do this in lots of simple, low-tech, low-overhead ways. It is often not necessary to introduce tool-intensive work products to manage it.
更特别的是，当我和Jim交换项目管理的心得时，我们意识到我们都观察到了成功的项目管理中的一个关键要素：开发人员能理解有关人员的工作并加以沟通。他们能通过 许多简单、低技术含量并且廉价的方法完成这一切。通常这并不需要引入什么特别的工具来管理。
Oh, but it is necessary to introduce two more things into the project: trust and communication.
不过项目中还是需要两个关键要素：信任和沟通。
A project that is short on trust is in trouble in more substantial ways than just the weight of the methodology. To the extent that you can enhance trust and communication, you can reap the benefits of Crystal Clear, XP, and the other lightweight methods.
在一个项目中，缺乏信任比选择了错误的方法学更要命。从某种程度上讲，只要你能加强信任和沟通，你就一定能受益于Crystal Clear，XP（极限编程 ？）或别的轻量级开发方法。
The second surprise with defining the Crystal Light methods was XP. I had designed Crystal Clear to be the least bureaucratic methodology I could imagine. Then XP showed up in the same place on the grid and made Clear look heavy! What was going on?
第二个惊喜是当我们定义Cystal Light方法的时候它就和XP一致了。我把Crystal Clear设计成我所能想象的最不官僚的方法学。随后XP在 同一领域出现并展露锋芒，在它面前Clear仿佛成了重量级的开发方法！这是怎么一回事？
It turns out that Beck had found another knob to twist on the methodology control panel: discipline. To the extent that a team can increase its internal discipline and consistency of action, it can lighten its methodology even more. The Crystal Light family is predicated on allowing developers the maximum individual preference. XP is predicated on having everyone follow tight, disciplined practices:
这大概是因为Beck发现了方法学的控制面板上的另一个开关：纪律。在某种程度，如果一个开发小组能增强内部的纪律性并保证行动的一致性，方法学可以变得更加 轻巧。Crystal Light衍生的方法学给予开发者最多的个性化。XP则要求每个人都遵守严格的有纪律的实践：
Everyone follows a tight coding standard.
每个人都必须遵守一个严格的编码标准。
The team forms a consensus on what is "better" code, so that changes converge and don't just bounce around.
关于什么是好的代码, 开发小组在此方面应达成共识，这样所有的变化都集中在一起，避免了反复。
Unit tests exist for all functions, and they always pass at 100%.
每个函数都必须经过单元测试，并且必须100%通过。
All production code is written by two people working together.
所有产品的代码都是由两名开发人员一起工作完成的
Tested function is delivered frequently, in the two- to four- week range.
以每两周到四周为一个周期, 频繁地发布那些经过测试的函数，。
In other words, Crystal Clear illustrates and XP magnifies the core principle of light methods:
换一句话说，Crystal Clear展示了轻量级方法的核心法则，而XP放大了它：
Intermediate work products can be reduced and project delivery enhanced, to the extent that team communications are improved and frequency of delivery increased.
在一定程度上，如果开发队伍的交流得到了改善，发布的频率得到提高，那么就可以减少中间产品的工作量，从而能更快地完成项目。
XP and Crystal Clear are related to each other in these ways:
XP和Crystal Clear有如下关联：
XP pursues greater productivity through increased discipline, but it is harder for a team to follow.
XP通过增强纪律性提高生产效率，但是它对于开发者更难于遵守。
Crystal Clear permits greater individuality within the team and more relaxed work habits in exchange for some loss in productivity.
Crystal Clear给予开发者更多的个性空间，允许比较松散的工作习惯，但是同时损失了一些生产效率。
Crystal Clear may be easier for a team to adopt, but XP produces better results if the team can follow it.
开发队伍可以比较轻松地使用Crystal Clear方法，但是如果能够有效地使用XP，效果会更好。
A team can start with Crystal Clear and move itself to XP. A team that falls off XP can back up to Crystal Clear.
开发队伍可以从Crystal Clear开始，然后转移到XP方法。开发队伍也可以放弃XP，重新使用Crystal Clear。
Although there are differences in Crystal Clear and XP, the fundamental values are consistent -- simplicity, communications, and minimal formality.
尽管Crystal Clear和Xp之间存在很多差异，但是它们的基本价值观是一致的--简单、交流和尽量减少形式化。
Editor's note: For more information on the Crystal Clear methodology, see Alistair Cockburn's Web site, listed in the References and Resources section. For more information on Crystal Orange, it is covered in the book Surviving Object-Oriented Projects, also listed in the References and Resources section.
编者按：如果你想深入了解Crystal Clear，请看"相关资源与引用"部分列出的Alistair Cockburn的网站，在。如果你想深入了解 Crystal Orange，你可以参阅《Surviving Object-Oriented Projects》一书，同样有关信息在"相关资源与引用"部分也已列出。
文章来源于领测软件测试网 https://www.ltesting.net/
