Carl Kessler，是IBM软件组内的全球开发副总裁。他在IBM领导大型的软件开发团队工作已经超过十年，他主要的工作领域为企业内容管理、系统管理、安全和网络等领域。
    John Sweitzer是一名拥有26年大型复杂的软件系统开发架构经验的IBM高级工程师和IBM技术研究院成员。在编写本书时，他领导IBM软件组由外到内的初始设计工作，这是由外到内开发的一部分。用来处理影响综合软件产品的易用性和业务相关性的设计原则。

    《成功软件开发方法：由外到内开发实践指南》介绍由外到内的软件开发方法，定义了利益相关者特定的分类和实用的方式。《成功软件开发方法：由外到内开发实践指南》介绍了易用性以及实用的技术，以评估和改进产品的快速有效部署、使用和支持的能力。《成功软件开发方法：由外到内开发实践指南》还介绍了要与利益相关者的目标保持一致、用利益相关者的术语定义成功，应用由外到内的开发技术和成功采用已验证的方法，增加成功的机会。

    由外到内的思想对团队正在采取的实际的软件实现方式进行了补充，它还改变了衡量成功的方式。一个由外到内的成功团队学习许多经验，而不做过多推测。
        ——Tom Poppendieck

    1.4 带领整个团队走向成功
    篮球运动员BillWalton说过：“整个团队团结一致才可以取得胜利。”这种说法对于构建软件产品或进行任何团体运动都是正确的。
    当一个组织整体都在使用由外到内的思想时，将能产生最大的积极影响。当每一个专业化的技术团队（包括经理和主管）都了解和鼓励由外到内的开发时，项目就会成功。因此，无论你是一名编码人员、测试人员、文档编写人员、产品计划人员、开发组长、经理或主管，我们都希望你能在这本书中找到可用的资源。
    整个团队的观点是关键
    我们所指的开发团队的范围非常广泛：不仅包括编码人员、测试人员、技术文档编写人员、设计人员、支持工程师和架构师，还包括用户界面设计人员、性能压力测试人员和其他的各种专业人员。重要的是，我们还包括营销人员、销售主管、业务战略家、产品经理、业务发展专家、产品定价师、其他金融类型的人员，还有服务人员。按我们的观点，成功的软件产品开发不仅仅是成功的编码。成功的产品是由高效的、跨职能的小组一起构建的。
    整个团队越强大，你就越能够体会到乐趣，而且产品也就越成功。
    实际上，虽然有些团队比其他的团队更有能力，而有些团队根本不强。如果你觉得自己正处于这种开发环境，不要沮丧。可以把关于由外到内开发技术的谈话当成一种产生更加整体性行为的方法，或者帮助你的同事，使他们觉得将要做一些提高产品的改进而变得兴奋。我们自己也清楚：小小的成功经常会产生更多的改变。事实上，任何组织中的文化转变，不论大小，似乎通常在下列情况下进行得更好：由个人推动、利用自己担当领导的机会、通过他们的团队逐步进行积极的转变。
    1.5 了解利益相关者
    压力很大。我们可以互相大喊大叫。
    这就是John所谓的“active”会议。团队必须对重要产品版本的新主题达成一致意见。

译者序
序
前言
第1章 由外到内的开发方法概述
1.1 可能需要一些挑战
1.2 考虑一种不同的软件产品开发方法
1.3 还需考虑一些已验证的技术
1.4 带领整个团队走向成功
1.5 了解利益相关者
1.6 了解组织的背景
1.7 使产品易于使用
1.8 与利益相关者的目标保持一致
1.9 用利益相关者的术语定义成功
1.10 成为一位由外到内的开发人员-
1.11 由外到内的开发中领导者的角色
1.12 要点：从现在开始

