march-bird lucian yjf taopin wl jazz韩伟 nullgate Simon[AKA](转载自cutter.com) 2003年09月15日
Crystal Light Methods: Comments by Alistair Cockburn
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 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:
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.
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 -- 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.
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.
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.
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.
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.
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.
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%.
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:
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 pursues greater productivity through increased discipline, but it is harder for a team to follow.
Crystal Clear permits greater individuality within the team and more relaxed work habits in exchange for some loss in productivity.
Crystal Clear may be easier for a team to adopt, but XP produces better results if the team can follow it.
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.
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》一书，同样有关信息在"相关资源与引用"部分也已列出。