软件项目管理学习笔记

人员管理

定义

能力框架————一个三层的框架，用于在几个领域组织和平衡个人的技能

文化实体————集合起来完成同一个目标的一群人的共同信念和实践

文化事件————以一群人所执行的以事件为中心的共同信念和实践

文化管理————监控和控制一群人的共同信念和实践

文化角色————在一群人的共同信念和实践中担任角色的个人

工程角色————在一个合作起来设计产品的技术群体中担任角色的个人

领导————一个人的引导、影响或指挥他人的能力

组织文化————组织的共同信念和实践

人的需求————个人的要求或期望

专业发展————导致个人的专业技能发生积极变化的事件、经验或培训

项目文化————在单独项目中的成员的共同信念和实践

项目需要————使项目朝着稳定或成功的方向前进的项目需求或期望

涉众——————一个或一群人，他们与某个软件项目有直接的而利益、直接的关系或者直接投资于该项目

团队凝聚力———一群人作为一个整体有效运行的程度

时间日志————一个表单，用于跟踪个人或小组在许多任务中的每个任务上所花费的时间

要点

形成项目文化的步骤

1:了解组织的文化

2:了解每一个团队成员的工程和人员背景

3：将文化和工程角色痛人相匹配

4：如同管理技术问题一样来监控和管理团队文化

管理优秀的人的准则

1：在不进行微管理的情况下获得可见性

2：评价过程和产品，而不是人

3：协调，而不是操纵

4：使用你的知识，而不是你的权利和职位

5：采用引导而不是控制的方式对人进行管理

6：将重点放在项目和人的需要，而不是你作为经理的权力

 

使优秀的人更优秀（步骤）

1．  使专业发展成为一个项目目标

2．  认清长期专业发展目标和短期专业发展目标

3．  让每一个团队成员确定个人进步目标

4．  让团队成员跟踪他们的个人时间

领导优秀的人（准则）

1．  对自己和团队有信息

2．  领导者不是没有错误的。出错了要承担责任，同时将重点放在纠正行动上

3．  树立领导榜样。向团队展示你对自己的团队有什么期望

4．  利用团队的全比聪明才智，你无法全凭自己来使项目取得成功

5．  按时完成你分内的工作

6．  不要将朋友关系与领导关系搞混

能力框架

技术、领导、领域、个人、通用、交流、管理

项目的基本要素

人员、过程、工具、测量

实施过程

定义

极限编程————是一个软件过程，在这个过程中结合了用户和软件开发人员，在这样的软件过程中包含了持续不断的测试、快速反馈和高频率交流

结对编程————一个软件过程，在这个过程中，软件开发人员成对地工作，通过将检验工作结合到代码生成中来提高生产力和质量

过程评估————对软件过程的评价，其目的是为了找出软件过程可以改进的地方

生产并行性———一种状态，当所有软件产品反映出项目的当前状态时达到这一状态

需求易变性———一种情形，在这种情形下，需求变换频繁、多样、不可预测，生产出不稳定的软件产品

审查无限循环——一个无限的循环，审查和后续的修改持续进行下去，看不到尽头

风险评估————对项目风险的影响所作出的评价

软件过程————一个任务序列，用于在预算内按时生产高质量软件

裁剪——————对软件过程进行修改一遍适合于特定的项目

颠簸——————执行与软件项目相关联的非生产性工作

本章强调

1.：每个项目都有过程，你需要选择和规定自己的过程

2：如果项目部存在规定的过程，那么项目会颠簸和晃动，从而会减少有价值的工作

3：为了指导过程，可以选择一个证明过的过程、裁剪组织过程、或者你自己规定一个过程

4：如果你团队不实施你规定的过程，那么这个过程就没有任何价值

5：逐渐曝光拒绝实施过程，并且快速处理存在问题的人员

6：过程评估问题需要在过程的规范和实施期间进行考虑

7：为了完整，过程评估应当由量化数据和历史信息组成

要点

裁剪组织过程（步骤）

1：确定你的项目与典型公司项目存在多大的差异

2：形成两个列表，在组织过程中尼的项目所需要的活动列表，组织过程中你的项目部需要的任务列表

3：提议对组织过程所需要进行的修改

4：在团队和其他关键公司人员中间宣传裁剪后的过程，以得到他人的检查和建议

5：综合所做的修改，快速结束对组织过程的裁剪工作

规定过程（步骤）

1：了解过程规定的目标

2：规定格式

3：先从最高级（最抽象）规定过程

4：随着规范的发展，逐渐包含更多的细节

5：利用团队对于过程规范的建议

确定项目差异

1：与典型公司项目团队相比，你的团队规模如何？

2：开发平台和目标平台在公司是众所周知的嘛？

3：充分了解开发环境吗?

4:进度表（在交付、里程碑和其他主要事件等方面）与其他进度表类似吗？

5：任何契约要求与公司标准有没有重大差别

6：团队的才能和经验是否适合这个项目，就像适合公司以前的项目一样

7：通常不涉入公司项目的外部当事人会影响或涉入这个项目吗？

过程规范目标

1：记录一个对于你的项目最有益的过程

2：向你的团队传达有关项目成功所需的任务

3：为该项目建立协调机制、质量保证机制与控制机制

4：明确指定在哪个时候要完成哪些任务

实施过程（准则）

1：拥护该过程————要做过程的最大支持者

2：忠于该过程，不要跳出其中的部分

3：只在必要的时候才调整该过程

4：如果团队成员拒绝实施该过程，则应采取行动

5：可以通过减少团队成员来对团队进行加强

使用工具

定义

比较图————同时比较几个对象的多个标准化属性的图形

标准化————用数学方法将一个值转换到某个单值域中，以便与该值域中的其他值相比较

软件工程工具——特别设计出的软件产品，在软件产品设计过程中为软件工程师提供帮助

培训方法————学习新技能过程中所用到的组织、表现和活动

本章强调

1：对工具的评价应该给予成本和收益

