管理团队环境
每天，我都不止一次地意识到，我外在和内在的生活是如何建立在他人劳动的基础之上，他们有的还活着，有的已经不在这个世界上了；我也意识到我必须一心一意地努力，以回报我所接受的一切恩泽。当我想到我借用了别人太多的成果时，我的内心就会因为这种痛苦而不再平静。---------阿尔伯特.爱因斯坦
这是一个小测试。这段话和你对天才爱因斯坦的想像相符吗？你能想到爱因斯坦对别人劳动的感激之情如此强烈吗？
管理者一个非常重要的任务，就是创建并培养一个有适应能力的团队。没有这样的团队，任何一个软件组织都无法建立驾驭自如型文化，或者超越未雨绸缪文化。
第18章 为什么是团队？
当一组人共同执行某个设计时，他们和一个管弦乐队很相似，但绝不是团队。对一个真正的团队来说，要么有一个带着鞭子的驱策者，要么有一个对立的团队存在。在管弦乐队中，每个演奏员-----（工人）都在诠释-----（工作）----同一个乐谱------（设计）-----并且演奏各自的乐器----（应用专门技术）------作为专家在需要他们的舞台上表演。
---------------------大卫.派
Ø 趋于完美的团队
最容易看到团队影响质量的地方之一就是侦错团队。他们的任务是负责找到发生错误的位置，防止错误报告中的问题不断循环地出现并且找人解决它们。这些没完没了的问题最常在反复无常型组织中出现，在这些组织中，管理者经常以建立更有效的侦错团队来达到立竿见影的效果。
1） 各种各样的眼睛
要建立一个有效的侦错团队，你首先要做的是选择多样化的成员。多样化对侦错团队来说异常关键------多样的经验、组织中的关系，特别是多样的思维模式。
2） 责任之旅
l 有了多样化的团队后，管理者的下一个任务就是把所有的成员召集到一个房间里，寻找一段独立部分中的错误。
l 在面临危机时，成立侦错团队是一个非常有效的管理手段。
l 把人们集中在一个房间内处理问题，能激发希望和兴奋感，另外，这种情感可以感染整个组织。
3） 平行和“比较”
l 有时，减少侦错时间是非常重要的。
l “看谁先找到”这样一种适度而友好的竞争被证明具有一定的激励作用，只要它不失控。我把这个方法称之为“竞合”，意思是“竞争的合作”。
l 很容易就能指出各种秉性的人对待“竞合”的态度。团队建立者们会抵制该做法，因为他们害怕团队一旦失败会很尴尬。组织者会担心两个团队致力于同一个问题所导致的效率问题。展望者有时会认为应该让最好的团队独自去解决问题。可是，到了麻烦解决者这儿，他们会非常喜欢这个办法，因为这在工作之外还带来一种做游戏的感觉。
Ø 技术评审团队
纠错过程的一个部分就是选择一个方案。另一个部分就是对每一个提出的方案进行评审，以防止方案实施时出现大的副作用。
1）错误预防
在纠错过程中，最大的失败往往来自解决方案的副作用，或者解决其他问题时造成的新错误。
2）过程改进
l 评审通过直接发现错误来实现。测试则通过跟踪运行失败后面的错误来实现。两者都用于改进产品，但评审还用于改进过程。
l 评审的过程本身也是个学习的过程。管理者还可以利用评审来改进评审之外的过程。
l 一旦感受到技术评审的好处，评审时间的安排就变得很重要了。较迟的评审会让你有更多的机会找到目前为止发生的错误，也能找到更多的从前评审中的错误。另一方面，较迟的评审使找到错误的根源变得困难。而早期的评审能够提高这种识别能力，这也正是评审的真正利益所在。因此，管理者可以通过尽早举行的评审会来影响产品和流程的质量。
l 有的管理者通过指责评审团队来为继续这个明显缺陷的产品找理由。这是个很严重的错误。评审团队的成员们是管理者而不仅仅是消息的来源。管理者的职责是要听到信息而不是杀死报信的人。
3） 减少不确定性
l 技术评审最引人注目的效能（当与精心设计的机器测试一起应用时）就是它减少不确定性的方式。
l 对管理能力来说更重要的是，评审能够减少质量的不确定性和因此需要的测试时间。
l 评审是测试的一种形式。评审和其他测试一前一后地应用，能够产生缺陷的系统，并且在项目结束的时候减少机器测试的时间。
l 更微妙的变化是，当代码评审的质量提高时，产品的不确定性降低了。测试时间不确定性的降低意味着项目的测试阶段更容易管理了。带到系统测试中的错误数量的减少意味着测试时间变得更容易预测了，这又表明了更好的可管理性。
第19章 成长的团队
1）可重复使用的工作单位
一旦我们设计了可用、可靠、并且可重复使用的模型集合时，我们就能够降低成本，提升品质，并且提高软件研发的可预测性。
2）维护团队
l 关于可重复使用团队的最强烈的观点之一，就是它们已经以维护团队的形式遍布于组织之中了。不幸的是，许多管理者并没有注意到表现好的维护团队，他们恰恰就是最能被重复使用的团队。
l 通过使用维护团队，组织能确保重要系统不会因为某个人的离去而变得抵抗力下降。
3）通过改进团队流程进行管理
l 通过改进团队流程，个人的进步过程能被拓展至管理中。这个办法是建立在多维共同创造的思想上的：
l 建立团队并培训他们互相吸取优点的技巧。
l 分析表现最好的团队和个人，弄清楚表现好的原因。
l 发展培训和技术评审系统，传播这些优秀的过程。
第21章 团队的启动和终止
直至面临灾难之前，没人能真正了解自己；只有在危机时刻，我们才会知道自己真正的身份；许多人一生都认为自己很强，但实际上，他只是很安全罢了。---西德尼.哈里斯
l 管理者在团队方面的任务是在需要的时候建立团队，它能有效运行时就放手让它发展，否则，终止该团队。
l 在危机时刻成立团队不是件普通的任务。当整个组织一片沮丧时，你可能需要一个有经验的推动者参加团队的第一次会议。组建团队时必须确保团队每一分子有一些其独特的作用。
l 对于一个长期团队来说，在研发和维护过程中自然形成团队比在危机时刻组建团队要好。管理研发团队的窍门不是项目一结束就解散它们。
l 现有的团队也能成为变革的障碍。他们认为成立新的任务解决团队会破坏他们现有的挤在一起的状态，或者害怕别人指责他们的工作没有做好。
l 如果管理者放手让团队去发挥，运转良好的团队就会成为他最有价值的资产。真正的团队比一般的管理者要强壮得多，不太可能被高层管理人员吓倒。团队的观点更有分量。
l 项目落后的时候，真正的团队不会慌乱。那些自己乱了阵脚，但却不愿意看到团队保持镇静的管理者们经常要把他的慌乱传染给团队。然而，一个经验丰富的团队通常会同化这位经理的不协调，镇定地工作。
l 一个突然插入团队日程的外部任务，会干扰团队的其他工作。团队可以通过任命专员的方式来解决这个问题，比如专门为客户和高层做演示说明的人。总之，团队在设计和实现任务优先级别时表现很好。
l 团队不可能自行解决每个问题。有时候某成员不能与他人合作因而必须离开。作为管理者的工作是进行干涉并且改变团队的组成。
l 团队成功的最大障碍来自某位个体的态度：“因为这是我的，我不容别人染指，甚至看都不能看一眼。”或者“这不是我的主意，所以不可能是最好的主意。”这种封闭的态度对软件工程来说简直就是灾难。因此，坚决不能允许。如果你决心改变这种态度，典型的方法是换人。不是每个人都适合软件组织的。
l 有时团队因为无法识别的原因，或某几个人的原因而丧失功能。这时，你应当介入并在警告无效后解散该团队。
l 一旦管理者成立了一个团队，他们就会自我生存，并可能在需要变革的时候很难被解散。因此，避免成立一个当没有作用时你很难解散的团队。当你创建了临时团队时，给他们一定的时限，时限结束后让他们自己证明继续存在的理由。
l 看起来失去功能的团队也许会有你料想不到的其他功能。在解散他们之前，考虑他们其他的用处。