软件协同设计

《软件协同设计》由会员分享，可在线阅读，更多相关《软件协同设计（25页珍藏版）》请在装配图网上搜索。

1、第三章软件协同中的角色与目标3.1为什么团队中需要区分角色？国内软件企业的开发模式多为“大拿领衔制”，通常公司十多个技术人员中 间有一个技术“大拿”，剩下人辅助他，把这个产品的所有代码写完，则软件就 算完成了。“大拿领衔制”脱不去小作坊的味道，虽然保证了 “技术大拿”的创 造性，却失去了软件研发过程应有的规范。为什么在一个TSP开发团队中团队成员需要区分角色呢？角色提供了一套 已定义和可接受的工作框架。有了角色，团队成员就能专注于特定的目标，把注 意力放在工作的特定层面上；有了角色，每名成员都可以支配整项工作的特定子 集，他人无需为此担心。当然，为了整体的高效，每名团队成员不仅要了解自己 的角

2、色，也要熟悉所有的其他角色。不论是足球、篮球、棒球还是橄榄球，运动员在上场前总会被安排在特定的 位置。与之相类似，在TSP进程的初始，团队成员被安排担任不同的标准角色， 在所有成员之间将主要团队职责进行了划分。通过将占据每项关键领域的团队成 员确定下来，确保了运营团队的过程中，一般问题能够迅速高效的解决。团队之 中没有真正的“权利大小（谁管谁）”，只有成员紧密沟通。总体而言，角色满 足了人类的需求，加速了团队组建过程，有助于处理迫切的团队任务。补充阅读：分工的善与恶笼统地说，正如其他人类制度一样，分工自身也同时具有益处和代价。如果允许一个空 泛的概括，分工的优点至少有：1）集中特定的知识、技能

3、一想想自己左右手、左右脑的 分工，我们也许就可以理解这对提高生产率的重要性；2）职责明确，不同职责的人为自己 做出的决定负责；3）增进交流：各个角色之间为确保顺畅的协作，必须要求高质量的交流， 这也就能使很多原本不言而喻的事情书面化、明晰化。但分工也有其自身的弊病。首先，不少人天性追求完满，要让他们接受分工，只完成整个工作的一个枝节部分，可 能是非常痛苦的事。我记得自己刚刚参加工作后参与开发的一个系统，直到开发接近尾声， 项目经理才在一次每周例会上说：“大家开发了这么久，对整个系统的用途可能还不很清楚， 今天我们简单谈谈”一一这时我才知道自己参与的是整个店铺系统的销售子系统的订货部分 的一个底

4、层数据模块。另外，分工往往导致等级制度和不同角色间的疏离。既然分工的要义是把高要求的工作 集中在少数人手中，在少数和大多数之间，不同的工种之间，必然会导致等级差异和隔阂。 人月神话中也谈到，在区分了产品设计和技术实现之后，单纯的实现者会感到仅仅听命 于人，常常缺乏独自开发时的“成就感”。这也是素朴的、混沌未开的开发过程一旦引入分工， 就必然产生的异化。如果说，上面谈到的这两点还应该算是人类各种分工制度共有的必要的恶”，软件开发 中的分工还有一种特有的弊端：细致的分工与“重量级方法论”之间有很强的亲和性，倾向于 导致更高的开发成本和开发风险。对于产品设计和系统构架设计来说，将决策权集中在产品经理

5、和系统架构师手中，意味 着一种集权式的专制体制。这也要假设，这些负责人对产品或系统构架具备了充分的、无遗 漏的了解。整个系统从他们头脑中的理念萌芽演化，再通过文档等介质，最终被实现为软件 产品。如果产品经理确实能够从一开始就清晰、完整地把握客户需求，选定的开发平台、技 术对系统架构师也不存在任何难点，那么类似的集权制可能是合理而且高效的。但软件开发 往往充满革新和变数，客户需求一日千变，开发技术也日新月异，大量不确定因素的引入， 使集权体制变得非常可疑。如果需求和设计无法自顶向下、一步到位的给出，而是需要多次 反复、迭代才能渐趋完善，那么一个多级的、细分工的开发体制与扁平的、粗分工的体制相 比

6、，就需要更大的初期代价(initial investment)，更多的文档和交流，并缺乏后者灵活、自 适应的应变能力。3.2开发团队的角色与开发步骤的对应关系任何开发过程的第一步都是找出客户想要什么，并且将需求文档化。因此， 开发团队包含一个或多个需求分析员跟客户一起工作，并且把客户想要的分解为 离散的需求。一旦了解了需求并且把需求文档化，分析员就与设计人员一起工作，以生 成系统层描述(系统要什么)。然后，设计人员与程序员一起工作，以程序员能 够编写实现指定需求的代码行的方式来描述系统。生成代码之后，必须对它进行测试。通常，第一次测试由程序员自己完成； 有时，也使用另外的测试人员帮助程序员发现

7、他们忽略的错误。当代码单元被集 成为一组运行的功能时，测试人员小组与实现小组一起工作，以验证随着将各部 分组合起来构建系统，是否它能够正确运行，以及是否符合规格说明。当开发团队对系统的功能和质量感到满意时，注意力就转向了客户。测试 小组和客户一起验证整个系统是否是客户想要的系统。他们通过把系统如何工作 与最初需求规格说明进行比较，来完成这项工作。然后，培训人员向用户说明如 何使用这个系统。如果在系统已经验收之后发现了故障，维护人员就会修复它们。另外，随 着时间的推移，客户的需求可能会发生变化，系统也必须进行相应的改变。因此， 维护可能涉及分析人员，由分析人员决定增加或变更哪些需求；还可能涉及设

