TSP复习整理.docx

结合了笔记和教学材料，翻译可能不是很准确哈~
前面和后面都有角色目标，前面是看的TSS上的TSP notebook里的，后面是PPT上的。
PPT上的就写了大概标题，详细内容请看PPT，针对自己的角色去看那章PPT。

下面去年试卷，没有回答的都在后面的整理中用红色和黑体标出来了

1. 系统集成的主要策略有哪些？这些策略对测试有什么影响？

2. 描述一个完整的Cycle1的Launch过程

3. 你所在的小组设计了哪些角色？你所担当角色在PM阶段就哪些工作内容进行了总结？
Team Leader、Customer Interface Manager、Design Manager、Complementation Manager、Planning Manager、Process Manager、Quality Manager、Support Manager 、Test Manager

4. TSP采取了哪些机制鼓励self-directed团队（一群紧密结合在一起的人，有凝聚力的小组）

From PPT
要建立高效的小组，可以通过给小组提供四种附加的支持来达到：
™ 内聚力：指小组成员之间的紧密联系，它使小组成员结合成一个整体进行工作
特征：经常自由交流；不一定是好朋友，但能在一起亲密工作，互相尊重、互相支持。
™ 目标：具有凝聚力的小组的一个关键因素
可从以下方面体现：目标必须是确定并且可量度的；小组目标必须代表了一种严肃的挑战；目标必须被跟踪
™ 反馈：
计划的跟踪与反馈，可以了解小组的工作情况、目标的进展、成员的表现等
有助于提高小组工作效率，避免“逃避”现象
™ 共同工作框架：
小组成员必须了解如何达到目标，并且知道自己应该做什么，及在最终目标上达成共识
如：必须完成什么计划；什么时间完成；按照什么顺序来完成；由谁来完成

5. Weekly Report实例分析，根据附录中的材料，给出你的观点

6. SUMP实例分析，根据附录中的材料，给出你的观点。

7. SUMQ实例分析，根据附录中的材料，给出你的观点。

TSP notebook

团队角色：
Team leader
充当项目和团队经理；获得项目人员、分配任务、赞同计划、报告状况、为需要的支持做准备；领导launch和relaunch会议；支持和指导小组成员；没有其他团队角色
目标：确保项目是成功的；建立一个有动力有效率的团队；充分利用所有小组成员的才能和能力；和管理层保持联系
责任：完成小组成员的承诺；遵循受过训练的个人过程；计划、管理和报告他们的个人工作；和小组成员们合作并使所有小组成员保持一个有效的、高效率的工作环境（以下都是）
Customer Interface Manager
管理需求问题和需求变更；确保所有需求假设被验证；lead 使用、安装、文档和训练计划
目标：理解用户想要的和需要的；带领团队开发一个满足用户的产品
Design Manager
领导设计工作并控制设计变更；制定设计标准和规格说明
目标：带领团队开发一个好的设计；在开发设计时充分利用小组成员的技能和想法；确保设计和它的文档是高质量的
Implementation Manager（development）
带领实现工作；制定实现、规模和性能标准
目标：带领团队开发一个好的实现；确保实现完全符合设计；开发一个高质量的实现
Planning Manager（进度、估算）
估算、计划、更总和风险管理；建立团队开发和个人计划中使用的计划框架标准；尽量使工程师计划融入整体团队计划中
目标：帮助团队run一个很好设计的并且被跟踪的项目；
帮助小组成员们个人计划和过程跟踪；和计划对照，有规律地跟踪和报告团队状态
Process Manager（一起定义过程）
领导过程和步骤定义工作；管理PIP过程；own并维护团队过程
目标：确保团队已经定义了对每个关键活动都有用的过程；帮助小组成员们定义和使用过程；
确保团队过程数据被准时地报告和分析；帮助团队定义和解决过程问题
Quality Manager（质量计划、度量）
开发、跟踪质量计划并分析质量数据；主持团队评审或当主持人；警告团队和管理层可能的质量问题
目标：带领团队开发和遵循质量计划；对质量问题提供及时的分析和警告；有效地扮演团队评审的主持人
Support Manager（开发环境、配置管理、版本、模板）
建立开发系统；配置管理、变更管理、问题跟踪系统；
目标：帮助团队使用特有的工具和方法；处理团队的配置管理和更换控制系统；扮演团队重用reuse提倡者
Test Manager
确保测试问题在每个阶段都被考虑了；领导测试计划、测试度量、测试跟踪和管理
目标：带领团队开发综合测试计划；确保系统全面地被测试、能够正确的执行所有重要功能

