---軟件工程系列文章之三
By Russ Finney
（來自軟件工程論壇 seforum.yeah.net）
(翻譯yanrj )
What makes a winning techical project team? A quick look at
some of the factors which seem to be consistently present on
winning project teams is appropriate. The degree of
attention paid to each can have a distinct impact on the
success of the project as well as elevating the confidence
of the business client.
是什麼造就了一個成功的專業項目團隊？瀏覽一下成功的項目團隊所固有的特點是
很好的。對每個因素的重視程度對於項目的成功和評價業務客戶的信任度將有很大的
影響。
System Building Competence
系統建造能力
This is absolutely critical. The ability to succeed is
established within the minds of the clients as well as the
project team members in the early stages of the effort. An
essential component of this perception is both the
management ability, the technical skills, and the sense of
direction possessed by the project leadership. Both the
business clients and the team can detect fairly quickly if
the project leaders have "what it takes" to take them to a
final product. Without question this feeling has a
tremendous impact on morale.
這是絕對關鍵的。成功的能力是在努力的早期階段在客戶的思想和項目團隊成員中
建立起來的。這個觀點的本質在於管理能力和專業技術和由項目主管擁有的方向感
上。業務客戶和團隊能夠快速清楚的察覺項目主管是否有帶領他們向最終目標前進的
思想。毫無疑問這個感覺對士氣是至關重要的。
Humphrey Watts in his book Managing the Software Process,
describes a model for measuring the maturity of a software
development organization. These ideas were further refined
by the Software Engineering Institute (SEI) at Carnegie
Mellon University. A brief summary of the maturity levels of
the model (in terminology which will relate to some of the
central themes of this white paper) are presented below:
Humphrey Watts在他的書《管理軟件過程》中描述了一個衡量軟件開發組織成熟
度的模型。這些觀點由Carnegie Mellon大學的軟件工程組織作了進一步精煉。有關
模型（有些術語與本文的一些要點有關）成熟層的簡短概括如下：
Initial Level
初始層
A team or organization at this level tends to take a
chaotic, ad-hoc, "invent as we go" approach toward every new
systems building effort.
處於這層的團隊和組織試圖以一種混亂的，特別的，"如我們所想的"方法對待每一
個新的系統建造工程。
Repeatable Level
可重複層
A team or organization at this level uses planning
techniques, gathers requirements in a systematic fashion,
utilizes software quality assurance techniques, and follows
a patterned approach on each subsequent effort.
處於這層的團隊和組織通常使用編制計劃技術，收集體系模式的需求，使用軟件質
量保證技術，並在後來的開發中使用模式化的方法。
Defined Level
被定義層
A team or organization at this level follows defined
methodological steps, uses process improvement techniques to
enhance the methodological approach, conducts regular
training programs, views the entire systems development
process from an integration perspective, and utilizes more
disciplined information engineering and structured
development techniques.
處於這層的團隊和組織使用定義好的方法步驟，使用改進過程的技術來提高方法，
管理有序的練習程序，從綜合的觀點看待整個系統開發過程，使用更加嚴格的信息工
程和結構化開發技術。
Managed Level
被管理層
A team or organization at this level actually captures and
utilizes software development metrics for future estimation
and process analysis purposes. In addition, some of concepts
of Total Quality Management (TQM) are employed to reinforce
the effectiveness of the entire development process.
處於這層的團隊和組織通常爲將來的評估和過程分析捕獲並使用軟件開發度量。另
外，整體質量管理的一些概念也被使用來增加整個開發過程的效力。
Optimized Level
優化層
A team or organization at this level utilizes continuous
organizational change management techniques to optimize its
own operations (as well as the company's), emphasizes defect
prevention rather than defect detection, and constantly
seeks technological innovation opportunities.
處於這層的團隊和組織使用持續的有組織的變化管理技術來優化他們的操作，強調
避免錯誤而不是發現錯誤，並經常尋求技術革新的機會。
Project Team Experience
項目團隊的經驗
Even within organizations with high success rates, one
factor which never changes on each new effort is the amount
of experience possessed by the chosen project team members.
Will the project team include a business expert? If not,
will the assigned members be able to effectively comprehend
and discuss the business requirements and issues in the
client terminology? Having someone on the team (even if only
in the initial phases) who understands the business is a
great confidence builder! It allows the analysts and
designers to ask the dumb or simplistic questions to someone
other than the client. This actually makes more effective
use of everyone's time and it adds an subsequent level of
security. In addition, it puts someone in the position of
making sure that "creative thinking" stays within reasonable
boundaries.
即使是擁有高成功率的組織中，每個新努力中從不改變的因素是被選擇的團隊成員
擁有的經歷的程度。項目團隊應該包括一個業務專家？如果不是，指定的成員能夠有
效的理解和討論業務需求和客戶術語中的組織？在團隊裏有沒有理解這項業務的人士
個很自信的開發者？允許分析員和設計員向任何人詢問簡單的問題，而不是向客戶。
這能充分利用每個人的時間，並增加後期工作的安全性。另外，它是每個人在合理的
範圍裏進行創造性的思想。
What about technical expertise? Is the project entering
uncharted waters without a guide? Having someone on the team
who is familiar with the specialized knowledge surrounding a
selected technological environment provides the same
confidence creating benefits as those listed above. A
technical expert can assist others, make suggestions,
develop standards, and prevent time consuming mistakes. In
addition, he or she can provide leadership by example. By
spearheading the work and creating examples for others, a
technical expert can transfer knowledge and experience in a
timely and effective manner. The prevents the "invent as we
go" situation teams often find themselves in when embarking
on a new technology.
專門的技術怎樣？是不是項目進入了沒有嚮導的水域？有沒有團隊中的成員熟悉指
定技術領域的特定知識提供上面提到的同樣的信心？一個技術專家能夠幫助別人，做
出建議，開發標準，阻止耗時的錯誤。另外，她或他能通過例子提供領導能力。通過
傳播工作併爲他人創造例子，一個技術專家能夠以及時有效的方式傳播知識和經驗。
這能阻止當一個團隊在着手於一項新技術時通常發現他們處於按自己所想進行的處
境。
Project Control and Coordination
項目的控制和合作
Large, complex undertakings which require the participation
of many people throughout the development process, demand
both high-level and detailed guidelines to assist in the
channeling of the individual results into an integrated
final product. As each person focuses on his or her's part
of the system, a clearly defined set of standards and
specifications must exist insure that the final result will
"mesh" with the results being produced by others. In many
ways, a systems building project can be thought of a series
of specifications, each level spiraling from broad
requirements into highly detailed procedural instructions.
The collection of these efforts into a unified whole
presents the ultimate challenge for the group. What are some
of the ways to successfully make this happen?
大型的複雜的事業需要在開發過程中很多人的參與，需要高水平詳細的設計細節來
輔助獨立的成果融入最後完整的產品中。當每個人專心與它所負責的系統的一部分
時，一個清楚的已經定義標準和規範的集合必須存在以保證最後的結果能夠和其他人
的結果相吻合。在很多方式下，系統的建造項目可以看成是一系列規範，每層從廣泛
的需求螺旋發展成爲高度詳細的過程指令。這些努力的集合就構成了一個整體，給整
個團體展現最後的挑戰。那些方法能使這件事情成功的發生？
Ultimately, three major factors contribute to the level of
success that systems building team will enjoy at each of the
required integration points. One of these factors is the
creation of "consistency" standards. During each phase,
guidelines should be developed for both the content as well
as the format of the final work products. A second important
factor is cross-team communication. Common requirements,
similar issues, shared data, and reusable functionality all
should be openly discussed and coordinated. Sub-teams should
participate in the development of overall high level shared
goals and objectives which encourage cross-team interaction
and decision making. A third factor is the insistence on the
part of the top team leadership that individual and sub-team
successes be innertwined. Consistent deliverable, quality
assurance, methodological, and review standards must apply
to all team members equally.
最後，三個關鍵的因素將對系統建造團隊將會享受每個需求的綜合點成功級別起作
用。這些因素之一是一致性標準的建立。在每個階段，詳細的細節必須爲內容和最後
的運行產品的形式所制定。第二個重要的因素是跨團隊的交流。通常的需求，相似的
組織，共享的數據和可複用的功能都應該被公開的討論和協作。子團隊應該參加整個
高層的開發，共享鼓舞跨團隊交互作用和決策制定的目標。第三個是代表高層領導的
堅持性，個人和子團隊的成功相交互。交付的一致性，質量的保證，方法和複審標準
必須對團隊的所有成員一視同仁。
Team Goals and Individual Objectives
團隊目標和個人目標
A project team seems to develop a unique "personality" over
time. It becomes a reflection of everyone involved,
radiating confidence and certainty if spirits are high,
seething with doubts and confusion when direction is
lacking. How can project dynamics be so different from one
team to the next? Leadership certainly plays a vital role,
but individual team member attitudes make the difference.
一個項目團隊看起來時在開發一個獨一無二的個性軟件。成爲每個參與者的反映，
如果士氣高的話則充滿自信和確定性，當缺乏方向時則由於疑慮和混亂而沸騰。怎樣
才能使項目因團隊的不同而不同？領導能力當然起了一個很關鍵的作用，但團隊成員
的態度也會造成不同影響。
Two fundamental questions illuminate the spirit of the group
effort. First, is everyone on the team driving toward a well
defined and articulative objective? Second, whose objective
is it? An amazing thing can happen on development projects;
everyone is busily working away on whatever it is that they
individually perceive as his or her's most important tasks.
Hopefully, each person's work will mesh with the rest of the
group's results. This will probably happen if everyone
clearly and precisely understands the ultimate phase
objectives. But what if they don't?
兩個基本的問題說明了組織努力的精神。首先，是不是團隊的每個人都朝着已經制
定的清楚的目標前進？第二，這是誰的目標？在開發項目中可能發生這樣令人驚訝的
事情，每個人都忙於她或他認爲最重要的任務。希望是每個人的工作都能與其他人的
工作相吻合。如果每個人都很清楚並精確的指導最終的目標則可能，但如果不是呢？
This is where human nature begins to step in and things can
begin to get interesting. If the attitudes of the team
members tend to be goal driven (which is good) but the team
leadership is fuzzy about what the objectives really are
(which is bad), individual and sometimes scattered goals
begin to pop up. Unique and potentially conflicting agendas
take shape. Before you know it everyone is busily working
away and the atmosphere appears to be productive. But an
time of reconciliation lies ahead. At some point the
individual results must be combined, and depending on the
fit, the attitude of the team will ultimately be affected.
The group's mission or purpose at this point becomes very
real, because it is at this moment that the team realizes
that there may not have really been a common direction in
the first place, and that fact is painfully obvious.
當人類開始涉足的地方並且能過的興趣。如果團隊成員是目標驅動，而領導者對最
終的目標而疑惑，獨立的或分散的目標突然出現。獨自的潛在的議程出現。在你知道
之前每個人都忙於工作，而且是生產性的氣氛。但要調和的時間擺在前面。在某個點
上獨立的結果必須合併，以來與合適性，團隊的態度最終會被影響。這時組織的任務
或目的變得很真實，因爲這時團隊才意識到在開始時就沒有統一的方向，事實顯然是
很痛苦的。
Why even take this risk? Insuring that goals and objectives
are clearly spelled out, and the activities and tasks which
will be followed to ultimately reach them are uniformly
understood, will only give the team a shared sense of
purpose. Everyone needs to have a stake in, and a share of,
the responsibility for the outcome of each phase. Doing this
can have an incredible impact on people's attitudes. Clearly
comprehending the relevance of the work and how it will
contribute to the final product, is a powerful motivator for
creating an air of cooperation and open channels of
communication between team members. Individual goals can be
visualized as a part of the larger team objectives. The goal
driven attitude of the team will truly be reflected in the
quality of the results.
爲什麼冒這個險？確保目標很清楚的確定，他們所從事的任務和活動被一律的理
解，將會給整個團隊一種目的共享的感覺。每個人都需要由對每個階段成果的責任
感，共享感。這樣做肯定會影響每個人的態度。清楚的理解工作的關鍵和怎樣影響最
終產品，是產生合作環境及創造成員界交流通道的強有力的因素。獨立的目標可以被
想象成爲大型團隊目標的一部分。團隊的目標去動態都會在產品的質量中有所反映。
Systems Building Vision
系統建造的藍圖
A "vision" doesn't do anyone any good if it is only in one
person's head. Only when it has been absorbed and adopted by
the team does its usefulness begin to emerge. A business or
system "visionary" plays an important yet sometimes
unenviable role in making this happen. His or her
willingness to share insight and understanding of a
situation, and the necessary steps he or she envisions to
arrive at a desired outcome, tend to be dependant on two
factors: the level of confidence he or she has in the ideas,
and his or her tolerance for scrutiny and criticism.
Regardless of these personal risks, a professional system
builder must strive to be a system "visionary". With each
passing phase of the project, he or she must constantly
develop and communicate his or her vision of both the system
functionality and the project approach.
如果藍圖只存在於一個人的腦中則不會給任何人帶來好處。只有被團隊吸取和採納
才能使它的作用發揮出來。一個業務或系統的“藍圖”作用重要但有時仍不能實現。
她或他的希望是共享對情況的理解和見識，並採取了步驟以達到理想的結果，依賴於
兩個因素：她或他的自信程度，忍耐審查和批評的能力。不管這些個人的冒險，一個
專業的系統建造者必須爲成爲一個系統設計者而奮鬥。隨着每個階段的完成，她或他
必須持續開發和交流她或他對系統功能和項目方法的構想。
Putting forward this vision assists in accomplishing two
important results. First, it creates a baseline foundation
for continuing discussion. In many cases, the original
system/approach vision may not survive for long as better
ideas are presented and improvement discussions occur.
Second, the vision promotes constructive, critical thinking.
提出構想能有處於實現兩個重要的結果。首先，它創造了繼續討論的基礎。在很多
情況下，最初的系統/方法構想不能比好的思想提出和改進的討論維持的時間長。第
二，構想提供建設性的嚴格的思考。
People tend to provide more input in a "review and improve"
mode rather than a "create from scratch" mode. The
presentation of a baseline vision stimulates this process.
In addition, if the "visionary" can relinquish ownership of
the original idea, and subsequently encourage it to become
the property of the group, the effectiveness of the process
can be even more enhanced. The system builder serves to
plant the "starting point" ideas, and the team members and
business clients assist with, and take responsibility for,
the ultimate direction and composition of the shared vision.
人們更傾向於提供更多的輸入給“複審和提高”而不是“從零開始”的模式。最初
的構想的提出促進這個過程。另外，如果“構想”能夠放棄最初的思想的所有權，而
成爲組織的財產，這個過程的效果將會更加提高。系統建造者負責產生開始點的思
想，團隊成員和業務客戶輔助並負責共享的構想的方向和合成。
Project Team Confidence
項目團隊信心
Another important team attitude is confidence. The
development of a complex system presents tremendous
challenges to a project team. Sometimes it can even feel
like an act of faith. An enormous amount of detail is
collected, analyzed, organized, and assimilated into a
functional "whole". On very large efforts, only a few key
individuals may possess the total "big picture", and this
may be at varying levels of completeness. This ambiguity can
from time to time test the confidence of the project team
members. Given these uncertainties, how does a team feel
assured and confident of success throughout the process, and
have this reflected in the individual team member attitudes?
另一個重要的團隊是信心。開發複雜的系統將會給團隊帶來很多挑戰。有時感覺是
一種信仰的活動。大量的細節被收集、分析、組織並吸取爲整體的功能。在非常大的
付出中，僅有一些關鍵個人支配整個“圖紙”，並隨完成的不同層次不同。這種不確
定性時不時的檢驗團隊成員的信心。給出這些不確定的事情，一個團隊怎樣才能在通
向成功的過程中感到有保證和信心，並反映到團隊個人的態度呢？
Clearly, the realization on the part of the team, that a
system design is formed as a gradually evolving solution,
from a process which tends to be iterative in nature, helps
everyone to be patient with the slowly disappearing level of
ambiguity. The more team members who participate on the
project who have been through the complete system building
life cycle, the more likely the overall team awareness will
be that everything will come together at each major
milestone. This is an important confidence builder for the
less experienced members of the team. The higher the level
of confidence possessed by the team, the more secure the
business clients feel, and the more likely the team will
actually "see" themselves succeeding, even in the face of
the unknown.
很明顯，在團隊方面的實現，系統的設計在逐漸演化的過程中形成，從本質上交互
的過程，幫助每個人在不確定性逐漸消除的過程中保持忍耐。參加項目並經歷整個系
統建造生命週期的成員越多，整個團隊意識在每個主要里程碑所有事都具備的可能性
就越大。這對於一個缺乏經驗的團隊成員是一個重要的信心締造者。團隊擁有的信心
水平越高，，業務客戶的安全感越大，團隊就更加可能看到他們的勝利，即使是面對
未知的事情。
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/jiangtao/archive/2001/02/02/1809.aspx