8、计 人员，由设计人员确定改变系统哪个部分的设计；还可能涉及实现这些变化的程 序员，确保改动后的系统仍然正确运行的测试人员，以及向用户解释这些变化如 何影响系统使用的培训人员。下图说明开发团队的角色与开发步骤的对应关系。需求分析和定义系统设计软件程序设计程序实现单兀测试集成测试系统测试I交付系统雄护分析员设计人员程序员测试人员开发人员角色资料管理员负责准备和存储在系统生命周期中用到的文档，包括需求规格说 明书、设计描述、程序文档、培训手册、测试数据、进度等。与资料管理员一起 工作的是配置管理小组的成员。配置管理涉及维护需求、设计、实施和测试之间 的对应关系。开发角色可由一个或几个人承担。就小型项

9、目而言，二三个人可以承担所有 角色。然而，就大型项目而言，通常根据他们在开发中职责，把开发团队分成不 同的小组。有时，维护系统的人员与最初设计和编写系统的人员是不同的。对某 些规模巨大的开发项目来讲，客户甚至会雇佣一家公司做最初的开发，而用另一 家公司进行维护工作。补充阅读：从角色入手管理团队中小型软件开发项目一般都具有任务急、工期短的特点，要在确保满足时间、质量、成 本和效益的情况下交付给客户满意软件产品，必须保证团队与客户、团队成员之间能良好 的沟通与协作。沟通与协作是团队开发活动的基础，它贯穿于软件开发的整个生命周期。是 软件开发项目速度、成本、效率的关键。虽然充分的协作开发具有很多优势

10、，但这在事实运行当中却存在很多问题，例如，对于 一个管理者而言，一类挑战是在既有协作团队中增加新的成员。有些小公司起步于一个核心 团队。当公司发展壮大时，该核心团队需要吸收新的成员，这时，就有可能发生一些冲突。 结果可能是，新成员会被驱逐出来或者核心团队成员选择放弃并离开公司。以下有几个方法，可以避免出现类似的情况。首先，当新成员加入一个团队时，请确保他们的个性与本团队相匹配。第二，不要聘请超级明星。尽管他们可能带来好的效果，但是你想要他们做的大部分工 作可能对于有经验的人们而言已是重复工作，而且也不能够充分他们的才能。第三，或许最重要的是，当团队中加入新成员时，为他们指派一些可以帮助他们掌握

11、窍 门并理解文化的良师。这将有助于他们更快地融入团队并产生一种归属感和成就感。从项目当中的角色管理入手，也是提高协作开发效率的一项重要举措，IBM Rational所 倡导的整合开发平台，是将与软件开发相关的所有人员凝聚在一起，通过一套整合的流程和 全面的质量控制机制，形成一个功能强大的开发平台。高品质软件是多道工序锤炼的结果，创造高品质软件的开发平台必须整合完成所有这些 工序的角色，以使其倾力协作。角色的整合建立在清晰的角色定位之上，从开发实践中IBM Rational定义了项目经理、系统分析人员、架构设计师、开发人员、测试人员、部署人员六 大角色，他们的工作环环相扣，形成一个缺一不可的团体

12、，每一个角色都能在开发平台上找 到自己的位置，并能获取适合自己的工具。沟通与协作不仅指开发团队的内部成员之间，也包括开发团队与用户、客户之间的互动。 在软件开发的全过程中，沟通与协作是一切活动的基础，它将会扮演越来越重要的角色， 而采用专业的平台与工具，不仅将会让团队的沟通写作更加有序、高效，更能够保证整个软 件项目的质量与客户满意度。3.3 IBM 的 Software Development Platform （软件开发平台）随着行业的快速发展，软件开发环境变得越来越复杂。IBM推出的软件开 发商业流程理念SDP,即Software Development Platform （软件开发平

13、台），使得原有的生命周期开发得到近一步完善，从而在一个高度集成、整 合的环境下，为用户提供高质量的软件开发解决方案。以Rational软件为主 体，SDP完美整合IBM其他软件产品和技术，为用户提供完整、开放和高度 集成的软件开发环境和平台。而今，用户对软件开发平台规范化、标准化的呼 声与日俱增；实现异地同步软件开发也是迫切需要解决的问题。SDP正好可 以满足这些需求。基于Rational成熟的技术和产品，高度集成了 IBM软件各 项优势，SDP是一个整合的、规范化、标准化的开发平台，帮助用户提升开 发效率，减少重复工作，更可以降低或避免因开发人员流动而带来软件资产流 失和工作停滞。同时，SD

14、P实现了异地同步软件开发，在实现开发人员间的 异地实时沟通、团队协作方面是一个历史性的突破。众所周知，软件开发是一个需要高度协作的技术过程。开发人员根据自身 的特点，在开发过程中扮演的角色也不尽相同。SDP把整个开发人员群体定 义为6种角色，即：分析人员、架构师、数据设计人员、项目经理、开发人 员和系统测试人员。这个定义明确了软件开发过程中不同角色的定位，从而大 幅提升了软件开发的管理水平，更为扮演不同角色的开发人群指明了相应的发 展方向。1. 分析人员业务分析人员的任务是理解和描绘客户的需求，引导和协调用户和业务需 求的收集和确认，文档化和组织系统的需求，或者向整个团队传达需求。2. 架构师

15、架构师负责理解系统的业务需求，并创建合理、完善的系统体系架构。架 构师也负责通过软件架构来决定主要的技术选择。这典型的包括识别和文档化 系统的重要架构方面，包括系统的需求、设计、实现和部署视图。3. 数据设计人员对于大多数的应用开发项目来说，用于持久存储数据的技术是关系型数据 库。数据库架构师负责定义详细的数据库设计，包括表、索引、视图、约束、 触发器、存储过程和其他的特定数据库用于存储、返回和删除持久性对象的结 构。4. 项目经理项目经理负责管理业务应用开发或者软件和系统开发项目。项目经理角 色计划、管理和分配资源，确定优先级，协调用户和客户的交互。项目经理也 要建立一系列的实践活动以确保项

