计算机 类型
可以朗读 语音朗读
295千字 字数
2018-09-01 发行日期
展开全部

主编推荐语

敏捷软件项目开发管理的艺术。

内容简介

本书的内容源自作者的实践经历和工作积累。在长期的实践中作者发现，越来越多的离岸交付需要适应敏捷开发的模式。本书结合分布式团队沟通、协作中的痛点，系统地分析了很多离岸项目虎头蛇尾的原因，并给出可供参考的解决方案。对于很多公司和组织头疼的如何让分布式团队推行敏捷的离岸交付的问题，本书给出很多成功经验。

此外，本书还系统介绍了建设自组织团队的一些措施和方法。涉及离岸交付的软件组织以及其他各类存在分布式团队合作的软件组织都能从本书中得到很多有价值的提示。本书适合开发人员、测试人员、需求管理人员或项目经理等参考阅读。

目录

  • 版权信息
  • 版权
  • 内容提要
  • 序一：认认真真做交付
  • 序二：理想的软件交付
  • 前言
  • 第1章 分布式团队的现状
  • 1.1 分布式团队介绍
  • 1.1.1 分布式团队的快速发展
  • 1.1.2 客户为何如此看重CMMI认证
  • 1.1.3 分布式团队的类型
  • 1.1.4 什么样的团队可以称为分布式团队
  • 1.2 服务外包行业的现状
  • 1.3 离岸团队的组建
  • 1.3.1 组建分布式团队的原则
  • 1.3.2 组建分布式团队
  • 1.3.3 建立一个离岸团队的投入和效益
  • 1.3.4 分布式团队需要注意的问题
  • 1.4 软件外包服务大方向的变化
  • 1.4.1 人才战争已经打响
  • 1.4.2 战略合作的成果——建立离岸交付中心
  • 1.4.3 客户衡量外包服务的方式在发生变化
  • 第2章 分布式团队的沟通
  • 2.1 管理客户的期望值
  • 2.1.1 了解客户
  • 2.1.2 保障客户的知情权
  • 2.1.3 维护客户的期望值
  • 2.1.4 超越客户期望值
  • 2.1.5 L项目的案例
  • 2.1.6 拆屋效应
  • 2.1.7 项目的成败是由客户的期望值决定的
  • 2.2 沟通是分布式团队最大的挑战
  • 2.2.1 分布式团队最基本的沟通方式：电子邮件
  • 2.2.2 常规意义上的沟通：异步沟通和实时沟通
  • 2.2.3 工具的利与弊
  • 2.2.4 主动的沟通
  • 2.2.5 沟通中的冲突
  • 2.2.6 同理心
  • 2.2.7 清楚而坦诚的沟通
  • 2.2.8 成功的离岸团队还需要关注的
  • 2.3 会议的组织
  • 2.3.1 典型的会议
  • 2.3.2 离岸团队的会议技巧
  • 2.3.3 小结
  • 2.4 常驻代表和短期面对面的访问
  • 2.4.1 常驻代表
  • 2.4.2 短期面对面的沟通
  • 2.4.3 一次访问客户现场之后的复盘
  • 2.4.4 小结
  • 2.5 虚拟交流工具
  • 2.5.1 知识分享类
  • 2.5.2 即时沟通类
  • 2.5.3 工作协作类
  • 2.5.4 流程控制类
  • 2.5.5 融合即时沟通和知识分享的工具类
  • 2.5.6 小结
  • 2.6 沟通失败的案例
  • 2.6.1 麦道飞机DC-10重蹈覆辙发生空难的教训
  • 2.6.2 某大型能源企业的一次集成失败
  • 2.6.3 L项目首次用户测试失败
  • 2.6.4 小结
  • 第3章 分布式团队的协作
  • 3.1 团队协作初识
  • 3.1.1 沟通与协作的关系
  • 3.1.2 意见统一是协作的前提
  • 3.1.3 协作更强调行动——执行力
  • 3.1.4 对协作有益的方法
  • 3.1.5 伤害协作的行为
  • 3.1.6 带动客户
  • 3.1.7 协作技巧
  • 3.1.8 关键的协作点
  • 3.1.9 Scrum of Scrums会议
  • 3.1.10 团队内部的协作
  • 3.1.11 小结
  • 3.2 提升离岸团队协作的水平
  • 3.2.1 使用假设
  • 3.2.2 双向沟通
  • 3.2.3 使用业务语言和实例
  • 3.2.4 建立离岸团队的规律性
  • 3.2.5 持续提升离岸团队的协作水平
  • 3.2.6 小结
  • 3.3 规范化提升分布式团队协作
  • 3.3.1 需求分析的规范化
  • 3.3.2 技术的规范化
  • 3.3.3 测试的规范化
  • 3.3.4 规范化自动化测试
  • 3.3.5 小结
  • 第4章 可视化的应用
  • 4.1 可视化的目的
  • 4.1.1 展示项目的状态
  • 4.1.2 消除需求的理解偏差
  • 4.1.3 反馈软件的质量
  • 4.1.4 代码的测试覆盖率
  • 4.1.5 描述复杂的业务流程
  • 4.1.6 理解项目全景
  • 4.1.7 帮助团队思考的思维导图
  • 4.2 可视化的方法
  • 4.2.1 项目状态的展示之看板
  • 4.2.2 项目状态的展示之燃尽图和燃起图
  • 4.2.3 业务流程的展示
  • 4.2.4 项目需求的全景展现
  • 4.2.5 需求故事的表达
  • 4.2.6 思维导图的使用
  • 4.2.7 数据可视化
  • 4.3 使用可视化度量我们的工作
  • 4.3.1 开发和测试工作的度量
  • 4.3.2 对团队工作度量的建议
  • 4.4 团队协作可视化工具的介绍
  • 4.4.1 Mingle的基本介绍
  • 4.4.2 Trello的基本介绍
  • 4.5 小结
  • 第5章 分布式团队中的浪费
  • 5.1 人的因素造成的浪费
  • 5.2 团队协作中的浪费
  • 5.2.1 浪费来自哪里
  • 5.2.2 浪费解决之道
  • 5.2.3 小结
  • 5.3 流程中产生的浪费
  • 5.3.1 缩短流程
  • 5.3.2 简化复杂的环节
  • 5.3.3 加快进度的重要途径
  • 5.3.4 过度设计也是一种常见的浪费
  • 5.4 信息处理中的浪费
  • 5.4.1 组织结构产生的浪费
  • 5.4.2 知识管理中的浪费
  • 5.4.3 信息过多造成的浪费
  • 5.4.4 解决信息处理造成的浪费
  • 5.5 隐性浪费
  • 5.5.1 给丈母娘送海参的故事
  • 5.5.2 快速试错消灭浪费
  • 5.5.3 识别隐性浪费需要一点点洞察力
  • 5.5.4 隐性浪费之不清楚进度
  • 5.5.5 技术债和需求债
  • 5.5.6 缺少优先级
  • 5.5.7 分布式团队中的隐性浪费
  • 5.5.8 隐性浪费带来的后果
  • 5.6 不要把BDD变成团队中的浪费
  • 5.7 小结
  • 第6章 自我管理的离岸团队
  • 6.1 传统文化对团队的影响
  • 6.2 团队的驱动力
  • 6.2.1 驱动源自何处
  • 6.2.2 建立扁平化的组织
  • 6.2.3 人，才是组织的核心
  • 6.2.4 扁平化的团队需不需要领导力
  • 6.2.5 传统组织如何向自组织转型
  • 6.2.6 扁平化不是万能的
  • 6.3 塑造团队的专业性
  • 6.3.1 团队的能力建设
  • 6.3.2 养成好习惯
  • 6.3.3 公司内部的流程标准化对团队的正面影响
  • 6.3.4 成为项目中的重要贡献者
  • 6.3.5 如何对待文档
  • 6.3.6 把简单的事情做好就是专业
  • 6.3.7 团队要以业务价值为导向
  • 6.4 让信息透明化
  • 6.4.1 传统团队中信息流动不畅的问题
  • 6.4.2 透明化的挑战
  • 6.4.3 高透明度是不可逆转的趋势
  • 6.4.4 离岸团队的信息透明化
  • 6.5 跳出舒适区
  • 6.5.1 找到舒适区
  • 6.5.2 为什么要跳出舒适区
  • 6.5.3 团队驱动跳出舒适区
  • 6.5.4 自我驱动跳出舒适区
  • 6.5.5 企业KPI驱动跳出舒适区
  • 6.5.6 小结
  • 6.6 项目经理做什么
  • 6.6.1 传统项目经理的特点
  • 6.6.2 自我管理团队的项目经理
  • 6.6.3 项目经理之于团队
  • 6.6.4 项目经理之于客户
  • 6.6.5 成功的项目经理之团队管家
  • 6.6.6 成功的项目经理之正确看待领导力
  • 6.6.7 成功的项目经理之解决冲突
  • 6.6.8 做什么
  • 6.6.9 怎么做
  • 6.6.10 更多地关注项目风险
  • 6.6.11 小结
  • 6.7 建立全团队意识
  • 6.7.1 需求的全团队参与
  • 6.7.2 测试的全团队负责
  • 6.7.3 开发实践
  • 6.7.4 系统安全意识
  • 6.7.5 小结
  • 6.8 反馈是分布式团队持续改进的推进器
  • 6.8.1 我们为什么要重视反馈
  • 6.8.2 做好反馈的要点
  • 第7章 服务于客户的离岸团队
  • 7.1 建立与客户的互信
  • 7.1.1 目标
  • 7.1.2 建立信任的客户关系
  • 7.1.3 建立和维持客户关系实例
  • 7.1.4 小结
  • 7.2 当与客户意见相左时
  • 7.2.1 处理分歧
  • 7.2.2 客户的意见决定交付质量
  • 7.3 按人天收费的交付项目
  • 7.4 固定金额的交付项目
  • 7.4.1 工作量大小和价格的估算
  • 7.4.2 固定金额项目的管理
  • 7.4.3 商务层面的关切
  • 7.4.4 固定金额项目的风险
  • 7.4.5 建议、提示和可能的陷阱
  • 7.5 与客户的工作衔接
  • 7.5.1 项目启动
  • 7.5.2 项目进行中
  • 7.5.3 项目后期
  • 7.5.4 其他
  • 7.6 帮助客户敏捷转型
  • 7.6.1 能力建设
  • 7.6.2 强化敏捷的优势，坚定所有参与人的信念
  • 7.6.3 建立跨职能团队/功能团队
  • 7.6.4 小结
  • 第8章 分布式团队的未来
  • 8.1 离岸团队中的人
  • 8.1.1 人员变动的应对
  • 8.1.2 关注个人绩效
  • 8.2 分布式团队仍然面临的问题
  • 8.2.1 很多人说，敏捷项目不能外包
  • 8.2.2 团队的领域知识管理和提升
  • 8.2.3 离岸团队的效能
  • 8.2.4 以史为鉴，面向未来
  • 8.3 离岸团队的未来
  • 8.3.1 聘请远程开发团队的理由
  • 8.3.2 国际竞争
  • 8.3.3 协助传统行业数字化创新
  • 8.3.4 离岸团队的敏捷模型
  • 8.3.5 与客户一起创新的实践
  • 8.3.6 小结
  • 8.4 离岸团队要为技术变革做好准备
  • 8.5 低成本的离岸交付是一条不归路
  • 8.6 小结
  • 后记
  • 参考文献
展开全部

评分及书评

尚无评分
目前还没人评分

出版方

人民邮电出版社

人民邮电出版社是工业和信息化部主管的大型专业出版社，成立于1953年10月1日。人民邮电出版社坚持“立足信息产业、面向现代社会、传播科学知识、服务科教兴国”，致力于通信、计算机、电子技术、教材、少儿、经管、摄影、集邮、旅游、心理学等领域的专业图书出版。