描述一个完整的Cycle1的Launch过程

Meetings
会议角色：支持人、记录员、时间保持者、参加者
会议大体流程：会议准备、会议角色、会议介绍、会议、会议总结、会议报告
当现实数据、进度已经和计划偏差较大时，需要进行relaunch重新计划

Meeting1：产品和管理目标-----------建立整个产品的业务目标
Review会议过程，介绍小组成员；和管理人员和销售人员讨论产品的业务目标
Meeting2：建立团队目标和角色
定义并document团队角色；在小组成员中分配角色
Meeting3：项目战略和支持 --------------定义具体的工作和方法
开发项目概要设计；定义开发策略（周期划分）和要开发的产品；定义使用的开发过程；产生过程和支持计划（即项目策略）
Meeting4：整体计划--------------工作产品进行估算
开发规模估算和整体团队计划
Meeting5：质量计划
开发质量计划 质量目标->估算注入缺陷->估算缺陷排除->产生质量计划
Meeting6：Balanced plan 平衡计划
把工作分配给小组成员；为每个小组成员开发自底向上的下阶段计划；为团队和每个小组成员开发一个平衡的下阶段计划
助忆：allocate task -> create individual plans -> balanced workload ->
任务列表：所有个人任务：估算时间，计划日期，planned value
Meeting7：项目风险分析（如需求变更）
定义和评估项目风险；定义风险评定检查点（risk assessment checkpoint）和责任；为近期阶段、高影响风险提议风险缓解方法和行为
Meeting8：准备会议报告
准备向管理层汇报launch报告
Meeting9：管理层review---------------向高级管理层报告（说服管理层这个计划可行，团队拥有这份计划）
和管理层评审会议报告；讨论项目风险、责任和计划的措施
Meeting10：会议总结
收集会议数据并产生会议报告；把会议报告放入project notebook评估会议过程并准备PIPs

第3、4次会议最为复杂：
Meeting3：项目战略和支持 ---------------定义具体的工作和方法
1. 概要设计：开发概要设计；定义主要产品组件、模块、功能；制定大致的每个组件、模块、功能的规模估算
（理解需求、考虑构架（概要设计尽量接近high level design）为估算充分讨论、设计经理）
2. 开发策略：team leader带领团队建立项目策略。（eg.若干周期、每个周期实现哪些组件、模块、功能）
记录结果（主要产品组件、模块，估算规模和开发时间，开发周期）
3. 罗列要做哪些产品：team leader带领团队定义下一阶段或周期要开发的工作产品和所有后期阶段或周期；
产品的开发区分优先次序：需求文档和规格说明；设计文档和规格说明；原型；主要产品组件和模块；安装、用户和维护手册；测试程序、脚本、数据和计划
（课堂：代码；需求文档；设计文档HLD、DLD；工具使用；学习资料；测试用例；测试报告；用户手册；总结报告；每周reports；每个人过程改进PIP；时间、缺陷日志）
4. 定义开发过程：过程经理带领团队定义开发过程；
定义直到交付的整体开发过程（主要过程阶段；每个阶段的主要活动）；
完善下一项目阶段或周期的过程步骤，以满足支持个人任务计划（10小时或更少）；
制定开发、修改的计划。包括估算规模和时间、阶段/周期需要的天数、谁document这个过程。
（课堂：HLD具体分成哪几个步骤；每个小组成员都有完整的概念，如何来实现；缺陷预防手段；个人评审、团队评审不要遗漏，否则质量目标达不到；测试时收益80%不可能）
5. 过程计划：过程经理带领团队定义其他过程元素。如设计、代码、规模命名、信息标准、做决定；
（过程方面准备文档，编码规范，模板）
6. 支持计划：支持经理带领团队评审可用的开发和过程支持工具和设备（需求和设计助手；编辑、编译、调试、测试工具；缺陷跟踪、配置管理、问题跟踪；LOC度量、数据分析）；（支撑环境、开发环境、工具如何使用）
7. CCB配置管理委员会：
coach带领定义支持经理是CCB主席；其他典型成员为：设计经理、team leader和用户接口经理
8. 定义每个角色人物：coach带领定义每个角色的任务和周报告（每周汇报每个角色的工作，制定周报告）