16、目工作产品的完整性和质量。5. 开发人员开发人员通常负责设计和实现可执行的代码方案、测试开发出了的组件和 分析运行时情况以去除可能存在的错误。有时开发人员还负责创建软件的体系 架构或者使用快速应用开发工具。6. 系统测试人员系统测试人员负责制定测试计划并依照测试计划进行测试。这些测试包括 功能性的测试（黑盒测试）和非功能性的测试（白盒测试）。测试人员需要良好的 测试工具来辅助完成测试任务，自动化的测试工具将大幅度提高测试人员的工 作效率和质量。补充阅读：软件开发中的三种重要角色“三”据说是玄学家们偏爱的数字。“三段论、三权分立、三位一体.”有人认为，通常称 为“软件工程”的学科至少包括三个重要

17、的组成部分：产品设计、系统构架设计和项目控制， 而相应地，软件开发队伍中也有三个重要角色：产品经理、系统架构师和项目经理。人月神话一书的读者都能理解“概念完整性”对于软件系统的重要性。概念完整性指 的是，软件系统作为一个整体，对于使用者体现出的概念上的一致性、清晰度和简洁度。按 照该书作者Brooks的看法，概念完整性是设计软件时需要考虑的首要因素，而为了确保概 念完整性，应该要求1）区分系统设计和系统实现工作；2）系统设计的工作由一个人或不 多的几个达成共识的人完成。这里谈的“系统设计”，基本上对应于我说的“产品设计”，即， 确定软件系统的功能、性能指标、交互模式等方面的需求。质言之，产品设

18、计者决定做什 么”的问题，而把“怎么做”的问题留给实现人员（implementers）来完成。这样就引入了第一组工作划分。这里的重点是，产品设计应该由专人负责，而不是交给 “程序员”代庖。相反的实践，即让具体开发者确定产品设计细节的做法，在国内软件业似乎 仍很常见，但正如人月神话所言，这是一种非常危险的尝试。首先，如果产品的各个设 计细节由多个开发者按各自的设想确定，那么概念完整性就几乎一定会被破坏。其次，具体 开发者往往更注重系统实现中的技术因素，而对最终使用者的需求、动机和感受都缺乏体认， 因而单纯出自程序员的产品设计，总是会偏离使用者对业务和易用性的实际需要，很难获得 用户的欣赏一一有一

19、个略显过分的比喻甚至说，让程序员做产品设计，无异于让精神病患者 们自己运营疯人院。而谈到产品设计或系统需求确定，另一种流行的误解是，这应该是客户的任务：“需求 调研人”至多需要记录下客户的所有需求，就能形成完美的需求规格设计书。天知道（至少， 任何做过委托开发的人都知道）这种论调和国内客户的实际情况之间的差距。不止一次，我 拿到的全部客户需求就是：开发一套电子商务系统。句号。设计产品或确定系统需求不仅需 要行业、领域经验（这是“客户”的优势所在），更需要大量同类系统的使用经验（甚至开发 经验）以及较强的抽象能力、表达能力等等。而目前很多客户，由于接触同类系统有限，自 身业务流程也远未标准化，若

20、指望他们提出清晰、明确的需求，好比是让一个只会喊“饿” 的小孩儿进饭馆点菜。开发团队必须委派专人，通过耐心诱导和反复尝试才能获知他们的实吵而罗c。负责产品设计的“专人”通常称为“产品经理”。我心目中理想的产品经理，应同时具备较 高的商业素质和较强的技术背景。具体地说，首先，一个优秀的产品经理要有深厚的领域经验，也就是说，对该软件系统 要应用到的业务领域非常之熟悉。比如，开发房地产销售软件的产品经理，应该对房地产公 司的标准销售流程了如指掌，甚至比大多数销售人员还要清楚。如果开发的是通用产品，他 /她还具备对市场、潜在客户需求的深刻洞察力。其次，他/她应该善于完成从使用者视角到开发者视角的转化，

21、善于将繁复的实际业务 抽象为概念模型和人机交互操作。再次，他/她在技术方面也应该具备足够的知识，能对特定需求的可行性做出初步的衡 量，能够做出方案选型的抉择。功能需求往往符合Paretos Principle（20-80原则），怎样设 计一个开发代价最小，而覆盖需求最多的功能集，怎样确定各个功能在实现时的优先度，是 产品经理必须懂得的艺术。另外产品经理应该知道采用特定开发平台、特定工具产品的优势 和代价，并从商业角度出发做出选择。最后，他/她还应该能够确定系统在人机交互方面的主要特征。程序员设计的产品为世 人讥评，很大程度上要归咎于糟糕的交互（UI）设计。产品经理应该能够从商业角度出发， 了解

22、特定客户/潜在客户群在人机交互方面的需求，并能衡量特定的人机交互模式的实现难 度在很多场合中，某个微小的操作模式的变化会导致整个系统实现构架的变化，因此， 尽早确定UI的主要特征，并要求它们在整个系统内保持一致，对于概念完整性和系统技术 构架都是至关重要的。对一次软件开发来说，产品设计是源头，是核心。因而产品经理的工作质量也直接关系 到开发的成败。记得一位业内资深人士曾说，合格的产品经理需要一份MBA学历，再加上 原先若干年的技术开发经验。综合考虑以上素质，我相信他提出了相当中肯的要求。如上所述，产品设计是一个复杂、困难的过程，其中充斥着争论和妥协、权衡和决断，并且，根据软件处理的实际业务不同

23、，这个过程的内涵也千差万别。让我们暂时告别这段恶魔般的旅程，轻快地考察另一个较为清晰的领域：“系统构架设计”。系统构架，是对已确定的需求的技术实现构架。与产品设计相比，系统构架设计的工作更明确，而目前该领域也已经形成了较为成熟、完善的方法论和一整套易于掌握、传授的知识。相应地，系统架构师是一个不折不扣的技术人员，主要着眼于系统的“技术实现”。他/她的责任是最终确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点。因此他/她应该是特定的开发平台、语言、工具的大师，对常见应用场景能马上给出最恰当的解决方案，同时要对所属的开发团队有足够的了解，能够评估自己的团队实现