第2章 理解利益相关者
2.1 理解利益相关者概述
2.2 识别利益相关者
2.3 理解利益相关者的目标
2.3.1 描述利益相关者目标的技术
2.3.2 识别讨论中出现的约束
2.4 四个利益相关者组
2.4.1 负责人
2.4.2 最终用户
2.4.3 合作伙伴
2.4.4 内部人员
2.4.5 考虑利益相关者之间的关系
2.5 和利益相关者进行对话
2.5.1 理解负责人利益相关者的目标
2.5.2 理解最终用户利益相关者的目标
2.5.3 理解合作伙伴利益相关者的目标
2.5.4 理解内部人员利益相关者的目标
2.6 使客户的讨论与利益相关者的目标一致
2.7 理解利益相关者中领导者的角色
2.8 要点
2.9 关键术语

第3章 理解组织背景
3.1 组织背景概述
3.1.1 由于组织背景不同而相互矛盾的反馈
3.1.2 现实中的组织背景差异
3.1.3 用组织的设计意识选择软件市场
3.1.4 组织背景差异的其他方面
3.2 处理不同的客户需求
3.2.1 不可能使所有人都满意
3.2.2 一个用户形不成市场
3.3 利用组织背景理解利益相关者的立场
3.4 使用组织背景中领导者的角色
3.5 要点
3.6 关键术语

第4章 使产品易于使用
4.1 产品易用性概述
4.2 识别易用性元任务
4.3 使用易用性计分卡指导投资
4.3.1 在计分卡中使用易用性元任务
4.3.2 构建计分卡
4.4 选择需要强调的易用性元任务
4.4.1 验证易用性数据
4.4.2 把真实世界包含在计分卡中
4.4.3 在计分卡中包含完整的产品组合
4.4.4 计分卡之外
4.5 容许更多的人使用产品
4.5.1 全球化
4.5.2 可达性
4.6 使产品易于使用中领导者的角色
4.7 要点
4.8 关键术语

第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.3.5 谨慎使用简化能力
5.4 最小化交付物中的噪音，赢得利益相关者的积极反馈
5.4.1 对团队投资
5.4.2 把缺陷引入与利益相关者的目标保持一致的讨论的原因
5.5 帮助确保质量
5.5.1 协作
5.5.2 自动化
5.5.3 对于未答复的缺陷要小心
5.5.4 从缺陷中学习
5.5.5 把利益相关者的世界引入你的工作
5.5.6 把利益相关者本身带到你的工作环境
5.5.7 让团队成员体验真实
5.6 为产品成功而预演
5.6.1 为产品的预演制定计划
5.6.2 欢迎批评意见
5.6.3 将预演应用于任何开发方法
5.6.4 邀请合作伙伴利益相关者参加预演
5.6.5 在预演中邀请尽可能多的内部人员
5.7 与利益相关者目标保持一致中领导者的角色
5.8 要点
5.9 关键术语

第6章 用利益相关者的术语定义成功
6.1 利益相关者在产品阶段获得成功的概述
6.2 第一波：一切为了负责人利益相关者获得成功
6.2.1 为产品设置成功的目标
6.2.2 确认是否已经达到目标
6.2.3 对第一波客户使用反向驻留
6.2.4 保持正常的心态
6.2.5 制定计划支持第一波获得成功的能力
6.3 使用从第一波中积累的经验
6.3.1 了解产品的运行情况
6.3.2 注意影响第一波客户的缺陷
6.3.3 迫切地为利益相关者提供更多的功能
6.3.4 使用适当的交付机制交付后续的功能
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.6 在定义成功中领导者的角色
6.7 要点
6.8 关键术语

第7章 成为由外到内的开发人员
7.1 如何采用由外到内开发的技术
7.1.1 利用由外到内的技术建立以利益相关者为基础的文化
7.1.2 文化的改变来自组织结构图的两端
7.1.3 适当地展开由外到内的开发
7.1.4 应该如何着手
7.1.5 存在多个领导机会
7.1.6 存在积极地推进的环境吗
7.2 洞察由外到内开发的效果
7.2.1 为团队计划增量地采用由外到内的开发技术
7.2.2 选择恰当的初始负责人利益相关者
7.2.3 如何对多个软件项目使用由外到内的开发
7.2.4 由外到内的开发如何适应瀑布式项目
7.2.5 由外到内的开发如何适应精益六西格玛项目
7.2.6 由外到内的开发如何适应精益敏捷项目
7.3 采用由外到内开发中领导者的角色
7.4 要点
7.5 关键术语