亚洲一区二区三区在线看,91精品国产综合久久香蕉的特点,精品久久久久久久久久久

成功的项目团队Winning Project Teams (�?

Thu, 12 Apr 2007 08:17:00 GMT

By Russ Finney

�Q�来自��Y件工�E�论�?seforum.yeah.net�Q?br> (��译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.

是什么造就了一个成功的专业��目团队�Q�浏览一下成功的��目团队所固有的特�Ҏ��
很好的。对每个因素的重视程度对于项目的成功和评价业务客��L��信�Q度将有很大的
影响�?br>
System Building Competence
�pȝ��建造能�?br>
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.

�q�是�l�对关键的。成功的能力是在努力的早期阶�D�在客户的思想和项目团队成员中
建立��h��的。这个观点的本质在于��理能力和专业技术和由项目主��拥有的方向�?br>上。业务客户和团队能够快速清楚的察觉��目�ȝ��是否有带领他们向最�l�目标前�q�的
思想。毫无疑问这个感觉对士气是至关重要的�?br>
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在他的书《管理��Y件过�E�》中描述了一个衡量��Y件开发组�l�成�?br>度的模型。这些观点由Carnegie Mellon大学的��Y件工�E�组�l�作了进一步精点{��有�?br>模型�Q�有些术语与本文的一些要�Ҏ��养I��成熟层的��短概括如下：

Initial Level
   初始�?br>
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.
   处于�q�层的团队和�l�织试图以一�U��؜��q��Q�特别的�Q?如我们所想的"�Ҏ��对待每一
个新的系�l�徏造工�E��?br>
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.
   处于�q�层的团队和�l�织通常使用�~�制计划技术，攉��体系模式的需求，使用软�g�?br>量保证技术，�q�在后来的开发中使用模式化的�Ҏ��?br>
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.
   处于�q�层的团队和�l�织使用定义好的�Ҏ��步骤�Q��用改�q�过�E�的技术来提高�Ҏ��Q?br>��理有序的练习程序，从综合的观点看待整个�pȝ��开发过�E�，使用更加严格的信息工
�E�和�l�构化开发技术�?br>
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.
   处于�q�层的团队和�l�织通常为将来的评估和过�E�分析捕获�ƈ使用软�g开发度量。另
外，整体质量��理的一些概念也被��用来增加整个开发过�E�的效力�?br>
Optimized Level
   优化�?br>
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.
   处于�q�层的团队和�l�织使用持箋的有�l�织的变化管理技术来优化他们的操作，��
避免错误而不是发现错误，�q�经常寻求技术革新的��Z��?br>
Project Team Experience
   ��目团队的经�?br>
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.

即��是拥有高成功率的�l�织中，每个新努力中从不改变的因素是被选择的团队成�?br>拥有的经历的�E�度。项目团队应该包括一个业务专�Ӟ��如果不是�Q�指定的成员能够�?br>效的理解和讨��Z��务需求和客户术语中的�l�织�Q�在团队里有没有理解�q�项业务的�h�?br>个很自信的开发者？允许分析员和设计员向��M��问简单的问题�Q�而不是向客户�?br>�q�能充分利用每个人的旉��Q��ƈ增加后期工作的安全性。另外，它是每个人在合理�?br>范围里进行创造性的思想�?br>
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.

专门的技术怎样�Q�是不是��目�q�入了没有向导的水域�Q�有没有团队中的成员熟悉�?br>定技术领域的特定知识提供上面提到的同��L��信心�Q�一个技术专家能够帮助别人，�?br>出徏议，开发标准，��L��耗时的错误。另外，�Ҏ��他能通过例子提供领导能力。通过
传播工作�q��ؓ他�h创造例子，一个技术专家能够以及时有效的方式传播知识和�l�验�?br>�q�能��L��当一个团队在着手于一��Ҏ��技术时通常发现他们处于按自己所惌��行的�?br>境�?/p>

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?

大型的复杂的事业需要在开发过�E�中很多人的参与�Q�需要高水��^详细的设计细节来
辅助独立的成果融入最后完整的产品中。当每个��Z��心与它所负责的系�l�的一部分
�Ӟ��一个清楚的已经定义标准和规范的集合必须存在以保证最后的�l�果能够和其他�h
的结果相��d��。在很多方式下，�pȝ��的徏造项目可以看成是一�p�d��规范�Q�每层从�q�泛
的需求螺旋发展成为高度详�l�的�q�程指��o。这些努力的集合��构成了一个整体，�l�整
个团体展现最后的挑战。那些方法能使这件事情成功的发生�Q?br>
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.

最后，三个关键的因素将对系�l�徏造团队将会��n受每个需求的�l�合�Ҏ��功��别�v�?br>用。这些因素之一是一致性标准的建立。在每个阶段�Q�详�l�的�l�节必须为内容和最�?br>的运行��品的形式所制定。第二个重要的因素是跨团队的交流。通常的需求，�怼��?br>�l�织�Q�共享的数据和可复用的功能都应该被公开的讨论和协作。子团队应该参加整个
高层的开发，�׃�n鼓舞跨团队交互作用和决策制定的目标。第三个是代表高层领导的
坚持性，个�h和子团队的成功相交互。交付的一致性，质量的保证，�Ҏ��和复审标�?br>必须对团队的所有成员一视同仁�?br>
Team Goals and Individual Objectives
团队目标和个人目�?br>
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.

一个项目团队看��h��时在开发一个独一无二的个性��Y件。成为每个参与者的反映�Q?br>如果士气高的话则充满自信和确定性，当缺乏方向时则由于疑虑和混�ؕ而沸腾。怎样
才能佉K��目因团队的不同而不同？领导能力当然起了一个很关键的作用，但团队成�?br>的态度也会造成不同影响�?br>
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?

两个基本的问题说明了�l�织努力的精��。首先，是不是团队的每个人都朝着已经�?br>定的清楚的目标前�q�？�W�二�Q�这是谁的目标？在开发项目中可能发生�q�样令�h惊讶�?br>事情�Q�每个�h都忙于她或他认�ؓ最重要的�Q务。希望是每个人的工作都能与其他�h�?br>工作相吻合。如果每个�h都很清楚�q�精��的指导最�l�的目标则可能，但如果不是呢�Q?br>
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.

当�h�c�d��始涉��的地方�q�且能过的兴��。如果团队成员是目标驱动�Q�而领��D��对最
�l�的目标而疑惑，独立的或分散的目标突然出现。独自的潜在的议�E�出现。在你知�?br>之前每个人都忙于工作�Q�而且是生产性的气氛。但要调和的旉��摆在前面。在某个�?br>上独立的�l�果必须合�ƈ�Q�以来与合适性，团队的态度最�l�会被媄响。这时组�l�的��d��
或目的变得很真实�Q�因��时团队才意识到在开始时��没有统一的方向，事实昄��?br>很痛苦的�?br>
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.

��Z��么冒�q�个险？��保目标很清楚的��定�Q�他们所从事的�Q务和�z�d��被一律的�?br>解，��会�l�整个团队一�U�目的共享的感觉。每个�h都需要由�Ҏ��个阶�D�|��果的责�Q
感，�׃�n感。这样做肯定会媄响每个�h的态度。清楚的理解工作的关键和怎样影响最
�l��品，是��生合作环境及创造成员界交流通道的强有力的因素。独立的目标可以�?br>惌��成�ؓ大型团队目标的一部分。团队的目标��d��态都会在产品的质量中有所反映�?br>
Systems Building Vision
�pȝ��建造的蓝图

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.

如果蓝图只存在于一个�h的脑中则不会�l��Q何�h带来好处。只有被团队吸取和采�U?br>才能使它的作用发挥出来。一个业务或�pȝ��?#8220;蓝图”作用重要但有时仍不能实现�?br>�Ҏ��他的希望是共享对情况的理解和见识�Q��ƈ采取了步骤以辑ֈ�理想的结果，依赖�?br>两个因素�Q�她或他的自信程度，忍耐审查和批评的能力。不��这些个人的冒险�Q�一�?br>专业的系�l�徏造者必��Mؓ成�ؓ一个系�l�设计者而奋斗。随着每个阶段的完成，�Ҏ��?br>必须持箋开发和交流�Ҏ��他对�pȝ��功能和项目方法的构想�?br>
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.

提出构想能有处于实现两个重要的结果。首先，它创造了�l�箋讨论的基��。在很多
情况下，最初的�pȝ��/�Ҏ��构想不能比好的思想提出和改�q�的讨论�l�持的时间长。第
二，构想提供��性的严格的思考�?/p>

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.

��Z��更們֐�于提供更多的输入�l?#8220;复审和提�?#8221;而不�?#8220;从零开�?#8221;的模式。最�?br>的构想的提出促进�q�个�q�程。另外，如果“构想”能够攑ּ�最初的思想的所有权�Q��?br>成�ؓ�l�织的胦产，�q�个�q�程的效果将会更加提高。系�l�徏造者负责��生开始点的�?br>惻I��团队成员和业务客戯��助�ƈ负责�׃�n的构想的方向和合成�?/p>

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?

另一个重要的团队是信心。开发复杂的�pȝ��会�l�团队带来很多挑战。有时感觉是
一�U�信仰的�z�d��。大量的�l�节被收集、分析、组�l��ƈ吸取为整体的功能。在非常大的
付出中，仅有一些关键个人支配整�?#8220;囄��”�Q��ƈ随完成的不同层次不同。这�U�不��?br>定性时不时的检验团队成员的信心。给��些不��定的事情，一个团队怎样才能在�?br>向成功的�q�程中感到有保证和信心，�q�反映到团队个�h的态度呢？

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.

很明显，在团队方面的实现�Q�系�l�的设计在逐渐演化的过�E�中形成�Q�从本质上交�?br>的过�E�，帮助每个人在不确定性逐渐消除的过�E�中保持忍耐。参加项目�ƈ�l�历整个�p?br>�l�徏造生命周期的成员��多�Q�整个团队意识在每个主要里程��所有事都具备的可能�?br>��p��大。这对于一个缺乏经验的团队成员是一个重要的信心�~�造者。团队拥有的信心
水��^��高�Q�，业务客户的安全感��大�Q�团队就更加可能看到他们的胜利，即��是面�?br>未知的事情�?/p>

有猫�怼�的日�?/a> 2007-04-12 16:17 发表评论

软�g开�?需求分析的20条法则（收藏�Q?

Thu, 12 Apr 2007 07:47:00 GMT

邢学�?(IT�l�理世界)

　　　对商业用��h��_��他们后面是成百上千个供应商，前面是成千上万个消费��֮�。怎样利用软�g��理错综复杂的供应商和消贚w��客，如何做好�_��C��个小��调料包的进、销、调、存的商品流通工作，�q�些都是商业企业需要信息管理系�l�的理由。��Y件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软�g开发成功的关键所在�?
---　　�l�理�Q?#8220;我们要徏立一套完整的商业��理软�g�pȝ��Q�包括商品的�q�、销、调、存��理�Q�是总部-门店的连锁经营模式。通过通信手段门店自动订货�Q�供应商自动�l�算�Q�卖场通过扫条码实现销售，��理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营�q�的报告�?#8221;

--　　-分析员：“我已�l�明白这个项目的大体�l�构框架�Q�这非常重要�Q�但在制定计划之前，我们必须攉��一些需求�?#8221;

--　　-�l�理觉得奇怪：“我不是刚告诉你我的需求了吗？”

--　　-分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不��以提供开发的内容和时间。我需要与实际��要使用�pȝ��的业务�h员进行讨论，然后才能真正明白辑ֈ�业务目标所需功能和用戯��求，了解清楚后，才可以发现哪些是现有�l��g卛_��实现的，哪些是需要开发的�Q�这样可节省很多旉��?#8221;

--　　-�l�理�Q?#8220;业务人员都在招商。他们非常忙�Q�没有时间与你们详细讨论各种�l�节。你能不能说明一下你们现有的�pȝ��Q?#8221;

---　　分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，�l�果不会令�h满意。我们只是��Y件开发�h员，而不是采购专家、营�q�专家或是胦务专�Ӟ��我们�q�不真正明白您这个企业内部运营需要做些什么。我曄��试�q�，未真正明白这些问题就开始编码，�l�果没有人对产品满意�?#8221;

---　　�l�理坚持道：“行了�Q�行了，我们没有那么多的旉��。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，�q��时将你们的进展情况告诉我�?#8221;

---　　风险�w�在需求的�q�雾之后

-　　--以上我们看到的是某客户项目经理与�pȝ��开发小�l�的分析人员讨论业务需求。在��目开发中�Q�所有的��目风险承担者都寚w��求分析阶�D�备感兴��。这里所指的风险承担者包括客��h��面的��目负责人和用户�Q�开发方面的需求分析�h员和��目��理者。这部分工作做得��C��Q�能开发出很优�U�的��Y件��品，同时也会令客��h��意。若处理不好�Q�则会导致误解、挫折、障��以及潜在的质量和业务�h��g��的威胁。因此可见——需求分析奠定了软�g工程和项目管理的基础�?

--　　-拨开需求分析的�q�雾

---　　像这��L��对话�l�常出现在��Y件开发的�q�程中。客户项目经理的需求对分析人员来讲�Q�像“��N��看花”般模�p��ƈ令开发者感到困惑。那么，我们��拨开雑֪��Q�分析一下需求的具体内容�Q?

--　-·业务需求——反映了�l�织机构或客户对�pȝ��、��品高层次的目标要求，通常在项目定义与范围文档中予以说明�?

---　·用户需求——描�q�C��用户使用产品必须要完成的��d��Q�这在��用实例或�Ҏ��脚本中予以说明�?

---　·功能需求——定义了开发�h员必��d��现的软�g功能�Q��用户利用�pȝ��能够完成他们的�Q务，从而满��了业务需求�?

--　-·非功能性的需求——描�q�C��pȝ��展现�l�用��L��行�ؓ和执行的操作�{�，它包括��品必��遵从的标准、规范和�U�束�Q�操作界面的具体�l�节和构造上的限制�?

---　·需求分析报告——报告所说明的功能需求充分描�q�C��软�g�pȝ��所应具有的外部行�ؓ�?#8220;需求分析报�?#8221;在开发、测试、质量保证、项目管理以及相关项目功能中��L��重要作用�?

---　前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后�l�工作徏立了一个指导性的框架。其他�Q何说明都应遵�?#8220;业务需�?#8221;的规定，然�?#8220;业务需�?#8221;�q�不能�ؓ开发�h员提供开发所需的许多细节说明�?

---　下一层次需求——用户需求，必须从��用��品的用户处收集。因此，�q�些用户构成了另一�U��Y件客��P��他们清楚要��用该产品完成什么�Q务和一些非功能性的�Ҏ��需求。例如：�E�序的易用性、健壮性和可靠性，而这些特性将会��用户很好地接受具有该特点的��Y件��品�?

---　�l�理层有时试图代替实际用戯��话，但通常他们无法准确说明“用户需�?#8221;。用户需求来自��品的真正使用者，必须让实际用户参与到攉��需求的�q�程中。如果不�q�样做，产品很可能会因缺乏��够的信息而遗留不��隐患�?

---　在实际需求分析过�E�中�Q�以上两�U�客户可能都觉得没有旉��与需求分析�h员讨论，有时客户�q�希望分析�h员无��讨论和�~�写需求说明就能说出用��L��需求。除非遇到的需求极为简单；否则不能�q�样做。如果您的组�l�希望��Y件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些��开发者感到困惑的斚w��?

---　优秀的��Y件��品徏立在优秀的需求基��之上�Q�而优�U�的需求源于客户与开发�h员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时�Q�才能徏立�v一�U�良好的合作关系�?

---　�׃��目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大安��惛_��发出一个既能实现商业�h值又能满��用戯��求，�q�能使开发者感到满��的优秀软�g产品�?

--　-客户的需求观

--　-客户与开发�h员交��需要好的方法。下面徏�?0条法则，客户和开发�h员可以通过评审以下内容�q�达成共识。如果遇到分歧，��通过协商达成对各自义务的�怺�理解�Q�以便减��以后的��擦�Q�如一方要求而另一方不愿意或不能够满��要求�Q��?

---　1�?分析人员要��用符合客戯��a�习惯的表�?

---　需求讨论集中于业务需求和��d��Q�因此要使用术语。客户应��有��x��语（例如�Q�采仗��印花商品等采购术语�Q�教�l�分析�h员，而客户不一定要懂得计算��业的术语�?

---　2、分析�h员要了解客户的业务及目标

---　只有分析人员更好��C��解客��L��业务�Q�才能��产品更好地满��需要。这��有助于开发�h员设计出真正满��客户需要�ƈ辑ֈ�期望的优�U�软�g。�ؓ帮助开发和分析人员�Q�客户可以考虑邀请他们观察自��q��工作��程。如果是切换新系�l�，那么开发和分析人员应��用一下目前的旧系�l�，有利于他们明白目前系�l�是怎样工作的，其流�E�情况以及可供改�q�之处。s

---　3�?分析人员必须�~�写软�g需求报�?

---　分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解��x��法和其他信息。通过�q�些分析�Q�客户就能得��C��?#8220;需求分析报�?#8221;�Q�此份报告��开发�h员和客户之间针对要开发的产品内容达成协议。报告应以一�U�客戯��为易于翻阅和理解的方式组�l�编写。客戯��评审此报告，以确保报告内容准��完整地表达光��求。一份高质量�?#8220;需求分析报�?#8221;有助于开发�h员开发出真正需要的产品�?

---　4�?要求得到需求工作结果的解释说明

---　分析人员可能采用了多�U�图表作为文字�?#8220;需求分析报�?#8221;的补充说明，因�ؓ工作图表能很清晰地描�q�出�pȝ��行�ؓ的某些方面，所以报告中各种图表有着极高的�h��|��虽然它们不太难于理解�Q�但是客户可能对此�ƈ不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符��L��意义和需求开发工作的�l�果�Q�以及怎样��查图表有无错误及不一致等�?

---　5�?开发�h员要��重客户的意�?

---　如果用户与开发�h员之间不能相互理解，那关于需求的讨论��会有障��。共同合作能使大�?#8220;兼听则明”。参与需求开发过�E�的客户有权要求开发�h员尊重他们�ƈ珍惜他们为项目成功所付出的时��_��同样�Q�客户也应对开发�h员�ؓ��目成功�q�一共同目标所做出的努力表�C�尊重�?

---　6�?开发�h员要寚w��求及产品实施提出��和解��x��?

---　通常客户所说的“需�?#8221;已经是一�U�实际可行的实施�Ҏ��Q�分析�h员应��力从这些解��x��法中了解真正的业务需求，同时�q�应扑և�已有�pȝ��与当前业务不�W�之处，以确保��品不会无效或低效�Q�在��d��弄清业务领域内的事情后，分析人员��p��提出相当好的改进�Ҏ��Q�有�l�验且有创造力的分析�h员还能提出增加一些用��h��有发现的很有价值的�pȝ��Ҏ��?

---　7�?描述产品使用�Ҏ�?

---　客户可以要求分析人员在实现功能需求的同时�q�注意��Y件的易用性，因�ؓ�q�些易用�Ҏ��或质量属性能使客��h��准确、高效地完成��d��。例如：客户有时要求产品�?#8220;界面友好”�?#8220;健壮”�?#8220;高效�?#8221;�Q�但对于开发�h员来�Ԍ��太主观了�q�无实用价倹{��正��的做法是，分析人员通过询问和调查了解客��h��要的“友好、健壮、高效所包含的具体特性，具体分析哪些�Ҏ��对哪些�Ҏ��有负面影响�Q�在性能代�h和所提出解决�Ҏ��的预期利益之间做出权衡，以确保做出合理的取舍�?

---　8�?允许重用已有的��Y件组�?

---　需求通常有一定灵�z�L��，分析人员可能发现已有的某个��Y件组件与客户描述的需求很相符�Q�在�q�种情况下，分析人员应提供一些修攚w��求的选择以便开发�h员能够降低新�pȝ��的开发成本和节省旉��Q�而不必严格按原有的需求说明开发。所以说�Q�如果想在��品中使用一些已有的商业常用�l��g�Q�而它们�ƈ不完全适合您所需的特性，�q�时一定程度上的需求灵�z�L��就昑־�极�ؓ重要了�?

---　9�?要求对变更的代�h提供真实可靠的评�?

---　有时�Q��h们面临更好、也更昂�늚��Ҏ��Ӟ��会做��Z��同的选择。而这�Ӟ��寚w��求变更的影响�q�行评估从而对业务决策提供帮助�Q�是十分必要的。所以，客户有权利要求开发�h员通过分析�l�出一个真实可信的评估�Q�包括媄响、成本和得失�{�。开发�h员不能由于不惛_��施变更而随意夸大评估成本�?

---　10�?获得满��客户功能和质量要求的�pȝ��

---　每个人都希望��目成功�Q�但�q�不仅要求客戯��清晰地告知开发�h员关于系�l?#8220;做什�?#8221;所需的所有信息，而且�q�要求开发�h员能通过交流了解清楚取舍与限�Ӟ��一定要明确说明您的假设和潜在的期望�Q�否则，开发�h员开发出的��品很可能无法让您满意�?

---　11�?�l�分析�h员讲解您的业�?

---　分析人员要依靠客戯��解业务概念及术语�Q�但客户不能指望分析人员会成��领域的专�Ӟ��而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的�l�微潜在之处�Q�他们可能不知道那些对于客户来说理所当然�?#8220;常识”�?

---　12�?抽出旉��清楚地说明�ƈ完善需�?

---　客户很忙�Q�但无论如何客户有必要抽出时间参�?#8220;头脑高峰会议”的讨论，接受采访或其他获取需求的�z�d��。有些分析�h员可能先明白了您的观点，而过后发现还需要您的讲解，�q�时误��心对待一些需求和需求的�_�֌�工作�q�程中的反复�Q�因为它是�h们交��中很自然的现象�Q�何况这对��Y件��品的成功极�ؓ重要�?

---　13�?准确而详�l�地说明需�?

---　�~�写一份清晰、准��的需求文档是很困隄��。由于处理细节问题不但烦��且耗时�Q�因此很�Ҏ��留下模糊不清的需求。但是在开发过�E�中�Q�必��解册��U�模�p�性和不准��性，而客��h��恰是��册��些问题作出决定的最佳�h选，否则�Q�就只好靠开发�h员去正确猜测了�?

---　在需求分析中暂时加上“待定”标志是个�Ҏ��。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特�D�需求难以解��x��没有人愿意处理它而标注上“待定”。客戯��量��每��w��求的内容都阐�q�清楚，以便分析人员能准��地��它们写�q?#8220;软�g需求报�?#8221;中去。如果客户一时不能准��表达，通常��p��求用原型技术，通过原型开发，客户可以同开发�h员一起反复修改，不断完善需求定义�?

---　14�?及时作出军_��

---　分析人员会要求客户作��Z��些选择和决定，�q�些军_��包括来自多个用户提出的处理方法或在质量特性冲�H�和信息准确度中选择折衷�Ҏ��{�。有权作出决定的客户必须�U�极地对待这一切，��快做处理，做决定，因�ؓ开发�h员通常只有�{�客户做出决定才能行动，而这�U�等待会延误��目的进展�?

---　15�?��重开发�h员的需求可行性及成本评估

---　所有的软�g功能都有其成本。客��h��希望的某些��品特性可能在技术上行不通，或者实现它要付出极高的代�h�Q�而某些需求试图达到在操作环境中不可能辑ֈ�的性能�Q�或试图得到一些根本得不到的数据。开发�h员会�Ҏ��作出负面的评��P��客户应该��重他们的意见�?

---　16�?划分需求的优先�U?

---　�l�大多数��目没有��_��的时间或资源实现功能性的每个�l�节。决定哪些特性是必要的，哪些是重要的�Q�是需求开发的主要部分�Q�这只能由客戯��责设定需求优先��Q�因为开发者不可能按照客户的观点决定需求优先��Q�开发�h员将为您��定优先�U�提供有��x��个需求的��p��和风险的信息�?

---　在时间和资源限制下，关于所需�Ҏ��能否完成或完成多少应尊重开发�h员的意见。尽��没有�h愿意看到自己所希望的需求在��目中未被实玎ͼ�但毕竟是要面对现实，业务决策有时不得不依据优先��来羃��项目范围或廉��工期�Q�或增加资源�Q�或在质量上��L��折衷�?

---　17�?评审需求文档和原型

---　客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客戯��为编写的“需求分析报�?#8221;不够准确�Q�就有必要尽早告知分析�h员�ƈ为改�q�提供徏议�?

---　更好的办法是先�ؓ产品开发一个原型。这样客户就能提供更有�h值的反馈信息�l�开发�h员，使他们更好地理解您的需求；原型�q��是一个实际应用��品，但开发�h员能��其转化、扩充成功能齐全的系�l��?

---　18�?需求变更要立即联系

---　不断的需求变��_��会给在预定计划内完成的质量��品带来严重的不利影响。变更是不可避免的，但在开发周期中�Q�变更越在晚期出玎ͼ�其媄响越大；变更不仅会导致代��h��高的�q�工�Q�而且工期��被延误�Q�特别是在大体结构已完成后又需要增加新�Ҏ��时。所以，一旦客户发现需要变更需求时�Q�请立即通知分析人员�?

---　19�?�늅�开发小�l�处理需求变更的�q�程

---　为将变更带来的负面媄响减��到最低限度，所有参与者必��遵照项目变更控制过�E�。这要求不放弃所有提出的变更�Q�对每项要求的变更进行分析、综合考虑�Q�最后做出合适的决策�Q�以��定应将哪些变更引入��目中�?

---　20�?��重开发�h员采用的需求分析过�E?

---　软�g开发中最��h��战性的莫过于收集需求�ƈ��定其正��性，分析人员采用的方法有其合理性。也许客戯��为收集需求的�q�程不太划算�Q�但��L��信花在需求开发上的时间是非常有�h值的�Q�如果您理解�q�支持分析�h员�ؓ攉��、编写需求文档和��保其质量所采用的技术，那么整个�q�程��会更�ؓ��利�?

---　“需求确�?#8221;意味着什�?

---　�?#8220;需求分析报�?#8221;上签字确认，通常被认为是客户同意需求分析的标志行�ؓ�Q�然而实际操作中�Q�客户往往�?#8220;�{�֭�”看作是毫无意义的事情�?#8220;他们要我在需求文档的最后一行下面签名，于是我就�{�了�Q�否则这些开发�h员不开始编码�?#8221;

---　�q�种态度��带来麻烦，譬如客户��x��攚w��求或对��品不满时��׃��_��“不错�Q�我是在需求分析报告上�{�了字，但我�q�没有时间去��d��所有的内容�Q�我是相信你们的�Q�是你们非让我签字的�?#8221;

---　同样问题也会发生在仅�?#8220;�{�֭��认”看作是完成�Q务的分析人员�w�上�Q�一旦有需求变更出玎ͼ�他便指着“需求分析报�?#8221;��_��“您已�l�在需求上�{�֭�了，所以这些就是我们所开发的�Q�如果您惌��别的什么，您应早些告诉我们�?#8221;

---　�q�两�U�态度都是不对的。因��Z��可能在项目的早期��׃��解所有的需求，而且毫无疑问地需求将会出现变��_��?#8220;需求分析报�?#8221;上签字确认是�l�止需求分析过�E�的正确�Ҏ��Q�所以我们必��L��白签字意味着什么�?

---　�?#8220;需求分析报�?#8221;的签名是建立在一个需求协议的基线上，因此我们对签名应该这��L��解：“我同意这份需求文档表�q�C��我们寚w��目��Y仉��求的了解�Q�进一步的变更可在此基�U�上通过��目定义的变更过�E�来�q�行。我知道变更可能会��我们重新协商成本、资源和��目阶段��d��{�事宜�?#8221;寚w��求分析达成一定的��p��会��双方易于忍受��来的摩擦，�q�些摩擦来源于项目的改进和需求的误差或市场和业务的新要求�{��?

---　需求确认将�q�雾拨散�Q�显现需求的真面目，�l�初步的需求开发工作画上了双方都明��的句号�Q��ƈ有助于�Ş成一个持�l�良好的客户与开发�h员的关系�Q��ؓ��目的成功奠定了坚实的基��

有猫�怼�的日�?/a> 2007-04-12 15:47 发表评论

Mon, 11 Dec 2006 10:00:00 GMT

Subversion是新一代的版本控制工具,�׃��其优于CVS的一些特�?得到了越来越多�h的关注和使用,本�h�Ҏ��自己使用SVN的经�?写了�q�篇文章,希望对大家有所帮助,其中有些实践�q�不是仅仅适用于SVN,对其他版本控制工具也是适用的�?br />
1、养成良好的记录日志的习�?
svn ci提交�Q�最好在日志中记下清晰明��的信息,�q�个非常重要,对以后的�l�护(包括合�ƈ)都有很大帮助�?br />
2、格式统一.
开发�h员提交的文�g格式要保持一�?�l�一为DOS格式或者UNIX格式,同时提交前对源代码采用统一的风格格式化�Q�比如jalopy�Q?�q�样对以后的合�ƈ、查看修改信息会更加方便�?br />
3、如何把分支合�ƈ��C��q�上�?
只需要比较分支的初始状态与最�l�状态，然后��这些分支的修改应用��C��q�目录的工作拯��?br />步骤�Q?br />(1)、在本地��最新的��d��取出
svn co http://svn.example.com/repos/example/trunk example
(2)、到当前的example目录下合�q�分�?4889,4906分别表示分支的最初版本号和最�l�版本号
svn merge -r 4889:4906 http://svn.example.com/repos/example/branches/branches_test

4、典型的svn目录�l�构
project/branches/
project/tags/
project/trunk/

5、项目代码测试发布前别忘打上tag,作�ؓ一个基�?代表一�ơ发布版本�?br />
6、实用的SVN命��o
* svn copy 创徏分支或者标�{?br />svn copy http://svn.example.com/repos/calc/trunk http://svn.example.com/repos/calc/tags/release-1.0 -m "Tagging the 1.0 release of the 'calc' project."

* svn switch 切换工作拯��到指定的分支或者返回主�q?br />svn switch http://svn.example.com/repos/calc/branches/my-calc-branch

* svn diff 版本比较
svn diff rules.txt 比较本地修改
svn diff --r 3 rules.txt 比较工作拯��和版本库
svn diff --r 2:3 rules.txt 比较版本库与版本�?

* svn revert 删除你的本地修改,恢复��C��改前的状�?

* 查一个过�ȝ��版本,重定向输出到一个文�?br />svn cat -r 2 rules.txt > rules.txt.v2

*svn info 查看当前工作拯��是在��d��q�是在哪个分支上�?br />subeclipse下蝲地址
http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=2240

启动服务
svnserve -d -r d:\svn

其中�?-d 参数表示 svnserve.exe ��会作�ؓ一个服务程序运行在后台�Q��?-r 参数表示��?``D:\svn`` 目录指定��Z��码库的根目录。这��P��当客��L��使用�c�M�� svn://192.168.0.1/foo �q�样内容�?URL 来访问服务器时候，其所讉K��到的真实代码库，其实��是 ``D:\svn\foo``

在服务器端的 ``D:\svn`` 目录下，建立一个名�?arm 的代码库�Q�命令如�?:
创徏代码�?br /> D:\svn>svnadmin create arm

使用上述命��o之后�Q�如果不出问题的话，�?``D:\svn`` 目录下就会多��Z��个叫�?``arm`` 的目录，其下具备 conf、dav、hooks、locks、db �{�子目录或文�Ӟ��此即 **一个名为arm的代码库** 。从此，通过 ``svn://192.168.0.1/arm`` �q�样�?URL�Q�我们就可以对这个代码库�q�行讉K��了。接下来��p��q�入本文的正题了�Q�也��是权限配置部分了�?/font>

有猫�怼�的日�?/a> 2006-12-11 18:00 发表评论