24、特定的功能需求需要的代价。这里，最容易导致误解的部分是产品经理和系统架构师的区别。我感到现有的不少论述和实践都倾向于将一者混为一谈。但在我看来，如果把开发软件比作摄制电影，产品经理之于系统架构师，就正像编剧之于导演。产品经理虽然要有一定技术背景，但仍应属于“商业 人士（business people）”，而系统架构师则肯定是一个技术专家。二者看待问题的立场、角 度和出发点完全不同。当然，就像有时电影导演也出任编剧（甚至存在“作家电影”流派）， 对于特定的开发领域或项目，产品经理和系统架构师这两种角色的重合也可能是无害、甚至 有益的（我能想到的一个领域是编程语言的设计），但即使如此，不加区别地对

25、待需求和实 现、产品设计和系统构架设计，肯定是危险的。如果你处在一人权充两种角色的情况下，你 应该时刻意识到自己目前进行的是哪一种职责，并据此调节视角和思路。我感到这两种角色的含混还来自人们对“architect”这个表达方式的不同用法。Architect 和architecture，这组显然是借自建筑学的隐喻，经常被不加区别地使用在产品设计和技术实 现这两个不同的方面。Brooks本人在人月神话做出的“architect”和“implementer”区分， 基本上对应于我在上面谈到的“产品设计”和“技术实现”，但是由于“技术构架”本身也可以称 作architecture，所以一般谈到syst

26、em architecture或system architect时，人们关注的却主要 是技术实现方面。正如Martin Fowler所说，人人都想被称为architect而不只是engineer，所 以这里用语的含混可能也体现了不同领域的人们对architect这个好词的争夺。如果继续上面的电影隐喻，那么摄制组中的“制片”职责也就对应于我所说的“项目控 制”。显而易见，项目控制工作与上面谈到的产品设计、构架设计都不同，如果说产品设计 偏重于“商业”、系统构架设计偏重于“技术”，那么项目控制注重的就是“管理”。它主要关注 的是项目本身的进度、质量等方面。软件开发项目需要专人负责这些内容，我愿意称

27、此为“项 目经理”。项目控制/管理已经形成了一个专门的学科（Project Management），对于软件项目经理， 其职责也未脱离该学科的描述，包括项目计划、进度跟踪监控、质量保证、配置发布/版本 /变更管理、人员绩效评估等方面。优秀的项目经理需要的素质，并不仅在于会使用几种软 件或是了解若干抽象的方法论原则，更重要的在于从大量项目实践中获得的宝贵经验，以及 交流、协调、激励的能力，甚至还应具备某种个性魅力或领袖气质（charisma）。通俗地说， 也许学校里的学生会主席要比“学习尖子”更适合这样的职位。由此可见，项目经理和系统架构师在职责上有很大差异。混同这两个角色，往往也会导 致低效、

28、无序的开发。特别是，从性格因素上讲，单纯的技术人员倾向于忽视人”的因素， 而这正是管理活动的一个主要方面。另外，就像战争中的空军掩护（air cover）一样，专职 的项目经理能够应付开发过程中大量的偶发事件和杂务，对于一个规模稍大的项目（人月 神话似乎说的是6个人以上），这些杂务本身就能占用一个全职工作者的几乎全部时间。3.4微软项目组中的角色一个伟大的软件后面都有一个伟大的故事，一个伟大的软件后面也有一个伟 大的方法。当Windows 2000经过胎死腹中的危机，终于如凤凰涅磐般再生时，微软决 定给整个产品组成员拍摄一张合影，以纪念这个历史时刻的诞生。到了拍摄那一 天，微软人发现，他们只有

29、把摄像师安排在飞机上才能干好这件事儿一一因为 Windows 2000产品组整整有5000人！“团队=软件”，微软软件开发管理理论的基础可以这样一个恒等式来表达， 软件可以忠实地展现创造它的团队的一切优点和缺点。软件业中没有两个完全相 同的失败，但最常见的莫过于新版本跟不上对手的脚步，微软开发模式的精髓之 一，便是通过产品组团队中每个成员对职责的承诺来控制产品的开发过程，保证 新产品准时地、经常地被推出。这正是软件业最大的金科玉律！我们来看看，微软的团队是怎样组成的？很多软件公司的开发团队，大部分是由一名项目经理，若干项目成员组成， 项目成员包括需求分析、架构设计、编码、测试等角色。而微软的团

30、队非常特别是没有项目经理的，由6类角色组成，分别是产品经 理(Product Management)、程序经理(Program Management)、开发(Development)、 测试(Test)、发布管理(Release Management)、用户体验(User Experience)o各类角色负责的职责如表1所示。衷1各类角色负责的职责角色职能领域职责产品管理混足客户市场升发 业务价值 客户拥护 产品计划为项目小组克当客户角色驱动共冏的顼目和方揖设祇管理客户彝求说明开贫和维护业务案例一交持潢足项目约束的解 决方案蓊苜麻愈解建方案体系结构 过程保证借理殷葬n管理客点期仙堑动产品特征“

31、日程亲.贸源权衡决黄 管理市场开发.产品宣传和技共是系 升发.垂护向执符交流计划 驱动开发过程以期指时的交付产品 管理产品兢格说明书首腐顼目构架师促进小组内部的安湘利照娘 维护项目曰程衰和报各斯目状恋 驱使美钮的权衡决镰的富现维护和执行顼目总规划和日程溃 驱使和管理腐险押怙曲凤险管理开农根据规格说明创建解决方案技术咨询实现的枸染别设计应用程序开翅基瑞结询开我估算完成誓个特征所奇的时间总糖为 构建每个特征并监智其实现 成昔部署时使用的产品为小塑提供技术主览的奁门知设飒试“左困有产品成;事宜被 识别并处理后送行发布篇展规划 漪说工程 测试报告瑚保了解所有向藏淡定测试策略桐制定计划执行测诚, .握高