Meeting4：整体计划--------------工作产品进行估算
1. 估算所有项目产品的规模：设计经理带领团队估算每个item的规模
（需求页数、设计类个数、HLD页数、报告、文档文本页数；程序LOC和测试用例LOC，测试和操作数据）；
2. 决定项目任务：team leader带领团队开发细节任务计划
3. 估算总体需要的资源：计划经理带领团队估算（上个步骤定的）每个任务所需要的资源；计算总计划任务时间
4. 决定每周可用资源：计划经理带领团队估算每个项目周所要的团队任务时间（考虑假期、训练、其他安排）；
计算总计划进度时间，直到满足或超过整个计划任务时间
5. 生成总体团队计划：计划经理生成规模、时间估算和整个项目的团队计划
（团队任务和进度模板；项目完成EV计划；规模和资源数据）

Project Notebook
1. Outline: notebook的内容清单。
2. Summary：项目名称，日期，团队成员，角色分配，SUMP，SUMQ，TASK，SCHEDULE。
3. Project cycle reports：Cycle Reports，项目完全结束后交一份。
4. Task and schedule plans and actuals：针对计划的一份任务和安排的表现的总结，TASK,SCHEDULE,LOGD,LOGT。
5. Process documents：使用的过程，所有PIP，变更管理、配置管理、问题和风险跟踪过程相关。
6. Test plan and actual data：构建，集成和系统测试的计划，测试日志和测试数据，缺陷复查记录。
7. Component data：每个产品组件的SUMP和SUMP。
8. Inspection reports and defect logs：所有的评审报告和缺陷报告。
9. Working notes and documents：每个工程师的项目周报，SRS，SDS，开发策略，设计模板，CCR，CSR，SUMTASK
10. Code
11. 会议记录

APIS数据分析（只贴了些可能会考的图，还有图中比较生疏的术语解释，具体怎么答还是比较容易的，看图上的数据说就可以了）

设计质量：设计时间/编码时间
设计评审时间：2*设计评审时间/设计时间
代码评审时间：2*代码评审时间/编码时间
代码质量：20/（10 + 编译缺陷数/KLOC）
程序质量：10/（5 + 单元测试缺陷数/KLOC）
标准都为1，PQI为以上5个的乘积

这个是我们项目的整体PV&EV，可以看出PV落后于EV，说明我们的整体项目落后于计划。

（PV：每项任务占整个项目总任务时间的估算百分比，即任务的计划值。当完成任务时，就获得了相应的EV值。部分完成的任务不会获得EV值。EV度量为我们提供了便捷方法来跟踪和报告进度。）

Weekly report

第二周：12/28 - 3/31：
累计工作时间和已完成任务的总时间的值是一样的，每周平均工作时间 = 累计工作时间 / 周数
迄今每小时获得的挣值 = 累计挣值 / 累计工作时间

SUMP

CPI（Cost Performance Index）：To-Date planned time or size / To-Date actual time or size
%New Reuse = New Reused LOC / size

（以下）实际百分比=阶段实际值 / 总的实际值

SUMQ

l 阶段收益：Yield (for a phase) = 100 * (defects found) / (defects found + not found)，PSP考试倒数第二大题填空
l 过程收益：第一次编译或测试之前排除缺陷的百分比。
Yield=100*（defects found before the first compile）/（defects injected before compile）

PPT
TSPi Lecture 1

