|
"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."
"工程師所面臨的問題是修改軟件會(huì)引起系統(tǒng)混亂,特別是一個(gè)微小的錯(cuò)誤就能導(dǎo)致系統(tǒng)崩潰。但是，修改也能帶來(lái)機(jī)遇。簡(jiǎn)而言之：如果很輕易地就能給系統(tǒng)增加一定功能，那么就會(huì)冒一定的風(fēng)險(xiǎn)增加更多的功能。從而使我們的計(jì)劃顯得有些瘋狂－我們將傾向于盡可能地冒風(fēng)險(xiǎn)。"
James Bach. October 1995. "American Programmer"
Copyright 1995 Advanced Development Methods All Rights Reserved
--------------------------------------------------------------------------------
Contents ：
Introduction
簡(jiǎn)介
Overview
概述
Current Development Situation
現(xiàn)在的發(fā)展?fàn)顩r
Methodology
方法
Phases
進(jìn)度
Controls
控制
Deliverables
可交付性
Project Team
項(xiàng)目組
Characteristics
特性
Advantages
優(yōu)勢(shì)
Estimating
評(píng)估
Appendix 1 - System Development Methodologies : Defined or Empirical
附錄1－系統(tǒng)開發(fā)方法：定義或經(jīng)驗(yàn)
--------------------------------------------------------------------------------
Introduction
簡(jiǎn)介
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ā)的主要部分看成一個(gè)可控制的黑盒。我們將之與復(fù)雜性理論相聯(lián)系，來(lái)說(shuō)明為什么這種方法改善了適應(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)提出許多改進(jìn)系統(tǒng)開發(fā)過程的方法。每一種方法都被吹捧為："重大成果性突破。"其實(shí)沒有一種做到。正如Grady Booch所說(shuō)的："我們常稱這種情況為軟件危機(jī)，但坦率的說(shuō)，長(zhǎng)久以來(lái)我們一直把這種病態(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è)過程控制的觀點(diǎn)應(yīng)用到系統(tǒng)開發(fā)領(lǐng)域。工業(yè)過程控制定義過程或者是"理論的"（完全定義的）或者是"經(jīng)驗(yàn)的"（黑盒）。當(dāng)將一個(gè)黑盒過程當(dāng)作完全定義的過程處理時(shí)，會(huì)發(fā)生不可預(yù)測(cè)的結(jié)果。對(duì)這種情況進(jìn)一步的處理將在附錄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āng)作完全定義的來(lái)處理。這就導(dǎo)致了無(wú)控制的不可預(yù)知性。SCRUM方法在處理系統(tǒng)開發(fā)過程時(shí)將其看作可控制的黑盒。
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將會(huì)適用于其他的軟件開發(fā)機(jī)構(gòu)以實(shí)現(xiàn)面向?qū)ο蟮募夹g(shù)與工具所期望帶來(lái)的利益。
--------------------------------------------------------------------------------
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方法論――一個(gè)團(tuán)隊(duì)負(fù)責(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是一種對(duì)已存在系統(tǒng)的管理，提高和維護(hù)的方法。在不久的將來(lái)，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)需要那些改進(jìn)。
Time pressure - what time frame is required to gain a competitive advantage.
時(shí)間壓力－需要什么樣的時(shí)間表以獲得競(jìng)爭(zhēng)優(yōu)勢(shì)。
Competition - what is the competition up to, and what is required to best them.
競(jìng)爭(zhēng)－競(jìng)爭(zhēng)的目標(biāo)是什么，如何最好地實(shí)現(xiàn)目標(biāo)
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.
版本－當(dāng)前需要什么樣的更改以完成系統(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.
這些因素形成了改進(jìn)軟件項(xiàng)目的最初方案。然而，這些因素是隨著項(xiàng)目的進(jìn)行而變化的。一個(gè)成功的開發(fā)方法應(yīng)該將這些因素現(xiàn)在及其將來(lái)可能的變化都考慮進(jìn)去。
--------------------------------------------------------------------------------
Current Development Situation
當(dāng)前開發(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)是在一個(gè)高度復(fù)雜的環(huán)境下開發(fā)的。復(fù)雜性同時(shí)存在于開發(fā)環(huán)境和目標(biāo)環(huán)境。例如，當(dāng)開始開發(fā)航空交通控制系統(tǒng)時(shí)，三層客戶－服務(wù)器系統(tǒng)及航線異常情況并沒有被考慮在內(nèi)。然而，這些環(huán)境和技術(shù)變化通常會(huì)發(fā)生在項(xiàng)目進(jìn)行過程中，你不得不在正在構(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. 實(shí)現(xiàn)技術(shù)的穩(wěn)定性——對(duì)于越新的技術(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)定性和工具的性能——越是新的和功能強(qiáng)大的開發(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. 方法的有效性——將使用什么樣的建模、測(cè)試、版本控制及設(shè)計(jì)方法，他們的效率怎樣？是否有足夠的保證？
Domain expertise - are skilled professionals available in the various domains, including business and technology.行業(yè)知識(shí)和經(jīng)驗(yàn)——是否有不同行業(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. 新特性——將添加什么樣的新特性，這些新特性將在什么樣的程度上符合當(dāng)前的功能。
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. 競(jìng)爭(zhēng)性——在項(xiàng)目進(jìn)行過程中，將怎樣提高競(jìng)爭(zhēng)性？將宣布或發(fā)布什么新功能？
Time/Funding - how much time is available initially and as the project progresses? How much development funding is available.時(shí)間/資金——在項(xiàng)目啟動(dòng)和進(jìn)展過程中，有多少時(shí)間可用？有多少開發(fā)經(jīng)費(fèi)可支配？
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. 其它因素——項(xiàng)目進(jìn)行過程中，為確保成功，任何其它因素都必須考慮，如機(jī)構(gòu)重組。
The overall complexity is a function of these variables :
整體的復(fù)雜性可以用這些因素的一個(gè)函數(shù)來(lái)表示：
complexity = f(development environment variables + target environment variables)
復(fù)雜度＝f（開發(fā)環(huán)境因素＋目標(biāo)環(huán)境因素）
where these variables may and do change during the course of the project.
其中，這些因素可能而且確實(shí)會(huì)在項(xiàng)目過程中變化。
As the complexity of the project increases, the greater the need for controls, particularly the ongoing assessment and response to risk.
隨著項(xiàng)目的復(fù)雜度增加，就更需要控制，特別是資產(chǎn)評(píng)估和風(fēng)險(xiǎn)反應(yīng)。
Attempts to model this development process have encountered the following problems:
對(duì)這類開發(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ì)量控制也是未定義的。測(cè)試過程就是一個(gè)樣例。
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ā)過程未被確認(rèn)。用于確保包含足夠內(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ā)過程中使用小的、詳細(xì)的方法模型的嘗試還未實(shí)現(xiàn)過，因?yàn)殚_發(fā)過程仍未完全定義。自以為開發(fā)過程是定義了的和可預(yù)知的，將會(huì)導(dǎo)致真正面對(duì)不可預(yù)知的結(jié)果時(shí)束手無(wú)策。
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ā)過程是未完全定義的和動(dòng)態(tài)的，眾多的機(jī)構(gòu)已經(jīng)制定出詳細(xì)的開發(fā)方法，包括流行的開發(fā)方法（結(jié)構(gòu)化的方法，面向?qū)ο蟮姆椒?，等等）。瀑布式方法是其中第一個(gè)這樣被定義的系統(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.
雖然瀑布式方法管理了未定義過程的使用，但是，它的線性特點(diǎn)成為它的最大問題。這種過程沒有定義如何響應(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 引入了一個(gè)螺旋型方法來(lái)解決這個(gè)問題。瀑布式過程的每個(gè)階段都用一個(gè)風(fēng)險(xiǎn)評(píng)估和原型活動(dòng)來(lái)結(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ā)過程中的階梯式前進(jìn)。原型讓用戶決定項(xiàng)目是否繼續(xù)進(jìn)行下去，或者是需要送回到前一個(gè)階段，還是應(yīng)該結(jié)束。然而，階段和階段過程仍然是線性的。需求分析仍然在需求分析階段處理，設(shè)計(jì)工作仍然在設(shè)計(jì)階段進(jìn)行，如此類推，每個(gè)階段包含線性的、定義明確的過程。
圖 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ā)展而來(lái)的。每個(gè)迭代過程包含所有的標(biāo)準(zhǔn)瀑布式階段，但每個(gè)迭代過程只處理解析過的功能的一個(gè)子集。整個(gè)可交付的項(xiàng)目被細(xì)分為區(qū)分優(yōu)先級(jí)的子系統(tǒng)，每個(gè)子系統(tǒng)都有清楚的接口。使用這種方法，可以在初始迭代過程中測(cè)試一個(gè)子系統(tǒng)和技術(shù)的可行性。進(jìn)一步的迭代能給項(xiàng)目添加新的資源，同時(shí)保持交付的速度。這種方法改善費(fèi)用控制，確保系統(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)境及對(duì)新的“時(shí)髦”系統(tǒng)的更多依賴的情況下，系統(tǒng)開發(fā)項(xiàng)目所要承擔(dān)的風(fēng)險(xiǎn)已經(jīng)加大，進(jìn)一步加深了對(duì)能處理風(fēng)險(xiǎn)的機(jī)制的需求。人們可以對(duì)使用當(dāng)前的方法是否比什么方法也不用更好提出質(zhì)疑。每一種方法都是對(duì)另一種方法的改進(jìn)。螺旋型方法和迭代方法灌輸正規(guī)的用于處理不可預(yù)知的結(jié)果的風(fēng)險(xiǎn)控制機(jī)制。它們提供一個(gè)開發(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.
然而，它們都取決于一個(gè)謬論：開發(fā)過程是定義的，可預(yù)知的。事實(shí)是不可預(yù)知的結(jié)果在整個(gè)項(xiàng)目過程中都可能發(fā)生。開發(fā)過程的嚴(yán)密，抑制了應(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ā)團(tuán)體中普遍使用，許多人只用它們作為宏觀的過程圖象，或者是詳細(xì)的方法描述。
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.
下面的圖片使用瀑布式方法、螺旋型方法或迭代過程中的任何一種方法來(lái)描述當(dāng)前開發(fā)環(huán)境。當(dāng)系統(tǒng)因素的復(fù)雜度增加到中等的程度，項(xiàng)目成功的可能性就迅速減少（成功的項(xiàng)目是指交付時(shí)有用的系統(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)性和進(jìn)行恰當(dāng)?shù)目刂啤＿M(jìn)化的過程喜歡把把環(huán)境的改變最大限度地暴露出來(lái)，不喜歡將自己和環(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)境中以非精確的步驟進(jìn)行開發(fā)的方法。復(fù)雜的系統(tǒng)開發(fā)發(fā)生于混亂的系統(tǒng)環(huán)境中。在混亂的環(huán)境中有序地進(jìn)行開發(fā)，需要開發(fā)團(tuán)隊(duì)有最大的適應(yīng)性。越靠近混亂的邊緣進(jìn)行開發(fā)的團(tuán)隊(duì)，越容易開發(fā)出具有競(jìng)爭(zhēng)力和有實(shí)用價(jià)值的系統(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é)可能說(shuō)是檢測(cè)軟件是否成功的最重要的因素。方法學(xué)鼓勵(lì)和支持軟件開發(fā)對(duì)環(huán)境變化擁有很高的調(diào)整能力。在這些方法學(xué)中，開發(fā)過程被認(rèn)為在開始時(shí)是不可預(yù)知的，而控制機(jī)制正是用來(lái)管理不可預(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.
如果我們畫一個(gè)關(guān)系圖，用來(lái)表示環(huán)境復(fù)雜性和的項(xiàng)目成功的概率之間的關(guān)系，這里的項(xiàng)目是指應(yīng)用了統(tǒng)一控制和風(fēng)險(xiǎn)管理的可適應(yīng)方法論的項(xià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以及事實(shí)上每一個(gè)其他的打包軟件的開發(fā)者軟件開發(fā)的經(jīng)驗(yàn)。這些機(jī)構(gòu)也都在開發(fā)項(xiàng)目時(shí)遇到風(fēng)險(xiǎn)和復(fù)雜的環(huán)境。他們經(jīng)歷了產(chǎn)品不斷需要增強(qiáng)的影響，項(xiàng)目的成功，生產(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.
瀑布和螺旋模型在項(xiàng)目開始時(shí)聲明前后關(guān)系和可交付定義。SCRUM和迭代的方法在開始時(shí)定義前后關(guān)系和主要的可交付定義，以后在根據(jù)項(xiàng)目環(huán)境增加可交付定義。SCRUM承認(rèn)根本的開發(fā)過程不能完全加以定義，需要用控制機(jī)制增加可行性。
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)驗(yàn)主義的SCRUM方法之間的基本不同點(diǎn)是SCRUM方法假定在快速變化中分析、設(shè)計(jì)、開發(fā)過程中的狀態(tài)是不可預(yù)知的。一種控制機(jī)制被用于管理不可預(yù)知性和控制風(fēng)險(xiǎn)。帶來(lái)的成效是適應(yīng)性、響應(yīng)能力和可靠性的增強(qiá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.
最先和最后階段（計(jì)劃階段和結(jié)束階段）由可定義的過程組成，這些過程的輸入輸出都能很好的加以定義。如何去實(shí)施這些過程的知識(shí)是很明確的。過程流程是直線的，在計(jì)劃階段會(huì)有一些迭代。
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.
沖刺階段是一個(gè)完全根據(jù)經(jīng)驗(yàn)的過程。在沖刺階段中的許多的過程是未經(jīng)確認(rèn)地和不可控制的?？梢砸暈樾枰~外控制的黑盒。因此包括風(fēng)險(xiǎn)管理的控制被放在沖刺階段的每一次迭代，以避免在取得最佳的適應(yīng)性的同時(shí)造成混亂。
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.
沖刺過程是非線性的和可變的。如果有明確的過程知識(shí)，就用它來(lái)建立過程知識(shí)，否則就使用默認(rèn)的知識(shí)以及試驗(yàn)的以及錯(cuò)誤的知識(shí)。沖刺過程被用于發(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.
項(xiàng)目是對(duì)環(huán)境開放的，直到項(xiàng)目結(jié)束階段。在項(xiàng)目的計(jì)劃階段和沖刺階段，可交付信息可以在任何時(shí)間被改變。在這些狀態(tài)中，項(xiàng)目始終保持對(duì)復(fù)雜的環(huán)境的開放，包括競(jìng)爭(zhēng)，時(shí)間，質(zhì)量和資金壓力。
The deliverable is determined during the project based on the environment.
可交付內(nèi)容由項(xiàng)目的環(huán)境所決定。
Figure 7 compares the primary SCRUM characteristics to those of other methodologies.
圖7基本的SCRUM方法和其他方法特性的比較
圖 7
--------------------------------------------------------------------------------
Phases
進(jìn)度
Pregame
項(xiàng)目開始前
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.
計(jì)劃階段：在當(dāng)前已知的待定項(xiàng)的基礎(chǔ)上，對(duì)新版本進(jìn)行定義，并預(yù)計(jì)其進(jìn)度和費(fèi)用。如果正在開發(fā)一個(gè)新的系統(tǒng)，本階段包含概念化和分析兩方面；如果正在對(duì)現(xiàn)有系統(tǒng)進(jìn)行增強(qiáng)，則本階段僅包含有限的分析。
Architecture : Design how the backlog items will be implemented. This phase includes system architecture modification and high level design.
體系架構(gòu)階段：構(gòu)思如何實(shí)現(xiàn)待定項(xiàng)。本階段包括系統(tǒng)架構(gòu)修改和高層設(shè)計(jì)。
Game
項(xiàng)目中
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ā)沖刺階段：在始終考慮時(shí)間、需求、質(zhì)量、費(fèi)用和競(jìng)爭(zhēng)等因素的情況下，開發(fā)新版本的功能。與上述因素間的相互作用標(biāo)志著本階段的完成。為了提升系統(tǒng)性能，會(huì)有多次的、迭代的開發(fā)沖刺或循環(huán)。
Postgame
項(xiàng)目結(jié)束后
Closure : Preparation for release, including final documentation, pre-release staged testing, and release.
結(jié)束階段：版本發(fā)布準(zhǔn)備，包括準(zhǔn)備最終文檔、發(fā)行前的階段性測(cè)試以及最終版本。
圖 9
Each of the phases has the following steps:
每一階段均包含以下步驟：
Planning
計(jì)劃
Development of a comprehensive backlog list.
形成一個(gè)全面的待定項(xiàng)的目錄
Definition of the delivery date and functionality of one or more releases.
確定發(fā)行日期及一個(gè)或多個(gè)發(fā)行版本的功能
Selection of the release most appropriate for immediate development.
為后繼開發(fā)選擇一個(gè)最合適的版本。
Mapping of product packets (objects) for backlog items in the selected release.
在選定的版本中，為待定項(xiàng)和產(chǎn)品包(對(duì)象)間建立對(duì)應(yīng)關(guān)系。
Definition of project team(s) for the building of the new release.
為新版本的開發(fā)確定各項(xiàng)目小組。
Assessment of risk and appropriate risk controls.
進(jìn)行風(fēng)險(xiǎn)評(píng)估，并加以適當(dāng)?shù)娘L(fēng)險(xiǎn)控制。
Review and possible adjustment of backlog items and packets.
對(duì)待定項(xiàng)和程序包進(jìn)行總結(jié)及可能的調(diào)整。
Validation or reselection of development tools and infrastructure.
對(duì)開發(fā)工具和基礎(chǔ)架構(gòu)進(jìn)行確認(rèn)或重新選擇。
Estimation of release cost, including development, collateral material, marketing, training, and rollout.
預(yù)測(cè)發(fā)行成本，包括開發(fā)、相關(guān)材料、市場(chǎng)營(yíng)銷、培訓(xùn)和首次展示。
Verification of management approval and funding.
確認(rèn)經(jīng)理的認(rèn)可和資金保障。
Architecture/High Level Design
架構(gòu)/高層設(shè)計(jì)
Review assigned backlog items.
總結(jié)已指派的待定項(xiàng)。
Identify changes necessary to implement backlog items.
確定為實(shí)現(xiàn)待定項(xiàng)所必須的變化。
Perform domain analysis to the extent required to build, enhance, or update the domain models to reflect the new system context and requirements.
進(jìn)行域分析，直至新的系統(tǒng)環(huán)境和需求需要建立、增強(qiáng)和更新現(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
對(duì)開發(fā)和實(shí)現(xiàn)這些改變時(shí)所出現(xiàn)的各種問題和觀點(diǎn)進(jìn)行確認(rèn)。
Design review meeting, each team presenting approach and changes to implement each backlog item. Reassign changes as required.
組織總結(jié)會(huì)議，各項(xiàng)目小組闡明為實(shí)現(xiàn)各自的待定項(xiàng)所需的方法和變更。按需要重新分配變更。
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ā)工作的一個(gè)迭代循環(huán)。經(jīng)理判定時(shí)間、競(jìng)爭(zhēng)性、質(zhì)量或功能符合要求后，迭代過程結(jié)束并進(jìn)入結(jié)束階段。該方法也被稱為并發(fā)工程。開發(fā)包含以下宏觀過程：
Meeting with teams to review release plans.
與各項(xiàng)目小組開會(huì)討論總結(jié)計(jì)劃。
Distribution, review and adjustment of the standards with which the product will conform.
對(duì)產(chǎn)品所需遵從的標(biāo)準(zhǔn)進(jìn)行分發(fā)、總結(jié)和調(diào)整。
Iterative Sprints, until the product is deemed ready for distribution.
迭代沖刺，直至產(chǎn)品可被確認(rè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:
一個(gè)沖刺是一系列開發(fā)活動(dòng)的集合，這些開發(fā)活動(dòng)貫穿預(yù)定義階段，通常為一至四個(gè)星期。間歇期建立在產(chǎn)品復(fù)雜性、風(fēng)險(xiǎn)評(píng)估和預(yù)計(jì)的監(jiān)管程度上。沖刺的持續(xù)時(shí)間決定了沖刺的速度和強(qiáng)度。風(fēng)險(xiǎn)評(píng)估是持續(xù)進(jìn)行的，并應(yīng)加入適當(dāng)?shù)娘L(fēng)險(xiǎn)控制和響應(yīng)。每一沖刺由一個(gè)或多個(gè)項(xiàng)目小組組成來(lái)完成以下工作：
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ā)：對(duì)為實(shí)現(xiàn)待定項(xiàng)所需加入程序包中的變更進(jìn)行定義，打開程序包，進(jìn)行域分析，設(shè)計(jì)，開發(fā)，實(shí)現(xiàn)，測(cè)試，記錄變更。開發(fā)包含發(fā)現(xiàn)、創(chuàng)新和實(shí)現(xiàn)的微觀過程。
Wrap: Closing the packets, creating a executable version of changes and how they implement backlog requirements.
封裝：關(guān)閉程序包，為變更和這些待定需求如何實(shí)現(xiàn)創(chuàng)建一個(gè)可執(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é)： 所有的小組開會(huì)介紹各自的工作，總結(jié)進(jìn)度，提出并解決問題和困難，增加新的待定項(xiàng)。在會(huì)上總結(jié)風(fēng)險(xiǎn)，定義適當(dāng)?shù)娘L(fēng)險(xiǎn)應(yīng)對(duì)策略。
Adjust: Consolidating the information gathered from the review meeting into affected packets, including different look and feel and new properties.
調(diào)整：將從總結(jié)會(huì)議中獲得的信息合并到相關(guān)程序包中，包括不同的觀點(diǎn)、體驗(yàn)和新的特性。
Each Sprint is followed by a review, whose characteristics are :
每一次沖刺均伴隨一次總結(jié)，其特征是：
The whole team and product management are present and participate.
整個(gè)小組和產(chǎn)品經(jīng)理均到場(chǎng)參加。
The review can include customers, sales, marketing and others.
總結(jié)可包括用戶、經(jīng)銷商、市場(chǎ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àng)目小組的目標(biāo)和為實(shí)現(xiàn)待定項(xiàng)所需的變更。
The way backlog items are implemented by changes may be changed based on the review.
通過變更實(shí)現(xiàn)待定項(xiàng)的方法可在總結(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é)的一部分，新的待定項(xiàng)可被引入并分配給各項(xiàng)目小組，以改變可交付版本的內(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é)的時(shí)間由進(jìn)度和復(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é)束：當(dāng)經(jīng)理綜合時(shí)間、競(jìng)爭(zhēng)性、需求、費(fèi)用和質(zhì)量等諸多因素，感到已經(jīng)適于發(fā)布一個(gè)新的版本，他們宣布開發(fā)"結(jié)束"并進(jìn)入本階段。本階段準(zhǔn)備對(duì)已開發(fā)完成的產(chǎn)品進(jìn)行常規(guī)發(fā)布。結(jié)束階段的任務(wù)包括集成，系統(tǒng)測(cè)試，用戶文檔，培訓(xùn)材料和市場(chǎng)營(yíng)銷材料的準(zhǔ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.
當(dāng)處于陷入混亂（未知性和復(fù)雜性）的邊緣時(shí)，需要管理者進(jìn)行控制避免最終陷入混亂中。在使用面向?qū)ο蠹夹g(shù)來(lái)構(gòu)建實(shí)際的可發(fā)行軟件過程中，SCRUM方法包括了一般化和松散的控制。
Risk is the primary control. Risk assessment leads to changes in other controls and responses by the team.
風(fēng)險(xiǎn)是首要的控制因素，風(fēng)險(xiǎn)評(píng)估會(huì)改變對(duì)于其他內(nèi)容的因素，進(jìn)而帶來(lái)開發(fā)團(tuán)隊(duì)對(duì)于這些控制因素的改變的反應(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.
待定項(xiàng)：當(dāng)前版本的產(chǎn)品不能夠充分地實(shí)現(xiàn)的產(chǎn)品功能需求、錯(cuò)誤、缺陷、用戶需求的增強(qiáng)、競(jìng)爭(zhēng)性產(chǎn)品的功能、更優(yōu)越的具有競(jìng)爭(zhēng)性的功能以及技術(shù)升級(jí)都是待定項(xiàng)。
Release/Enhancement: backlog items that at a point in time represent a viable release based on the variables of requirements, time, quality, and competition.
版本/增強(qiáng)：在基于需求、時(shí)間、質(zhì)量和競(jìng)爭(zhēng)這些因素的基礎(chǔ)上，一個(gè)可行的新版本由在某個(gè)時(shí)點(diǎn)上的待定項(xiàng)決定。
Packets: Product components or objects that must be changed to implement a backlog item into a new release.
軟件包： 為實(shí)現(xiàn)待定項(xiàng)以形成新版本而必須加以修改的產(chǎn)品組件或?qū)ο蟆?nbsp;
Changes: Changes that must occur to a packet to implement a backlog item.
變更：軟件包必須改變從而實(shí)現(xiàn)待定項(xiàng)。
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)險(xiǎn)：必須不斷地對(duì)影響項(xiàng)目成功的風(fēng)險(xiǎn)因素進(jìn)行評(píng)估并且制定出對(duì)策。風(fēng)險(xiǎn)評(píng)估的結(jié)果影響了其他方面因素的控制。
Solutions: solutions to the problems and risks, often resulting in changes.
解決方案：解決困難和防范風(fēng)險(xiǎn)的解決方案通常會(huì)發(fā)生變化。
Issues: Overall project and project issues that are not defined in terms of packets, changes and problems.
結(jié)果：整個(gè)項(xiàng)目和項(xiàng)目結(jié)果并不是由軟件包、變化和問題來(lái)定義的。
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方法的不同階段中。管理者使用這些控制因素來(lái)管理預(yù)定的項(xiàng)目。開發(fā)團(tuán)隊(duì)使用這些控制因素來(lái)解決變化和問題。管理者和開發(fā)團(tuán)隊(duì)共同地管理結(jié)果、風(fēng)險(xiǎn)和解決方案。在每次沖刺總結(jié)會(huì)上這些控制因素都被提出來(lái)討論、修改并進(jìn)行協(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)容取決于包括時(shí)間、競(jìng)爭(zhēng)、費(fèi)用和功能等在內(nèi)的環(huán)境因素?？山桓懂a(chǎn)品的決定因素包括了市場(chǎng)能力、客戶關(guān)系和開發(fā)人員的技術(shù)水平。環(huán)境的變動(dòng)促使軟件項(xiàng)目在開發(fā)過程中對(duì)于可交付內(nèi)容不斷地作出調(diào)整?？山桓懂a(chǎn)品可能取決于軟件項(xiàng)目過程中的任何階段。
--------------------------------------------------------------------------------
Project Team
項(xiàng)目小組
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ā)過程中，項(xiàng)目小組不僅僅包括全職開發(fā)人員，也包括了新版本會(huì)影響到的外部人員，比如市場(chǎng)營(yíng)銷人員和顧客。在傳統(tǒng)的版本開發(fā)過程中，后者是被排除在開發(fā)小組之外的，以避免開發(fā)過程過于復(fù)雜并且避免導(dǎo)致對(duì)開發(fā)工作產(chǎn)生不必要的干擾。然而，SCRUM方法歡迎并且階段性地利用了他們有限制的參與，認(rèn)為這樣將更加能夠促使新版本合適、有用并且受到市場(chǎng)歡迎。
The following teams are formed for each new release:
每個(gè)新版本的開發(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ā)布時(shí)間，然后管理項(xiàng)目開發(fā)進(jìn)度的變化以及各種因素的變化。管理者需要管理待定項(xiàng)、風(fēng)險(xiǎn)和版本內(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ì)量控制人員。每個(gè)開發(fā)小組規(guī)模在3到6個(gè)人之間，并且都有特定的任務(wù)。每個(gè)小組被指派去完成一組軟件包（或者對(duì)象），每個(gè)軟件包包含了與該包相關(guān)的待定項(xiàng)。為了實(shí)現(xiàn)軟件包中待定項(xiàng)，開發(fā)小組定義需要做出的改變，并且解決由這些改變而帶來(lái)的問題。小組可以按照功能進(jìn)行劃分（分配實(shí)現(xiàn)特定產(chǎn)品功能組合的軟件包），也可以按照系統(tǒng)來(lái)劃分（分配系統(tǒng)中唯一的一個(gè)層次）。每個(gè)小組的成員是根據(jù)他們對(duì)所指定的軟件包應(yīng)具有的專業(yè)知識(shí)和技能來(lái)選擇的，或者根據(jù)專家意見來(lái)選擇。
--------------------------------------------------------------------------------
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方法是橄欖球比賽的一個(gè)隱喻。 橄欖球是由英式足球在劇烈的比賽壓力下發(fā)展而來(lái)的：
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)了一種新的運(yùn)動(dòng)，并且該項(xiàng)運(yùn)動(dòng)的游戲規(guī)則于1839年被確認(rèn)。一次在為有256年歷史的東沃里克郡學(xué)院踢足球的比賽期間，威廉·韋布·埃利斯（William Webb Ellis）發(fā)現(xiàn)比賽就要結(jié)束而他的球隊(duì)還是落后，情急之下，他一把抓起足球，帶著跑，以此來(lái)挑戰(zhàn)比賽規(guī)則。
SCRUM projects have the following characteristics :
SCRUM 項(xiàng)目具備下面的特性：
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.
靈活的進(jìn)度安排―― 版本交付可能早于也可能遲于最初計(jì)劃時(shí)間。
Small teams - each team has no more than 6 members. There may be multiple teams within a project.
小的隊(duì)伍――每個(gè)小組不超過6個(gè)成員，一個(gè)項(xiàng)目可能包括了多個(gè)小組。
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)險(xiǎn)度的改變，小組的進(jìn)度經(jīng)常要進(jìn)行總結(jié)（通常為1到4個(gè)星期為一個(gè)周期）。為每次總結(jié)每個(gè)小組都必須精心準(zhǔn)備有一定功能的可執(zhí)行代碼。
Collaboration - intra and inter-collaboration is expected during the project.
協(xié)作：―― 在項(xiàng)目的整個(gè)過程中需要內(nèi)部的和相互的協(xié)作。
Object Oriented - each team will address a set of related objects, with clear interfaces and behavior.
面向?qū)ο螅總€(gè)小組開發(fā)一系列相關(guān)的具有確定接口和行為的對(duì)象。
The SCRUM methodology shares many characteristics with the sport of Rugby :
SCRUM方法具有與橄欖球運(yùn)動(dòng)相似的許多特征：
The context is set by playing field (environment) and rugby rules (controls).
由比賽場(chǎng)地（環(huán)境）和橄欖球規(guī)則（控制）來(lái)決定前后關(guān)系。
The primary cycle is moving the ball forward.
主要的循環(huán)周期是把球向前送。
Rugby evolved from breaking soccer rules - adapting to the environment.
橄欖球來(lái)源于打破足球規(guī)則――為了適應(yīng)環(huán)境
The game does not end until environment dictates (business need, competition, functionality, timetable).
除非環(huán)境要求否則比賽不會(huì)結(jié)束（商業(yè)需求、競(jìng)爭(zhēng)、功能、時(shí)間表）
--------------------------------------------------------------------------------
Advantages
優(yōu)勢(shì)
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ā)方法只是為了彌補(bǔ)在增強(qiáng)周期開始的時(shí)候由于外部的和開發(fā)環(huán)境的不確定造成的影響。一些新的途徑諸如Boehm螺旋方法以及它的變體，其在項(xiàng)目啟動(dòng)后響應(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è)計(jì)自始至終具有很強(qiáng)的適應(yīng)性。它提供了規(guī)劃產(chǎn)品版本從而在項(xiàng)目過程中進(jìn)行變化因素管理的控制機(jī)制。這使得開發(fā)機(jī)構(gòu)可以及時(shí)地在任意點(diǎn)上修改項(xiàng)目和發(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ā)過過程中隨著知識(shí)的增長(zhǎng)和環(huán)境的變化，能夠在整個(gè)項(xiàng)目過程中自由地設(shè)計(jì)最有創(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ā)過程的默認(rèn)知識(shí)。為所有參與者提供了一個(gè)優(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ǔ)。對(duì)象，或者說(shuō)產(chǎn)品特征，提供了一個(gè)離散的可管理的環(huán)境。面向過程的代碼所具有的包含諸多相互交織的接口的特點(diǎn)對(duì)于SCRUM技術(shù)是不合適的。然而對(duì)于有著清晰接口和明顯的數(shù)據(jù)導(dǎo)向的面向過程的系統(tǒng)SCRUM技術(shù)還是可以考慮的。
--------------------------------------------------------------------------------
Estimating
評(píng)估
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項(xiàng)目可以用標(biāo)準(zhǔn)的點(diǎn)估計(jì)函數(shù)。但是，明智的做法是以現(xiàn)有度量的兩倍作為生產(chǎn)力的估計(jì)。而且這個(gè)估計(jì)只是用于項(xiàng)目啟動(dòng)之用，因?yàn)檎麄€(gè)過程的時(shí)間安排和花費(fèi)是由諸多的環(huán)境因素動(dòng)態(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項(xiàng)目同時(shí)具有速度和加速度。就發(fā)布的功能或者待定項(xiàng)而言：
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
當(dāng)基本功能加入到對(duì)象中時(shí)，加速度增加了
acceleration decreases and velocity remains sustainably high
加速度降低，速度保持足夠高
Further development in metrics for empirical processes is required.
對(duì)基于經(jīng)驗(yàn)的過程的度量的有待做進(jìn)一步地研究。
--------------------------------------------------------------------------------
Appendix 1
附錄 1
System Development Methodologies : Defined or Empirical
系統(tǒng)開發(fā)方法：規(guī)定和經(jīng)驗(yàn)
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ā)是在計(jì)算機(jī)上通過邏輯和數(shù)據(jù)來(lái)創(chuàng)建邏輯結(jié)構(gòu)的行為。這個(gè)邏輯結(jié)構(gòu)包括輸入、過程和輸出，可分為宏觀的(整個(gè)結(jié)構(gòu)）和微觀的（整個(gè)結(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)的過程中會(huì)創(chuàng)建許多的人工附屬物，可以用來(lái)幫助思考，檢驗(yàn)完整性，創(chuàng)建審計(jì)紀(jì)錄。它們包括在創(chuàng)建整個(gè)系統(tǒng)前創(chuàng)建的文檔、模型、程序、測(cè)試用例以及其他發(fā)布文檔。可能的話，用元模型來(lái)定義模型的語(yǔ)義內(nèi)容。符號(hào)描述用以構(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è)框架，描述了定義、構(gòu)建和實(shí)現(xiàn)系統(tǒng)的相關(guān)活動(dòng)。因?yàn)榉椒ㄊ菢?gòu)建系統(tǒng)（過程）的一個(gè)邏輯過程，所以它也被稱作元過程（為過程建模的過程）
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í)行工作的整個(gè)流程和時(shí)序框架。微觀成份則包括一般設(shè)計(jì)規(guī)則、翻閱模式和規(guī)則。其中一般設(shè)計(jì)規(guī)則描述在設(shè)計(jì)上所要達(dá)到或者避免的特性，或者描述在構(gòu)建系統(tǒng)時(shí)要采取的一般方法。模式是可以用于一類開發(fā)活動(dòng)的解決方案；用于解決在某一方法的某一活動(dòng)實(shí)行過程中出現(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).
當(dāng)把工業(yè)過程控制中的概念引入到系統(tǒng)開發(fā)的領(lǐng)域時(shí)，方法可以歸為理論的(完全定義的）或者經(jīng)驗(yàn)的（黑箱）。
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ā)的方法進(jìn)行分類是關(guān)鍵的。用于構(gòu)建某一類特殊的系統(tǒng)的方法的合適的結(jié)構(gòu)取決于這個(gè)方法是經(jīng)驗(yàn)的還是理論的。
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ì)和能量守恒以及基本法則來(lái)決定模型。如果哪個(gè)系統(tǒng)開發(fā)方法要被歸為理論的，它必須滿足這個(gè)定義。
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)驗(yàn)過程的模型是通過將觀察到的輸入輸出進(jìn)行分類，將限制其在一定范圍內(nèi)發(fā)生的控制進(jìn)行定義得到的。經(jīng)驗(yàn)過程模型只考慮嚴(yán)格按照實(shí)驗(yàn)數(shù)據(jù)進(jìn)行建模，并不考慮任何與系統(tǒng)的基本特性相關(guān)的法則。有關(guān)過程的先驗(yàn)知識(shí)是不必要的(盡管會(huì)有幫助），系統(tǒng)被完全當(dāng)作一個(gè)黑箱來(lái)看待。
Upon inspection, we assert that the systems development process is empirical:
通過以上分析，我們斷言系統(tǒng)開發(fā)過程是經(jīng)驗(yàn)的：
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é)家同意這樣的觀點(diǎn)：“......不要奢望一個(gè)方法告訴你要做的一切。寫軟件是一個(gè)創(chuàng)新的過程，就象是繪畫、寫作或者建筑......(一個(gè)方法）提供了一個(gè)告訴你如何去做的框架，并且識(shí)別需要?jiǎng)?chuàng)新的地方。但是創(chuàng)新必須由你來(lái)完成。”
Categorizing the systems development methods as empirical is critical to the effective management of the systems development process.
將系統(tǒng)開發(fā)過程劃歸為經(jīng)驗(yàn)的對(duì)于對(duì)系統(tǒng)開發(fā)過程進(jìn)行有效的管理是關(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)驗(yàn)的，那么就需要度量和控制。因?yàn)榉椒ǖ膬?nèi)部工作方式的定義太寬松以至于不可能進(jìn)行提前操作。
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.
在以前，方法被當(dāng)作是基于理論的而提出和應(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ā)的許多問題。當(dāng)一個(gè)黑箱過程被當(dāng)作一個(gè)完整定義的過程時(shí)，不可預(yù)料的結(jié)果出現(xiàn)了。而且，用于度量和響應(yīng)這意外的控制機(jī)制并沒有被使用。
--------------------------------------------------------------------------------
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.
|