32、用户技率技术交流培训可用性用户界面设计易用性为项目小蛆克当用月的角色管理用户需求设明设计曲开发性能支持系统驱动可用性和用户胜能垠数的权衡决第为用户强供我助特点和帮明文档的规格设 明中开屐和提供用户培训投布管过进行平滑的部署及日常运行基础姑拘支持操作业务发布瞥璀管理产品部骨驱使可用性和可支弥:决策管理各珂操作,支持和交付阳百亍何的关系为项目小蛔提供后勤支持微软的团队模型中的6种角色，不代表团队最少要6个人组成，一个人可以 兼任多种角色，也不代表每一种角色只有一个人，可以多个人公担一个角色。微 软这种团队结构与我们常见的团队结构相比，有这样的特点：扁平对等的团队结构，强调每个人的价值。这种团队结构

33、，是 赋予小组成 员权力”、“清晰的责任和共同的职责”、“推动开放式沟通”这三个原理的表现。 这样的结构，让每位小组成员都感受得到自己的重要性，项目的成败与每位成员 直接相关。这样的结构更容易调动每位成员的工作积极性，更容易让团队激发工 作热情，产生更多的创造性成果。微软很重视的我们常会忽略的用户体验和发布管理微软团队的6种角色所负责的工作，覆盖了软件开发中需要考虑的各个方 面，用户体验、发布管理是常被我们忽视的地方。微软软件的用户体验都非常好， 规范一致的界面，详细的帮助系统，良好易用的安装程序，良好的技术支持等。 微软创造了很多界面规范，操作习惯，这些都是我们需要认真去学习的。知识管理软件

34、开发团队是知识密集型的团队，学习再学习，是软件开发团队的重要 特点。没有学习的团队，是没有活力的！如何保证团队的每位成员都具备完成本项目的能力呢？就绪管理就是来解 决这个问题的。小组成员的6种角色，需要不同的技能来完成本职工作，任何一种角色技 能的欠缺，都会影响最终解决方案。小组应该根据项目的前景，列出各成员所欠 缺的技能，这些技能包括技术方面的也包括非技术方面的，安排相应的学习计划、 培训计划，保证每位成员的技能都达到要求。就绪管理是知识管理的重要组成部分，知识管理还包括知识的共享和积累、 技能的评估、技能提升机制等。从微软提供的系列认证，如MCSD、MCP等， 大家就可以感受到微软系统的培

35、训制度。项目团队的知识管理，应该在组织层面上进行，跨越项目组进行，每位团 队成员都可以学习其他团队的经验，每位团队成员都可以共享知识给其他的团 队。补充阅读:角色模型-来自MS的软件开发实践总结John Pruitt & Jonathan Grudin 著 Persona: Practice and Theory项目情况MSN Explorer开发项目组成员：数百人角色模型项目组：共4人。可用性工程师3人（其中两人兼职），产品设计师1人（兼职）角色模型项目时间：从2001年1月起，持续大约10个月Microsoft Windows开发项目组成员：数百人至数千人（随时间变化）角色模型项目组：共2

36、2人。包括几个技术文案、几个可用性工程师、4个产品策划 人、2个市场调研角色模型项目时间：从2001年3月起，持续大约2年时间（到著者发稿时还没有结碰到的问题1角色不可信。明显是由项目成员人为设计（并不是基于数据），或者与数据之间的关 系不那么清晰。2角色的传达沟通没做好（译者注：应该是指把角色向整个项目组的成员传达）。通常 的手段就是把做得像简历一样的文档打印到很大一张纸上，然后四处张贴。3没有真正认识到要怎么去使用角色模型。尤其是在整个项目过程中没有向所有的人一 直不停地讲述模型。4没有足够的资源支持。包括高层的支持、人力资源和预算等。引出的思考怎么提取用户抽象是最好的办法？可以虚构到什么

37、程度？那些内容必须以数据为基础？哪些数据是最合适的？怎样才能把不同类型的数据整合起来？几个相关的产品开发小组能不能共享一组通用的用户抽象?怎么评价这些努力是值得的？结果我们的产品变得更好了吗？等等实践中的细节利用已有的数据，特别是用户研究的数据。包括行业调研、焦点组、用户访谈和市场趋 势研究等。角度数量控制在一个比较可控范围：3-6个。收集大量相关的市场调研和用户研究数据（从网上或者一些外部资源）。创建一个“反面角色”，尽可能表现出那些没有被考虑到的用户。Windows项目中人员较多，所以拆分到两三个人的多个小组中，每组负责一个角色。关于角色的每一句描述都尽可能地和数据相关联。创建一个“基础文

38、档”，所有的角色都在这个基础上创建。它包括数据、关键属性、照 片、相关材料等）。当一个角色基本上被创建出来之后，就近找一个人来当模特，为他拍上一到两小时的照 片，用作后面的视觉材料。避免使用图库的图片，因为图库中的同一个人常常只有一两张照角色完成之后，为它建一个网站。找那些总体上匹配的用户来看看在细节上是不是和他 们匹配。角色和文档都搞定之后，开一个启动会议来向大家介绍。用多种方法让大家时刻都记得角色模型。比如做一些角色模型（真的模型，玩具）、印 有角色的鼠标垫、啤酒杯、其他多种形式的电子材料等等。花大量的精力保证产品和功能文档中包含使用角色模型来创建的情景流程。视觉设计师在角色模型的基础上来

39、创作视觉表现。3.5软件协同中的团队成员角色TSP角色涵盖了团队管理的所有方面，从客户接口到测试，从过程管理到 质量控制。这样，TSP团队成员拥有他们自己的过程和计划，决定他们要如何工 作，并且控制项目运营的方式。TSP团队成员角色TSP过程定义了 8项标准团队成员角色。它们是：客户接口经理设计经理实现经理 测试经理 计划经理 过程经理 质量经理支持经理这些角色覆盖了团队要完成的大部分管理任务。但是，角色的目标不是完成 每个角色所涵盖的所有任务，而是要提供团队对某项活动的关注和领导。通过对 角色提供一致关注，角色担当者就能够确保所有相关事件和需要考虑的事项都及 时确定并得到处理。除了 TSP定

