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》一書，同樣有關信息在"相關資源與引用"部分也已列出。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