TSPi是TSP的简化版。
为了在开发团队中建立并保持高效的工作关系，需要有共同的目标，有大家一致同意的行动计划和适当的领导；还需要了解团队中每个人的长处和短处，互相支持，适当的时候乐于寻求帮助。 卡耐基梅隆大学

TSPi设计
提供一个基于PSP的简单框架
把产品开发划分为数个周期
建立标准的质量和效率评测机制
提供关于小组和组员的准确评价
采用角色和小组评估
明确小组纪律
提供关于小组协同工作的指导

TSPi结构和流程：
通过多个开发周期完成最终产品；
针对最终产品目标，每个周期进行7个步骤：cycle 1（->策略->计划->需求->设计->实现->测试->总结）
-> cycle 2。。。->完成产品->最终评价
采用循环开发战略，通过各周期产品组合成最终产品

TSPi开发脚本：
review
->会议、开始：指定团队和角色；产生概要设计、建立开发策略、规模预测和风险评估
->计划：产生周期1队和工程师计划
->需求：定义并评审cycle1的需求；产生系统测试计划和支持工具
->设计：生产并评审cycle1高层设计；产生集成测试计划和支持工具
->实现：实现并评审cycle1；产生单元测试计划和支持工具
->测试：构建，集成和系统测试周期1；产生cycle1的用户手册
->总结：进行总结PM，并写cycle1的最后报告；产生cycle1的角色和团队评审
->cycle2.。。。

项目失败的原因：
很少是技术因素（内部政策、团队没有绑定、没有和用户建立和谐关系、会纠结于毫无意义的方法技术问题、。。。）
压力问题（活动计划会有帮助）

团队通常存在的问题：
（1）领导不力
（2）无法协调或合作
（3）缺少参与
（4）拖延和缺少自信
（5）质量低劣
（6）随意增加功能
（7）无效的互评

如何在TSPi建立团队---------------------TSPi是为5人小组设计的
一致的目标（共同建立目标、在后期周期中复查并调整目标）
分配角色（大多数人都要做贡献、每个人都要有自己了解的明确任务、同事间压力是有效的）
需要做计划（达到目标的策略）
交流（周会）
额外的和管理层或指导师间的交流（提交周报、否则，只会看到失败，不能从指导师那得到益处）

TSPi Lecture3 SRS--------定义需求

什么是需求
用户需求VS产品需求
在需求阶段，要开发SRS（软件需求规格说明书-software requirements specification）
SRS提供了一个清晰的无歧义的产品描述，也包括评价最终产品的精确的标准

SRS
软件需求规格说明书是对将要开发的系统的软件行为的一个完整的描述。你计划开发什么，你希望怎样完成这个产品，SRS聚焦于产品是用来干什么的。
包括：
一组用例（描述用户使用软件时的所有的交互行为），也叫做功能需求
非功能需求/补充的需求（在设计或实现上强制约束的需求，例：性能需求、质量标准、设计限制）

开发SRS
保持需求可跟踪；在开发SRS过程中平衡工作量；按照团队定义的过程

为什么我们需要需求过程
一个定义好的需求过程：
评审用户需求、阐述问题、和小组成员讨论这些问题、从用户那得到额外的信息
每个人都要参与定义需求，从而在开发什么上得到团队一致的看法

管理需求变更
需求变更不可避免；所有的变更都要花费时间和金钱；如何区分需求澄清和重要功能追加；需要SRS

需求引出（elicitation）获取
询问用户、使用者或者其他受益者，发现他们真正的需要
需求引出步骤
评价系统的可行性、了解机构问题、定义系统的受益者、记录需求来源、
定义系统操作环境、评价商业问题、定义领域限制、记录需求逻辑依据、
简单原型来了解需求、定义使用场景、定义操作过程

进入标准
开发策略和计划；在策略开发中产生的概念设计