2：对使用工具的培训与选择工具一样重要

3：培训需要进行谨慎的研究和选择，这样团队成员才能充分利用培训时间

4：一旦选定了工具并完成了培训，团队就需要克服困难和抱怨，坚持使用工具

要点

选择软件工具（步骤）

1：列出过程中能够从工具提供的支持中获益的任务和活动

2：列出项目必须产生的产品

3：鉴别出满足过程和产品需要的工具

4：制作比较图对工具进行比较

5：对于每个工具，从使用过它的人那里获取信息

6：做出决定，就好像成本出自你个人的资金、培训时间出自专业时间一样

制作标准化比较图

1：创建一个电子表格，它的内容包括每个工具的成本、训练时间、和所要求的功能所占的百分比

2：以最昂贵的工具的成本为基准，对每个工具的成本进行标准化

3：以最复杂的工具所需要的培训时间为基准，对每个工具每人所需要的培训时间进行标准化

4：以功能最强大的工具的功能为基准，对每个工具的功能进行标准化

5：制作复合图

标准化

设最复杂的工具培训时间为x，则它的标准化值为100，其他工具的标准化值为(y/x)*100

研究软件培训课程

1：获取一份培训资料

2：与老师通过电话或当面交谈

3：与最近从统一老师那里接受同一课程的学习者交谈

从无组织培训中回去最大收益（准则）

1：为团队提供关于工具的学习内容的具体指导

2：使团队的注意力集中在项目所需要的那些工具特征上

3：提出一个试验的组织，以领导团队对整个工具进行学习，避免“自由游戏“

使用测量

定义

控制测量————用于做出及时的决定和对软件项目的当前状态进行调整的测量

臆测——————基于直觉的估计

指标——————表明某个特征存在或者不存在的测量，单它自身并不能明确地表明特征

预见性测量———预计在将来某时候项目将会进展到何处的测量，用于作出决定并调整

过程测量————对组成软件过程的任务和活动的测量

产品测量————对软件项目生产出来的产品进行的测量

项目测量————对所使用的过程或特定软件项目所产生的产品的测量，只用于本项目范围之内

时间日志————用于跟踪个人或团队在一组任务上所花费的工作时间的表单

本章强调

1:测量必须深思熟虑地选择、计划和实施。

2：测量应该包含一个来自软件工程师的最好实践的基本集合。这些测量包括产品、工作量、改动和管理测量

3：额外测量的选择应该给予独特的项目因素

4：一旦开始收集测量，你就需要检查其正确性，并将其投入使用。这样做将会改进测量工作，并使团队相信测量是有价值的

要点

选择测量（步骤）

1：指定在评估项目过程时想要回答的一些问题

2：指定回答这些问题所需要的测量

3：指定测量的收集和存储

4：指定测量的分析

选择测量（准则）

1：收集产品规模测量，从而知道团队创建了什么

2：收集工作量的测量，从而知道团队把时间花费阿紫什么地方

3：随时获取修改的数据，从而知道产品进展得如何

4：随时获取管理数据，从而了解项目进展、进度表和成本

随时跟踪团队工作量（步骤）

1：建立一个标准的时间日志格式和团队成员更新个人时间日志的过程

2：在结构管理下有规律地更新团队时间日志

3：在有归来吧地将团队日志进行了更新之后，用图或者表的方式查看团队时间日志

选择项目特有的测量（步骤）

1：列出你想要回答的项目特有的问题

2：列出你人又有助于回答每个问题的测量

3：对于每个测量，列出要测量什么、什么时候测量、将要采用什么格式以及将要如何获取测量

4：与团队一起复审测量

计划项目测量（准则）

1：使测量作为软件开发果真中正常的一部分

2：确保整个团队知道谁来收集什么测量

3：明确指出什么时候收集测量

4：指定在获取测量之后将其存储到哪里

使用测量（步骤）

1：检查一下测量过程，因此你和团队就能够确定过程的进行时令人满意的

2：检查所获取的测量的精确性和一致性

3：对测量进行分析，因此你和团队就能够从测量工作中获益

形成愿景

定义

收益————源于项目的积极地接过或影响

特性/资源/时间三角————一个描述产品特性、项目资源和项目花费时间之间的关系的三角形，它特别能反映其中一个因素发生改变时，会对另外两个因素产生的影响

需求————用来支持或保证项目成功的要求

风险————可能导致项目遭受损害、损失或拖延的时间、情况或状态

软件项目大纲（SPO）————在项目早期阶段用来确定关于软件项目的特性和要素的文档，它记录了愿景

涉众————对一个项目软件有直接的兴趣、介入或投资的人或集团

折衷————对有冲突的软件任务、决策或目标的属性或特性所进行的妥协

本章强调

1：仔细地确定你的项目中的所有涉众，无论他们是支持者还是排斥者

2：项目都有大量的需求和期望。确信你了解这些需求，强调不同的项目优先权，同时还要在此基础上对需求进行折衷

3：必须对你的项目进行不间断的风险评估。列出一张风险清单，并更具其发生的可能性和会产生的影响进行评价，再更具二者的综合进行排序

4：要清楚并确定项目的回报，以最大化他们对你的团队的积极作用

5：必须要在SPO只能够确定一个精确地项目愿景。SPO对项目进行概述，并形成其他软件项目文档的基础

要点

分析涉众（步骤）

1：列出所有在你的项目里有风险股本的个人和团体

2：确定项目成功对每个个人和团体的影响

3：确定项目失败对每个个人和团体的影响

4：了解每个准备从项目的成功中获益的个人或团体对项目所做的贡献，并要使之平衡

5：了解每个准备从项目的失败中获益的个人或团体对项目的影响，并使之降到最小

平衡项目的需求（准则）

1：时刻要牢记特性/资源/时间三角

2：在过程和项目中药认清生产率和质量的折衷

3：考虑与项目决策并行的文化和技术之间的折衷

4：平衡汇合时间和个人工作时间

