| 商家名称 |
信用等级 |
购买信息 |
订购本书 |
|
|
 |
TSP培训开发团队 |
 |
|
|
TSP培训开发团队 |
|
基本信息·出版社：人民邮电出版社
·页码：270 页
·出版日期：2008年01月
·ISBN：7115169934
·条形码：9787115169938
·版本：第1版
·装帧：平装
·开本：16
·正文语种：中文
·丛书名：图灵计算机科学丛书
·外文书名：TSP—Coaching Development Teams
内容简介 TSP是Humphrey在SEI开发的一种软件团队开发过程，在针对个人的PSP与针对企业的CMMI之间架设了桥梁。其效果已经经过大量成功项目的验证。
《TSP培训开发团队》系统讲述了持续激励团队并引导团队走向成功的各种实用方法，内容包括团队的组建、启动、培训和维护等。
无论是对正在考虑使用TSP的开发人员还是正在实施TSP的开发人员，《TSP培训开发团队》都提供了极具价值的案例、准则和建议。《TSP培训开发团队》适用于软件开发项目经理及希望成为项目负责人的开发人员，也可作为高等院校软件工程课程的参考教材。
目录 第一部分团队形成
第1章开发团队
1.1TSP概述
1.2为什么需要团队
1.3什么是团队
1.4团队的类型
1.4.1开发团队
1.4.2团队规模
1.4.3小型、大型和超大型团队
1.5自主型团队的本质
1.5.1成员感和归属感
1.5.2对共同目标的承诺
1.5.3过程和计划的自主权
1.5.4技能和纪律
1.5.5正直、诚实和谦恭的行为
1.5.6追求卓越
1.6团队领导和培训师角色
1.7培训工作量
1.8小结
参考文献
第2章团队行为
2.1团队生命周期
2.1.1形成阶段
2.1.2风暴阶段
2.1.3规范阶段
2.1.4执行阶段
2.1.5培训建议
2.2小组类型
2.2.1工作小组
2.2.2过程小组
2.2.3战斗小组
2.2.4培训建议
2.3团队风格
2.3.1开放小组
2.3.2随机小组
2.3.3封闭小组
2.3.4同步小组
2.4团队失败的原因
2.4.1资源不足
2.4.2领导能力问题
2.4.3不可能实现的目标
2.4.4士气问题
2.4.5培训建议
2.5小结
参考文献
第3章培训工作
3.1培训原则
3.2启动TSP团队
3.3培训团队成员
3.4培训经验丰富的团队
3.4.1使用已定义的过程
3.4.2建立基准
3.5培训团队领导
3.5.1新人
3.5.2培训新人
3.5.3设计师
3.5.4培训设计师
3.5.5懦弱的人
3.5.6培训懦弱的人员
3.5.7独断专行的人
3.5.8培训独断专行的人
3.5.9顽固分子
3.5.10培训顽固分子
3.6培训管理层
3.7小结
参考文献
第4章组建团队
4.1团队成功的原因
4.2团队组建方法
4.2.1团队组建演习
4.2.2团队组建演习中的问题
4.3TSP团队组建策略
4.4启动过程如何组建团队
4.5置身其中
4.5.1提问，不要叙述
4.5.2沉默不语
4.5.3频繁检查约定
4.5.4感受无言的顾虑或分歧
4.5.5不要让任何人垄断讨论
4.5.6管理专家
4.5.7培训团队领导
4.5.8关注事实和数据
4.5.9不允许观察者出现
4.6小结
第二部分启动TSP团队
第5章启动准备
5.1启动项目时间
5.2团队范围
5.2.1承诺
5.2.2分配时机
5.2.3整合相关功能
5.2.4经验
5.3团队成员选择
5.4与准备相关的论题
5.4.1计划
5.4.2项目报告
5.5共同的准备问题
5.6启动准备步骤
5.7启动准备状态每周例会
5.8小结
参考文献
第6章团队章程
6.1制定团队章程
6.2首次管理层会议
6.3以积极的态度启动
6.4问题和考虑事项
6.4.1缺少主管
6.4.2缺席会议
6.4.3人员未接受过培训
6.5小结
第7章团队目标
7.1目标是什么
7.1.1为什么说目标很重要
7.1.2团队为什么需要目标
7.2反馈的重要性
7.3目标优先权
7.4可以度量的目标
7.5目标度量的类型
7.5.1具体目标
7.5.2判断目标
7.5.3观点
7.6度量的问题
7.7目标的类型
7.7.1陈述性目标
7.7.2强制目标
7.7.3隐含目标
7.7.4内部目标
7.8TSP目标设定过程
7.8.1会议概述
7.8.2回顾管理层的陈述性目标
7.8.3隐含目标
7.8.4团队目标
7.9目标跟踪
7.10目标度量示例
7.11小结
参考文献
第8章团队成员角色
8.1何为角色
8.2为什么需要角色
8.2.1满足人类需求
8.2.2处理迫切的团队任务
8.2.3加速团队组建过程
8.3选择团队角色
8.4TSP角色
8.4.1客户接口经理的职责
8.4.2设计经理的职责
8.4.3实现经理的职责
8.4.4测试经理的职责
8.4.5计划经理的职责
8.4.6过程经理的职责
8.4.7质量经理的职责
8.4.8支持经理的职责
8.5其他团队成员角色
8.6角色和团队规模
8.7培训角色管理者
8.8角色管理者的承诺
8.9小结
参考文献
第9章团队计划
9.1TSP计划过程
9.2第3次启动会议
9.3产品的概念设计
9.3.1细节太多
9.3.2细节不充分
9.4团队策略
9.4.1粗略的规模估算
9.4.2选择开发策略
9.5待生产的产品
9.6开发过程
9.6.1组建单位自己的过程
9.6.2过程定义示例
9.6.3过程一致性
9.7过程和支持计划
9.8CCB成员资格
9.9启动会议文档
9.10小结
参考文献
第10章整体计划
10.1第4次启动会议
10.2规模估算
10.3确定项目任务
10.4整体资源估算
10.5资源可用性
10.6生成和评估整体计划
10.7最优人员配置
10.8小结
参考文献
第11章质量计划
11.1质量的重要性
11.2质量目标
11.3缺陷的成本
11.3.1Teradyne公司的经验
11.3.2测试所需要的时间
11.3.3维护成本
11.4度量软件的质量
11.5无缺陷比率
11.6制订质量计划
11.6.1估算注入的缺陷
11.6.2估算清除的缺陷
11.6.3制订质量计划
11.7小结
参考文献
第12章详细计划
12.1团队计划要有多长远
12.2计划会有多详细
12.3计划怎样提高效率
12.4现在制订计划，还是以后制订
12.5均衡计划的需求
12.6TSP详细计划过程
12.7小结
参考文献
第13章管理风险
13.1什么是风险
13.2风险管理的重要性
13.3风险管理的原则
13.4TSP风险管理过程
13.5风险识别
13.6风险评估
13.7风险评估过程
13.8分配风险
13.9风险缓解
13.10风险管理示例
13.10.1人员影响
13.10.2电力故障
13.10.3后期变更
13.11风险跟踪和管理
13.12小结
参考文献
第14章管理层会议
14.1准备管理层会议
14.2递交项目计划
14.3候选计划
14.4风险
14.5结束会议
14.6提交建议
14.6.1没有任何值得惊讶的事
14.6.2提醒管理层要记得公开操作项
14.6.3快速转移话题
14.6.4使用平实的语言
14.6.5态度要明确
14.6.6管理层接受计划就停止
14.6.7确保团队了解管理层的需要
14.6.8大量备份
14.7小结
第15章启动后总结分析
15.1总结分析的态度
15.1.1总会有地方需要改进
15.1.2许多细微的变更
15.1.3用户拥有最好的改进思想
15.1.4让每个人都参与其中
15.1.5识别出所有的问题
15.1.6个性不能太强，不要有防备心理
15.1.7把人员问题变成过程问题
15.2总结分析过程
15.2.1会议介绍
15.2.2评审启动数据
15.2.3准备PIP
15.2.4启动评价
15.2.5启动会议文档
15.3总结分析培训策略
15.4小结
第16章重新启动团队项目
16.1何为重新启动
16.2为何要重新启动
16.2.1有限计划期
16.2.2完成周期
16.2.3项目变更
16.2.4团队变更
16.3何时重新启动
16.3.1重新启动会花费时间
16.3.2小变动
16.3.3“分析麻痹”
16.4如何重新启动
16.5重新启动过程
16.6修订质量计划
16.7重新制订质量计划的示例
16.8结束重新启动
16.9小结
参考文献
第三部分TSP项目培训
第17章启动后培训
17.1启动新团队
17.2培训过程
17.3启动后短会
17.4团队每周例会
17.5每日例会
17.6每周状态报告
17.7培训审查
17.8培训个体
17.9培训角色管理者
17.10培训团队领导
17.11项目备忘录
17.12团队成员备忘录
17.13检查点评审
17.14培训计划
17.15小结
参考文献
第18章维护计划
18.1计划类型
18.1.1基线计划
18.1.2团队计划
18.1.3详细计划
18.1.4整体计划
18.1.5质量计划
18.2计划动力学
18.3维护团队的计划
18.4工作量失衡示例
18.5面对现实
18.6何时更新计划
18.7更新个体计划
18.7.1每周任务时数
18.7.2任务生产率
18.7.3未计划任务的频率
18.7.4处理未计划的任务
18.8动态负载平衡
18.9诠释计划数据
18.10管理层报告
18.11小结
参考文献
第19章管理质量
19.1质量管理的原则
19.2为什么要管理质量
19.3质量之旅
19.4开发人员的质量职责
19.5团队的质量职责
19.6质量管理方法
19.6.1计划评审
19.6.2设计方法
19.6.3设计评审方法
19.6.4审查预评审
19.6.5捕获－重新捕获缺陷估算
19.6.6预测收益
19.6.7质量简档和质量标准
19.6.8测试数据分析
19.7诠释质量数据
19.8报告质量数据
19.9缺陷报告事项
19.10小结
参考文献
第20章项目总结分析
20.1总结分析的目的
20.2期望数据
20.2.1预测准确性
20.2.2质量绩效
20.2.3过程改进
20.3总结分析准备
20.4总结分析过程
20.4.1基线评价
20.4.2计划评价
20.4.3质量绩效
20.4.4计划数据
20.4.5过程评价
20.4.6利益相关者调查
20.4.7目标评价
20.4.8最终报告准备
20.5团队协作评估
20.6培训和领导力评估
20.7培训总结分析
20.8团队成员总结分析
20.9小结
参考文献
第四部分TSP扩展
第21章团队差异
21.1工作观点
21.1.1互相依赖
21.1.2特殊化
21.1.3规模
21.2团队结构
21.3团队沟通
21.4职能型团队
21.5分布式团队
21.5.1与团队成员的沟通
21.5.2团队成员之间的沟通
21.5.3支持
21.5.4指导、评价和培训
21.6多重团队
21.6.1结构问题
21.6.2人员配备问题
21.7系统级别的团队
21.8培训准则
21.9小结
参考文献
第22章职能型团队
22.1为什么需要职能型团队
22.2职能型团队策略
22.3为职能型团队启动做准备
21.3.1团队培训
21.3.2工作识别和分配
21.3.3概念设计
21.3.4数据准备
22.4树立目标
22.4.1多重目标
22.4.2模糊或人为的目标
22.4.3客户优先级
22.4.4目标定义
22.5启动职能型团队
22.5.1第1次启动会议
22.5.2第2次启动会议-目标
22.5.3第2次启动会议-角色
22.5.4第3次启动会议
22.5.5第4次启动会议
22.5.6第5次启动会议
22.5.7第6次启动会议
22.5.8第7次启动会议
22.5.9第8次启动会议
22.5.10第9次启动会议和PM
22.6培训职能型团队启动
22.6.1团队整合
22.6.2团队成员培训
22.6.3启动会议进度安排
22.7培训职能型团队
22.7.1职能型团队的跟踪
22.7.2职能型团队的状态报告
22.7.3职能型团队的任务优先级
22.7.4职能型团队的每周例会
22.8小结
参考文献
第23章多重团队
23.1什么是多团队
23.2TSP多团队策略
23.3形成多团队
23.4TSPm启动准备过程
23.5启动多团队
23.6培训多团队启动
23.7启动分布式多团队
23.8培训多团队
23.9多团队跟踪和报告
23.10小结
参考文献
第24章集成开发团队
24.1大规模团队的过程原则
24.1.1在各个层次上使用可靠的工程方法
24.1.2管理每日工作量的变更
24.1.3定义标准的报告度量
24.1.4鼓励团队级的决策制订
24.1.5强制实施架构纪律
24.1.6管理系统的突现特性
24.1.7实施量化质量管理
24.2项目启动团队
24.3项目管理的问题
24.3.1管理职责
24.3.2矩阵管理
24.3.3制订项目决策
24.3.4项目沟通
24.4项目启动和培训策略
24.5角色管理者团队
24.6项目监控和报告
24.7小结
参考文献
第五部分维护TSP团队
第25章发展团队合作
25.1团队成员沟通
25.1.1广播和通知
25.1.2劝说
25.1.3协商
25.1.4倾听
25.1.5调节
25.2原则协商
25.3TSP沟通策略
25.4维持团队沟通
25.4.1分享公共的工作空间
25.4.2频繁召开团队例会
25.4.3关注于事实和数据
25.4.4把所有事情都拿出来讨论
25.5过程纪律
25.5.1纪律的重要性
25.5.2建立过程的纪律
25.5.3维持过程纪律
25.5.4团队的纪律职责
25.6小结
参考文献
第26章培训道德
26.1培训师的职责
26.2培训承诺
26.2.1棘手的管理层
26.2.2处理管理层的问题
26.2.3棘手的团队领导
26.2.4棘手的团队成员
26.2.5毫无希望的项目
26.3处理团队和个体数据
26.3.1数据收集的成本
26.3.2管理层评审数据
26.3.3团队成员的个人数据
26.4人员度量
26.4.1正确地使用数据
26.4.2数据误用
26.4.3度量限制
26.5与管理层相关的事务
26.6处理棘手的团队成员
26.7小结
参考文献
第27章培训团队
27.1单位内的培训
27.2为什么要使用培训团队
27.3组建培训团队
27.4启动培训团队
27.4.1资源承诺
27.4.2备选计划
27.4.3最小进度
27.5管理和跟踪培训团队
27.6对培训团队进行培训
27.7参加培训团队
27.8小结
第28章成为团队培训师
28.1培养理解和动机
28.2组建培训团队
28.3成功是无形的
28.4向管理层报告
28.5自我培训
28.6小结
索引
……
序言 大多数开发项目都需要团队协作。虽然个人也能处理一些小型任务，但现代系统的规模庞大，而且都需要在短期内交付，一个人根本无法完成全部的工作。开发工作是一项团队活动，团队协作的效率在很大程度上决定了团队工作的质量。反过来，团队工作的质量也影响着整个项目的成功与否。
团队并不仅仅是碰巧凑在一起工作的一群人。团队协作需要有实践配合，需要特殊的技能。团队要有协作的过程、一致的目标以及高效的领导。为了提高效率，团队成员必须接受培训。开发团队需要有与其他类型的团队同样多的指导和支持。为了满足这种需求，美国卡内基-梅隆大学的软件工程研究所（SEI）开发了一套框架和过程，用于组建和指导开发团队，我们称其为团队软件过程（TSP）①。
虽然本书书名中说的是开发团队，但书中的内容比书名所蕴含的要广泛得多。除了几个例子和一些对质量管理方面的讨论之外，书中所有的内容都可以应用于几乎所有类型的专业团队。例如，测试团队可以使用TSP过程来完成需求方面的工作，高层管理小组可以用TSP过程来运营业务和指导过程改进。
在描述不同培训场景的过程时，书中采用了很多例子。虽然例子中没有提到任何具体组织和个人的名字，但这些例子全都是以真实的TSP团队的实践场景为基础的。这些案例来自曾经与SEI合作过的数百支团队。在合作过程中，他们研究、开发并将TSP方法应用到业界的实践中。希望更多的人在获得这类培训开发团队的经验之后，把自己的经验和体会发表出来，以便创建一个参考文献库，同时也能拓展开发团队的培训领域。
本书面向的读者
本书适用于各种不同类型的读者。对于高级经理和主管来说，第一部分的4章内容简洁而完整地概述了现代系统开发团队所涉及的问题。考虑使用TSP改进开发组织的管理人员应该阅读第二部分和第三部分的内容。希望成为TSP培训师的读者应该阅读整本书。本书解决了在组织和构建开发团队，激励和引导这些团队以及帮助团队领导者和团队成员完成卓越工作等过程中将会面临的许多问题。
虽然本书主要关注的是TSP团队，但阅读本书并不需要具备TSP和个体软件过程（PSP）的知识。书中所描述的方法简单易学，任何没有学过过程和方法的人都能理解。但是，要想最大限度地利用好这些方法，最好首先学习PSP，并使用整套TSP过程指导开发工作。PSP和TSP的其他信息可以在SEI的网站（www.sei.cmu.edu/tsp）上找到。
书中能学到的知识
在开发现代复杂系统的过程中，任何一个错误都会产生严重的后果，因此，开发团队中的每名成员都要完成高质量的工作。只有通过有效的培训和领导，才能使大家一致地完成高质量的工作。本书描述了如何识别高质量的工作，如何引导团队一致地完成这样的工作，还讨论了团队工作不符合预期要求时如何识别以及如何激励开发人员改进工作。
团队培训师监控团队的绩效并辅助团队成员做出改进。本书也向培训师展示了如何齐心协力地支持团队领导，以及如何与领导一起工作来构建、引导和激励整个团队。
本书的内容
虽然从总体上来讲团队协作有许多值得讨论的地方，但本书关注的只是培训在指导开发团队过程中的作用。本书分为5个部分。
第一部分团队形成
第一部分共4章提供了整本书的背景知识和上下文环境。这一部分主要讨论开发团队、团队行为、培训原则和方法以及团队组建等内容。第4章里的示例LAU脚本阐述了TSP过程的概念和方法。但是，与所有实用的过程一样，随着我们对团队了解得更多以及通过演化TSP过程来充分地利用这些知识，TSP过程也在不断变化。因此，如果要用到TSP脚本一定要找到最新的副本。访问SEI或它的合作伙伴的网站（www.sei.cmu.edu/tsp/）可以查看有关获得这些脚本的信息。
第二部分 启动TSP团队
第二部分描述了如何组建高效、高生产率和自主型的开发团队。这样的团队特别适合完成创造性的开发工作。该部分共12章，概述了TSP启动过程，并对在执行卓有成效的团队启动过程中如何培训和支持团队及团队领导提出了建议。
第三部分 TSP项目培训
第三部分关注的是指导团队解决开发工作中面临的一些常见问题。这部分共4章，描述了在TSP启动之后，如何对团队进行培训，团队如何维护计划、管理质量以及处理项目终止后的事情。
第四部分 TSP扩展
团队有很多种类型，改变TSP过程以适应特定的项目和团队非常重要。第四部分共4章，其中讨论了团队类型和团队规模，并解释了如何改变TSP以满足它们。职能型团队一般都要支持如产品维护和系统测试等职能活动。这类团队中的开发人员一般都是独立工作，或者在两三个人组成的小组中工作。在大型项目或者包含硬件、软件、系统或测试等不同科目的项目中，以及需要在多个地方同时进行工作的时候，会出现多项目TSP团队和分布式TSP团队。非常庞大的项目一般都有独特的需求，需要定制的过程。这一部分的最后一章讨论了改变TSP以满足超大规模集成开发项目需求的途径。
第五部分维护TSP团队
这一部分共4章，讨论的是团队组建过程中更微妙的主题，以及培训开发团队的实质和收获。
TSP先决条件
在开发人员实践TSP之前，他们必须接受合理的培训。他们需要了解如何计划和跟踪工作，如何度量和管理质量，以及如何遵循一套已定义的过程。他们必须理解高质量工作的重要性，必须掌握记录任务时间以及引入并清除缺陷的规则。所有这些方法都在PSP课程①里讲述过。因为需要讨论的内容太多，PSP课程一般会在本科高年级或研究生阶段进行讲授，通常需要半个学期或一个学期的时间。PSP课程需要开发人员花100~120小时，课外作业一般耗时超过两周。
尽管PSP培训的强度很高且需要投入大量的时间，但对于一名合格的软件专业人员来说，完成它并非难事。许多开发人员在大学阶段都接受过PSP培训，还有许多人在单位内部以TSP前导课程的形式接受过PSP培训。因为PSP和TSP都独立于语言和工具，所以它们都有长期价值，并且可以与开发人员平常使用的语言和工具一起使用。成千上万名开发人员都接受过PSP培训，这些课程的数据也显示了这种培训会大幅度提升在规定期限内交付高质量产品的能力。SEI已经设立了一套PSP认证项目，可以帮助各种组织识别合格的PSP专家。
致谢
本书源自我在SEI工作中获得的知识和经验。几年前我加入SEI时，就定下了变革软件工程界的目标。虽然有些人认为这个目标太渺茫，但我认为它能让人释放激情，令人兴奋。从IBM退休之后，这个目标一直引导着我的工作。
我会一直追寻这个目标，因为软件密集型系统在现代社会中所扮演的角色越来越重要。软件对于许多产品和服务而言变得非常重要，它甚至已经变成了完成许多业务目标的主要约束。事实上，开发实践的糟糕现状一直限制着许多业务和科学领域的发展。如果我们不能在预定期限内以合理的成本创造出高质量的产品，就会严重地抑制现代技术服务于人类这个伟大的过程。
尽管尝试改变世界似乎是一个疯狂的想法，但有了SEI和TSP项目型团队的帮助和支持，我们就有了良好的开端。团队协作是一个非常迷人的主题，但这样的主题不能由个人单独来完成。SEI的TSP团队慷慨地贡献了自己的时间和精力，来支持这项工作。我要特别感谢这支团队的成员，感谢他们多年来对我的帮助和支持。他们是DanBurton、KimCampbell、AnitaCarleton、NoopurDavis、MarleneMacDonald、JimMcHale、JuliaMullaney、BillNichols、JimOver、MarshaPomeroy-Huff、JodieSpielvogle和AlanWillett。
非常感谢SEI管理团队，感谢他们无私的支持和鼓励，我还要特别感谢软件过程管理项目的主管BillPeterson、SEI的首席执行官ClydeChittester和SEI的主管PaulNielsen。没有他们的帮助和支持，这项工作不可能完成。
在本书的编写过程中，许多人都提供了帮助和鼓励。在这里，我无法一一感谢那些为我提供了精彩示例的每一位团队成员，但我要对那些曾经直接帮助过我完成本书的人们致以谢意。他们是LindaAlexander、DanBurton、BobCannon、DavidCarrington、JohnCiurczak、NoopurDavis、DonMcAndrews、JimMcHale、BillOmmert、JimOver、Hans-PeterPfister、MarshaPomeroy-Huff、DanReese、DanRoy、JeffSmith、RafiSyed、RobTonneberger、JimVanBuren、DanWall和AlanWillett。我还要谢谢我的兄弟PhilHumphrey，感谢他给我提供了许多深刻的见解。
最后，我要把本书献给SEI的PSP项目和TSP项目的领导人JimOver，感谢他的领导和激情。他比其他任何人都有发言权，他把本书中所阐释的思想转变成了现代工业开发团队可以使用的有效且实用的方法。我与Jim一起工作已经超过了15年，他是一个极富见解和同情心的领导，同时也是一个创造力极强的技术专家，他不愧为我的良师益友。
文摘 4.5.5不要让任何人垄断讨论
有时候，团队里会有一名成员的发言比其他人都要多。他总是会第一个打断谈话，让评论很快变成个人独白，这种独白通常都很拖拉。这种情况会很难控制主要有以下3个原因：第一，在会议的控制过程中，你和团队领导既不能草率，也不能独裁，因为这样做会破坏非正式的、可以自由发挥的环境（而这种环境是团队参与所必需的），这也会导致团队成员不再随意发表自己的观点；第二，要把独裁者隔离开，这很重要，因为他在浪费宝贵的时间，但要做得有技巧，以免挫伤团队其他成员的积极性；第三，这个人是团队的一份子，他的贡献和承诺同样重要。
你和团队领导可以公开或巧妙地来应付这类成员。公开的方式是让团队其他成员来帮助你。当发言者（比女~lJed）刚刚阐述完一个观点，正准备继续往下进行的时候，你插话说，“Jed，多谢。在你继续之前，我还想听听其他人对这个问题的看法。”然后调转话题，讨论团队正在解决的问题，向一些团队成员询问他们的观点。如果Jed想要再次插话，你要礼貌地告诉他你还没有做完，还得再听听下一名成员的观点。不时地让Jed发表言论，间歇打断他的谈话，听听其他人的意见，再回到手头的议题。
这些“Jed”往往不会停顿在一个议题上，这时候我们应该这么说，“Jed，谢谢你。虽然你有意见，但我们还得继续。我先把你的观点写在黑板上，等有时间了再来讨论。”然后，把他的想法记录在房间一边的黑板上，继续启动过程。
另一种更加巧妙的做法是不使用语言的方法。在你或团队领导展开讨论的时候，绕着房间来回动。如果你能有效地领导会议，那么每个人都会和你交谈，而不会私底下讨论。这样，如果在交谈的时候没有眼神的交流，就比较困难。直接站在Jed后面，如果在交谈的时候，他不将身体扭过来就会比较难受。不但他说话困难，团队其他人听起来也会很吃力。在这种情形下，与团队其他成员眼神交流而不理会Jed，也并不会显得不礼貌，这种做法会比较容易。
毕竟，我们也不能失去Jed这样的人。他们也是团队成员，往往也都会做出颇有价值的贡献。通常，他们只是有某种不安全的感觉，因而渴望被他人注意。要礼貌地对待他们，不能完全不理会，因为他们也能发挥自己的作用。实际上，我们有时还需要得到他们的帮助，比如让他们记录会议，张贴文件，或者维护一份公开问题清单等。
