团队软件过程（Team Software Process：TSP）用于指导工程团队开发软件密集型产品。早期的TSP经验显示，TSP的应用改进了团队的质量和生产率，并有助于软件团队更精确地满足成本与进度。TSP设计作于2至20个成员的团队，更高一级的多团队TSP过程，用于大约150个成员的团队。用于较大项目的TSP版本，在这写作的时候不是可得。
本文描述了TSP，以及其开发过程。从软件质量背景的简要探讨开始，介绍了团队工作的基本要素。描述了TSP、个人软件过程（Personal Software Process：PSP）、能力成熟度模型（CMM）过程改进率先之间的关系。本文也描述了TSP过程的结构、启动一个TSP团队，TSP团队协作过程，及推介TSP的问题和方法。对TSP的发展历程、现状与发展前景作了评介。
一、软件质量
团队软件过程（Team Software Process：TSP）开发遵循了W. Edwards Deming与J.M. Juran提出的质量策略。这一个策略由Michael Fagan在1976拓展到的软件过程。通过在1987年能力成熟度模型（Capability Maturity Model：CMM）、以及1995年个人软件过程（Personal
Software Process：PSP）的引进，得到进一步拓展。
PSP之后，软件过程改进的一个重大举措，是团队软件过程（TSP）。TSP为工程工作提供了训练有素的背景。TSP开发的主要推动因素，是确信：只要恰当地组织、适当地培训、配备熟练的成员、有效地领导，团队能够有非凡的表现。TSP的目标就是建设和指引这样的团队。
二、TSP的开发过程
1996年，Watts Humphrey开发了TSP过程的最初版本。他的目标是提供一个可操作的过程，以帮助工程师统一进行高质量的工作。他以尽可能简单的方式，设计了最初的TSP0过程，在两个团队中试用，然后对其作用结果进行审查。然后确定团队在哪些方面需要进一步的指导，并提供指导以改进过程。第一个TSP0过程，用于除了接受过TSP过程和团队的直接管理提供的培训或指导，只接受过PSP培训的团队。
以最初两个TSP团队的结果为基础，很清楚，TSP能帮助工程师进行训练有素的工作，但需要更多的指导和支持。很显然，管理必须广泛支持TSP过程。改进的TSP0.1过程，被更多的团队使用，为所需的过程细化提供更多信息。
在随后的三年里，Humphrey开发了另外九个TSP版本。最初，他的目标是想看看，一个通用团队过程，是否有助于团队工作。一旦确信TSP能达到这个基本目标，他的开发精力集中在简化过程、减小规模、并提供所需的支持和指导，以使过程达到最高效率的实用。所以，最新的TSP版本，比1996年末1997年初开发的TSP0.1和TSP0.2版本小得多。
随着更多的团体应用TSP过程，几个介绍方法被开发，用来协助工程师和经理进行团队建设，更好地遵循过程，定期对项目进行重新评估和重新计划。也开发了各种原型支持工具，来简化工程师的计划、数据记录、数据分析、和项目报告活动。
1、团队工作
大多数工程项目都需要团队。虽然一些小的硬件或软件产品能由个人开发，现代系统的规模和复杂性，对短期进度要求是如此之多，一个人来做大多数工程工作已是不现实的。系统开发是团队行为，团队的效率很大程序上决定了工程质量。
团队的类型形形色色。在运动中，举例来说，篮球队队员的位置是不断变化的，而棒球队队员的位置相对较固定。然而，在两种情形下队员都必须协同合作。与此相对，摔交与田径队是由不相互联系的单个队员组成的，尽管队员们从群体上、情感上彼此相互支持。
一个团队，不仅仅是一群凑巧一起工作的人。团队精神至关重要，并涉及到特别的技巧。团队需要统一的过程、统一的目标，需要有效的指引和领导。指引和领导这类团队的方法的众所周知，但是不是显而易见的。软件工程研究所(Software Engineering Institute
：SEI)支持TSP作为指导工程师和他们的经理的一种方法，以使用有效的团队工作方法。
2、团队工作的条件
团队是由拥有共同目标一群人所组成。他们必须为此目标全力以赴，并拥有统一的工作框架。以下是对一个团队的定义：
◆一个团队至少由两个人组成；
◆团队成员为共同的目标而工作；
◆每个团队成员都有明确的分工；
◆ 任务的完成，需要团体成员之间的某些形式的依赖关系。
团队定义的四个部份都很重要。举例来说，一个团队的成员得在一个以上，这一点显而易见；团队成员目标一致也毋庸质疑。但是，团队成员为什么一定要有角色分工就不那么显而易见。角色分工提供了一种责任感和归属感，帮助指导团队成员如何开展工作，避免了冲突，重复工作和浪费精力，也为团队成员提供了对工作环境一定程度的控制。这种控制的感觉是有进取心和精力充沛的团队成员的基本需求。
互相依赖也是团队协作的一个重要因素。它意味着每个团队成员某种程度依赖于其他成员的表现。由于团队成员可以互相帮助和支持，这种互相依赖能够改进个体的表现。举例来说，设计组的设计成果，通常比任何单个成员的设计更为出色。这是因为团队成员比任何单个成员都拥有更广泛的技巧和经验，由于全体成员的支持，团队表现会得到进一步的改进。人类是社会性的动物，很少人喜欢完全独自工作。由于团队的社会性，团队成员通常会尽力履行自己对其他团队成员的义务。通过相互支持和互相依赖，团队力量就会大于团队成员简单相加的总和。
3、高效的团队
要成为高效的团队，团队必须具备适当的技能，具备向心力，进行运作。高效的团队有以下共同的特征：
◆团队成员具备技能；
◆团队的目标很重要、明确、可见、现实；
◆团队的资源充足；
◆团队成员积极进取，为实现团队的目标而努力；
◆团队成员彼此合作和支持；
◆ 团队成员在工作中训练有素。
高效团队的另外一个特征，是创新能力。创新不仅仅是想出聪明的点子，还需要创造力和许多坚苦的工作。差不多每一项工程任务，都是创新努力的一部份。创新团队一定要有高度进取的能工巧匠，他们具备创造力、灵活、训练有素，能够随机应变，控制成本和进度，使管理层始终对项目进展了如指掌。
要做到创新和高效，团队必须在相互信任和支持的环境下工作。团队由极有能力的人组成，这些人对缺乏信赖很敏感。当经理不信任团队雄心勃勃的进度，或团队努力实现这些进度，工程师们将会明了这一点。当工程师感觉到不受信任和尊重，他们常常会觉得受敌视、被操纵。这些工程师不再会对组织忠诚，并会丧失对团队的承诺。
因为在面对重要和有意义的挑战时，人们通常会更努力地工作，对管理层来说，用雄心勃勃的目标来激励团队再合适不达。但当团队对挑战提出一个方案，管理层一定要乐于就工程师们认为能够实现的实际承诺进行商议。很少人会为实现一个看来毫无希望的进度而努力地工作。为了高效运作，团队一定要确信其计划很重要而且进度是能实现的。
4、打造高效团队
TSP用来建立标志着高效团队的条件。建立这些条件的TSP团队建设原则如下：
◆团队成员建立共同的目标，并分工明确；
◆团队形成一致的策略；
◆团队成员定义一致的工作流程；
◆所有的团队成员参与制定计划，而且每个成员都明确其在计划中的角色；
◆团队与管理层就计划进行协商；
◆管理层审查并接受经商议的计划；
◆团队成员按即定计划开展工作；
◆团队成员能够自由地、经常沟通。
◆团队具有向心力：团队成员相互合作，都为共同的目标而努力；
◆团队成员了解各自的职责，取得工作中的回报，并且有领导层支持。
高效团队的形成，需要团队成员真正明了其职责、如何工作，并相信计划是可行的。所有这些条件可通过团队成员制定自己的计划来建立。之后，假定这些计划都已完全制定，团队的计划几乎总能符合管理层的要求。
虽然所有这些条件对高效的团队工作是必需的，建立这些条件的特定方法却不是显而易见的。TSP提供了组织建立高效的工程团队的明确指引。
三、可运作的团队过程
要训练有素地工作，工程师需要Deming所称的"操作过程"。这些过程精确定义了工作如何进行的过程。糟糕的的软件过程是过程定义书籍中庞大而复杂文字描述，而可行的过程是更象手写体。由团队成员实际工作中应用。
TSP提供明确的可行过程，通过团队建设的步骤来指导工程师和经理。这一过程明确了建立高效团队环境的步骤。没有明确的指引，工程师不得不自己定义团队建设、团队工作的细节。由于定义这些细节涉及到高超的技巧和精力，并且由于很少工程师有经验或时间定义全部的必要细节，工程团队通常遵循特定的团队建设和团队工作过程。这浪费了时间，并且通常产生糟糕的团队。
有了定义的过程，以及遵循过程的计划，工程师的效率可大大提高。如果没有这样一个过程，在每一步都得停下来，决定下一步做什么、怎么做。大多数工程过程相当复杂，并且包括许多步骤。没有明确的指引，工程师可能会跳过一些步骤、以低效的步骤进行工作，或者浪费时间决定下一小做什么。TSP提供了可行的建设团队所需要的过程，以建立高效的团队环境，并指导团队工作。
如图1所示，TSP是过程改进方法系列之一，有助于工程团队进行高效开发，以及支持软件密集系统的开发。能力成熟度模型(Capability Maturity Model：CMM)提供了高效工程团队的需的总体改进框架。个人软件过程(Personal Software Process：PSP)提供了工程师所需的工程训练，以统一使用的已定义的过程、计划及度量过程。TSP将集成产品团队的原则与PSP和CMM方法相结合了，来打造高效团队。从根本上来说，CMM和PSP为高效团队提供了背景和技巧，而TSP则指导工程师的实际工作。因此，TSP 利用PSP与CMM所提供的准备，并对如何进行工作提供了明确的指引。
图1：过程改进方法
四、TSP的结构
图2显示了TSP过程的主要要素。在成员加入TSP团队之前，一定得知道如何做训练有素地工作。如图所示，个人软件过程(PSP)中的培训要求向工程师提供应用TSP的的知识和技能。PSP培训包括如何制定详细的计划、收集与使用过程数据、制定挣值计划、应用挣值去追踪计划、度量和管理产品质量、定义和使用运作过程。工程师在参与TSP 团队建设，或遵循已定义的TSP过程之前，必须接受这些技能培训。
图2：TSP团队建设
有许多团队建设的方法，这些方法都要求个体协同工作以完成某些坚巨的任务。在TSP中，团队建设这一坚巨的任务是一个四阶段的计划过程：团队启动。在启动过程中，所有的团队成员参与建立项目的策略、过程、以及计划。启动完成之后，团队遵循所定义的过程开展工作。
如图3所示，TSP团队定期再启动。因为TSP过程遵循迭代和演化的发展策略，周期性的再启动是必需的，以使每个阶段或周期，能够以前一阶段的经验为基础进行计划。再启动也要求更新工程师的详细计划，这些计划通常只在几个月内是精确的。再启动的原因是详细的计划只可能在几个月内精确。在TSP启动中，团队制定今后三到四个月内的总体计划和详细计划。在团队成员完成下一项目阶段或周期的全部或大部分任务之后，必要时修订总体计划，并制定此后三到四个月新的详细计划。TSP再启动过程对此进行指导。
图3：TSP过程
五、启动TSP团队
一旦团队成员经过适当培训，并组建了团队，整个团队就开始参与TSP团队的启动（启动过程见图4）。启动过程通过详细的文本描述，用于指导团队。通过遵循启动过程，团队制定详细的计划。为建设一具有内聚力、高效的工作单元，所有的团队成员必须遵循计划。为强化这一义务，TSP 要求所有的团队成员参与计划的制定。由此，通过完成TSP启动过程，所有的团队成员都参与了计划制定，并达成一致，遵循共同制定的的计划。
图4.TSP启动过程
团队通常需要专业的指导来正确完成启动过程。这一指导可由经过培训的启动教练在启动过程中提供，TSP文本也提供了足够的指引。每个团队都有其独特的问题和议题，因此，一个简单的过程，不可能提供启动过程中指导一支毫无经验的团队的所有必须的材料。除非团队经验丰富，并有已经完成过一些TSP项目的团队领导，否则通常需要经过培训的教练支持。
六、TSP团队过程
一旦TSP团队启动，主要的任务是确保所有的团队成员遵循计划，包括以下方面：
◆领导团队
◆过程训练
◆问题跟踪
◆沟通
◆管理汇报
◆维护计划
◆估计项目完状况
◆团队工作量重新权衡
◆项目再启动
◆TSP质量管理
七、TSP的推介
TSP在工业界与学术界都进行了推介。在大学开设了TSP课程。在学习TSP课程前，学生必须学习过PSP课程。TSP课程的结果显示对学生和相关系、科都很有帮助。
SEI主要关注于向工程组织引进TSP。TSP是为工程团队设计的，最初针对对象是开发软件密集型产品的团队。为支持除软件领域之外的工业界团队，SEI为非软件界的PSP课程，并引进了一系列培训和认证程序，使组织能够获得自己的PSP讲师。此外，SEI提供TSP指导培训，使组织能够启动和指导自己的TSP团队。SEI也与许多合格的PSP和TSP培训与指导伙伴建立了联系。
八、TSP现状与前景
最初开发TSP的原因，是为受过PSP培训的工程师提供环境，在此环境下能对所学的方法运用自如。在工程师统一使用方法上，PSP培训本身并不足够。对此有几个原因。首先，没有培训，经理通常不明白PSP方法或欣赏其益处之所在。他们常常反对工程师们花时间作计划、进行个人审查、或收集和分析数据。其次，即使有支持和指导，培训工作也不容易。而没有这种帮助，长期的可持续培训工作几乎不可能。TSP设计的最初动机就是要解决这些问题。
1、培训与支持
由软件工程研究所(SEI) 向团队领导和TSP讲师提供TSP培训。PSP培训课程涵盖了工程师所需的主要培训。
工具支持对TSP也是非常重要的。SEI已经开发了一个原型工具，可为团队所用。SEI也开发了一个工具说明，用于指导商业领域开发支持TSP过程的工具。没有合适的工具支持，即使是相对较小的项目所产生的数据，都是难以管理的（更多SEI资料和支持信息可见http://www.sei.cmu.edu/tsp)。
2、未来趋势
由于TSP的初衷大部分都已经实现，TSP当前和下一步即要开展的开发努力，是将基本的TSP过程转变为通用的工业界应用，以及增加教授这些方法的学术机构。工业界主要关注于改进培训和入门方法，以便工程师能够更切实遵守过程，并鼓励商业性的TSP支持工具和环境的开发。将来的行动包括将TSP过程扩展到各种不同类型的团队和较大的团队。从长远来看，扩展到大型团队是必要的。学术方面主要包括大学相关系科与成果出版。
由于团队工作情形的迥然不同，需要一系列的TSP过程。基本TSP用于2至20个成员的团队，但它对3至12个人团队最有效。多重TSP过程（即TSPm），用于大约100到150个工程师的团队。除此之外，一些TSP扩展用于成员分布在不同地点的团队、以及在多个地点有多个团队的大项目。同样地，用于测试或维护团队的功能团队过程也是必要的。最后，应用于拥有成百上千个团队成员，开展巨型项目的真正的大团队的TSP扩展过程也是必不可少的。这一过程序也必须是跨越组织和技术的。
随着团队扩大，PSP、TSP和CMM之间的关系将会变得更为重要。对于巨型团队，团队过程与组织过程的区别不复存在。此时，组织的CMM活动必须与团队过程合为一体。对于较小的TSP和TSPm团队，团队过程和组织过程必须相关联。更密切结合这些过程改进策略的工作是必要的，并向CMM与TSP团体显示这两个框架如何互为补充并相互支持。
最后，附带总体业务过程的组织过程的关系必须进行定义。将产品相关的团队与业务过程相关联，需要组织范围的一些基本变化。但是，一旦这些过程完全相关联，TSP团队的的能力：如应用其成员的技能、精确地进行计划、报告成员的工作，将会大大改进工程组织的总体绩效。
-完-
没有评论:
发表评论