第11章 Teamwork（团队合作）
高绩效的团队有时体现为已“胶冻”的团队或凝聚力强的团队。一个高绩效的、胶冻的、凝聚力强的团队具有如下特点：
l A shared, elevating vision or goal（共同的、催人向上的愿景或目标）
l A sense of team identity（团队认同感）
l A result-driven structure（结果驱动的团队结构）
l Competent team members（胜任的团队成员）
l A commitment to the team（对团队的承诺）
l Mutual trust（相互信任）
l Interdependence among team members（团队成员相互依赖）
l Effective communication（有效沟通）
l A sense of autonomy（自主意识）
l A sense of empowerment（授权意识）
l Small team size（团队规模较小）
l A high level of enjoyment（高层次的乐趣）
下面是关于打造团队合作的一些建议。注意：下面的几点应该同时做到，如果有一个没做到，团队建设就可能遭遇失败。
1. 建立共同的、催人向上的愿景或目标
在项目真正动作之前，一个团队需要获得一个共同的愿景或共同的目标。没有这一共同的愿景，就不会产生高绩效的团队合作。
共同的愿景有时是有重要意义的事，有时又可能是一件不甚重要的事。愿景实际上可以是任意的，但只要愿景被整个团队共同拥有，它就能帮助团队凝聚在一起。
为了起到激励的作用，愿景又需要催人向上。制定催人奋发的愿景或目标，是构建高绩效团队的第一步。
2. 选择胜任的团队成员
一些软件经理常因为错误的原因为团队挑选了错误的团队成员。挑选团队成员时，应以项目目前最需要的技能为标准。以下三种能力最重要：
l 特定的technical skill。例如：应用领域、平台、方法论和编程语言
l 强烈的对团队作出贡献的意愿
l 善于与他人有效地合作
另一方面，一个团队需要多方面的人才，而不是全部由技术高手组成。一个好的团队中，不同的人乐于在不同的时间扮演不同的角色。团队不能正常运转的一个征兆是成员对于他们是否接受某方面工作表现得非常坚决。
如果不幸，团队中存在害群之马，那么必须对这类问题员工进行处理，决无例外。问题员工很容易识别，如果你稍微花点心思的话。
l 他们宁愿掩盖他们的无知也不愿意试着向其他成员学习。（“我不知道如何解释我的设计，我只能说它确实可行”或者“我的代码过于复杂而无法测试”）
l 他们有过分的保密欲望。（“我不需要任何人review我的代码”）
l 他们的本位观念很强。（“没人能修复我的代码中的bug。我现在太忙了，没空修复这个bug。我下周会修复它的。”）
l 他们抱怨团队的人决定，在团队作出决定之后还不断回到老路子上。（“我仍然觉得我们该回过头去修改我们上个月谈到的设计。我们选择的这个设计是不会成功的”）
l 其他团队成员都取笑或抱怨同一个人。软件开发人员通常都不直接抱怨，所以当你听到很多俏皮话的时候，必须询问是否出了什么问题。
l 他们从不积极参与团队的活动。
对于问题员工，可以首先尝试指导他/她如何作为团队的一份子去参与工作。如果指导不能很快产生效果，不要怕，直接解雇他。
3. 营造有效沟通的氛围
必须为团队营造起有效沟通的氛围，鼓励团队成员表达他们真实的感受，即使这是种不好的感受。在相互依赖和信任的环境里，当团队成员一旦意识到有不愉快的问题，他们就会提出来，这样还有时间进行有效的补救行动。
4. 维持一支长期的团队
有战斗力的团队多是长期培养的结果，因此持久地维持一支团队，让团队成员相互磨合，整个团队都会长期受益。
5. 打造团队成员的认同感
软件经理应该多创造机会增加成员对整个团队的认同感。认同感的建立包括对工作及时的鼓励和肯定、聚餐、户外活动和参加运动等。
第12章 团队结构
在决定团队结构时首先应考虑的是团队的广义目标。以下是三种团队的广义目标：
l Problem resolution（解决问题）
l Creativity（创新）
l Tactical execution（战术执行）
一旦确定了团队的广义目标，就需要一种能与该广义目标最关键特征相匹配的团队结构。请见下表。
|
| Problem Resolution | Creativity | Tactical Execution |
| 最关键特征 | Trust | Aotunomy | Clarity |
| 典型软件示例 | 对已上线系统的纠错维护 | 新产品研发 | 产品升级研发 |
| 过程重心 | 对issue的关注 | 探索可能性和各种备选方案 | 角色和目标高度明确的任务，并通常具有明确的任务成败标准 |
| 团队成员选择准则 | 理解力强，聪明，感觉敏锐，高度诚实 | 睿智的、独立的思考者，做事主动，顽强 | 忠诚，信守承诺，侧重于行动，有紧迫感，积极响应 |
软件经理必须明白：没有哪一种团队结构在所有项目中都可以实现最快的开发速度。最有效的团队结构取决于实际的项目情况。
目前的软件团队大多采用Feature Team的组织形式。如下图所示。
![clip_image002[4]](http://images.cnblogs.com/cnblogs_com/lijia821130/201209/20120901210127856.gif "clip_image002[4]")
而在开发人员内部，常常采用Business Team或Chief-Programmer Team的组织形式。
![clip_image004[4]](http://images.cnblogs.com/cnblogs_com/lijia821130/201209/201209012101284868.gif "clip_image004[4]")
大型团队在沟通和协调方面存在着特殊的问题。大型的项目要求组织将沟通正式化和简化。任何简化沟通的方法基本上都是引入层级结构，即划分出small group，然后指派small group的代表与其它small group和管理层进行沟通。你可以有如下的方法来创建small group：
l 形成多个Feature Team，让每个Feature Team的项目管理代表同其他group进行沟通。
l 形成多个Business Team，并在business team中指派一个联络人同其他group进行沟通。
l 形成多个Chief-Programmer Team，并让Backup Programmer同其他group进行沟通。
团队结构的另一个问题是：Project Manager与Technical Lead之间缺乏清晰的职责划分。鉴于项目经理/技术领导二者的关系难以界定，技术领导和项目经理应该在项目启动之初就讨论彼此的角色，这有助于避免职责冲突。下图可以作为这种讨论的参考。
![clip_image006[4]](http://images.cnblogs.com/cnblogs_com/lijia821130/201209/201209012101303034.jpg "clip_image006[4]")
第13章 Feature-Set Control（功能集控制）
最严重是Feature-set control问题是需求蔓延，即在产品开发的晚期增加需求。那些未能控制需求蔓延的项目都非常容易受到过度的进度的影响。若干研究已经发现，需求蔓延是造成cost及time超出预期的最普遍原因之一，而且也是项目被取消的一个主要因素：由于需求蔓延而导致的变更，使产品不稳定直到产品根本不可能完成。
项目后期破坏性的需求变更与软件的进度拖延之间是因果关系。软件经理必须理解这种关系，牢记在心，并在项目规划的最基础层面上解决它。Feature-set control构成了软件项目四维中的Product维。
有三种常见类型的feature-set control：
l 项目早期控制：制定一个与项目进度和预算等目标一致的feature-set。
l 项目中期控制：控制需求蔓延。
l 项目后期控制：砍掉feature，以满足进度或成本目标。
成功的软件项目会综合使用了这三类feature-set control方法。
13.1 项目早期：Feature-set Reduction
一个项目的早期feature-set control手段主要就是从一开始就不把不必要的功能放入产品中。快速开发的第一条戒律就是“narrow your scope”（缩小产品范围）。有三种基本的方法：
l Minimal specification（最小化的需求规格书）
l Requirements scrubbing（需求筛选）
l Versioned development（版本化软件开发）
13.1.1 Minimal Specification（最小化的需求规格书）
当制定项目需求时，经常遇到的问题就是需求规格书要详细到什么程度。传统智慧认为需求规格书越详细越好。但是，详细的需求规格书也有一些缺点：
l 浪费。你可能花费时间去事无巨细地规定连用户都根本并不关心的系统特征。
l 过时。项目进行过程中的变更会使需求文档很快变得过时。很可能你一开始详细地规定了feature-set，但后面却为了响应市场状况和客户要求的变化而修改feature-set。
l 缺乏功效。以十分详细的方式陈述系统需求并不中心保证系统的成功。系统可以满足需求规格书的条款，但可能仍然不能令人满意。
l 过分约束软件设计。为软件规定过死可能导致浪费时间的软件设计和代码实现。
可以倡导撰写一份minimal specification。一份minimal specification应该是：包含能够有意义地描述产品的最少量信息。Minimal specification可以由以下任意的内容组成：
l 简短的书面spec。这是对拟开发软件的文本描述，它应该不多于10页。
l Point-of-departure spec。这是一次性的近似规格书，写完后不做变更。它的主要目的是使开发人员、客户及最终用户对产品形成共识。一旦各方达成共识，这份spec就完成任命，不需要再维护了。
l 把user maunal（用户手册）作为spec。撰写用户手册以代替传统的spec，并要求软件与手册一致。这个想法的一个变通作法是撰写一份在线帮助系统。
l User-interface prototypes。用户界面原型既可以作为实际的spec，也可以用作对文本spec的补充。假如认真撰写的话，一图抵千言，可以节省大量的时间。
l Paper storyboard（书面的情节串联图板）。有时，使用“低科技”的图板来画出报表、屏幕或UI控件反而更快更容易。
l 愿景陈述。创建一个愿景陈述，以描述哪些应该放到产品中，哪些应该从产品中去掉。
l 产品主题。为产品创建一个主题。主题与愿景是有关联的，它们是控制feature-set的良好机制。
保证minimal specification的关键因素有：
1. 仅当需求具有灵活性时才使用minimal specification。
2. 获取重要的需求。完成一份优秀的minimal spec需要对用户真正关心的需求有特殊的敏锐度。
3. 关键用户的参与。为软件产品找到了解业务需求和组织需求的人，并让他们参与到产品的需求分析和开发中来。
4. 尽量使用图形类的文档。图片、输出示例和原型式的spec往往比文本式spec更容易撰写，用户也更容易理解。
13.1.2 Requirements Scrubbing（需求筛选）
需求筛选，即彻底地从产品中删除（砍掉）一个feature，是缩减软件进度计划最有效的方法之一。而且，需求筛选比minimal spec的风险要小。
| 最佳实践：Requirements Scrubbing（需求筛选） 1. 在创建了一个产品的需求规格书之后，对照以下的目标将规格书梳理一遍： l 排除所有的非绝对必要的需求 l 简化所有的复杂需求 l 如果某项需求有更省时省力的方案，就把它替换成该方案 2. 要明白这一实践的成功在于坚持，被砍掉的feature就是不能被加入到feature-set中。 |
13.1.3 版本化软件开发
版本化软件开发是指把某些feature推迟到后续版本开发。
13.2 项目中期：Feature-Creep Control
一个典型的软件项目会有约25%的需求变得。因此在项目进行过程中控制好需求变更以防止feature creep（功能蔓延）就非常重要。要在项目进行过程中完全冻结需求规格不太现实，用户会认为项目的响应度非常差。因此，在项目进行期间的主要问题不是冻结需求，而是如何有效地管理需求变更。以下是一些常用做法。
1. Change Analysis（变更分析）。对需求变更请求进行分析，提供该变更对项目的cost、resource和schedule的影响报告，让客户自己去评估是否还需要进行该变更。
2. Version 2（下一版本完成）。拒绝在当前版本中进行需求变更，但承诺会在未来版本中进行变更。不必强调该变更一定会在第几号版本中实现，但应强调你正在倾听用户关心的需求和计划在适当时间实现它。
3. Change board（变更委员会）。变更委员会已被证明能够有效地阻止大型项目中的需求蔓延，并且对于小型项目同样有效。
| 最佳实践：Change Board（变更委员会） 1. 从项目的需求分析阶段结束之后，就建立变更委员会。 2. 该委员会是由产品开发中具有利害关系的每一个小组的代表组成，如来自开发、质量保证、用户文档、客户支持、市场和项目管理方面的代表。 3. 该委员会对每一处变更请求进行分析，分析该变更对项目的cost、resource、schedule和feature的影响和对每个小组的影响。 4. 在分析的基础上，变更委员会将决定对变更请求的处理措施： l 在当前版本中引入变更，并重要估算项目进度和所需资源。 l 推迟到下一版本。 l 无视该变更请求。 |
13.3 项目后期：Feature Cuts
如果项目进度已经落后于估算进度，那么保证按时交付的办法只有砍掉优先级低的feature，把资源集中到保障高优先级的feature。