5：总要在决策之前考虑折衷问题

评估风险（步骤）

1：列出你认为可能影响项目的所有明显的风险

2：按最可能到最不可能的顺序给风险排序

3：更具风险所产生的消极的影响，从大到小给风险排序

4：合并步骤2和步骤3中的风险表，对每个风险在两个表中的值求和

5：根据合并的结果，对风险按升序排序

确定项目回报（准则）

1：公司的回报是所有项目的基础

2：客户要从你的项目中获取极大的利益

3：你的开发团队必须要被认为是一个很强大的团队

4：你的团队所使用的范例和技术要使团队成员成为更高级的专家

5：这个项目会在专业上带来个人和公司的进步

6：过程规范、软件测量和项目评价都将对公司和开发团队很有价值

明确并传达你的项目愿景（准则）

1：考虑涉众、风险、需求和项目的回报

2：愿景要覆盖整个项目生命周期

3：把你的愿景反复地、坚持地在你的团队中进行灌输

4：给团队成员的不同愿景留有余地，只要他们不损害项目的成功

5：将“寻找一条成功的出路“作为你的愿景的一部分

6：当你修改了你的愿景，将新的愿景传达给你的团队

7：将你的愿景形成文件，并列在将成为软件开发计划的软件项目大纲中

SPO

概述————用三到五张表来描述产品功能、平台、客户、进度表和开发职责

高级功能————用一个段落来综述产品，再用一个段落来描述每个重要的功能

涉众————用一个段落来明确每个重要的涉众群体和他们的风险股本

项目需求————用一个段落来讲述每个重要的项目需求

项目风险————按风险的可能性或影响的顺序，对每个重要的项目风险都用一个段落进行讨论

项目回报————用一个段落综述产品的回报，其后对每个重要的项目回报都用一个段落讨论

结论————用一个到三个段落将上述所有部分联系在一起。明确项目需求和风险，再用论点和论据来总结为什么这个项目会成功

组织资源

定义

配置————为了把软件放置到目标硬件上、并使用户能使用软件而进行的装载，安装或其他类似的行为

硬件资源——在软件项目中，进行产品开发或维护软件所需要的硬件装置和支持设备

重构————把源代码转换成一个可执行的产品的行为

软件升级——对已经分发好的软件产品进行添加、更新或改变，以修正错误、提供增强功能或在其他方面提高的软件

支持————由人员、硬件或软件所执行的任务，其目的是提供硬件、软件或工具

本章强调

1：确定项目需要的所有硬件，以及项目在什么时候需要这些硬件。

2：确定项目需要的所有软件，并确定合适需要这些软件，以及何时可能要对软件进行升级。

3：确定团队需要从外部人员和团队那里获取的支持。要从这些人员和团队那里获得对支持行为和对何时提供支持的承诺

4：确信你组织并计划处你的团队需要的所有资源，并在他们需要时提供资源。这能使开发团队专心致志地关注项目，而不会有意外的事件使他们偏离项目行为

要点

确定硬件需求（步骤）

1：列出在你的项目里所需要的所有硬件

2：确定你的项目需要每个硬件所提供的功能

3：对每项硬件，列出必须的软件和支持设备

4：决定哪个团队成员需要哪些硬件完成他的职责

确定软件需求（步骤）

1：列出你的项目里所需要的所有软件

2：确定你的项目所需的软件版本

3：对每个软件，确定哪些在项目过程中将要进行升级或需要服务包

4：对每个软件，确定由谁来负责安装和升级

5：计划出对项目影响最小的软件升级时机

获得提供支持的承诺（步骤）

1：列出要从每个团体那里获得的支持

2：确定何时需要这些支持，这样项目才会没有延误而继续前进

3：确定支持是如何提供的

4：获得每个团队对项目支持的承诺

5：和提供支持的团体保持良好的关系

勾勒出进度表

定义

调整过的功能点————反映在软件需求规范里确定的，或现存的软件产品中确定的功能和功能的难度的量化

COCOMO———————软件成本估计模型

COSMOS———————将功能点方法和COCOMO模型集成在一起的软件产品

成本动因———————对完成一个软件项目的工作有积极地、不确定的或负面影响的因子

功能点————————对软件需求中确定的功能，或现存的软件产品所表现出来的功能的测量

固定不变的里程碑———在项目进度表中特定的额日期发生的事情，无论项目因子或进展得如何都不能对这些事情重新安排

可集成性———————软件产品的部分，这些部分能被合并来形成一个可执行的、包含部分功能的软件产品

无会议项目——————只有很少或是没有会议来协调项目考法团队进度的软件项目

同步点————————在一个项目进度表中需要项目团队用以同步产品内容、完成任务和减少缺陷的时间点

未调整过的功能点———反映在软件需求规范里确定的功能，或现存的软件产品里确定的功能的量化

本章强调

1：功能点方法可以用来估计项目规模

2:：COCOMO模型可以用来估计项目的工作量和项目持续时间

3：有两种项目进度：计划任务以达到固定不变的期限；选择同步点并对同步点确定进度

4：进度表需要包含交流时间，这样才能确保项目不会偏离当前状态、承诺和需求的轨道

5：如果你不对交流进行计划，那么开发团队的成员将饱受缺乏交流之苦

要点

估计产品诡秘、进度和工作量（步骤）

1：估计已经调整的和未调整的功能点的数目，要由两个或更多的人分别独立地进行估计

2：根据两个或更多人的独立估计，用COCOMO或COCOMO II模型来估计项目持续时间和工作量

3：随着两名的进展持续调整项目估计

为固定不变的里程碑计划进度（步骤）

1：在你的进度表里置定固定不变的里程碑

2：使用COSMOS中的逆工程功能，来估计你的团队在到达固定不变的里程碑式完成的功能总量

3：进行这样的计划：确定在就要大大里程碑之前要完成的工作，以及项目开始后或在前一个里程碑后马上要进行的工作

计划同步点（准则）