和需求有关的活动
Need Statement Review需求说明复核（审查需求陈述并定义问题或不确定的事）
Need Statement clarification需求说明澄清（和指导师一起审查问题列表和团队澄清）
需求任务分配
需求分析文档（SRS或可测试的需求、用例）
系统测试计划（基于用例、也为压力测试、性能测试等做计划）
需求评审和系统测试计划评审及需求更新（主持评审会与来评审SRS和系统测试计划）
用户复查SRS
需求基线（变更管理）

结束标准
配置管理下的完整的、评审过的、更新过的SRS和系统测试计划
每个人的时间、缺陷、规模数据都填入了TSPi表格和支持系统
来自需求评审的完整的评审表格
所有表格、SRS、系统测试计划都拷贝到project notebook

可测试的需求
需求已经被分成一个精确、无歧义、不可再分成更小需求层次的层次
如果可以写出一个能够证实这个需求有没有被正确实现的测试用例，这些标准才能满足
系统状态和数据输入->条件或者动作->指定的结果

TSPi Lecture4 Designing with Teams----------HLD设计

完美的设计具备4个模板：操作规格模板、功能规格模板、状态规格模板、逻辑规格模板
HLD和DLD的差别仅在于范围和细节不同

设计原则：
设计是决定如何去创建一个产品的创造性过程；
它必须生产而不仅仅是产生想法
它必须产生一个如何构建产品的完整的和精确的规格说明
（创造性过程；如何来实现功能；设计来指导实现，不能是大概的想法；应该是较为精确的描述；高质量的）

在团队中设计
是否要把整个团队加进来？规模因素；设计学习；用所有小组成员的天赋

设计标准：
组件命名；接口模式；系统和出错信息（按照一定的方法分类，统一）；
缺陷标准；LOC计算；设计表示标准（用例等）

复用设计：不等于代码拷贝
复用接口标准（eg.参数顺序，返回值还是参数带出）；复用文档标准（复用注释格式标准）；
复用部分的质量；复用的应用支持（响应的应用程序帮助查找复用部分缺陷）

可用性设计
设计时就要考虑可用性；为每个关键用户功能产生用户场景；分析用户的操作环境

可测性设计
尽可能减少需要测试的代码；（分划法）分层测试、分模块测试；黑盒、白盒都要用

个人评审和团队评审设计
团队评审，两个阶段：准备和讨论
准备：提前两天把评审内容发给相关人员，开个小会：评审对象、目标描述一下，约定多少时间完成个人评审
讨论：三天后，讨论缺陷
（代码评审发现的是逻辑错误），时间日志不一样（被加人员分别添加日志）
两个人分别进行评审（A）a个错误，（B）b个错误，A和B共同的有（A&B）c个错误，则共有a*b/c个错误
四个人评审：独立发现问题最多的是a，其他人的和为b

进入标准
开发策略和计划；完整的评审过的SRS

设计相关活动
高层设计：定义结构；组件命名；组件功能分配；确定设计任务；
设计标准：命名词汇表、设计标准
设计任务：列SDS文档提纲并完成它
任务分配：成员任务分配及时间安排
设计规格说明：SDS；每个小组成员生产并评审自己所写的部分SDS文档；开发经理综合成一个完整的SDS
集成测试计划：生产并评审集成测试计划，检查系统的所有接口
团队评审设计和集成测试计划：每个用例都在设计中覆盖和设计到；设计是完整的、正确的；
集成测试计划是充分的；每个问题都被记录并安排责任分配；团队评审写入检查表，缺陷记录到日志
设计更新：开发经理得到更新的SDS部分并组合到SDS；验证SDS的可跟踪性
设计基准：配置经理设置SDS基线

结束标准
正式的SDS、集成测试计划；设计标准和命名词汇表；更新了的SUMP和SUMQ和检查表；更新project notebook

TSPi Lecture 5 Product Implementation

设计完成标准：
完整的、评审过的、更新过的SRS和SDS规格说明
设计层次：不同层析的反复过程：系统、子系统、产品、组件、模块
并行实现

实现标准：
标准审查；命名、接口和信息标准；编码标准；规模标准；缺陷标准；缺陷预防（找可能会发生缺陷的类型）