40、义的角色外，还允许有许多其他角色。例如：硬件接口经理（设计、实现或测试经理）装配经理（客户接口、支持或测试经理）性能经理（设计、实现或测试经理）保险经理（设计、实现、测试或质量经理）安全经理（客户接口、设计、实现或质量经理）隐私经理（客户接口、设计、实现或质量经理）外包经理（计划、设计、实现或测试经理） COTS （商业现货）经理（设计、实现或测试经理）在启动过程中，团队应该考虑项目的特殊事件，确定需要特别注意的额外角 色。分配这些额外角色时，要确保被选择的角色担当者定义了角色职责，并且 和整个团队一起评审了这些职责，并达成协议。通常情况下，当某项额外职责确 定下来之后，在逻辑上是可以加入现有

41、角色当中的。上面括号内所列出的角色显 示了对这种做法的建议。3.5.1客户接口经理的职责客户接口经理负责团队与客户之间的关系。因为团队提供产品的每一个小组 都可以看成是客户，因此准确界定客户接口经理需要来应对的特定客户非常重 要。最常见的定义是团队与任何代表用户团队的小组一同开发的产品的最终用 户。这可能包括系统小组、需求小组、市场人员、合约谈判代表或者真实的最终 客户。TSP客户接口经理的角色规范在表3-1中给出。表3-1 TSP客户接口经理的角色和职责目的当团队成员全都持续履行了角色职责，遵循了已定义的过程，朝着共同 目标和规范而工作的时候,团队最为高效目标客户经理的目标是：1. 理解客户

42、的想法和需求2. 引导团队提供可以令客户满意的产品角色特性对客户接口经理最有帮助的特征是：1. 喜欢和人们一起工作2. 理解人们的需求,能够体会他们的顾虑3. 能够用非技术的语言描述技术问题4. 对定义和构建优质产品有兴趣团队成员职责为了帮助客户接口经理完成工作，所有的团队成员都应做到：1. 满足团队成员的承诺2. 遵循严格的个人过程3. 计划、管理和汇报个人工作4. 与团队所有成员一起合作以维护一种高效的生产性工作环境客户关注度作为客户接口经理，要领导团队与客户进行交互1. 在整个项目当中，维持对客户需求的关注2. 确保客户同意产品需求3. 在必要的地方，定义原型，帮助客户理解产品特征4.

43、与客户一起工作以建立产品接受的测试标准和计划5. 归档达成一致的接受测试标准和计划，确保客户评审并同意定义需求客户接口经理的一项主要职责就是领导产品需求的开发和演化。1. 确定和定义需求问题，管理他们的解决方案2. 归档和确认需求问题的解决方案3. 领导团队生产、定义和验证产品需求4. 领导团队确认、测试、分析和解决产品可用性问题5. 确保所有的需求假设都得到确认、归档和校验6. 确保团队及时解决了安装问题管理需求变更除定义需求外，客户接口经理还要：1. 管理需求变更过程2. 领导团队评估和归档每一次需求变更的影响3. 对需求变更决策，确保有及时完整的数据提供给配置控制委员会建立和管理需求标

44、准客户接口经理还要建立团队标准和过程，用以归档和评审产品需求报告要跟踪并每周向团队报告需求标准和需求开发的状态设计经理负责团队设计工作的质量，他需要跟踪设计工作，确保满足了所有 相应的设计标准，确保设计工作被正确的记录了下来。设计经理可能需要团队其 他成员的帮助。TSP设计经理的角色规范在表3-2中给出。表3-2 TSP设计经 理的角色和职责目的当团队成员全都持续履行了角色职责，遵循了已定义的过程，朝着共同 目标和规范而工作的时候,团队最为高效目标设计经理的目标是：1. 领导团队完成优质的设计2. 在设计过程中全面利用团队的技能和思想3. 确保设计及其文档都有较高的质量角色特性对设计经理最有帮

45、助的特征是：1. 喜爱设计和构造2. 对设计方法很熟悉3. 即使设计与最初想法发生偏差，也对完成优质设计最感兴趣4. 可以客观的比较自己和他人的设计团队成员职责为了帮助客户接口经理完成工作，所有的团队成员都应做到：1. 满足团队成员的承诺2. 遵循严格的个人过程3. 计划、管理和汇报个人工作4. 与团队所有成员一起合作以维护一种高效的生产性工作环境领导设计作为设计经理要1. 在整个项目当中，维持对设计问题的关注2. 确定和解决所有的设计问题3. 归档和确认设计问题的解决方案4. 让团队关注并解决产品性能及规模问题5. 领导团队生产、提炼和校验产品设计6. 合理使用并分析原型或实验，确保所有的设

46、计问题和假设都得以 确定、归档和解决管理设计变更作为设计经理1. 管理设计变更过程2. 对于在配置控制之下的产品元素，领导团队评估和归档每项变更对 设计的影响3. 对于在配置控制之下的产品元素，确保有及时完整的数据提供给配 置控制委员会，以完成设计变更决策建立管理需求标准设计经理还要建立团队用以生产设计材料的标准和过程报告要每周向团队报告设计标准和产品设计工作的状态实现经理负责团队实现工作的总体质量。例如，他在设计阶段应该关心设计 的充分性。实现经理还要负责所有必需的实现标准以及这些标准将要被遵循的程 度。例如，实现经理应该确保编码和注释标准的合理性和遵循程度。在某些情况 下。实现经理还会取代

47、测试经理来验证单元测试计划的充分性和单元测试的完整 性。TSP实现经理的角色规范在表3-3中给出。表3-3 TSP实现经理的角色和职责目的当团队成员全都持续履行了角色职责，遵循了已定义的过程，朝着共同 目标和规范而工作的时候,团队最为高效目标实现经理的目标是：1. 领导团队完成优质产品实现2. 确保实现完全与设计相符3. 生产出的产品具有较高质量角色特性对实现经理最有帮助的特征是：1. 喜爱构造2. 理解实现工具和环境3. 对生产高质量的产品最有兴趣团队成员职责为了帮助客户接口经理完成工作，所有的团队成员都应做到：1. 满足团队成员的承诺2. 遵循严格的个人过程3. 计划、管理和汇报个人工作4