1：在选择同步点之前在进度表里设置固定不变的里程碑

2：阿紫主要的决策或风险评估前插入同步点

3：确信同步点在功能的可测试的、可集成的和显著地部分完成时出现

4：使用同步点老评估产品和任务状态，并减少潜在的缺陷

促进交流（准则）

1：项目开发团队需要会议，但他们并不需要把所有的时间都花在会议上

2：管理团队会议，一遍能充分利用时间

3：用标准的格式收集状态报告，以在两个会议的时间间隔时间里进行交流

4：把重要的交流用文档记录下来，这样每个人都能通知到并能理解交流的内容

5：在进度表中为会议和交流留出时间

写出计划

定义

结构管理系统————一个软件产品，通过到处和归并过程来控制对项目文件的访问，就像图书馆里的过程一样

特性蠕变———————随着时间变化，不断给产品增加新特性

质量保证———————一组行为，其目的是在软件项目生命周期中确保并评价产品和过程的质量

需求易变性——————在软件开发和维护中不断改变软件的需求

软件开发计划（SDP）—它是一个文件，详细描述了与软件项目有关的关键的估计、行为、风和

                     产品

目标环境———————软件产品交付给用户后，运行产品的软件和硬件的总和

本章强调

1：软件开发计划要和特定的公司和内容紧密相连

2：改变会影响SDP中的很多部分

3：计划的每一部分都和其他部分由联系，因此改变必须做得仔细和彻底

4：审查SDP时进行管理项目准备的和必须的部分

要点

SDP

概述——————用三到五张表来描述产品功能、平台、客户、进度表和开发职责

高级功能————用一到五页的篇幅来概述产品的特性，其中，要包括有关这种功能的附加信息

项目成员————关于软件工程职能确定的信息，以及分配到这个项目的工程师的数量

软件过程————概述在这个项目中所应用的软件过程。

软件工程方法——概述这个项目中所应用的软件工程方法和技术

进度和工作量——这一部分要表达出整个项目进度和工作量的估计。其中，要包括对固定不变的里程碑和同步点的解释；也要包括对下述内容的的讨论：在评估中的设想情况、估计中的不准确性的可能来源，以及随着项目的进行如何更新估计

测量——————要收集的测量的专用列表，这些测量要确定在什么时候、由哪些职能成员来收集，以及在哪里存储。在这一部分还要包括这样一个概述：如何对测量进行分析，并利用测量来监督并控制项目

项目风险————对每一个显著的项目风险都要用一个段落来描述，还要用一个段落来介绍风险可能性和风险影响

软件工具————列出要使用的每一项软件工具，以及该工具所支持的任务

硬件支持————明确所需硬件的有关信息，包括哪些需要移动、获得或升级的硬件

软件支持————明确所需硬件的有关信息，包括哪些需要移动、获得或升级的软件

人力支持————明确支持信息：要由哪些人或哪些团体为开发团队的哪项任务提供支持

指定SDP（准则）

1：用SPO作为开始部分以保持一致性

2：完整地完成每一部分。如果你不能完成某一部分，那就说明你有悬而未决的问题

3：使用以前的SDP来做参考并保持一致性，还要从中汲取经验

4：小心地考虑计划中的语气，以便你能传达项目会成功的信心

5：注释SDP中有疑问的部分，这样你可以喝计划审查者、开发团队一起讨论它们

6：要有修订SDP的计划，然后遵循最新的SDP版本

7：计划属于整个团队，而不是你个人，所以把你的自负留在家里

审查SDP（步骤）

1：选择有经验的项目经理，并得到他们参加审查的许诺

2：分发SDP给项目经理，并给他们足够的时间进行审查

3：安排一个会议，在这里介绍SDP并收集审查者的反馈

4：把你对SDP所作的改变和没有使用的审查反馈都记录在案，这样在项目评价中，你就可以把这两种情况都考虑到

分配角色

定义

义务————完成另外一个角色所需的任务或提供一个产品的许诺

依赖关系————两个任务之间的关系，在其他任务没有完成的情况下，一个任务不能完成或不能正确完成

领导角色————一个角色，某人在软件项目中被分配或主动承担的软件工程角色的领导职责

支持角色————一个角色，某人在软件工程项目中被分配或支持软件工程的角色，但不承担该角色的职责

重叠角色————在软件工程项目中，给一个人分配两个或多个角色

职责————对他人所富有的行为、任务或产品职责

角色————在给定的软件项目中某个人所承担的、被定义为软件工程任务、并受该人所处社会环境影响的部分

本章强调

1：应当了解团队成员的能力，并小心地将其与软件供角色相匹配

2：匹配人员和角色应同时考虑项目需要和团队成员的期望，这是因为人们更愿意对他们选择的任务负责

3：分配角色时应当考虑文化因素

4：如果可能，为了提高生产力和质量，每个人都应当担任多个角色，并且避免团队过分依赖于某一个人

5：若但当多个角色的团队成员对其他角色负有依赖关系、义务和职责，那么你，作为经理，应该关注这些依赖关系、义务和职责

6：通过对依赖关系、义务和职责进行清楚地交流，你的团队可以避免潜在的问题

要点

确认项目角色（步骤）

1：列举出完成项目所需要的主要的软件工程任务

2：把适合于痛一个角色的任务集合到一起

3：对工作量、所使用工具以及每个角色的重要性进行评估

4：确认每个角色所需要的软件工程和个人技能

5：检查所有角色以确定它们相互匹配并且是可管理的

匹配人员和角色（步骤）

1：检查每个团队成员的软件工程技能和文化技能

2：根据你对每个人技能的评价、他们对自己技能的评价以及最后他们自己想从事的角色，将团队成员分配到每个角色

3：在每一个角色中选择一个团队成员作为领导者

4：给每个团队成员分配一个或多个支持角色，这样，每个人都有重叠的角色

制订进度表

定义

核心功能————保证产品价值的用户所需的基本功能

