UML軟件工程組織
SCRUM軟件開發(fā)過程
編寫最好的軟件
譯者 littledwarf 林燕鋒 Allan bianh sunshinezhou 胡慶培 [AKA]
"The problem for engineers is that change translates into chaos, especially when a single error can potentially bring down an entire system. But, change also translates into opportunity. It‘s as simple as this: if there is time to put a certain amount of functionality into the product easily, then there is time to put in more functionality at the price of a certain amount of disruption and risk. Thus does madness creep into our projects - we will tend to take on as much risk as we possibly can."
"工程師所面臨的問題是修改軟件會引起系統(tǒng)混亂,特別是一個微小的錯誤就能導(dǎo)致系統(tǒng)崩潰。但是，修改也能帶來機遇。簡而言之：如果很輕易地就能給系統(tǒng)增加一定功能，那么就會冒一定的風(fēng)險增加更多的功能。從而使我們的計劃顯得有些瘋狂－我們將傾向于盡可能地冒風(fēng)險。"
James Bach. October 1995. "American Programmer"
Copyright 1995 Advanced Development Methods All Rights Reserved
--------------------------------------------------------------------------------
Contents ：
Introduction
簡介
Overview
概述
Current Development Situation
現(xiàn)在的發(fā)展狀況
Methodology
方法
Phases
進度
Controls
控制
Deliverables
可交付性
Project Team
項目組
Characteristics
特性
Advantages
優(yōu)勢
Estimating
評估
Appendix 1 - System Development Methodologies : Defined or Empirical
附錄1－系統(tǒng)開發(fā)方法：定義或經(jīng)驗
--------------------------------------------------------------------------------
Introduction
簡介
In this paper we introduce a development process, SCRUM, that treats major portions of systems development as a controlled black box. We relate this to complexity theory to show why this approach increases flexibility and ability to deal with complexity, and produces a system that is responsive to both initial and additionally occurring requirements.
在本章中，我們將介紹一種新的開發(fā)過程－SCRUM，它將系統(tǒng)開發(fā)的主要部分看成一個可控制的黑盒。我們將之與復(fù)雜性理論相聯(lián)系，來說明為什么這種方法改善了適應(yīng)性和處理復(fù)雜問題的能力，并能建立一種適應(yīng)初始的和額外的需求的系統(tǒng)。
Numerous approaches to improving the systems development process have been tried. Each has been touted as providing "significant productivity improvements." None has. As Grady Booch noted, "We often call this condition the software crisis, but frankly, a malady that has carried on this long must be called normal."
人們已經(jīng)提出許多改進系統(tǒng)開發(fā)過程的方法。每一種方法都被吹捧為："重大成果性突破。"其實沒有一種做到。正如Grady Booch所說的："我們常稱這種情況為軟件危機，但坦率的說，長久以來我們一直把這種病態(tài)看作是正常的。
Concepts from industrial process control are applied to the field of systems development in this paper. Industrial process control defines processes as either "theoretical" (fully defined) or "empirical" (black box). When a black box process is treated as a fully defined process, unpredictable results occur. A further treatment of this is provided in Appendix 1.
在這篇文章中，工業(yè)過程控制的觀點應(yīng)用到系統(tǒng)開發(fā)領(lǐng)域。工業(yè)過程控制定義過程或者是"理論的"（完全定義的）或者是"經(jīng)驗的"（黑盒）。當將一個黑盒過程當作完全定義的過程處理時，會發(fā)生不可預(yù)測的結(jié)果。對這種情況進一步的處理將在附錄1中給出。
A significant number of systems development processes are not completely defined, but are treated as though they are. Unpredictability without control results. The SCRUM approach treats these systems development processes as a controlled black box.
許多大型的系統(tǒng)開發(fā)過程是非完全定義的，但卻當作完全定義的來處理。這就導(dǎo)致了無控制的不可預(yù)知性。SCRUM方法在處理系統(tǒng)開發(fā)過程時將其看作可控制的黑盒。
The SCRUM approach is used at leading edge software companies with significant success. We believe SCRUM may be appropriate for other software development organizations to realize the expected benefits from Object Oriented techniques and tools.
SCRUM方法現(xiàn)在被很多領(lǐng)先的軟件公司成功使用。我們相信SCRUM將會適用于其他的軟件開發(fā)機構(gòu)以實現(xiàn)面向?qū)ο蟮募夹g(shù)與工具所期望帶來的利益。
--------------------------------------------------------------------------------
Overview
概述
Our new approach to systems development is based on both defined and black box process management. We call the approach the SCRUM methodology, after the SCRUM in rugby -- a group responsible for picking up the ball and moving it forward.
我們的系統(tǒng)開發(fā)的新方法是基于定義的和黑箱過程管理的。我們借用橄欖球中的SCRUM并稱這種方法為SCRUM方法論――一個團隊負責(zé)拿球向前沖。
SCRUM is a management, enhancement and maintenance methodology for an existing system. SCRUM will address new or re-engineered systems development efforts at a later date.
SCRUM是一種對已存在系統(tǒng)的管理，提高和維護的方法。在不久的將來，SCRUM將致力于新的或重組的系統(tǒng)開發(fā)。
Software product releases are planned based on the following variables :
軟件產(chǎn)品的發(fā)布是基于以下因素制定的：
Customer requirements - how the current system needs enhancing.
客戶需求－現(xiàn)在的系統(tǒng)需要那些改進。
Time pressure - what time frame is required to gain a competitive advantage.
時間壓力－需要什么樣的時間表以獲得競爭優(yōu)勢。
Competition - what is the competition up to, and what is required to best them.
競爭－競爭的目標是什么，如何最好地實現(xiàn)目標
Quality - What is the required quality, given the above variables.
質(zhì)量－有了以上的因素，那么需要什么樣的質(zhì)量。
Vision - what changes are required at this stage to fulfill the system vision.
版本－當前需要什么樣的更改以完成系統(tǒng)版本。
Resource - what staff and funding are available.
資源－有多少可用的資金和員工。
These variables form the initial plan for a software enhancement project. However, these variables also change during the project. A successful development methodology must take these variables and their evolutionary nature into account.
這些因素形成了改進軟件項目的最初方案。然而，這些因素是隨著項目的進行而變化的。一個成功的開發(fā)方法應(yīng)該將這些因素現(xiàn)在及其將來可能的變化都考慮進去。
--------------------------------------------------------------------------------
Current Development Situation
當前開發(fā)情況
Systems are developed in a highly complicated environment. The complexity is both within the development environment and the target environment. For example, when the air traffic control system development was initiated, three-tier client server systems and airline deregulation did not have to be considered. Yet, these environmental and technical changes occurred during the project and had to be taken into account within the system being built. Environmental variables include:
系統(tǒng)是在一個高度復(fù)雜的環(huán)境下開發(fā)的。復(fù)雜性同時存在于開發(fā)環(huán)境和目標環(huán)境。例如，當開始開發(fā)航空交通控制系統(tǒng)時，三層客戶－服務(wù)器系統(tǒng)及航線異常情況并沒有被考慮在內(nèi)。然而，這些環(huán)境和技術(shù)變化通常會發(fā)生在項目進行過程中，你不得不在正在構(gòu)建的系統(tǒng)中考慮到這些因素。環(huán)境因素包括：
Availability of skilled professionals - the newer the technology, tools, methods, and domain, the smaller the pool of skilled professionals.是否有足夠的熟練專業(yè)人員——技術(shù)、工具、方法、領(lǐng)域越新，相應(yīng)的熟練專業(yè)人員就越少。
Stability of implementation technology - the newer the technology, the lower the stability and the greater the need to balance the technology with other technologies and manual procedures. 實現(xiàn)技術(shù)的穩(wěn)定性——對于越新的技術(shù)，穩(wěn)定性可能就越低，并且更需要去平衡該技術(shù)及其它技術(shù)和人工程序的關(guān)系。
Stability and power of tools - the newer and more powerful the development tool, the smaller the pool of skilled professionals and the more unstable the tool functionality. 穩(wěn)定性和工具的性能——越是新的和功能強大的開發(fā)工具，就擁有更少的熟練開發(fā)人員，并且它的功能上的穩(wěn)定性就越差。
Effectiveness of methods - what modeling, testing, version control, and design methods are going to be used, and how effective, efficient, and proven are they. 方法的有效性——將使用什么樣的建模、測試、版本控制及設(shè)計方法，他們的效率怎樣？是否有足夠的保證？
Domain expertise - are skilled professionals available in the various domains, including business and technology.行業(yè)知識和經(jīng)驗——是否有不同行業(yè)(包括商業(yè)和技術(shù)方面)的專業(yè)人才？
New features - what entirely new features are going to be added, and to what degree will these fit with current functionality. 新特性——將添加什么樣的新特性，這些新特性將在什么樣的程度上符合當前的功能。
Methodology - does the overall approach to developing systems and using the selected methods promote flexibility, or is this a rigid, detailed approach that restricts flexibility. 方法學(xué)——用于開發(fā)系統(tǒng)的途徑和所選擇的方法是提升系統(tǒng)的適應(yīng)性還是限制了系統(tǒng)的適應(yīng)性？
Competition - what will the competition do during the project? What new functionality will be announced or released. 競爭性——在項目進行過程中，將怎樣提高競爭性？將宣布或發(fā)布什么新功能？
Time/Funding - how much time is available initially and as the project progresses? How much development funding is available.時間/資金——在項目啟動和進展過程中，有多少時間可用？有多少開發(fā)經(jīng)費可支配？
Other variables - any other factors that must be responded to during the project to ensure the success of the resulting, delivered system, such as reorganizations. 其它因素——項目進行過程中，為確保成功，任何其它因素都必須考慮，如機構(gòu)重組。
The overall complexity is a function of these variables :
整體的復(fù)雜性可以用這些因素的一個函數(shù)來表示：
complexity = f(development environment variables + target environment variables)
復(fù)雜度＝f（開發(fā)環(huán)境因素＋目標環(huán)境因素）
where these variables may and do change during the course of the project.
其中，這些因素可能而且確實會在項目過程中變化。
As the complexity of the project increases, the greater the need for controls, particularly the ongoing assessment and response to risk.
隨著項目的復(fù)雜度增加，就更需要控制，特別是資產(chǎn)評估和風(fēng)險反應(yīng)。
Attempts to model this development process have encountered the following problems:
對這類開發(fā)過程的建模嘗試已經(jīng)遇到下列問題：
Many of the development processes are uncontrolled. The inputs and outputs are either unknown or loosely defined, the transformation process lacks necessary precision, and quality control is not defined. Testing processes are an example.
許多開發(fā)過程是未加以控制的。輸入輸出都是未知的或僅僅初略定義的，過程轉(zhuǎn)換缺少必要的精確性，并且質(zhì)量控制也是未定義的。測試過程就是一個樣例。
An unknown number of development processes that bridge known but uncontrolled processes are unidentified. Detailed processes to ensure that a logical model contains adequate content to lead to a successful physical model is one such process.
那些在已知的但未經(jīng)控制的過程之間尚有未知數(shù)量的開發(fā)過程未被確認。用于確保包含足夠內(nèi)容的邏輯模型過渡到成功的物理模型的分過程就是這樣一種過程。
Environmental input (requirements) can only be taken into consideration at the beginning of the process. Complex change management procedures are required thereafter.
環(huán)境輸入（需求）只能在過程的初始考慮。之后就需要復(fù)雜的變化管理程序。
Attempts to impose a micro, or detailed, methodology model on the development process have not worked because the development process is still not completely defined. Acting as though the development process is defined and predictable results in being unprepared for the unpredictable results.
在開發(fā)過程中使用小的、詳細的方法模型的嘗試還未實現(xiàn)過，因為開發(fā)過程仍未完全定義。自以為開發(fā)過程是定義了的和可預(yù)知的，將會導(dǎo)致真正面對不可預(yù)知的結(jié)果時束手無策。
Although the development process is incompletely defined and dynamic, numerous organizations have developed detailed development methodologies that include current development methods (structured, OO, etc.). The Waterfall methodology was one of the first such defined system development processes. A picture of the Waterfall methodology is shown in Figure 1.
盡管開發(fā)過程是未完全定義的和動態(tài)的，眾多的機構(gòu)已經(jīng)制定出詳細的開發(fā)方法，包括流行的開發(fā)方法（結(jié)構(gòu)化的方法，面向?qū)ο蟮姆椒ǎ鹊龋?。瀑布式方法是其中第一個這樣被定義的系統(tǒng)開發(fā)過程。 見圖1。
圖 1
Although the waterfall approach mandates the use of undefined processes, its linear nature has been its largest problem. The process does not define how to respond to unexpected output from any of the intermediate process.
雖然瀑布式方法管理了未定義過程的使用，但是，它的線性特點成為它的最大問題。這種過程沒有定義如何響應(yīng)任何中間過程的不可預(yù)知的輸出。
Barry Boehm introduced a Spiral methodology to address this problem. Each of the waterfall phases is ended with a risk assessment and prototyping activity. The Spiral methodology is shown in Figure 2.
Barry Boehm 引入了一個螺旋型方法來解決這個問題。瀑布式過程的每個階段都用一個風(fēng)險評估和原型活動來結(jié)束。 見圖2.
The Spiral methodology "peels the onion", progressing through "layers" of the development process. A prototype lets users determine if the project is on track, should be sent back to prior phases, or should be ended. However, the phases and phase processes are still linear. Requirements work is still performed in the requirements phase, design work in the design phase, and so forth, with each of the phases consisting of linear, explicitly defined processes.
螺旋型方法就象剝洋蔥一樣，在開發(fā)過程中的階梯式前進。原型讓用戶決定項目是否繼續(xù)進行下去，或者是需要送回到前一個階段，還是應(yīng)該結(jié)束。然而，階段和階段過程仍然是線性的。需求分析仍然在需求分析階段處理，設(shè)計工作仍然在設(shè)計階段進行，如此類推，每個階段包含線性的、定義明確的過程。
圖 2
The Iterative methodology improves on the Spiral methodology. Each iteration consists of all of the standard Waterfall phases, but each iteration only addresses one set of parsed functionality. The overall project deliverable has been partitioned into prioritized subsystems, each with clean interfaces. Using this approach, one can test the feasibility of a subsystem and technology in the initial iterations. Further iterations can add resources to the project while ramping up the speed of delivery. This approach improves cost control, ensures delivery of systems (albeit subsystems), and improves overall flexibility. However, the Iterative approach still expects that the underlying development processes are defined and linear. See Figure 3.
迭代方法是在螺旋型方法之上發(fā)展而來的。每個迭代過程包含所有的標準瀑布式階段，但每個迭代過程只處理解析過的功能的一個子集。整個可交付的項目被細分為區(qū)分優(yōu)先級的子系統(tǒng)，每個子系統(tǒng)都有清楚的接口。使用這種方法，可以在初始迭代過程中測試一個子系統(tǒng)和技術(shù)的可行性。進一步的迭代能給項目添加新的資源，同時保持交付的速度。這種方法改善費用控制，確保系統(tǒng)（盡管是子系統(tǒng)）的交付，并且改善整體的適應(yīng)性。然而，迭代方法仍然要求其中的開發(fā)過程是定義的和線性的。見圖3。
圖 3
Given the complex environment and the increased reliance on new "state-of-the-art" systems, the risk endured by system development projects has increased and the search for mechanisms to handle this risk has intensified. One can argue that current methodologies are better than nothing. Each improves on the other. The Spiral and Iterative approaches implant formal risk control mechanisms for dealing with unpredictable results. A framework for development is provided.
在復(fù)雜的環(huán)境及對新的“時髦”系統(tǒng)的更多依賴的情況下，系統(tǒng)開發(fā)項目所要承擔的風(fēng)險已經(jīng)加大，進一步加深了對能處理風(fēng)險的機制的需求。人們可以對使用當前的方法是否比什么方法也不用更好提出質(zhì)疑。每一種方法都是對另一種方法的改進。螺旋型方法和迭代方法灌輸正規(guī)的用于處理不可預(yù)知的結(jié)果的風(fēng)險控制機制。它們提供一個開發(fā)框架。
However, each rests on the fallacy that the development processes are defined, predictable processes. But unpredictable results occur throughout the projects. The rigor implied in the development processes stifles the flexibility needed to cope with the unpredictable results and respond to a complex environment.
然而，它們都取決于一個謬論：開發(fā)過程是定義的，可預(yù)知的。事實是不可預(yù)知的結(jié)果在整個項目過程中都可能發(fā)生。開發(fā)過程的嚴密，抑制了應(yīng)付未知結(jié)果及響應(yīng)復(fù)雜環(huán)境的適應(yīng)性，
Despite their widespread presence in the development community, people don‘t use the methodologies except as a macro process map, or for their detailed method descriptions.
盡管這些開發(fā)方法已經(jīng)在開發(fā)團體中普遍使用，許多人只用它們作為宏觀的過程圖象，或者是詳細的方法描述。
The following graph demonstrates the current development environment, using any of the Waterfall, Spiral or Iterative processes. As the complexity of the variables increase even to a moderate level, the probability of a "successful" project quickly diminishes (a successful project is defined as a system that is useful when delivered). See Figure 4.
下面的圖片使用瀑布式方法、螺旋型方法或迭代過程中的任何一種方法來描述當前開發(fā)環(huán)境。當系統(tǒng)因素的復(fù)雜度增加到中等的程度，項目成功的可能性就迅速減少（成功的項目是指交付時有用的系統(tǒng)）。 見圖4。
圖 4
--------------------------------------------------------------------------------
Methodology
方法
The system development process is complicated and complex. Therefore maximum flexibility and appropriate control is required. Evolution favors those that operate with maximum exposure to environmental change and have maximized flexibility. Evolution deselects those who have insulated themselves from environmental change and have minimized chaos and complexity in their environment.
系統(tǒng)開發(fā)過程是復(fù)雜的和綜合的，所以需要擁有最大化的適應(yīng)性和進行恰當?shù)目刂?。進化的過程喜歡把把環(huán)境的改變最大限度地暴露出來，不喜歡將自己和環(huán)境的改變隔離，以及將環(huán)境的復(fù)雜性最小化的行為。
An approach is needed that enables development teams to operate adaptively within a complex environment using imprecise processes. Complex system development occurs under chaotic circumstances. Producing orderly systems under chaotic circumstances requires maximum flexibility. The closer the development team operates to the edge of chaos, the more competitive and useful the resulting system will be.
需要一種允許開發(fā)小組在復(fù)雜的環(huán)境中以非精確的步驟進行開發(fā)的方法。復(fù)雜的系統(tǒng)開發(fā)發(fā)生于混亂的系統(tǒng)環(huán)境中。在混亂的環(huán)境中有序地進行開發(fā)，需要開發(fā)團隊有最大的適應(yīng)性。越靠近混亂的邊緣進行開發(fā)的團隊，越容易開發(fā)出具有競爭力和有實用價值的系統(tǒng)。
Methodology may well be the most important factor in determining the probability of success. Methodologies that encourage and support flexibility have a high degree of tolerance for changes in other variables. With these methodologies, the development process is regarded as unpredictable at the onset, and control mechanisms are put in place to manage the unpredictability.
方法學(xué)可能說是檢測軟件是否成功的最重要的因素。方法學(xué)鼓勵和支持軟件開發(fā)對環(huán)境變化擁有很高的調(diào)整能力。在這些方法學(xué)中，開發(fā)過程被認為在開始時是不可預(yù)知的，而控制機制正是用來管理不可預(yù)知性。
If we graph the relationship between environmental complexity and probability of success with a flexible methodology that incorporates controls and risk management, the tolerance for change is more durable. See Figure 5.
如果我們畫一個關(guān)系圖，用來表示環(huán)境復(fù)雜性和的項目成功的概率之間的關(guān)系，這里的項目是指應(yīng)用了統(tǒng)一控制和風(fēng)險管理的可適應(yīng)方法論的項目。參見圖5。
圖 5
Figures 4 and 5 reflect software development experiences at ADM, Easel, Vmark, Borland and virtually every other developer of "packaged" software. These organizations have embraced risk and environmental complexity during development projects. Increased product impact, successful projects, and productivity gains were experienced. The best possible software is built.
圖4和圖5反映出ADM，Easel,Vmark,Borland以及事實上每一個其他的打包軟件的開發(fā)者軟件開發(fā)的經(jīng)驗。這些機構(gòu)也都在開發(fā)項目時遇到風(fēng)險和復(fù)雜的環(huán)境。他們經(jīng)歷了產(chǎn)品不斷需要增強的影響，項目的成功，生產(chǎn)力的不斷提高。這樣最好的軟件誕生了。
Waterfall and Spiral methodologies set the context and deliverable definition at the start of a project. SCRUM and Iterative methodologies initially plan the context and broad deliverable definition, and then evolve the deliverable during the project based on the environment. SCRUM acknowledges that the underlying development processes are incompletely defined and uses control mechanisms to improve flexibility.
瀑布和螺旋模型在項目開始時聲明前后關(guān)系和可交付定義。SCRUM和迭代的方法在開始時定義前后關(guān)系和主要的可交付定義，以后在根據(jù)項目環(huán)境增加可交付定義。SCRUM承認根本的開發(fā)過程不能完全加以定義，需要用控制機制增加可行性。
The primary difference between the defined (waterfall, spiral and iterative) and empirical (SCRUM) approach is that The SCRUM approach assumes that the analysis, design, and development processes in the Sprint phase are unpredictable. A control mechanism is used to manage the unpredictability and control the risk. Flexibility, responsiveness, and reliability are the results. See Figure 6.
在瀑布、螺旋、迭代等模型的已定義方法和經(jīng)驗主義的SCRUM方法之間的基本不同點是SCRUM方法假定在快速變化中分析、設(shè)計、開發(fā)過程中的狀態(tài)是不可預(yù)知的。一種控制機制被用于管理不可預(yù)知性和控制風(fēng)險。帶來的成效是適應(yīng)性、響應(yīng)能力和可靠性的增強。見圖6
圖 6
Characteristics of SCRUM methodology are :
SCRUM方法的特征如下：
The first and last phases (Planning and Closure) consist of defined processes, where all processes, inputs and outputs are well defined. The knowledge of how to do these processes is explicit. The flow is linear, with some iterations in the planning phase.
最先和最后階段（計劃階段和結(jié)束階段）由可定義的過程組成，這些過程的輸入輸出都能很好的加以定義。如何去實施這些過程的知識是很明確的。過程流程是直線的，在計劃階段會有一些迭代。
The Sprint phase is an empirical process. Many of the processes in the sprint phase are unidentified or uncontrolled. It is treated as a black box that requires external controls. Accordingly, controls, including risk management, are put on each iteration of the Sprint phase to avoid chaos while maximizing flexibility.
沖刺階段是一個完全根據(jù)經(jīng)驗的過程。在沖刺階段中的許多的過程是未經(jīng)確認地和不可控制的?？梢砸暈樾枰~外控制的黑盒。因此包括風(fēng)險管理的控制被放在沖刺階段的每一次迭代，以避免在取得最佳的適應(yīng)性的同時造成混亂。
Sprints are nonlinear and flexible. Where available, explicit process knowledge is used; otherwise tacit knowledge and trial and error is used to build process knowledge. Sprints are used to evolve the final product.
沖刺過程是非線性的和可變的。如果有明確的過程知識，就用它來建立過程知識，否則就使用默認的知識以及試驗的以及錯誤的知識。沖刺過程被用于發(fā)展最終產(chǎn)品。
The project is open to the environment until the Closure phase. The deliverable can be changed at any time during the Planning and Sprint phases of the project. The project remains open to environmental complexity, including competitive, time, quality, and financial pressures, throughout these phases.
項目是對環(huán)境開放的，直到項目結(jié)束階段。在項目的計劃階段和沖刺階段，可交付信息可以在任何時間被改變。在這些狀態(tài)中，項目始終保持對復(fù)雜的環(huán)境的開放，包括競爭，時間，質(zhì)量和資金壓力。
The deliverable is determined during the project based on the environment.
可交付內(nèi)容由項目的環(huán)境所決定。
Figure 7 compares the primary SCRUM characteristics to those of other methodologies.
圖7基本的SCRUM方法和其他方法特性的比較
圖 7
--------------------------------------------------------------------------------
Phases
進度
Pregame
項目開始前
Planning : Definition of a new release based on currently known backlog, along with an estimate of its schedule and cost. If a new system is being developed, this phase consists of both conceptualization and analysis. If an existing system is being enhanced, this phase consists of limited analysis.
計劃階段：在當前已知的待定項的基礎(chǔ)上，對新版本進行定義，并預(yù)計其進度和費用。如果正在開發(fā)一個新的系統(tǒng)，本階段包含概念化和分析兩方面；如果正在對現(xiàn)有系統(tǒng)進行增強，則本階段僅包含有限的分析。
Architecture : Design how the backlog items will be implemented. This phase includes system architecture modification and high level design.
體系架構(gòu)階段：構(gòu)思如何實現(xiàn)待定項。本階段包括系統(tǒng)架構(gòu)修改和高層設(shè)計。
Game
項目中
Development Sprints : Development of new release functionality, with constant respect to the variables of time, requirements, quality, cost, and competition. Interaction with these variables defines the end of this phase. There are multiple, iterative development sprints, or cycles, that are used to evolve the system.
開發(fā)沖刺階段：在始終考慮時間、需求、質(zhì)量、費用和競爭等因素的情況下，開發(fā)新版本的功能。與上述因素間的相互作用標志著本階段的完成。為了提升系統(tǒng)性能，會有多次的、迭代的開發(fā)沖刺或循環(huán)。
Postgame
項目結(jié)束后
Closure : Preparation for release, including final documentation, pre-release staged testing, and release.
結(jié)束階段：版本發(fā)布準備，包括準備最終文檔、發(fā)行前的階段性測試以及最終版本。
圖 9
Each of the phases has the following steps:
每一階段均包含以下步驟：
Planning
計劃
Development of a comprehensive backlog list.
形成一個全面的待定項的目錄
Definition of the delivery date and functionality of one or more releases.
確定發(fā)行日期及一個或多個發(fā)行版本的功能
Selection of the release most appropriate for immediate development.
為后繼開發(fā)選擇一個最合適的版本。
Mapping of product packets (objects) for backlog items in the selected release.
在選定的版本中，為待定項和產(chǎn)品包(對象)間建立對應(yīng)關(guān)系。
Definition of project team(s) for the building of the new release.
為新版本的開發(fā)確定各項目小組。
Assessment of risk and appropriate risk controls.
進行風(fēng)險評估，并加以適當?shù)娘L(fēng)險控制。
Review and possible adjustment of backlog items and packets.
對待定項和程序包進行總結(jié)及可能的調(diào)整。
Validation or reselection of development tools and infrastructure.
對開發(fā)工具和基礎(chǔ)架構(gòu)進行確認或重新選擇。
Estimation of release cost, including development, collateral material, marketing, training, and rollout.
預(yù)測發(fā)行成本，包括開發(fā)、相關(guān)材料、市場營銷、培訓(xùn)和首次展示。
Verification of management approval and funding.
確認經(jīng)理的認可和資金保障。
Architecture/High Level Design
架構(gòu)/高層設(shè)計
Review assigned backlog items.
總結(jié)已指派的待定項。
Identify changes necessary to implement backlog items.
確定為實現(xiàn)待定項所必須的變化。
Perform domain analysis to the extent required to build, enhance, or update the domain models to reflect the new system context and requirements.
進行域分析，直至新的系統(tǒng)環(huán)境和需求需要建立、增強和更新現(xiàn)有域模型為止。
Refine the system architecture to support the new context and requirements.
精化系統(tǒng)架構(gòu)以適應(yīng)新的環(huán)境和需求。
Identify any problems or issues in developing or implementing the changes
對開發(fā)和實現(xiàn)這些改變時所出現(xiàn)的各種問題和觀點進行確認。
Design review meeting, each team presenting approach and changes to implement each backlog item. Reassign changes as required.
組織總結(jié)會議，各項目小組闡明為實現(xiàn)各自的待定項所需的方法和變更。按需要重新分配變更。
Development (Sprint) - the Development phase is an iterative cycle of development work. The management determines that time, competition, quality, or functionality are met, iterations are completed and the closure phase occurs. This approach is also known as Concurrent Engineering. Development consists of the following macro processes :
開發(fā)(沖刺)－開發(fā)階段是開發(fā)工作的一個迭代循環(huán)。經(jīng)理判定時間、競爭性、質(zhì)量或功能符合要求后，迭代過程結(jié)束并進入結(jié)束階段。該方法也被稱為并發(fā)工程。開發(fā)包含以下宏觀過程：
Meeting with teams to review release plans.
與各項目小組開會討論總結(jié)計劃。
Distribution, review and adjustment of the standards with which the product will conform.
對產(chǎn)品所需遵從的標準進行分發(fā)、總結(jié)和調(diào)整。
Iterative Sprints, until the product is deemed ready for distribution.
迭代沖刺，直至產(chǎn)品可被確認為適于發(fā)行。
A Sprint is a set of development activities conducted over a pre-defined period, usually one or four weeks. The interval is based on product complexity, risk assessment, and degree of oversight desired. Sprint speed and intensity are driven by the selected duration of the Sprint. Risk is assessed continuously and adequate risk controls and responses put in place. Each Sprint consists of one or more teams performing the following:
一個沖刺是一系列開發(fā)活動的集合，這些開發(fā)活動貫穿預(yù)定義階段，通常為一至四個星期。間歇期建立在產(chǎn)品復(fù)雜性、風(fēng)險評估和預(yù)計的監(jiān)管程度上。沖刺的持續(xù)時間決定了沖刺的速度和強度。風(fēng)險評估是持續(xù)進行的，并應(yīng)加入適當?shù)娘L(fēng)險控制和響應(yīng)。每一沖刺由一個或多個項目小組組成來完成以下工作：
Develop: Defining changes needed for the implementation of backlog requirements into packets, opening the packets, performing domain analysis, designing, developing, implementing, testing, and documenting the changes. Development consists of the micro process of discovery, invention, and implementation.
開發(fā)：對為實現(xiàn)待定項所需加入程序包中的變更進行定義，打開程序包，進行域分析，設(shè)計，開發(fā)，實現(xiàn)，測試，記錄變更。開發(fā)包含發(fā)現(xiàn)、創(chuàng)新和實現(xiàn)的微觀過程。
Wrap: Closing the packets, creating a executable version of changes and how they implement backlog requirements.
封裝：關(guān)閉程序包，為變更和這些待定需求如何實現(xiàn)創(chuàng)建一個可執(zhí)行版本。
Review: All teams meeting to present work and review progress, raising and resolving issues and problems, adding new backlog items. Risk is reviewed and appropriate responses defined.
總結(jié)： 所有的小組開會介紹各自的工作，總結(jié)進度，提出并解決問題和困難，增加新的待定項。在會上總結(jié)風(fēng)險，定義適當?shù)娘L(fēng)險應(yīng)對策略。
Adjust: Consolidating the information gathered from the review meeting into affected packets, including different look and feel and new properties.
調(diào)整：將從總結(jié)會議中獲得的信息合并到相關(guān)程序包中，包括不同的觀點、體驗和新的特性。
Each Sprint is followed by a review, whose characteristics are :
每一次沖刺均伴隨一次總結(jié)，其特征是：
The whole team and product management are present and participate.
整個小組和產(chǎn)品經(jīng)理均到場參加。
The review can include customers, sales, marketing and others.
總結(jié)可包括用戶、經(jīng)銷商、市場人員和其他人。
Review covers functional, executable systems that encompass the objects assigned to that team and include the changes made to implement the backlog items.
總結(jié)覆蓋功能性的、可執(zhí)行的系統(tǒng)。這些系統(tǒng)包含了分配給該項目小組的目標和為實現(xiàn)待定項所需的變更。
The way backlog items are implemented by changes may be changed based on the review.
通過變更實現(xiàn)待定項的方法可在總結(jié)的基礎(chǔ)上改變。
New backlog items may be introduced and assigned to teams as part of the review, changing the content and direction of deliverables.
作為總結(jié)的一部分，新的待定項可被引入并分配給各項目小組，以改變可交付版本的內(nèi)容和方向。
The time of the next review is determined based on progress and complexity. The Sprints usually have a duration of 1 to 4 weeks.
下一次總結(jié)的時間由進度和復(fù)雜性確定。沖刺階段通常持續(xù)1到4周。
Closure - When the management team feels that the variables of time, competition, requirements, cost, and quality concur for a new release to occur, they declare the release "closed" and enter this phase. This phase prepares the developed product for general release. Integration, system test, user documentation, training material preparation, and marketing material preparation are among closure tasks.
結(jié)束：當經(jīng)理綜合時間、競爭性、需求、費用和質(zhì)量等諸多因素，感到已經(jīng)適于發(fā)布一個新的版本，他們宣布開發(fā)"結(jié)束"并進入本階段。本階段準備對已開發(fā)完成的產(chǎn)品進行常規(guī)發(fā)布。結(jié)束階段的任務(wù)包括集成，系統(tǒng)測試，用戶文檔，培訓(xùn)材料和市場營銷材料的準備。
--------------------------------------------------------------------------------
Controls
控制
Operating at the edge of chaos (unpredictability and complexity) requires management controls to avoid falling into chaos. The SCRUM methodology embodies these general, loose controls, using OO techniques for the actual construction of deliverables.
當處于陷入混亂（未知性和復(fù)雜性）的邊緣時，需要管理者進行控制避免最終陷入混亂中。在使用面向?qū)ο蠹夹g(shù)來構(gòu)建實際的可發(fā)行軟件過程中，SCRUM方法包括了一般化和松散的控制。
Risk is the primary control. Risk assessment leads to changes in other controls and responses by the team.
風(fēng)險是首要的控制因素，風(fēng)險評估會改變對于其他內(nèi)容的因素，進而帶來開發(fā)團隊對于這些控制因素的改變的反應(yīng)。
Controls in the SCRUM methodology are :
在SCRUM方法中控制包括了下面的內(nèi)容：
Backlog: Product functionality requirements that are not adequately addressed by the current product release. Bugs, defects, customer requested enhancements, competitive product functionality, competitive edge functionality, and technology upgrades are backlog items.
待定項：當前版本的產(chǎn)品不能夠充分地實現(xiàn)的產(chǎn)品功能需求、錯誤、缺陷、用戶需求的增強、競爭性產(chǎn)品的功能、更優(yōu)越的具有競爭性的功能以及技術(shù)升級都是待定項。
Release/Enhancement: backlog items that at a point in time represent a viable release based on the variables of requirements, time, quality, and competition.
版本/增強：在基于需求、時間、質(zhì)量和競爭這些因素的基礎(chǔ)上，一個可行的新版本由在某個時點上的待定項決定。
Packets: Product components or objects that must be changed to implement a backlog item into a new release.
軟件包： 為實現(xiàn)待定項以形成新版本而必須加以修改的產(chǎn)品組件或?qū)ο蟆?div style="height:15px;">
Changes: Changes that must occur to a packet to implement a backlog item.
變更：軟件包必須改變從而實現(xiàn)待定項。
Problems: Technical problems that occur and must be solved to implement a change.
問題：由于技術(shù)變化而出現(xiàn)的問題必須被解決。
Risks: risks that effect the success of the project are continuously assessed and responses planned. Other controls are affected as a result of risk assessment.
風(fēng)險：必須不斷地對影響項目成功的風(fēng)險因素進行評估并且制定出對策。風(fēng)險評估的結(jié)果影響了其他方面因素的控制。
Solutions: solutions to the problems and risks, often resulting in changes.
解決方案：解決困難和防范風(fēng)險的解決方案通常會發(fā)生變化。
Issues: Overall project and project issues that are not defined in terms of packets, changes and problems.
結(jié)果：整個項目和項目結(jié)果并不是由軟件包、變化和問題來定義的。
These controls are used in the various phases of SCRUM. Management uses these controls to manage backlog. Teams use these controls to manage changes, problems. Both management and teams jointly manage issues, risks, and solutions. These controls are reviewed, modified, and reconciled at every Sprint review meeting.
這些控制因素存在于SCRUMf方法的不同階段中。管理者使用這些控制因素來管理預(yù)定的項目。開發(fā)團隊使用這些控制因素來解決變化和問題。管理者和開發(fā)團隊共同地管理結(jié)果、風(fēng)險和解決方案。在每次沖刺總結(jié)會上這些控制因素都被提出來討論、修改并進行協(xié)調(diào)。
--------------------------------------------------------------------------------
Deliverables
可交付性
The delivered product is flexible. Its content is determined by environment variables, including time, competition, cost, or functionality. The deliverable determinants are market intelligence, customer contact, and the skill of developers. Frequent adjustments to deliverable content occur during the project in response to environment. The deliverable can be determined anytime during the project.
交付的產(chǎn)品是可變的。具體內(nèi)容取決于包括時間、競爭、費用和功能等在內(nèi)的環(huán)境因素?？山桓懂a(chǎn)品的決定因素包括了市場能力、客戶關(guān)系和開發(fā)人員的技術(shù)水平。環(huán)境的變動促使軟件項目在開發(fā)過程中對于可交付內(nèi)容不斷地作出調(diào)整。可交付產(chǎn)品可能取決于軟件項目過程中的任何階段。
--------------------------------------------------------------------------------
Project Team
項目小組
The team that works on the new release includes full time developers and external parties who will be affected by the new release, such as marketing, sales, and customers. In traditional release processes, these latter groups are kept away from development teams for fear of over-complicating the process and providing "unnecessary" interference. The SCRUM approach, however, welcomes and facilitates their controlled involvement at set intervals, as this increases the probability that release content and timing will be appropriate, useful, and marketable.
在新版本的開發(fā)過程中，項目小組不僅僅包括全職開發(fā)人員，也包括了新版本會影響到的外部人員，比如市場營銷人員和顧客。在傳統(tǒng)的版本開發(fā)過程中，后者是被排除在開發(fā)小組之外的，以避免開發(fā)過程過于復(fù)雜并且避免導(dǎo)致對開發(fā)工作產(chǎn)生不必要的干擾。然而，SCRUM方法歡迎并且階段性地利用了他們有限制的參與，認為這樣將更加能夠促使新版本合適、有用并且受到市場歡迎。
The following teams are formed for each new release:
每個新版本的開發(fā)過程將包括下面的小組：
Management: Led by the Product Manager, it defines initial content and timing of the release, then manages their evolution as the project progresses and variables change. Management deals with backlog, risk, and release content.
管理者：由產(chǎn)品經(jīng)理領(lǐng)導(dǎo)，該小組確定該版本的初始內(nèi)容和發(fā)布時間，然后管理項目開發(fā)進度的變化以及各種因素的變化。管理者需要管理待定項、風(fēng)險和版本內(nèi)容。
Development teams: Development teams are small, with each containing developers, documenters and quality control staff. One or more teams of between three and six people each are used. Each is assigned a set of packets (or objects), including all backlog items related to each packet. The team defines changes required to implement the backlog item in the packets, and manages all problems regarding the changes. Teams can be either functionally derived (assigned those packets that address specific sets of product functionality) or system derived (assigned unique layers of the system). The members of each team are selected based on their knowledge and expertise regarding sets of packets, or domain expertise.
開發(fā)小組：開發(fā)小組規(guī)模都很小，其中包括了開發(fā)人員，文檔書寫管理人員和質(zhì)量控制人員。每個開發(fā)小組規(guī)模在3到6個人之間，并且都有特定的任務(wù)。每個小組被指派去完成一組軟件包（或者對象），每個軟件包包含了與該包相關(guān)的待定項。為了實現(xiàn)軟件包中待定項，開發(fā)小組定義需要做出的改變，并且解決由這些改變而帶來的問題。小組可以按照功能進行劃分（分配實現(xiàn)特定產(chǎn)品功能組合的軟件包），也可以按照系統(tǒng)來劃分（分配系統(tǒng)中唯一的一個層次）。每個小組的成員是根據(jù)他們對所指定的軟件包應(yīng)具有的專業(yè)知識和技能來選擇的，或者根據(jù)專家意見來選擇。
--------------------------------------------------------------------------------
Characteristics
特性
The SCRUM methodology is a metaphor for the game of Rugby. Rugby evolved from English football (soccer) under the intense pressure of the game :
SCRUM方法是橄欖球比賽的一個隱喻。 橄欖球是由英式足球在劇烈的比賽壓力下發(fā)展而來的：
Rugby student William Webb Ellis, 17, inaugurates a new game whose rules will be codified in 1839. Playing soccer for the 256-year-old college in East Warwickshire, Ellis sees that the clock is running out with his team behind so he scoops up the ball and runs with it in defiance of the rules. The People‘s Chronology, Henry Holt and Company, Inc. Copyright ?1992.
17歲的橄欖球?qū)W生威廉·韋布·埃利斯（William Webb Ellis）開創(chuàng)了一種新的運動，并且該項運動的游戲規(guī)則于1839年被確認。一次在為有256年歷史的東沃里克郡學(xué)院踢足球的比賽期間，威廉·韋布·埃利斯（William Webb Ellis）發(fā)現(xiàn)比賽就要結(jié)束而他的球隊還是落后，情急之下，他一把抓起足球，帶著跑，以此來挑戰(zhàn)比賽規(guī)則。
SCRUM projects have the following characteristics :
SCRUM 項目具備下面的特性：
Flexible deliverable - the content of the deliverable is dictated by the environment.
靈活的可交付能力――可交付內(nèi)容由環(huán)境因素決定。
Flexible schedule - the deliverable may be required sooner or later than initially planned.
靈活的進度安排―― 版本交付可能早于也可能遲于最初計劃時間。
Small teams - each team has no more than 6 members. There may be multiple teams within a project.
小的隊伍――每個小組不超過6個成員，一個項目可能包括了多個小組。
Frequent reviews - team progress is reviewed as frequently as environmental complexity and risk dictates (usually 1 to 4 week cycles). A functional executable must be prepared by each team for each review.
經(jīng)?？偨Y(jié)―― 隨著環(huán)境復(fù)雜度和風(fēng)險度的改變，小組的進度經(jīng)常要進行總結(jié)（通常為1到4個星期為一個周期）。為每次總結(jié)每個小組都必須精心準備有一定功能的可執(zhí)行代碼。
Collaboration - intra and inter-collaboration is expected during the project.
協(xié)作：―― 在項目的整個過程中需要內(nèi)部的和相互的協(xié)作。
Object Oriented - each team will address a set of related objects, with clear interfaces and behavior.
面向?qū)ο螅總€小組開發(fā)一系列相關(guān)的具有確定接口和行為的對象。
The SCRUM methodology shares many characteristics with the sport of Rugby :
SCRUM方法具有與橄欖球運動相似的許多特征：
The context is set by playing field (environment) and rugby rules (controls).
由比賽場地（環(huán)境）和橄欖球規(guī)則（控制）來決定前后關(guān)系。
The primary cycle is moving the ball forward.
主要的循環(huán)周期是把球向前送。
Rugby evolved from breaking soccer rules - adapting to the environment.
橄欖球來源于打破足球規(guī)則――為了適應(yīng)環(huán)境
The game does not end until environment dictates (business need, competition, functionality, timetable).
除非環(huán)境要求否則比賽不會結(jié)束（商業(yè)需求、競爭、功能、時間表）
--------------------------------------------------------------------------------
Advantages
優(yōu)勢
Additional development methodologies are designed only to respond to the unpredictability of the external and development environments at the start of an enhancement cycle. Such newer approaches as the Boehm spiral methodology and its variants are still limited in their ability to respond to changing requirements once the project has started.
其他的開發(fā)方法只是為了彌補在增強周期開始的時候由于外部的和開發(fā)環(huán)境的不確定造成的影響。一些新的途徑諸如Boehm螺旋方法以及它的變體，其在項目啟動后響應(yīng)需求變化的能力是有限的。
The SCRUM methodology, on the other hand, is designed to be quite flexible throughout. It provides control mechanisms for planning a product release and then managing variables as the project progresses. This enables organizations to change the project and deliverables at any point in time, delivering the most appropriate release.
然而，SCRUM方法論的設(shè)計自始至終具有很強的適應(yīng)性。它提供了規(guī)劃產(chǎn)品版本從而在項目過程中進行變化因素管理的控制機制。這使得開發(fā)機構(gòu)可以及時地在任意點上修改項目和發(fā)布日期，從而做到發(fā)布最合適的版本。
The SCRUM methodology frees developers to devise the most ingenious solutions throughout the project, as learning occurs and the environment changes.
SCRUM方法論使得開發(fā)人員在開發(fā)過過程中隨著知識的增長和環(huán)境的變化，能夠在整個項目過程中自由地設(shè)計最有創(chuàng)意的解決方案。
Small, collaborative teams of developers are able to share tacit knowledge about development processes. An excellent training environment for all parties is provided.
小型的合作開發(fā)組能夠共享有關(guān)開發(fā)過程的默認知識。為所有參與者提供了一個優(yōu)秀的訓(xùn)練環(huán)境。
Object Oriented technology provides the basis for the SCRUM methodology. Objects, or product features, offer a discrete and manageable environment. Procedural code, with its many and intertwined interfaces, is inappropriate for the SCRUM methodology. SCRUM may be selectively applied to procedural systems with clean interfaces and strong data orientation.
面向?qū)ο蠹夹g(shù)為SCRUM提供了技術(shù)基礎(chǔ)。對象，或者說產(chǎn)品特征，提供了一個離散的可管理的環(huán)境。面向過程的代碼所具有的包含諸多相互交織的接口的特點對于SCRUM技術(shù)是不合適的。然而對于有著清晰接口和明顯的數(shù)據(jù)導(dǎo)向的面向過程的系統(tǒng)SCRUM技術(shù)還是可以考慮的。
--------------------------------------------------------------------------------
Estimating
評估
SCRUM projects can be estimated using standard function point estimating. However, it is advisable to estimate productivity at approximately twice the current metric. The estimate is only for starting purposes, however, since the overall timetable and cost are determined dynamically in response to the environmental factors.
SCRUM項目可以用標準的點估計函數(shù)。但是，明智的做法是以現(xiàn)有度量的兩倍作為生產(chǎn)力的估計。而且這個估計只是用于項目啟動之用，因為整個過程的時間安排和花費是由諸多的環(huán)境因素動態(tài)決定的。
Our observations have led us to conclude that SCRUM projects have both velocity and acceleration. In terms of functions delivered, or backlog items completed :
我們的觀察發(fā)現(xiàn)SCRUM項目同時具有速度和加速度。就發(fā)布的功能或者待定項而言：
initial velocity and acceleration are low as infrastructure is built/modified
最初的速度和加速度比較低是由于要構(gòu)建基礎(chǔ)架構(gòu)
as base functionality is put into objects, acceleration increases
當基本功能加入到對象中時，加速度增加了
acceleration decreases and velocity remains sustainably high
加速度降低，速度保持足夠高
Further development in metrics for empirical processes is required.
對基于經(jīng)驗的過程的度量的有待做進一步地研究。
--------------------------------------------------------------------------------
Appendix 1
附錄 1
System Development Methodologies : Defined or Empirical
系統(tǒng)開發(fā)方法：規(guī)定和經(jīng)驗
System development is the act of creating a logical construct that is implemented as logic and data on computers. The logical construct consists of inputs, processes, and outputs, both macro (whole construct) and micro (intermediate steps within whole construct). The whole is known as an implemented system.
系統(tǒng)開發(fā)是在計算機上通過邏輯和數(shù)據(jù)來創(chuàng)建邏輯結(jié)構(gòu)的行為。這個邏輯結(jié)構(gòu)包括輸入、過程和輸出，可分為宏觀的(整個結(jié)構(gòu)）和微觀的（整個結(jié)構(gòu)的中間步驟）兩類。這三者一起被稱作完成的系統(tǒng)。
Many artifacts are created while building the system. Artifacts may be used to guide thinking, check completeness, and create an audit trail. The artifacts consist of documents, models, programs, test cases, and other deliverables created prior to creating the implemented system. When available, a metamodel defines the semantic content of model artifacts. Notation describes the graphing and documentation conventions that are used to build the models.
在構(gòu)建系統(tǒng)的過程中會創(chuàng)建許多的人工附屬物，可以用來幫助思考，檢驗完整性，創(chuàng)建審計紀錄。它們包括在創(chuàng)建整個系統(tǒng)前創(chuàng)建的文檔、模型、程序、測試用例以及其他發(fā)布文檔?？赡艿脑挘迷Ｐ蛠矶x模型的語義內(nèi)容。符號描述用以構(gòu)建模型的書寫和文檔約定。
The approach used to develop a system is known as a method. A method describes the activities involved in defining, building, and implementing a system; a method is a framework. Since a method is a logical process for constructing systems (process), it is known as a metaprocess (a process for modeling processes).
用于開發(fā)系統(tǒng)的途徑稱為方法。它是一個框架，描述了定義、構(gòu)建和實現(xiàn)系統(tǒng)的相關(guān)活動。因為方法是構(gòu)建系統(tǒng)（過程）的一個邏輯過程，所以它也被稱作元過程（為過程建模的過程）
A method has micro and macro components. The macro components define the overall flow and time-sequenced framework for performing work. The micro components include general design rules, patterns and rules of thumb. General design rules state properties to achieve or to avoid in the design or general approaches to take while building a system. Patterns are solutions that can be applied to a type of development activity; they are solutions waiting for problems that occur during an activity in a method. Rules of thumb consist of a general body of hints and tips.
方法有著宏觀和微觀成份。宏觀成份規(guī)定了實行工作的整個流程和時序框架。微觀成份則包括一般設(shè)計規(guī)則、翻閱模式和規(guī)則。其中一般設(shè)計規(guī)則描述在設(shè)計上所要達到或者避免的特性，或者描述在構(gòu)建系統(tǒng)時要采取的一般方法。模式是可以用于一類開發(fā)活動的解決方案；用于解決在某一方法的某一活動實行過程中出現(xiàn)的問題。翻閱規(guī)則包括一般提示和技巧。
Applying concepts from industrial process control to the field of systems development, methods can be categorized as either "theoretical" (fully defined) or "empirical" (black box).
當把工業(yè)過程控制中的概念引入到系統(tǒng)開發(fā)的領(lǐng)域時，方法可以歸為理論的(完全定義的）或者經(jīng)驗的（黑箱）。
Correctly categorizing systems development methods is critical. The appropriate structure of a method for building a particular type of system depends on whether the method is theoretical or empirical.
正確地將系統(tǒng)開發(fā)的方法進行分類是關(guān)鍵的。用于構(gòu)建某一類特殊的系統(tǒng)的方法的合適的結(jié)構(gòu)取決于這個方法是經(jīng)驗的還是理論的。
Models of theoretical processes are derived from first principles, using material and energy balances and fundamental laws to determine the model. For a systems development method to be categorized as theoretical, it must conform to this definition.
理論過程的模型是從第一原則得到的，這一原則利用物質(zhì)和能量守恒以及基本法則來決定模型。如果哪個系統(tǒng)開發(fā)方法要被歸為理論的，它必須滿足這個定義。
Models of empirical processes are derived categorizing observed inputs and outputs, and defining controls that cause them to occur within prescribed bounds. Empirical process modeling involves constructing a process model strictly from experimentally obtained input/output data, with no recourse to any laws concerning the fundamental nature and properties of the system. No a priori knowledge about the process is necessary (although it can be helpful); a system is treated like a black box.
經(jīng)驗過程的模型是通過將觀察到的輸入輸出進行分類，將限制其在一定范圍內(nèi)發(fā)生的控制進行定義得到的。經(jīng)驗過程模型只考慮嚴格按照實驗數(shù)據(jù)進行建模，并不考慮任何與系統(tǒng)的基本特性相關(guān)的法則。有關(guān)過程的先驗知識是不必要的(盡管會有幫助），系統(tǒng)被完全當作一個黑箱來看待。
Upon inspection, we assert that the systems development process is empirical:
通過以上分析，我們斷言系統(tǒng)開發(fā)過程是經(jīng)驗的：
Applicable first principles are not present
缺乏可用的第一原則
The process is only beginning to be understood
過程剛剛開始被了解
The process is complex
過程是復(fù)雜的
The process is changing
過程是變化的
Most methodologists agree with this assertion; "...you can‘t expect a method to tell you everything to do. Writing software is a creative process, like painting or writing or architecture... ... (a method) supplies a framework that tells how to go about it and identifies the places where creativity is needed. But you still have to supply the creativity...."
大多數(shù)的方法學(xué)家同意這樣的觀點：“......不要奢望一個方法告訴你要做的一切。寫軟件是一個創(chuàng)新的過程，就象是繪畫、寫作或者建筑......(一個方法）提供了一個告訴你如何去做的框架，并且識別需要創(chuàng)新的地方。但是創(chuàng)新必須由你來完成。”
Categorizing the systems development methods as empirical is critical to the effective management of the systems development process.
將系統(tǒng)開發(fā)過程劃歸為經(jīng)驗的對于對系統(tǒng)開發(fā)過程進行有效的管理是關(guān)鍵的。
If systems development methods are categorized as empirical, measurements and controls are required because it is understood that the inner workings of the method are so loosely defined that they cannot be counted on to operate predictably.
如果系統(tǒng)開發(fā)過程被劃歸為經(jīng)驗的，那么就需要度量和控制。因為方法的內(nèi)部工作方式的定義太寬松以至于不可能進行提前操作。
In the past, methods have been provided and applied as though they were theoretical. As a consequence, measurements were not relied upon and controls dependent upon the measurements weren‘t used.
在以前，方法被當作是基于理論的而提出和應(yīng)用。這樣就不依賴于度量，而依賴于度量的控制就沒有被使用。
Many of the problems in developing systems have occurred because of this incorrect categorization. When a black box process is treated as a fully defined process, unpredictable results occur. Also, the controls are not in place to measure and respond to the unpredictability.
這種不正確的分類導(dǎo)致了系統(tǒng)開發(fā)的許多問題。當一個黑箱過程被當作一個完整定義的過程時，不可預(yù)料的結(jié)果出現(xiàn)了。而且，用于度量和響應(yīng)這意外的控制機制并沒有被使用。
--------------------------------------------------------------------------------
References
Bach, James. "Process Evolution in a Mad World." Borland International, Scotts Valley, CA.
Bach, James. October, 1995. "The Challenge of "Good Enough" Software", American Programmer.
Coplien, J. "Borland Software Craftsmanship: A New Look at Process, Quality and Productivity." Proceedings of the 5th Annual Borland International Conference, June 5, 1994. Orlando, Florida.
DeGrace, P. and Hulet Stahl, L. 1990. Wicked Problems, Righteous Solutions. Yourdon Press
Gleick, J. 1987. Chaos, Making A New Science. Penguin Books.
Kahn, D. and Sutherland, J. March-April 1994. "Let‘s start under-promising and over-delivering on OT." Object Magazine.
Ogunnaike, B. 1994. Process Dynamics, Modeling, and Control. Oxford University Press.
James Rumbaugh, October 1995, "What Is a Method". Journal of Object Oriented Programming.
Takeuchi, Hirotaka and Nonaka, Ikujiro. January-February 1986. "The New Product Development Game." Harvard Business Review.
Takeuchi, Hirotaka and Nonaka, Ikujiro. 1995. The Knowledge Creating Company: How Japanese Companies Create the Dynamics of Innovation, Oxford University Press.
版權(quán)所有：UML軟件工程組織