48、. 与团队所有成员一起合作以维护一种高效的生产性工作环境领导实现作为实现经理，要1. 在整个项目当中，维持对实现问题的关注2. 确定并解决所有的实现问题3. 归档并确认实现问题解决方案4. 领导团队确认并处理产品包装、分销和安装问题5. 领导团队生产、提炼和验证产品实现6. 领导团队度量并识别任何性能及规模问题7. 合理使用和分析原型或实验，确保所有的实现问题和假设都得以确 定、归档和解决管理实现变更作为实现经理，要1. 管理实现变更过程2. 对于在配置控制之下的产品元素，领导团队评估和归档每项变更对 设计的影响3. 对于在配置控制之下的产品元素，确保有及时完整的数据提供给配 置控制委员会，以

49、完成实现变更决策建立管理需求标准实现经理要建立团队用以完成产品实现及文档整理的标准和过程 确保团队拥有编码、LOC计数、语言和文档的标准报告实现经理要每周向团队汇报实现标准和产品实现的状态这些报告包括计划和实际编码、评审、编译、审查和修改、单元测试 和集成发布的LOC3.5.4测试经理的职责测试经理负责项目所有测试和测试相关工作的质量。这包括测试标准、测试 计划、测试过程和测试工作与单位内计划和标准的相符程度。TSP测试经理的角 色规范在表3-4中给出。表3-4 TSP测试计经理的角色和职责目的当团队成员全都持续履行了角色职责，遵循了已定义的过程，朝着共同 目标和规范而工作的时候,团队最为高效

50、目标测试经理的目标是：1. 领导团队制订综合测试计划2. 确保系统经过详细测试，可以正确地执行所有重要的功能角色特性对测试经理最有帮助的特征是：1. 爱好理解和掌握事物的内部结构2. 复杂的题目可以引发兴趣3. 喜欢测试产品发现缺陷的挑战性团队成员职责为了帮助客户接口经理完成工作，所有的团队成员都应做到：1. 满足团队成员的承诺2. 遵循严格的个人过程3. 计划、管理和汇报个人工作4. 与团队所有成员一起合作以维护一种高效的生产性工作环境测试计划在需求阶段，测试经理支持客户接口经理来定义接受测试标准，并得 到客户的同意。测试经理还要领导团队：1. 在整个开发过程当中，维持对测试的关注2. 在设

51、计阶段定义和规划系统测试3. 在实现阶段定义和规划集成测试测试支持测试经理支持团队成员：1. 规划和执行所有的测试活动2. 建立单元测试标准3. 报告和评审所有的集成和系统测试缺陷测试分析测试经理要1. 分析每一个测试阶段的数据以识别易于出现缺陷的产品元素2. 对于每一个测试阶段，维护所有产品组件和整个系统的缺陷密度表3. 与质量经理一起工作以寻找需要审查或测试的地方报告测试经理跟踪并每周向团队汇报团队测试计划、开发和执行工作的 状态计划经理负责维护团队的计划、报告计划状态、支持团队解决任何与计划相 关的问题。TSP计划经理的角色规范在表3-5中给出。表3-5 TSP计划经理的角色和职责目的当

52、团队成员全都持续履行了角色职责，遵循了已定义的过程，朝着共同 目标和规范而工作的时候,团队最为高效目标计划经理的目标是：1. 帮助团队运作计划和跟踪得完好的项目2. 帮助团队成员完成个人计划和进度跟踪3. 依据计划定期跟踪和汇报团队的状态角色特性对计划经理最有帮助的特征是：1. 拥有逻辑思维，在工作的时候遵循计划就会感到最舒服2. 虽不是总能制定出计划，但如有机会还是愿意制定计划3. 对过程数据感兴趣，愿意督促人员跟踪和度量他们的工作团队成员职 责为了帮助客户接口经理完成工作，所有的团队成员都应做到：1. 满足团队成员的承诺2. 遵循严格的个人过程3. 计划、管理和汇报个人工作4. 与团队所有

53、成员一起合作以维护一种高效的生产性工作环境领导团队计 划作为计划经理，要1. 确保团队向着一套已定义的归档计划而工作2. 帮助开发人员制定自己的和团队的预测和计划3. 确保在每一次团队启动和重新启动中、项目进度或资源变化巨大 的情况下计划都得到了修订4. 帮助团队一贯的维持平衡的计划跟踪团队进 度计划经理要：1. 跟踪团队的计划进度，每周向团队汇报项目状态2. 支持团队领导者跟踪项目问题和风险3. 为系统及其组成部分维护一套SUMP的更新拷贝4. 更新团队TASK和SCHEDULE模板，确保每名开发人员都更新了个人的 TASK 和 SCHEDULE 模板报告除此之外，计划经理还要：1. 确保团

54、队成员在每周团队会议上及时汇报了进度数据2. 制定一份团队计划状态的组合报告，在每周团队会议上或之前就分 发报告3. 基于日程安排和资源进度，保持团队和管理层获知阶段和项目的可 能完成日期4. 在阶段和项目完成之后，维护数据制定项目报表的进度、资源、规 模和生产率（参见SUMMARY规范和PM脚本）过程经理负责确保团队的过程被合理定义了，并且按照定义的方式使用了。 团队成员提交了过程改进提议（PIP）后，过程经理还要负责处理PIP。TSP过 程经理的角色规范在表3-6中给出。表3-6 TSP过程经理的角色和职责目的当团队成员全都持续履行了角色职责，遵循了已定义的过程，朝着共同 目标和规范而工作

55、的时候,团队最为高效目标过程经理的目标是：1. 确保团队在所有关键活动上都有定义明确的过程2. 帮助团队成员定义和使用过程3. 确保团队过程数据得以及时汇报和分析4. 辅助团队识别和解决过程问题角色特性对过程经理最有帮助的特征是：1. 对过程和过程度量感兴趣2. 了解如何定义、使用、度量和分析过程团队成员职 责为了帮助客户接口经理完成工作，所有的团队成员都应做到：1. 满足团队成员的承诺2. 遵循严格的个人过程3. 计划、管理和汇报个人工作4. 与团队所有成员一起合作以维护一种高效的生产性工作环境过程支持作为过程经理，要1. 确保主要的开发、管理和团队活动中都有定义明确的过程2. 领导团队开发

