团队制胜:掌握软件项目成功主动权(华章程序员书库)
点此进入淘宝搜索页搜索分類: 图书,计算机与互联网,软件工程及软件方法学,软件过程,
品牌: 布鲁斯欧
基本信息·出版社：机械工业出版社
·页码：275 页
·出版日期：2009年
·ISBN：7111255054/9787111255055
·条形码：9787111255055
·包装版本：1版
·装帧：平装
·开本：16
·正文语种：中文
·丛书名：华章程序员书库
产品信息有问题吗？请帮我们更新产品信息。
内容简介《团队制胜——掌握软件项目成功主动权》介绍在软件开发过程中团队之间如何实现高效的合作。《团队制胜——掌握软件项目成功主动权》从个人、团队和利益相关者等三个方面进行组织，讨论主题包括个人、质量、责任、主动性、可持续性、沟通、动机与期望、合作、一致性、组织、协调、指导、客户、目标设定、规范、优先级、变更等，基本上涵盖了构建高效团队合作的各个方面。
《团队制胜——掌握软件项目成功主动权》适合软件开发人员与管理人员参考。
作者简介Jim Brosseau，自1980年以来一直在软件行业中工作，从事过测试、开发，担任过项目经理以及讲师。他在嵌入式电子设备、ATC系统和商业软件包等领域有着丰富的开发经验和管理经验。Jim是Clarrus Consultirlg Group公司的负责人．自1998年以来，为世界各地的众多组织提供咨询服务，帮助他们改进交付软件的方法。他在Cutter IT Joumal杂志上发表了多篇文章并且担当顾问，出席过许多重要的会议并参与地方行业协会。Jim与他的妻子和两个孩子生活在温哥华。
媒体推荐如果希望在软件团队中推动一些行之有效的变更或者施以更大的影响力，那么有两种选择：一种选择是自行对各种技术进行实验，在黑暗中摸索几年；另一种选择就是购买本书，阅读并且应用书中所给出的技术。当然，究竟如何选择，决定权在于你自己。
——Matthew Heusser
Jim Brosseau对于IT工作环境中各种驱动因素的真知灼见在本书中得到了充分的体现。对于提供IT解决方案的开发人员和管理人员来说，他在书中给出的见解不仅能促进项目朝着更好的方向发展，而且能使工作本身也变得更为轻松。
——Bruce A.Stewart，Accendor Research公司CEO
编辑推荐优化软件开发中的人力因素
基于真实数据和经验的解决方案
《团队制胜——掌握软件项目成功主动权》是一本令人信服的、全面创新的以及切实可行的指导著作，它能够有效地改善在构建优秀软件中的一个重要方面——人力因素。
通过与众多团队的多年合作，Jim Brosseau在书中阐述了如何通过小规模的、立竿见影的变更，来逐步推动大型的改进工作。这些变更针对团队整体来设计，充分考虑现有的组织文化。此外，Jim Brosseau还提供了每个人都可以立即付诸实施的方案，而无需等待管理层来推动。
无论采用何种方法，技术或者组织结构，通过阅读《团队制胜——掌握软件项目成功主动权》，你都能够掌握如何将各种解决方案应用于实际的开发环境中，这些实际问题往往涉及错综复杂的利益相关者。Jim Brosseau还与读者共同分享了在面对项目管理软件方面的问题时，人们的态度、动机和人际关系方面重要的新观点。
《团队制胜——掌握软件项目成功主动权》是一本启示录——对于每个项目团队成员、领导者以及利益相关者来说，它是您工作中的一份宝贵的参考资源。
目录
译者序
图标说明
前言
第一部分 问题空间
第1章 我们面临的巨大挑战
1.1 困难
1.2 缺乏远见的解决方案
1.3 人力因素的脆弱性
1.4 最优方法的真相
1.5 小结
第2章 做正确的事
2.1 正确地做事与做正确的事
2.2 做事的方式
2.3 我们需要掌控成功
2.4 解决方案框架
2.5 小结
第二部分 个人
第3章 个人的正确态度
3.1 牛仔和无名英雄
3.2 合理的自我批评
3.3 情绪
3.4 加快进度
3.5 我们都是领导者
3.6 小结
第4章 以质量为中心
4.1 质量是一种责任
4.2 输出质量理念
4.3 按照人员、过程、产品的顺序
4.4 小结
第5章 面对挑战
5.1 感受痛苦
5.2 应对痛苦
5.3 否定
5.4 忽视
5.5 毅力
5.6 思维定式
5.7 小结
第6章 主动性成效
6.1 认识你自己
6.2 赌徒与冒险家
6.3 设计我们的环境
6.4 并行工作
6.5 决策
6.6 坚持到底
6.7 小结
第7章 可持续性
7.1 什么才是重要的
7.2 充电
7.3 闻一闻玫瑰的花香
7.4 将内省作为一种商业策略
7.5 生活质量
7.6 小结
第三部分 群体
第8章 沟通
8.1 表达自己的意见
8.2 舒适的沟通
8.3 全面公开
8.4 信任
8.5 客户满意度
8.6 明确性和共同的理解
8.7 沟通的消极面
8.8 小结
第9章 动机与期望
9.1 动机驱动行为
9.2 成为一个激励者
9.3 公开我们的动机
9.4 反思阿喀琉斯之踵
9.5 期望
9.6 管理我们的期望
9.7 没有消息其实就是最坏的消息
9.8 小结
第10章 合作愉快
10.1 技术赎金
10.2 游戏
10.3 工作保障
10.4 谣言和暗讽
10.5 尽量减少干扰
10.6 质量圈族谱
10.7 就像在家里一样
10.8 小结
第四部分 团队
第11章 一致性
11.1 团队保持一致
11.2 团队规模的增长
11.3 与团队保持步调一致
11.4 制订规则
11.5 有意识的团队契约
11.6 包容各种观点
11.7 按比例缩放
11.8 小结
第12章 组织
12.1 各得其所
12.2 已定义方法，还是科幻小说
12.3 过程架构
12.4 阅读组合方法说明中的小字内容
12.5 这是一个过程项目吗
12.6 通过优化提升速度
12.7 培训
12.8 当问题出现时
12.9 但是我们不在乎
12.10 有条理的讨论
12.11 小结
第13章 协调
13.1 清理路障，还是阻塞道路
13.2 开诚布公的管理
13.3 只是一名雇员吗
13.4 检出，检入
13.5 对文档化工作的态度
13.6 不要轻易地将一切都外包
13.7 有人情味的平衡
13.8 保留上下文
13.9 小结
第14章 指导
14.1 胡萝卜和大棒
14.2 可控的多样性
14.3 是懒惰还是创造力
14.4 捷径
14.5 过程工效学
14.6 规模并不重要
14.7 持续的一致性
14.8 小结
第五部分 利益相关者
第15章 客户
15.1 谁是我们的客户
15.2 终端客户的代表
15.3 真实可靠
15.4 掌控期望
15.5 小结
第16章 设定目标
16.1 目标和任务
16.2 定义成功
16.3 根据产品的优势调整优先次序
16.4 是否真正重视产品质量
16.5 滑坡
16.6 全局观
16.7 小结
第17章 规范
17.1 意外的规范
17.2 规范的锥体特性
17.3 保持领先一步
17.4 到什么程度才是足够的
17.5 小结
第18章 优先级
18.1 正确的开端
18.2 在确定优先级之前首先制定计划
18.3 优先级排序
18.4 衡量和确定项目范围的优先级
18.5 拖延带来的成本
18.6 小结
第19章 变更
19.1 变动性要求多样性
19.2 偏离预计路线
19.3 通过配置管理来了解我们当时的思考
19.4 只需再多一点
19.5 小结
第20章 进展
20.1 三个关键角色
20.2 一种有条理的方法
20.3 解决难题
20.4 有风险的业务
20.5 关键路径
20.6 文档签字的含义
20.7 知道何时退出
20.8 完成
20.9 小结
第六部分 理清思路
第21章 挑选目标
21.1 正确的过程
21.2 规则
21.3 解耦项目
21.4 亡羊补牢
21.5 小结
第22章 灵活性和严格性
22.1 指导与规定
22.2 检查列表与签字
22.3 真正的设计问题：多样化和趋同
22.4 文档化和公共知识
22.5 避免发展过程中的复杂性
22.6 张贴出来
22.7 小结
第23章 回顾进展
23.1 将量化作为一项必要工作
23.2 战术度量和战略度量
23.3 隐性消耗
23.4 不能太大，也不能太小
23.5 小结
第24章 回顾变更
24.1 为变更制定计划
24.2 去掉旧方法
24.3 对未来的工作分类
24.4 机会
24.5 采取小的、可量化的步骤
24.6 提高认识
24.7 小结
第25章 始终保持警惕
25.1 眼罩
25.2 有哪些伤害
25.3 倒退
25.4 小结
第七部分 附录
核心工具
……[看更多目录]
序言软件开发中的个人英雄主义已逐渐成为历史，取而代之的是团队合作形式。然而，由个人过渡到团队并非简单的1+1=2问题。随着团队规模的增加，所面对的挑战将呈非线性增长。如何提高软件开发团队的生产率，这是目前困扰着大多数软件公司和开发人员的主要问题之一。人们通常倾向于从技术层面上来解决这个问题，例如引入某种新的语言或者框架，却似乎达不到预想中的效果。即使采用了一些标准的开发管理流程，例如CMM，通常也只是做一些表面上的工作，而没有深入理解这些流程的本质内容，因此，往往流于形式。开发人员仍然要忍受着加班，返工以及无休止的编码-修改过程，而公司的管理层也不得不面对庞大的开发成本和居高不下的人员流失率。
这些问题的根源在于忽视了团队开发中的人力因素。与传统的制造行业相比，软件行业有其特殊性。传统制造业中的生产要素包括生产设备、原材料等，这些生产要素的一个共同点在于它们之间的差异很小，可以通过标准的流水线方式来提高生产率。然而，我们不能将软件开发工作等同于流水线。软件行业中的生产要素为开发人员，他们作为社会中的独立体，每个人都有自己独特的个性（情绪、需求和关注等），我们要理解和尊重这种差异。高效的软件开发团队并不只是包含一些标准的管理流程，更重要的是精心培育团队中的人力因素。
本书的作者在软件行业中工作了近30年，具有丰富的开发经验和管理经验，他目前的主要研究方向是如何在团队之间实现更高效的合作。本书的内容从个人、团队和利益相关者等三个方面进行组织，讨论主题包括个人、质量、责任、主动性、可持续性、沟通、动机与期望、合作、一致性、组织、协调、指导、客户、目标设定、规范、优先级、变更等，基本上涵盖了构建高效团队合作的各个方面。
掌握一项技术可能需要几个月或者一年的时间，而培育一个成功的团队则需要更长的时间，并且要持之以恒，不能松懈。团队合作需要很长时间的相互磨合才可以形成，而不是可以一蹴而就的。希望本书能够对读者在构建软件团队的过程中有所帮助。
参与本书翻译工作的还有李杨、吴汉平、徐光景、童胜汉、陈军、胡凯、刘红、张玮、陈红、李斌、李勇涛、王海涛、周云波、彭敏才和张世锋等。由于译者的时间和水平有限，翻译中的疏漏和错误在所难免，还望读者和同行不吝指正。
文摘个人的正确态度
在做每件事情时我们都会有着不同的态度，无论是在软件开发工作中还是在日常生活中。必须了解这些态度将如何影响我们的活动能力，并且要注重培养一些最有作用的态度。
在这一章中，我们将讨论一些成为高效的团队成员所应该具备的态度，并且指出领导能力（Leadship）是非常重要的，不论你的角色或头衔是什么。
3.1牛仔和无名英雄
在我曾经参与的项目中，总会有一两个人从项目团队中脱颖而出。他们远远超出了完成项目的要求——就像传奇牛仔John Wayne骑马而去消失在日落中的情境。他们都是软件开发中的传奇牛仔，可以解决棘手问题的人，似乎他们知道项目中的所有重要信息，他们是不可缺少的。
不可缺少？你是否遇到过在某个项目中，这些英雄人物突然离开？在团队中突然没有人知道为什么要做出这些晦涩的设计，而你肯定也不想去阅读这些英雄在离开之前编写的代码。嗯。生活并不总是美好的，是吧？个人的不可缺少性已成为一种不利的因素。Tom Demarco曾经指出，“凑合（Can-do）的态度可以将轻微的挫折升级为真正的灾难”。
然而，在项目中还存在另外一种类型的英雄，他们不会带来这样的消极作用。他们始终认为做正确的事是工作的一部分，他们在幕后做了许多的工作，但却似乎从来都没有受到大家的关注。虽然他们不会提出一些巧妙的解决方案，但也不会犯重大的失误。他们很少会偏离软件基线。他们既不会不切实际地夸下一些海口，也不会让项目经理讨论他们的工作预估（这往往会令经理感到惊讶）。
他们很少大量地加班，因为通常不需要这么做。他们的方法有条不紊并且压力很小，然而这些却往往被人们视作在工作中缺乏兴趣，给人以“没有尽职”的印象。当他们离开时，其他人可以很容易地接手他们的工作。他们的工作是清晰的并且易于理解的，没有隐藏任何东西。虽然人们很少从这个角度来看，但这些迹象都表明他们是在按照正确的方式来做工作，而不只是简单地完成工作。他们