实现策略：
评审：自底向上实现策略，简化评审和复用 （设计时是自顶向下方法）
复用：使用注释和代码标准帮助潜在使用者；
在简洁的日会上讨论实现计划（小方法，复用机会多，尽量寻找复用机会）
测试：可测性，保证与测试计划保持一致

个人评审和团队评审：随即缺陷；影响测试；详尽测试的困难；为源程序设计团队评审

进入标准：
完整的开发策略和计划；完整的、评审过的、更新过的SRS和SDS；定义好的编码标准；命名词汇表及其它文档化的标准

实现的活动：
实现计划和任务分配：定义并计划实现任务；确定完成任务时间
详细设计和设计个人评审：完成时间、缺陷日志
测试开发：遵循UT脚本，开发单元测试用例，测试步骤，测试数据
详细设计团队评审：每一个DLD组件评审
编码和代码个人评审
代码团队评审
单元测试
组件质量评审：质量要达到团队标准

组件发布

一些指标：
设计时间 > 编码时间；设计评审时间 > 50%设计时间；
代码评审时间 > 50%编码时间，更好是75%；
在代码阶段尽可能多的找到缺陷；每小时发现缺陷 > 3个缺陷；评审速率 < 200LOC/小时
（评审发现缺陷数 >= 2*compile发现的缺陷数）

结束标准：
完整的、评审过的、更新过的组件；组件被记入了配置管理系统；完成设计、代码团队评审的检查表和日志；更行SUMP、SUMQ和SUMS中的系统和它的组件部分；单元测试计划和支持环境；规模、时间、缺陷数据；更新的project notebook

TSPi Lecture 6 Integration and System Testing

测试原则：
测试的目的是为了评估产品，而不是修正产品
一个产品的质量是在它被开发时决定的
即使是使用传统软件开发方法的组件设计时也会生产低质量产品
程序测试时，测试时间大大增加，测试后你一般会得到低质量产品

测试策略
使用经过单元测试的部件来创建系统。
通过集成测试，来判定单元部件是否都存在，以及它们是否能共同工作。
通过系统测试来确认产品是否满足系统需求。
确认质量差的模块，并将它们交给质量/过程经理处理
确认那些除去缺陷仍令人头痛的质量差的部件，并交给质量/过程经理进行返工或替换。

建立和集成策略
Big-Bang策略：
将所有的组件放在一起来观察它们是否能工作，它需要最少的测试开发，但很少成功，尤其对质量差的系统。组件质量高的话，效率高，不用太多回归测试。
每次一个策略：
逐次添加一些部件，这样得到问题相对较少的简单系统，因而更有效，但要求更多的测试开发工作。
聚类策略：
以类的方式添加部件，选定某种特定类型的相关部件然后测试它们。
平面系统策略：
首先集成所有最高层次部分，然后并行的一层层向下钻研，可以一次测试所有部分，或者一次加入一个部件，其好处是能在早期发现系统级问题，建立系统梗概。

系统集成的主要策略有哪些？这些策略对测试有什么影响？

系统测试策略
回答四个问题：
系统是否展示了其要求具备的功能
系统是否达到了它的质量目标
在正常情况下系统是否能适当地工作
在非正常情况下系统是否能够适当地工作
可选择的系统测试策略：
1. 以不同的方式来强调测试目标，如连续测试每一个目标。可以先测试每一个预期的功能，重点检查操作，评价可用性等
2. 关注选出来的功能区，在进行下个功能区之前，确认这个功能区的每个方面。它没有强调整体系统行为。
3. 结合上两种策略，对正常、非正常和重点条件下的低层次功能进行测试，然后进入高一点的层次，再测试其结合后的协同工作功能，再重复上述过程，直至覆盖整个系统。此策略对于质量差的系统较适用，因为许多系统功能最初是完全不起作用的，但对于大系统，其不利之处是要花费长时间循序渐进地测试所有的重要功能。
4. 首先对最高层次进行功能测试，然后逐步向下，一次次进行正常和重点测试，依据系统的大小和系统的主要目标，进行不同功能的综合测试。此方法能最快地包含系统问题，对于高质量的系统有效。（和策略3相反）