及时的方法———在一项行为马上就实际需要之前才执行它

小节点—————项目进度表中的一个小的、零散的目标，这样的节点标志着整个任务、行为或产品的一部分完成

返工——————以前的一个任务或行为所需要的一次或多次的重复

监视员—————为了减小风险而在既定的时间之前完成某项任务或行动的团队成员

老虎团队————由团队成员组成的一个小组，负责快速地执行一项任务或行动，或者是解决团队急需解决的特点问题

预备任务————并不直接对产品作出贡献，但是必须在项目的特定任务之前完成的任务

工作分解结构——显示与人员相关并且在时间上已经安排好的任务文档，完成这里所有的任务也就意味着完成了整个项目

本章强调

1：软件开发计划中的进度表过于抽象，不适于日常的应用，因此，你和团队必须制订一个更为详细的进度表

2：如果你的项目在使用一个分阶段的或者是循环的过程，团队需要检查并进一步指定每个阶段或周期内要完成的功能

3：详细的进度必须指定哪些角色负责哪些任务，以及这些任务应该何时开始和结束

4：预备任务和软件工程任务都需要根据项目需要和团队的投入来安排

5：需要把任务分配到角色，然后是到人。需要根据文化和软件工程因素来分配任务

6：任务分配的重叠对个人和团队来说都是有利的

7：团队需要根据确定的风险检查进度表，并制定考虑了风险影响和进度表偏移的备份计划

要点

安排预备任务

1：列举软硬件安装任务、相应的估计时间和相互之间的依赖性

2：列举团队所需要的培训以及每项培训活动所需要的时间估计

3：提供时间让团队了解产品、客户、开发和运行环境

4：列举团队需要的产品和过程标准，并指定开发所需时间

5：规划软硬件安装、培训、项目理解以及标准，关注所有的依赖关系

安排软件工程任务（步骤）

1：决定在设计开始之前需要指定哪些需求

2：决定在编码开始之前需要完成哪些设计

3：决定在测试开始之前需要完成哪些编码

4：决定在测试安装和运行之前要完成哪些测试

5：在重叠和潜在的修改之间进行折衷

6：了解依赖关系和义务

7：根据需要进行前向和后向安排来制作一个进度表

把任务分配到角色

1：征求团队对每个任务的意见

2：考虑每个团队成员的技能和对特定任务的动力

3：评定和降低每个人员——任务分配的风险

4：将人员——任务分配以团队决定的形式发布出来

5：考虑人员——任务分配的文化影响

创建备份计划（步骤）

1：检查软件开发计划后中指定的风险

2：确定在什么时间、如何可以察觉每个风险

3：监视每个已经出现的风险，收集信息并进行评估

4：检查风险的影响，针对每个风险的影响确定团队的行为

5：将这些行为确定为一个或多个备份计划

 

获取支持

定义

获取进度表————一个为软件项目提供支持的进度表，用来指定什么时候硬件、软件和工具可以得到、安装和配置

采购订单——————一个文档，用于一个公司承诺向另一个公司购买硬件、软件、工具或服务，建立在议定的价格之上

资源————————硬件、软件、工具、资金和人员，围绕任务需要来完成一个项目

支持————————人员、团队和公司完成任务或提供信息，为软件项目的完成提供服务

系统管理——————一个团队，其职责是在一个公司内部，负责有组织的硬件、软件、网络、数据库及其他产品的安装、配置和解决问题

版本问题——————当项目的两个或多个产品、工具、软件或硬件由于一个或多个版本不同而导致不能同步的时候，项目所处的一种“病态”

本章强调

1：项目和团队需要特定的硬件、软件和工具支持

2：硬件、软件和工具支持由人提供。缺陷你对待人的方式不会妨碍你将来从他们那儿获取支持的能力

3：作为项目经理，你需要确保你知道团队所有的需求以及需求发生的时间

4：一旦你知道团队所需要的支持，就确保该支持能按时到位

5：随着项目的进展，未预料到的项目需求将会出现。你需要迅速满足这些需求，而不能损失团队成员珍贵的项目开发时间

6：软件工具需要安装、培训以及实践才能最大限度地发挥作用。确保你不会缩短团队所需要的用来学习、理解和实践工具的时间

7：当一个不正常的学习曲线使得团队想要避免使用工具来“快速结束”时，你需要坚持对工具的使用。否则，跳过对某个工具的使用会给团队造成一种印象，使他们认为以后对于任何任务中的任何工具，都可以跳过不用换

要点

获取硬件（步骤）

1：调查购买过程和所要涉及的关键人物

2：确定你需要的硬件提供者

3：获取采购部门需要的报价表

4：通过采购订单或其他可接受的程序来按皮付款

5：获取负责接受、组装和配置硬件的人员承诺

6：得到在项目生命周期里面有关的硬件维护和解决问题的承诺

获取软件支持（准则）

1：为团队所有的软件获取足够的许可证，如果你能支付得起的话

2：坚持所有的软件许可证协议

3：安排软件的安装、配置和测试

4：获得对意料之外的软件问题和配置问题进行解决的承诺

5：避免让团队成员成为他们自己的系统管理员

6：缺陷你提前安排了软件升级

获取工具支持（步骤）

1：获取并检查待选软件工具

2：安排培训需求事宜，包括房间、硬件、软件、网络和培训材料

3：确认销售商对于软件安装和配置的支持

4：确认销售商针对功能和配置对团队问题的支持

5：对工具要保持强烈的责任

离开起跑线

定义

文化状况————软件团队的文化状况，包括个人对自己、对他人、对团队整体、对团队做决策、解决问题和共同工作直到成功的能力的看法

最后期限————在这个日期以后，一个产品或任务对于项目团队或公司就没有意义了

工程状况————项目团队应用软件工程方法、技术、时间和准则的状况

微观管理————管理团队执行的每个行为和任务的每个步骤

过程精简————从过程规范中削减特定的任务，使得过程更为抽象和更难追溯