56、团队需要的过程3. 确保团队成员熟知每套已定义过程，如有需要，培训其使用方法4. 确保团队一贯遵循定义明确的归档过程过程跟踪过程经理要负责保证：1. 所有团队成员都及时汇报了他们的过程数据2. 如果有成员延迟提交了过程数据，要立即得到他们的数据或向团队领导者寻求帮助3. 项目备忘录要完整，及时更新过程分析过程经理要：1. 分析团队的过程数据2. 识别团队或任何团队成员遵循已定义过程中出现的问题3. 辅助团队成员的改进工作过程问题如果有过程问题，过程经理要：1. 警告团队2. 提议行动，解决问题3. 提供必备帮助，以解决问题PIP处理过程经理管理提取、搜集、记录、跟踪和处理团队PIP报告过程经理

57、要：1. 每周向团队报告所有团队过程开发和分析工作的状态2. 当有过程问题需要注意的时候，警告团队和团队领导3.在阶段和项目完成之后，维护数据制定项目报表的进度、资源、规 模和生产率（参见SUMMARY规范和PM脚本）3.5.7质量经理的职责质量经理负责确保团队成员都记录了他们各自的数据、检察这些数据从而帮 助开发人员合理地遵循了过程。虽然团队领导者可以帮助分析团队的数据，激励 开发人员遵循过程，个体开发人员的数据评审还是应该留给质量经理来完成。质 量经理应该每周都评审团队所有的质量数据，警告团队和团队领导者那些质量欠 佳的工作。TSP质量经理的角色规范在表3-7中给出。表3-7 TSP质量经

58、理的角色和职责目的当团队成员全都持续履行了角色职责，遵循了已定义的过程，朝着共同 目标和规范而工作的时候，团队最为高效目标质量经理的目标是：1. 领导团队制定和遵循质量计划2. 提供质量问题的及时分析和报警3. 作为团队的审查调解员高效工作角色特性对质量经理最有帮助的特征是：1. 关心软件质量2. 了解如何度量、分析和改进软件质量3. 有一些经验或了解审查方法4. 愿意并且能够建设性的评审和评价他人的工作，且不与他人为敌团队成员 职责为了帮助客户接口经理完成工作，所有的团队成员都应做到：1. 满足团队成员的承诺2. 遵循严格的个人过程3. 计划、管理和汇报个人工作4. 与团队所有成员一起合作以

59、维护一种高效的生产性工作环境质量支持作为质量经理，要1. 在整个项目过程中维持对产品和过程质量的关注2. 领导团队开发和遵循质量计划审查支持质量经理要：1.确保有一名能够胜任的调解人员，来领导团队审查或充当审查调 解员质量跟踪质量经理要：1. 定时跟踪产品和过程质量度量2. 如果有成员延迟提交了质量数据，要立即得到他们的数据或者向团队领导寻求帮助质量分析质量经理要定期地：1. 更新系统的SUMQ表，每个部分 张报表2. 分析团队质量数据，并确保这些分析可为团队参考所用3. 只要定义过程没有被遵循就警告团队4. 推荐如何解决问题5. 只要有需要特别注意的质量问题，就警告团队和管理层质量经理决定何

60、时何地有质量问题，推荐解决方法。例如：1. 有选择性的重新审查2. 组件重新定制3. 严重情况下，丢弃并重新开发报告质量经理要：1. 每周向团队汇报质量度量和产品质量状态2. 在阶段和项目完成之后，维护数据制定项目报表的缺陷、收益、比 率、进度和组件（参见SUMMARY规范和PM脚本）3.5.8支持经理的职责支持经理负责确保每一名团队成员都拥有合适的工具和支持，都了解如何 正确地使用这些工具。支持经理还要为开发环境制订推荐计划，建立和管理团队 配置管理系统。TSP支持经理的角色规范在表3-8中给出。表3-8 TSP支持经理的角色和职责目的当团队成员全都持续履行了角色职责，遵循了已定义的过程，朝

61、着共同 目标和规范而工作的时候，团队最为高效目标支持经理的目标是：1. 帮助团队使用合时的工具和方法2. 处理团队的配置管理和变更控制功能3. 充当团队的复用倡导者角色特 性对支持经理最有帮助的特征是：1. 对软件支持工具有兴趣并且喜欢使用它们2. 感觉自己可以帮助团队解决支持需求3. 拥有支持工具和系统的经验4. 对于有可能会在当前项目中使用的工具一般都比较了解团队成员职责为了帮助客户接口经理完成工作，所有的团队成员都应做到：1. 满足团队成员的承诺2. 遵循严格的个人过程3. 计划、管理和汇报个人工作4. 与团队所有成员一起合作以维护一种高效的生产性工作环境工具支持支持经理要：1. 确保团

62、队有一套合适的开发支持系统2. 跟踪支持系统的性能和可靠性3. 在本组和其他小组内维持对支持系统开发的关注4. 只要支持系统发生变化，或者提升团队绩效需要改进，就要向管理 层推荐5.领导团队开发或获取特殊支持工具或设备6 .确保团队成员熟知支持工具，需要的时候，对其进行培训配置管理支持经理获得并管理团队的配置管理系统1. 对于所有的受控项目，维护一份保护主拷贝2. 只批准受控版本的变动3. 维护所有受控项目和版本的主拷贝变更控 制支持经理领导配置控制委员会1. 评审受控产品的所有变化2. 评估每项变更的影响和收益3. 向团队推荐需要完成的变更复用支持经理要充当团队复用的倡导者：1. 维护潜在可复用部件的列表2. 提醒团队复用时机报告支持经理要跟踪并每周向团队汇报：1. 所有支持采购和开发工作的状态2. 复用状态和时机3.6如何选择团队角色团队成员必须参与自己的角色选择。为了过程保真度