《团队软件过程(修订版)》—第1章1.1节TSPi是什么

简介: TSPi是一个为研究生或高年级本科生的团队软件工程课程而设计的框架。它很好地平衡了过程、产品和团队协作等几方面的培养要求,并且在计划和管理软件项目方面,它有效利用了业界的实践经验。

本节书摘来自异步社区《团队软件过程(修订版)》一书中的第1章1.节,作者【美】 Watts S. Humphrey(沃茨?S. 汉弗莱),更多章节内容可以访问云栖社区“异步社区”公众号查看。

第一部分 绪论
团队软件过程(修订版)
本书第一部分介绍了小组软件过程导论(TSPi),简要说明了为何需要TSPi,以及TSPi是如何工作的。第1章说明了从TSPi课程中获得什么益处,阐述了TSPi设计结构背后的原则。第2章介绍了什么是团队,以及如何使团队工作。第2章的材料还包括一个有关团队协作问题的讨论,并解释了为何TSPi能够帮助处理这些问题。第2章还简要介绍了如何处理团队和团队协作中与人相关的问题,对于此类主题的深入探讨我们将在第四部分的章节中给出。

第1章 TSPi简介
团队软件过程(修订版)
大多数商业软件都是由团队开发的,因此,要想成为一个优秀的软件工程师,你就必须有在团队中工作的能力。如果你有与人合作的意识并且愿意付诸实践,你就具备了成为一个优秀的团队成员的基本素质。但是,团队协作的涵义远比融洽相处要丰富。团队必须计划项目、跟踪进展、协调工作,还必须有一致的工作目标,共同的工作过程,并且经常自由沟通。

要想满足挑战性的进度要求并且开发出高质量的产品,熟练的团队协作是基本要求。但是,熟练的团队协作需要大量的实践经验以及专业技能和方法。本书及相应课程全面介绍了团队软件开发,基本思路是让你接触真实的团队协作问题,并给你实用的团队协作经验。基于从本课程中获得的经验,你将具备参与大型商业软件项目的基础。

本章介绍了团队软件过程导论(TSPi),阐述了TSPi设计背后的原则以及TSPi过程的整体结构和流程。另外,本章还解释了为何需要TSPi,讨论了TSPi课程将带给你的收获。

1.1 TSPi是什么
团队软件过程(修订版)
TSPi是一个为研究生或高年级本科生的团队软件工程课程而设计的框架。它很好地平衡了过程、产品和团队协作等几方面的培养要求,并且在计划和管理软件项目方面,它有效利用了业界的实践经验。TSPi指导学生一步一步地完成团队软件项目课程,并且教会你如何在团队协作环境中应用成熟的软件工程和软件过程原则。在学习过个体软件过程(PSP)之后,TSPi将教会你如何计划和管理团队项目。TSPi还为团队成员定义了角色。当团队中的每个人都担任职责明确的角色时,就知道在过程的每一步该做什么了。遵循TSPi过程,大家将获得成熟的工程方法和团队协作方法的实践经验。

TSPi是基于团队软件过程(TSP)设计的,TSP是一个为多达20人的团队开发或者升级大型软件密集系统而设计的工业过程。由于TSP是为通常需要几年时间才能完成的大型项目设计的,因此,与你现在的课程学习需要相比,它更加庞大,也更加复杂。这样一来,TSPi实际上是TSP的简化版本。但是,TSPi仍然保留了TSP最基本的概念和方法。用过TSPi之后,你会感到TSP很熟悉,也很容易上手。

工程小组为何需要过程
单纯把一项工作任务交给一群工程师并不能自动产生一个团队。建设团队的步骤并不显而易见,新的团队经常要花费大量时间去建立团队的运行机制。他们必须明确如何作为一个团队一起工作,如何定义要做的工作,以及如何设计工作方案。他们必须在团队成员间分配任务、协调任务,并且跟踪和汇报工作进展。虽然这些团队建设工作很重要,但是并不难,而且已有很多完成这些工作的方法,你和你的团队成员并不需要自己去重新发明这些方法。

团队不是偶然产生的,优秀的团队表现也不是偶然。尽管熟练的成员和明确定义的过程很重要,我们仍要明白,团队远不止是一群天才的简单集合。为了建立和维持高效的工作关系,你们需要共同的目标、全体一致同意的行动计划以及适当的领导关系。你们还必须知道每个人的长处和短处,支持团队成员,并且乐于在需要的时候求助于人。

TSPi还会帮你提高工作效率。虽然早期的计划和团队建设工作看起来会耗费大量时间,但是,这些工作却是团队项目的基本组成部分。这有点像足球比赛的临场战术安排:有经验的球队首先要对战术和每个球员的角色达成一致。如果一支球队不能做出有效的临场战术安排,他们将疲于奔命,而不会赢得多少比赛。

本文仅用于学习和交流目的,不代表异步社区观点。非商业转载请注明作译者、出处,并保留本文的原始链接。

相关文章
|
12月前
|
运维 NoSQL 关系型数据库
带团队后的日常思考(十)
带团队后的日常思考(十)
|
存储 数据采集 SQL
为什么你成为不了团队核心成员
为什么你成为不了团队核心成员
93 0
|
SQL 小程序 测试技术
带团队后的日常思考(七)
  最近被插入了一个需求,我们组经常会被插入各式各样的需求,因为之前负责的范围非常广。   这次的需求就和一个陈年接口有关,其实要修改的地方并不多,就是为一个请求多加一个参数。   但是比较麻烦的地方就是验证阶段,就是我在加上这个字段后,我得知道发请求的时候真的带上了。   根据URL地址反查到了页面代码,在本地启动项目,访问页面,直接报错。   调试陈年项目,这种情况是经常发生的,涉及的问题很多,例如内部接口不通了,数据库表结构变了,需要的数据记录本地没有等等。
|
缓存 前端开发 JavaScript
带团队后的日常思考(六)
  当前我们组管理着一套审核系统,除了数据源是服务端提供的,其余后台管理都是由我们组在维护。   这个系统就是将APP中的各类社交信息送到后台,然后有专门的审核人员来判断信息是否合规,当然在送到后台之前已经让机器审核了一遍。
|
移动开发 自然语言处理 前端开发
带团队后的日常思考(五)
  他们组没有一个正式的组长,只有一个临时的代理组长,这种情况从我进公司到现在一直是这种情况,也是蛮奇怪的。   前几天,这个代理组长和其中的一个组员爆发了点冲突,我从旁观者对他们对话的理解就是,组员觉得他瞎指挥,他觉得组员无担当。
|
监控 NoSQL 前端开发
带团队后的日常思考(三)
  参与制订业务方的BUG规范,业务方最近投诉我们技术部,在飞书群中提出BUG后,技术部没有人响应,认为我们的态度太冷漠。   后面我就提出任何看到的人,只要知道是谁负责的,就@那个人,大家都不要客气,这是第一步。
带团队后的日常思考(三)
|
缓存 运维 前端开发
带团队后的日常思考(八)
  最近有个活动,在提测后的第二天,大家才得知上线时间是后天。但是问各个技术,大家都不知道这个时间,而产品是知道的,运营也知道这个时间。   那这就有点诡异了,为何会出现这个情况呢,进一步了解后,才发现原来在一次会议上,口头说了下上线时间和提测时间。   在那次会议上,大家都说了自己的开发时间,但是,对于提测时间,开发和运营却有不同理解。我的提测时间是11或12,但运营的提测时间是10号,以后对于这种时间截点还是要更敏感一点。   UI给到我们设计稿的时间,晚了一天,其实如果不晚的话,即使我们不知道上线时间,也会按预期进行。