过程可见度———项目经理对项目团队完成软件过程的情况的了解和理解程度

项目启动阶段——项目刚开始时一段时间，这时项目团队需要定义和理解产品、技术、项目和过程

重新聚焦————指出并专注于对项目团队最重要的产品、任务或者工具的子集

任务状况————与任务目标和完成相关的特定任务的状况

应对方案————一系列的任务火鹤行为，它并非是直接的、简单的或者要组合到一起的，然而，它是避免一个问题、制作一个产品或者完成一项任务所需的

本章强调

1：引导团队到优先级最高、需要马上完成、将会使项目组织起来和协调起来的任务

2：在项目早期确认和纠正潜在的以及真正存在的文化问题

3：把重点放在项目的技术问题上，以保证它们都用在正确的地方并可以被团队理解

4：在项目早期评估测量的收集、存储和分析行为，这样可以较早地改变以确保收集到的测量讲会最大限度地支持项目

5：较早地开发新方法来监视项目文化和工程状况，这样你作为项目经理可以在项目进展过程中持续地监视这些问题

要点

指导团队（准则）

1：迅速指定和阐明完成任务和活动所需的细节

2：区分团队项目的优先次序

3：保持团队对于项目目标的关注

4：提问，不要发号施令

5：重视过程、进度表、角色、任务和测量

6：将严肃问题与小问题分离开来

7：迅速解决问题

8：将解决方案坚持到底

9：心口一致

实现项目技术（准则）

1：给团队成员分配研究硬件、软件和工具的任务

2：非正式地评估团队成员的知识

3：测试硬件、软件和工具

4：检查结果、确保测试有效

5：耐心支持团队成员完成艰难的学习过程

6：识别并迅速地解决重要问题

7：完全将解决方案贯彻到底

获取测量（步骤）

1：为每个测量的获取指定人员

2：指定如何获取测量

3：指定什么时候获取测量

4：指定如何存储测量

5：指定测量的存储位置

6：检查测量收集过程

7：检查收集到的测量

监视文化状况（准则）

1：监视团队成员对自身角色的满意度

2：监视工程任务之间的匹配成都以确保每个人可以完成相应的工程任务

3：监视团队的整体文化氛围

监视工程状况（准则）

1：监视软件工程最佳实践的实施

2：不断地检查硬件、软件和工具状况

3：监视软件过程的实现

4：监视每个任务直至结束

5：针对问题检查过程

检查任务状况（准则）

1：任务的完成度并不总是定义的很好，因此缺陷你和你的团队了解什么完成了，还留下什么没有完成

2：某些任务通常与其他任务相联系，在生命某个任务完成之前，必须声明所有其他任务已经完成

3：外部因素可能会阻碍任务的完成，因此，应当识别出浙西因素然后减轻他们的影响

4：软件工程师可能会出于个人或项目的原因希望声明任务已经完成，因此要确保任务状况得到了很好的定义

 

监视项目

定义

行动计划————在需要解决一个问题的时候指定谁在什么时间负责什么任务的计划

谴责游戏————与寻找问题的解决方案相比来说，团队成员对责备他人更加有兴趣的情况

群体思想————团队成员在思想和行为上的服从，尤其是当这种服从是无意的并且导致了对主要                                  要观点盲目接受时的情况

经理的检查清单——一个用来阻止一个经理的行为，尤其是用来保证每天联系了所有的团队成员且                                     且识别了项目的短期和长期报告的日常清单

项目方向—————在给定当前项目状况、项目进度表和未来事件时项目将要实行的任务和事件

项目计分板————一个在某一点及时测量项目所有领域的状况和方向的文档化方法

项目状况—————项目的当前状况，包括过程的实现、测量值和文化

项目视图————单个成员或者项目团队对于项目状况和方向的感觉

本章强调

1：在项目进展中不断从软件项目中收集信息

2：整合来自于过程、文化和测量的信息，这样才可以得到尽可能准确的项目视图

                              3：了解项目信息需要平衡信息源，整合项目的多个视图，接受更为准确的视图而不考虑谁对视图的那                            些部分做出了贡献

4:将风险评估、项目状况和方向联系起来使用来避免尽可能多的潜在问题

5：使用团队参与的问题解决方法，决定行动方案，然后监视行动方案直到完成

要点

收集信息（准则）

1：对过程中的所有任务进行计划

2：观察并讨论团队执行的过程任务

3：收集团队对于过程的反馈以确保执行和评估的有效性

4：让测量定期出现在项目状况会议中

5：在状况报告和决策制定中使用测量

理解信息（准则）

1：保持信息源的平衡

2：在你有足够的信息和时间来考虑它之前不要形成你的视图

3：不要先形成一个视图然后再寻找确认它所需要的信息

4：强迫自己考虑和替换的视图

5：如果一个视图比你自己的更准确那就接受它

6：了解什么时候由分析走向决策

经理的日常检查清单大纲

访问每个团队成员

必须要马上完成的任务

                                        

                                        

                                        

需要今天检查的条目

                                         

                                        

                                        

需要今天检查的未来任务

                                        

                                        

                                        

安排的条目

                                        

                                        

避免问题（准则）

1：不断地使用你的风险评估，这样你就会知道会发生什么样的问题

2：将来自团队的测量和个人状况报告用于趋势分析

3：使用新信息来挑战你对项目状况和方向的观点

4：使用你对于团队文化及其变化的认识来避免问题

5：快速解决不一致的问题，而不管是什么引起的或者影响如何

寻找解决方案（步骤）

1：理解问题及其影响

2：让团队参与到解决过程中来

3：指定并衡量多个解决方案

4：选择适合于问题的解决方案

5：指定一个实施解决方案的计划

6：实施并监视解决方案计划

重新安排进度表

定义

档案文件————存储于资料库的某个版本的软件产品，在这里将不会对它做任何变动并且可以取出用于评价或分析

最好的情况————一种情况，其中所有最有利的事件、行动、任务和状况被组合起来，产生了在将来某个时候软件项目可能出现的最好情况