测试计划
（1）所有要执行的测试步聚清单
（2）每个测试所需要的支持材料
（3）测试产生的结果
（4）估计每个测试的无缺陷运行时间，发现的缺陷数，以及总时间
（5）在测试计划中要求开发的每个item所需的工作估计
测试用例、测试用例评审（结合需求、看覆盖、涉及面）、进行测试、写支持文档（用户手册、安装手册等）

跟踪和度量测试：测试日志；有缺陷倾向的模块；模块缺陷数据；跟踪缺陷数据

测试文档
商业系统需要很多文档：安装、维护、跟踪、市场需要
TSPi，我们只写基本的用户文档
描述一个功能的最佳时间是刚刚设计好
TSPi也包括测试阶段的文档
文档设计：写读者需要的；不再标准字典里的使用词汇表定义item；
包括错误信息部分、解决问题步骤和恢复步骤；有关键话题的索引；提供详细目录
文档提纲；文档书写风格；文档评审（组织、术语、内容、准确性、可读性、易理解）

进入标准：完整的、评审过的SRS、SDS规格说明；配置控制下的实现了的、评审过的、单元测试过的组件
活动：测试开发、建立、集成、系统测试、文档化
结束标准：集成并测试过的cycleN；完成所有测试日志和测试日志；
完整的、评审过的用户文档；记录时间、规模、缺陷数

TSPi Lecture7 The Postmortem

PIP表格记录潜在改变
定义：insanity愚顽：反复做同样一件事而期望不同的结果

PM的概念：
评审团队工作保证你：已经完成所有需要的任务；已经记录了所有需要的数据；
再次检查你在这个周期做了什么：做错了什么，做对了什么；下次如何做的更好

为什么需要PM：持续不断的改进对软件开发者是尤其重要的；跟上技术的脚步，满足未来更多的竞争需要

PM的作用：提供学习和进步的结构方法；看到从一个周期到下一个的变化

进入标准：完成并测试了产品；收集了所有的数据并完成了所有需要填写的表格
评审过程数据：质量/过程经理评审完整的SUMP、SUMQ等
质量评审
角色评价（team leader负责）
准备cycle report
描述你开发了什么，你使用了那些过程，扮演的角色；
描述你做了什么，没有做什么，下次如何做的更好；
描述你作为开发者和团队角色的表现；
学到了什么，未来如何改进；
和前期开发周期比较工作情况和突出的趋势
Cycle report提纲：
目录；总结；角色报告（评价自己的角色表现及改进方法；从自己角色角度评价团队表现）；
工程师报告（开发工作上的个人表现）
结束标准：团队开发了高质量产品，包括所有需要的文档；配置控制下完整的开发；
过程数据被评估，PIP已完成并提交；角色互评已完成并提交；
cycle report已完成，每个小组成员和导师都有其有拷贝；所有TSPi表格已完成；project notebook更新

你所担当角色在PM阶段就哪些工作内容进行了总结？
Team leader：
从一个领导者的角度陈述小组的工作情况、评审团队表现
包括动力和承诺问题，导师附加的有用的指导的地方，主要学到的知识；
Comment on会议引导人：使用的practices，他们如何工作的，未来如何处理这个角色责任
Development经理：
比较产品内容和对产品的要求，并且评价开发策略的有效性（策略是否如期望的工作；
其他方法可能风有效，此策略以后应如何改变）；
描述设计和实施步骤，taken to address质量话题（可用性、性能、兼容性等）；
阐述这些质量度量的有效性，下次如何更有效地address这些话题。
计划经理：
描述小组工作与计划相比怎样（每周时间和挣值趋势；团队挣值跟踪和报告的充分度，下个周期做的更好方法）；
和之前周期或其他项目比较团队工作情况
质量/过程经理：
使用实际的质量数据描述相对质量目标而言的小组工作情况（展示开发周期的整体质量趋势）；（质量经理）
评价团队的过程discipline（过程经理）
The degree to which the engineers：
Follow the process；度量他们的工作；使用的改进措施；提交改进想法的PIPs
总结所有团队提交的PIPs和简要分析他们是如何处理的
评审标准工作和团队的引导团队评审：团队评审收益，未来提升建议（质量）
支持经理：
描述支持设施，记下问题或建议改进的地方；
Comment on配置管理和更换控制步骤（提供更换活动数据；Comment on迟的更换的影响；
未来如何更好处理更换的建议）
报道跟踪问题、跟踪团队处理风险和问题的有效性
阐述重新使用的问题（复用策略如何工作的？团队复用率和个人复用率达到了百分之多少？
描述未来周期提高这些百分比的机会，建议如何去做这些提高）