支持者——————团队或公司中努力工作去推动、支持和实现一个任务、行为或者方法的成员

可能的情况————一种情况，项目中在一些人或者团队的眼中，所有可能的事件、行动、任务和状况被组合起来，产生了将来某个时候软件项目最可能出现的情况

最坏的情况————一种情况，项目中所有最少有利的事件、行动、任务和状况被组合起来，产生了在将来某个时候软件项目可能出现的最坏情况

本章强调

1：团队必须跟上进度表，进度表也必须跟上团队

2：进度表需要成为团队规律性的交流、活动和回忆的一部分

3：要经常检查进度表，这样才能考虑和集成每个人的评价

4：进度表要处于版本控制之下，就像其他的项目文档和产品一样

5：为了确定进度表的整体偏移，团队必须考虑偏移的任务、以来于这些偏移任务的任务、对完成偏移任务的估计和对任务的重叠

6：项目经理必须根据新的全局估计考虑偏移量，以确定新估计的精度

7：另外的影响进度表偏移的因素包括团队成员的各项，团队文化和外部因素

8：在你必须重新安排的时候，尽最大可能地考虑风险、对工作量估计的精度和项目的实际情况来进行正确的安排

9：如果项目进度表反反复复地出现偏移，那你就要检查项目、计划和总体进度表，容纳后进行改变，这样可以防止团队继续引发进度表发生偏移

要点

让进度表变得更重要（准则）

1：将项目任务事件和问题与进度表联系起来

2：在团队会议上评价进度表

3：不断地更新进度表

4：宣传项目的进度表

5：征求大家对进度表的看法

6：将进度表作为一个关键项目文档呈现出来

用于了解进度表会在什么时候发生偏移（步骤）

1：确认已经偏移的任务

2：量化进度表的偏移时间以及占原始安排时间的百分比

3：确认哪些任务依赖于哪些发生了偏移的任务

4：考虑跟上进度表的方法，如记录任务和重新划分资源

5：为进度表假设最好、最坏和可能的情况

6：在总体进度表偏移上达成团队的决策

重新正确安排（步骤）

1：选择前向或后向安排方法

2：如果你可以前向安排，那么：估计偏移的任务，考虑进一步偏移的可能性

                          小小地重新安排相关任务，考虑这些变化时如何影响任务重叠的

3：如果你必须后安排，那就：使用可能存在的多余资源

                           减少软件活动的余地

4：将新进度表文档化并进行检查和修订，在适当的地方进行修改

设计伟大的产

定义

接受性测试————用来评估产品是否为客户的接受和运行做好准备的软件测试

特别测试—————没有脚本的软件测试，在这种测试中，测试人员通过同软件进行系统交互来对该软件进行测试，这种交互的方式是基于需求规范的，而且这种交互是在该软件部署之后用户的典型交互行为

代码检查————通过设计文档对软件设计进行的检查，目的是为了发现缺陷和提出改造

凝聚力—————设计和代码的一个特点，在这里面每个单元和子系统都提供了一个功能或一系列相关功能

耦合——————设计和代码的一个特点，其中每个单元或者子系统都需要其他单元或子系统才能提供所需功能

关键路径————一系列为完成一个任务或者阶段所必须完成的活动或任务

设计的一致性——单个问题解决或系统分割的规则和准则和整个软件设计中的应用

可扩展性————向一个软件产品添加功能的难易程度

实现计划————详细阐述一个软件产品的代码如何开发、集成、控制和测量的计划

信息隐藏————设计和代码的一个特征，在设计或代码单元的外面看不到具体的实现细节

隔离——————设计和代码的一个特征，允许对设计或代码的某个部分改变而不会对设计或代码的其他部分造成影响

可维护性————维护一个软件产品的难易度，包括纠正缺陷、改进性能或者添加功能

模块性—————软件产品的一个特点，即软件产品可以分割为一系列单元，这些单元使软件的改变、提高系统的可理解性和降低复杂度变得更为容易

可移植性————将一个产品移植到另外一个硬件或软件平台的难易程度

急板影响————软件项目或团队中未知或为纠正的问题的影响，它马上产生负面影响

需求————软件系统的功能和行为

需求的一般性———在高度抽象的层次定义的软件系统的功能和行为，使得可以有多个具体的功能和行为用来满足需求

软件架构————组成软件系统的各个软件单元之间的互连接性和关系

软件工程实践————软件工程规范中通用的可以为软件项目或产品带来好处的活动

软件工程原则————引导软件项目的执行和软件产品的创建和维护的通用规则和原则

系统测试——————系统测试时用来评估软件产品是否为进行接受性测试或发布做好了准备的方法

可测试性————为了发现缺陷和支持正确的活动而对软件产品进行测试的难易程度

本章强调

1：需求需要时间和很大的投入。项目经理必须在急躁的行动和匆忙的需求规范之间维持平衡

2：在项目中持续需求的规范、澄清和修正

3：软件设计需要规范、与其他设计进行比较以及一系列基于一致性的准则和方针

4：设计的一致性是通过实现团队的会议、检查和实现代码同步的设计文档来维护的

5：需要使用实现计划对实现进行提前规划

6：实现需要监视细节、符合标准和避免版本问题

7：测试需要根据具体的目标进行计划

8：测试最好在需求、设计和实现期间同时进行确定

9：需要分析测试结果，以理解完成情况和进展状况

要点

收集需求（准则）

1：安排时间来对特定的需求进行提议、考虑和归档

2：攻击需求的一般性

3：确保需求的一致性

4：坚持需求；控制自由变动的变量

5：知道什么时候说什么；够了就是够了

6：在需求完成之前要牢记这些没有完成的需求

7：使用测量

管理设计（准则）

1：提供时间来提议多种设计

2：更加设计质量在多个设计中进行选择

3：攻击设计的一般性

4：保证设计的一致性

5：加强设计准则和规则；控制自由变动的变量

6：使用测量跟踪设计进展和变化

7：重复直至项目完成：文档化、评价和跟踪设计

实现软件（准则）

1：了解在什么时候实现什么

2：利用“短跑选手“（优秀的、聪明的人）；帮助”步履艰难者“（不太聪明、但辛勤工作的人）

3：避免版本问题

4：关注所有的细节

5：检查代码

6：使用测量

软件实现计划大纲

概述——用三到四段描述实现计划最显著地目标

高级里程碑——描述实现过程中的里程碑

实现人员——描述针对系统实现的每个部分而进行的软件工程师的分配

软件过程——描述单元开发跟踪，登录/退出过程，构建过程和测试活动

软件工程方法——描述本项目将要使用的实现方法和技术，并阐述编码标准文档以及如何执行编码标准

测量——列出将要收集的测量的清单、进行收集的实际、负责收集的角色，以及测量的存放位置。包括测量分析和利用的总看法

实现风险——每个显著地实现风险占用一段，按照风险的可能性或者风险影响的大小顺序排列

软件工具——列出每个软件工具及每个工具支持的实现任务

软件支持——有关所需软件的特定信息，包括将要获得、安装和升级的软件

人员支持——有关针对实现任务为团队提供支持的人员或小组的信息

测试软件（准则）

1：对则是制定计划

2：设定测试目标

3：较早地并经常地测试

4：强制测试和测试结果明确化

5：分析结果

6：只有通过了测试才算结束

交付系统

定义

快速止血修复————对软件产品、安装包或部署进行一个临时的修正；它能解决问题或缺陷，但只在短时间范围内才会有效

完成标准——————一个状况和任务的集合；只有符合了集合中所要求的状况，完成了集合中所要求的任务，才能宣布软件的交付成功完成了

部署————————一个要在客户得点执行的任务集合，其目的是在客户软件环境中安放软件产品，这样用户才能顺利地使用这个软件产品

演习————————执行软件安装或部署的一个或更多部分的行为；这项工作要在用户环境中执行安装或部署之前进行，以发现缺陷或问题

冰山效应————对一个项目的负面影响，而且当前抑制的问题只是一个潜在的大问题的一小部分

安装包————一个文件或一个文件集合，它拷贝、防止、联系并操纵所需的文件来把软件产品成功地放置到软件环境中，并有可能会重新被指用户的计算机，这样用户才能顺利地使用软件产品

电子魔方循环——一个软件项目所落入的循环；在这个循环中，在产品的一部分中修正了相关的问题，却导致了项目的另一部分的问题，随后对新问题的修复又产生了其他部分的问题，直到一系列随后的修复又破坏了产品中原本已经修复好的那一部分

软件环境————在一体爱计算机或一个计算机网络上的软件配置；它包括操作系统、软件包、安全软件和它们之间的相关性

担保————安装或部署后的一段时间；在这段时间内，软件开发公司的部分员工提供正确的维护行为和对用户的支持

本章强调

1：正确地交付一个软件产品以确保一个项目的成功完成

2：结束一个项目需要进行计划

3：对结束一个项目所进行的计划要根据客户指定的软件产品和非定制产品而不同

4：要按照一定的步骤来计划产品的交付

5：执行交付计划需要有效地管理任务、要求和问题

6：对于客户的支持经常是软件开发的组后阶段而且不能忽略

7：成功的项目要执行成功的交付计划并提供质量支持

要点

对软件项目的完成进行计划（准则）

1：要在项目早期就对交付进行计划

2：要及早并且经常地对按照何部署进行测试

3：要及时地解决安装和部署问题

4：把测量作为安装和部署工作的一个常规部分

5：检查，检查，再检查

计划部署（步骤）

1：研究当前的环境和部署后的环境

2：确定成功完成的标准

3：略述任务和任务次序

4：通过“任务——人员”配对来计划部署

5：预期可能出现的问题并为之做出准备

执行软件交付（准则）

1：对解决方案进行工程化

2：记录问题及其解决方法和决策

3：对升级、服务包和替换方案进行计划

4：监督并跟踪客户经历

5：检查完成的标准

提供客户支持（步骤）

1：在项目早期就确定支持的类型和期限

2：明确支持的项目需求

3：用“要求——分配”匹配来对支持进行计划

4：对支持的质量及其执行进行评价

5：明确支持的终点

评价项目

定义

数据贫乏————一个项目或项目的一个领域只有很少或没有测量可以用来进行分析的情况

无记忆的————个人、团队或公司没有记录和运用以前的经验来改进对未来项目的执行

标准化—————通过数据比例缩放、转换或运用其他数学技术得到可以进行比较的量

过程评价————检查和分析一个公司的多个项目，以确定在公司范围内可用于未来项目的过程改进

项目领域————为一个软件项目提供特定的功能而需要花费显著工作了的主要领域

项目评价————检查和分析一个项目，以确定可用于未来同类型项目的改进

项目历史————设计到软件项目的文档化和非文档化的过去事件

本章强调

1：评价需要计划

2：要对评价进行管理和监督，以记录意识的测量和信息、使团队将精力集中于发现改进，以及要保证评价按时完成

3：对评价的分析应该保持简单，并综合项目信息，以得到正确的结论

4：测量应该标准化，这样它们就可以合乎逻辑地正确地对照、比较和理解

5：有些评价结果只需要说说而不要写下来，这样它们就不会被有意或无意地滥用

6：要对成功的项目进行评价，并把得到的改进运用到后续项目中

要点

对测量进行分析（准则）

1：使用工具可以快速而且准确地进行测量

2：要让分析易于执行和解释

3：不要把预想的结论具体化

4：使用项目信息

5：发现问题就要解决问题

提交评价项目（准则）

1：首先要指定格式

2：按固定的顺序：从问题到数据，再到分析，最后到改进

3：要易于分发和理解

4：任何人都能发现问题——发现能改进的地方

5：评价只要用来获得改进才是有益的