TSPi Lecture8 The Team Leader Role

TSPi里，每个小组成员有两种目标：共同目标；角色目标
小组成员共同目标：成为一个能合作、起作用的小组成员；支援其他成员并且协调工作

Team leader的目标：建立并维持一个有效的小组；督促所有的小组成员努力工作；
解决所有小组成员给你带来的问题；使上司/导师全面了解小组的进展情况；作为小组会议推动者有效地工作
What is a leader：有拥护者；有需要的特性（能督促同时努力工作；坚持工作质量）；克服困难；处理人际关系
Team leader主要活动：
动员小组成员执行它们的任务；主持每周的小组会议；报告每周工作情况；帮助小组分配任务；小组会议上充当领导人和记录人；
维护project notebook----工程记事本；领导整个小组制定出开发周期报告；充当开发工程师

TSPi Lecture9 The Development Manager Role
设计经理的目标：生产处极优秀的产品；充分利用小组成员的技能和才干
开发经理的主要活动：
领导小组制定开发策略；领导小组给要生产的产品制定最初的大小和时间估计；领导软件需求细节的开发；
领导小组制定出高水平的设计；领导小组制定出软件设计细节；领导小组实现产品；领导小组制定出集成和系统测试用例；
领导小组制定测试材料并进行测试；领导小组制定产品的用户文档；参与制定开发周期报告；充当开发工程师

TSPi Lecture10 The Planning/Quality/Process Manager Role

计划经理的目标：为小组和每个小组成员制定出一个完整的、精密的、正确的计划；每周准确地报告小组的工作情况
计划经理的主要活动：
领导小组制定下一个开发周期的任务计划；领导小组制定开发周期的日程表；领导小组制定平衡稳定的计划；
跟踪小组对照计划进行的进展情况；参与生产开发周期报告；充当开发工程师

质量/过程经理的目标：
所有成员应正确地报告和合理地使用TSPi过程中数据；小组忠实地遵循TSPi质量计划并生产处高质量产品；
所有小组评审要被合理地调整和报告；所有的小组会议要被正确地报告并将报告加入到工程记事本中；
主要活动：
领导组员判定和遵循质量计划；将质量问题及时通报给team leader和导师；领导小组定义和文档化它的过程并维持过程的改进；
建立和保持小组开发标准（编码、命名、错误处理、LOC计算等）；在提交配置控制委员会CCB之前审查和通过所有的产品；
充当小组评审调解员；作为小组会议记录者；参与制定开发周期报告；充当开发工程师

TSPi Lecture10 The Support Manager Role
目标：小组有合适的工具和方法来支持他的工作；没有授权通过的更新不能够应用在规范好了的产品中；
小组所有的风险和问题被记录在风险跟踪系统中，并且每个星期都报告；小组满足开发周期的复用目标
活动：领导小组决定其支持的需要和获得需求的工具与设备；主持配置控制委员会，管理和更换控制系统；管理配置管理系统；
维护系统词汇表；维护小组的问题和风险跟踪系统；成为一个复用的提倡者；参与制定开发周期报告；充当开发工程师

1. Goal
• Build and maintain an effective team
– The team meets its cost, schedule, and quality goal
– The PEER form evaluations of overall team effectiveness are 3 or better
– The team members’ PEER form ratings of the team leader’s role are good(3) or better for overall contribution.
– The team members’ PEER form ratings of the team leader