【内容】
基本信息
书名：
敏捷可执行需求说明-Scrum提炼及实现技术
作者：
(美)卡迪纳尔|译者:黄灵
开本：
*：
39
页数：
现价：
见顶部
出版时间
2014-10-01
书号：
9787111480600
印刷时间：
出版社：
机械工业出版社
版次：
商品类型：
正版图书
印次：
内容提要
作者简介
Mario Cardinal 著名敏捷教练，Scrum的实践者，多年来专攻软件架构，有20多年大型信息系统设计经验。他是Slingboards实验室的创始人之一，该实验室是一个新兴创业公司，他们将即时贴功能做进智能手机、平板电脑和互联网，帮助团队更好地协作。Cardinal已经连续9年获得微软最有价值的专家称号（MVP）。MVP一般授予社区最好的成员、最愿意在社区分享经验并帮助他人发挥潜力而值得信赖的技术专家。
黄灵 PMP、CSM、 CSPO、CSP，管理3.0_敏捷领导力实践培训课认证讲师，敏捷实践者及敏捷教练，有多年软件开发项目及项目群管理、Scrum 实施经验。现供职于上海惠普有限公司，GDC 敏捷推广项目负责人，专注于传统项目团队敏捷转型实施指导、敏捷相关培训以及公司、组织级敏捷转型咨询。与人合作翻译出版了《敏捷技能修炼：敏捷软件开发与设计*实践》和《言语的力量：高效的商务呈现和谈话技巧》。
精彩导读
第1章
解决正确的问题
敏捷是一组鼓励快速、灵活地响应变更的软件开发框架。它们基于迭代开发实践，需求和解决方案都在跟客户合作过程中逐渐演进并完善。2001年发布的“敏捷软件开发宣言”[1]引入了敏捷这个词。
Scrum[2]现在已经成为最著名且使用最广泛的敏捷框架。Ken Schwaber和Jeff Sutherland[3]设计的Scrum框架，由角色、事件、工件以及将它们整合在一起的一系列规则组成。Scrum使研发团队通过频繁地检查和调整，并不断优化产出成果，最终构建复杂的产品。这个术语来自橄榄球中的scrum（或者scrummage），即用来重新启动强制暂停后的比赛。在2011年发起的年度“敏捷研发现状”调查中，选择使用Scrum或Scrum的变种形式的人数继续在被使用到的敏捷框架中占据三分之二以上的比例[4]。因为Scrum被如此广泛地采用，所以本书也仅关注这种框架形式。对于采用其他敏捷框架的情况，本书所介绍的经验教训因其通用性也足够使用。
将“敏捷”与“需求说明书”两个词绑在一起看起来有点怪异。而特别为这个话题撰写一本书看起来更加怪异。对很多人来说，需求说明书只与“传统”的以文档为中心的工程实践相匹配。在敏捷背景下，可运行的软件是度量开发进度的基本标准，人们很容易认为需求说明书将不再有存在的必要。然而，需求说明书仍然是需要的——甚至比以往任何时候都更需要。区别在于产出物有本质上的不同。需求说明不仅简短，而且也需要在计算机上以一种固定的格式发布成可执行的文档。——因此得名为可执行的需求说明书。
本书的目标旨在解决众多软件开发团队不断遇到的问题：他们无法生产“正确”的软件。这是一个很严重的问题，甚至令你震惊。不管怎样，仍然有大量的软件系统成功地解决了“正确”的问题。其中很多这样的系统都是由实施Scrum框架的团队生产的。我不仅从这些团队那里学习到了关于敏捷的技能，而且也是他们中的一员。如果你也属于这样杰出的团队，你就会意识到本书中介绍的这些纲要性的实践正是你所熟知的。
不幸的是，仍然存在着大量的过于臃肿和复杂的软件系统。即使研发团队写的代码都是对的，结果往往是他们没有有效地解决实际的问题。客户想要的或需要的功能跟产品实际能够提供的功能有着巨大的差距。一个经常被引用的Standish Group [5]的统计结果显示，在一个典型的系统里，64%的功能很少被用到或几乎从不被使用。图1-1是根据Standish Group的准确数据画的饼图。
图1-1 在一个典型系统里功能的使用情况
从饼图上来看，非常有意思的是有20%的功能一直或者经常被用到。这个结果更重要的是吻合了80–20原则，同时也符合帕累托原则。帕累托原则说的是在很多事件中，几乎80%的成果（产出物）都来自20%的付出（投入）。比如说，在生意场合，通常几乎80%的销售业绩都来自20%的客户。在软件开发行业，如果你能正确地选择最重要的20%的需求来实现，就能满足80%的业务需求了。随着对可用性和可靠性的期望值不断增长，要构建符合要求的软件是很困难的。因此专注于那20%的功能就显得很重要。这样你就可以拥有必要的资源来实现符合预期的技术解决方案。
本章将介绍为了解决正确的问题，必须首先学会从解决方案中甄别出需求。紧接着，必须在描述需求时识别出不确定性的影响。这是因为描述我们需要构建的是什么，同时还要拥抱变化是很有挑战的。最后，我们将得出结论，当前从传统工程中继承来的实践根本满足不了这种需要。当需求难以把握，并且持续变动时，你必须以一种非传统的方式来应对不确定性。Scrum框架下的可执行需求说明被证明行之有效。本书的目标就是要分享这一经验。
1.1 从解决方案中甄别需求
敏捷并不排除从解决方案中甄别需求的必要性。它是一种从“如何”构建中识别出构建“什么”的有效实践。即使你将交付产品的迭代周期缩短到30天以内，团队仍然需要在解决问题前理解问题。不同的仅仅是需求说明方式。为了更有效地合作，只有利于开展需求相关的交流讨论的关键内容才会被文档化。
描述“是什么”，即需要解决的问题，组成需求说明的核心内容。需求说明定义了软件产品需要做什么，但不是“如何做”。很显然，需求说明的内容远不止“是什么”。还会包含“是谁”，阐明了针对哪些干系人和“为什么”，将需求范围的界定合理化。然而，目标仍然是为了详细说明“是什么”，以及任何应该支持最终目标的问题的答案。
如果针对“是什么”还有很多不确定性，将需求说清楚的能力就将显著降低，风险也将明显增加。如果你需要满足20个干系人，而他们又对需要“是什么”有不同的理解，你可以想象一下不确定程度到底有多大。你必须在从解决方案中鉴别需求的时候，识别出不确定性的影响。
……
目录
本书赞誉
译者序
前言
第1章 解决正确的问题
1.1 从解决方案中甄别需求
1.2 识别不确定性的影响
1.3 处理不确定性
1.4 小结
1.5 参考资料
第2章 依赖坚实的基础
2.1 界定不可更改的边界
2.2 组建一个健康的团队
2.3 要求所有干系人参与
2.4 明确一个可以共享的愿景
2.5 识别出一个有意义的共同目标
2.6 识别出一系列高级别的特征
2.7 验证“可能存在”的假设
2.8 小结
2.9 参考资料
第3章 使用短周期反馈环探索干系人的“愿求”
3.1 运用试错法
3.2 应用短周期反馈环
3.3 根据预期收益设定反馈目标
3.4 关注干系人的“愿求”
3.5 小结
3.6 参考资料
第4章 使用用户故事表达“愿求”
4.1 使用用户故事描述愿求
4.2 通过研究角色及其利益探索“愿求”
4.3 建立一种通用语言
4.4 使用待办事项列表记录“愿求”
4.5 小结
4.6 参考资料
第5章 优化产品待办事项列表提炼用户故事
5.1 管理产品待办事项列表
5.2 通过合作优化产品待办事项列表
5.3 采用圆点投票法对用户故事进行排序
5.4 采用故事板的方式阐明用户故事的需求
5.5 通过比较的方式估算用户故事规模
5.6 按照业务价值拆分用户故事
5.7 使用协作白板追踪用户故事
5.8 交付一组功能连贯的用户故事
5.9 使用用户故事计划工作
5.10 小结
5.11 参考资料
第6章 使用场景确认用户故事
6.1 使用场景创建用户故事脚本
6.1.1 用标准形式表达场景
6.1.2 使用FIT表格化格式编写场景脚本
6.1.3 使用已知–当…时–那么句型结构编写场景脚本
6.1.4 选择FIT表格化格式或者已知–当…时–那么的句型结构
6.1.5 规范化通用语言
6.2 将场景拆分成指令和查询
6.3 两步法流程协同确认
6.4 从场景里剔除技术考量
6.5 在Sprint过程中演进场景
6.5.1 按照特征（feature）组织场景
6.5.2 通过特征编写场景文档
6.5.3 避免重复和合并冲突
6.6 小结
6.7 参考资料
第7章 使用验收测试自动确认需求
7.1 在验收测试中引入场景
7.2 使用红–绿–重构循环自动化场景
7.3 将场景转换成验收测试
7.3.1 使用内部DSL进行调换
7.3.2 创建一个测试
7.3.3 将DSL代码写进新创建的测试中
7.4 将新创建的测试与接口连接起来
7.4.1 接口设计练习
7.4.2 场景步骤间的背景链
7.4.3 使测试失败
7.5 实现接口
7.5.1 用需求说明–情景测试替换单元测试
7.5.2 让测试通过
7.6 演进验收测试
7.7 使用持续集成并同时运行验收测试
7.8 通过测试结果来增强场景
7.9 小结
7.10 参考资料
第8章 处理非功能性需求
8.1 使用约束改善外部质量
8.1.1 将非功能性需求转换成约束条件
8.1.2 将功能性需求范围降低至一个简单场景
8.1.3 设置可度量的质量目标
8.1.4 使用行之有效的实践来测试约束
8.2 使用正确的工程实践确保内部质量
8.3 通过协作构建掌握实践
8.4 小结
8.5 参考资料
第9章 结论篇
9.1 本书概要重述
9.2 流程总结
9.3 提请注意各种角色
词汇表
七天无理由退货服务
书名：
敏捷可执行需求说明-Scrum提炼及实现技术
作者：
(美)卡迪纳尔|译者:黄灵
开本：
*：
39
页数：
现价：
见顶部
出版时间
2014-10-01
书号：
9787111480600
印刷时间：
出版社：
机械工业出版社
版次：
商品类型：
正版图书
印次：
内容提要
作者简介
Mario Cardinal 著名敏捷教练，Scrum的实践者，多年来专攻软件架构，有20多年大型信息系统设计经验。他是Slingboards实验室的创始人之一，该实验室是一个新兴创业公司，他们将即时贴功能做进智能手机、平板电脑和互联网，帮助团队更好地协作。Cardinal已经连续9年获得微软最有价值的专家称号（MVP）。MVP一般授予社区最好的成员、最愿意在社区分享经验并帮助他人发挥潜力而值得信赖的技术专家。
黄灵 PMP、CSM、 CSPO、CSP，管理3.0_敏捷领导力实践培训课认证讲师，敏捷实践者及敏捷教练，有多年软件开发项目及项目群管理、Scrum 实施经验。现供职于上海惠普有限公司，GDC 敏捷推广项目负责人，专注于传统项目团队敏捷转型实施指导、敏捷相关培训以及公司、组织级敏捷转型咨询。与人合作翻译出版了《敏捷技能修炼：敏捷软件开发与设计*实践》和《言语的力量：高效的商务呈现和谈话技巧》。
精彩导读
第1章
解决正确的问题
敏捷是一组鼓励快速、灵活地响应变更的软件开发框架。它们基于迭代开发实践，需求和解决方案都在跟客户合作过程中逐渐演进并完善。2001年发布的“敏捷软件开发宣言”[1]引入了敏捷这个词。
Scrum[2]现在已经成为最著名且使用最广泛的敏捷框架。Ken Schwaber和Jeff Sutherland[3]设计的Scrum框架，由角色、事件、工件以及将它们整合在一起的一系列规则组成。Scrum使研发团队通过频繁地检查和调整，并不断优化产出成果，最终构建复杂的产品。这个术语来自橄榄球中的scrum（或者scrummage），即用来重新启动强制暂停后的比赛。在2011年发起的年度“敏捷研发现状”调查中，选择使用Scrum或Scrum的变种形式的人数继续在被使用到的敏捷框架中占据三分之二以上的比例[4]。因为Scrum被如此广泛地采用，所以本书也仅关注这种框架形式。对于采用其他敏捷框架的情况，本书所介绍的经验教训因其通用性也足够使用。
将“敏捷”与“需求说明书”两个词绑在一起看起来有点怪异。而特别为这个话题撰写一本书看起来更加怪异。对很多人来说，需求说明书只与“传统”的以文档为中心的工程实践相匹配。在敏捷背景下，可运行的软件是度量开发进度的基本标准，人们很容易认为需求说明书将不再有存在的必要。然而，需求说明书仍然是需要的——甚至比以往任何时候都更需要。区别在于产出物有本质上的不同。需求说明不仅简短，而且也需要在计算机上以一种固定的格式发布成可执行的文档。——因此得名为可执行的需求说明书。
本书的目标旨在解决众多软件开发团队不断遇到的问题：他们无法生产“正确”的软件。这是一个很严重的问题，甚至令你震惊。不管怎样，仍然有大量的软件系统成功地解决了“正确”的问题。其中很多这样的系统都是由实施Scrum框架的团队生产的。我不仅从这些团队那里学习到了关于敏捷的技能，而且也是他们中的一员。如果你也属于这样杰出的团队，你就会意识到本书中介绍的这些纲要性的实践正是你所熟知的。
不幸的是，仍然存在着大量的过于臃肿和复杂的软件系统。即使研发团队写的代码都是对的，结果往往是他们没有有效地解决实际的问题。客户想要的或需要的功能跟产品实际能够提供的功能有着巨大的差距。一个经常被引用的Standish Group [5]的统计结果显示，在一个典型的系统里，64%的功能很少被用到或几乎从不被使用。图1-1是根据Standish Group的准确数据画的饼图。
图1-1 在一个典型系统里功能的使用情况
从饼图上来看，非常有意思的是有20%的功能一直或者经常被用到。这个结果更重要的是吻合了80–20原则，同时也符合帕累托原则。帕累托原则说的是在很多事件中，几乎80%的成果（产出物）都来自20%的付出（投入）。比如说，在生意场合，通常几乎80%的销售业绩都来自20%的客户。在软件开发行业，如果你能正确地选择最重要的20%的需求来实现，就能满足80%的业务需求了。随着对可用性和可靠性的期望值不断增长，要构建符合要求的软件是很困难的。因此专注于那20%的功能就显得很重要。这样你就可以拥有必要的资源来实现符合预期的技术解决方案。
本章将介绍为了解决正确的问题，必须首先学会从解决方案中甄别出需求。紧接着，必须在描述需求时识别出不确定性的影响。这是因为描述我们需要构建的是什么，同时还要拥抱变化是很有挑战的。最后，我们将得出结论，当前从传统工程中继承来的实践根本满足不了这种需要。当需求难以把握，并且持续变动时，你必须以一种非传统的方式来应对不确定性。Scrum框架下的可执行需求说明被证明行之有效。本书的目标就是要分享这一经验。
1.1 从解决方案中甄别需求
敏捷并不排除从解决方案中甄别需求的必要性。它是一种从“如何”构建中识别出构建“什么”的有效实践。即使你将交付产品的迭代周期缩短到30天以内，团队仍然需要在解决问题前理解问题。不同的仅仅是需求说明方式。为了更有效地合作，只有利于开展需求相关的交流讨论的关键内容才会被文档化。
描述“是什么”，即需要解决的问题，组成需求说明的核心内容。需求说明定义了软件产品需要做什么，但不是“如何做”。很显然，需求说明的内容远不止“是什么”。还会包含“是谁”，阐明了针对哪些干系人和“为什么”，将需求范围的界定合理化。然而，目标仍然是为了详细说明“是什么”，以及任何应该支持最终目标的问题的答案。
如果针对“是什么”还有很多不确定性，将需求说清楚的能力就将显著降低，风险也将明显增加。如果你需要满足20个干系人，而他们又对需要“是什么”有不同的理解，你可以想象一下不确定程度到底有多大。你必须在从解决方案中鉴别需求的时候，识别出不确定性的影响。
……
目录
本书赞誉
译者序
前言
第1章 解决正确的问题
1.1 从解决方案中甄别需求
1.2 识别不确定性的影响
1.3 处理不确定性
1.4 小结
1.5 参考资料
第2章 依赖坚实的基础
2.1 界定不可更改的边界
2.2 组建一个健康的团队
2.3 要求所有干系人参与
2.4 明确一个可以共享的愿景
2.5 识别出一个有意义的共同目标
2.6 识别出一系列高级别的特征
2.7 验证“可能存在”的假设
2.8 小结
2.9 参考资料
第3章 使用短周期反馈环探索干系人的“愿求”
3.1 运用试错法
3.2 应用短周期反馈环
3.3 根据预期收益设定反馈目标
3.4 关注干系人的“愿求”
3.5 小结
3.6 参考资料
第4章 使用用户故事表达“愿求”
4.1 使用用户故事描述愿求
4.2 通过研究角色及其利益探索“愿求”
4.3 建立一种通用语言
4.4 使用待办事项列表记录“愿求”
4.5 小结
4.6 参考资料
第5章 优化产品待办事项列表提炼用户故事
5.1 管理产品待办事项列表
5.2 通过合作优化产品待办事项列表
5.3 采用圆点投票法对用户故事进行排序
5.4 采用故事板的方式阐明用户故事的需求
5.5 通过比较的方式估算用户故事规模
5.6 按照业务价值拆分用户故事
5.7 使用协作白板追踪用户故事
5.8 交付一组功能连贯的用户故事
5.9 使用用户故事计划工作
5.10 小结
5.11 参考资料
第6章 使用场景确认用户故事
6.1 使用场景创建用户故事脚本
6.1.1 用标准形式表达场景
6.1.2 使用FIT表格化格式编写场景脚本
6.1.3 使用已知–当…时–那么句型结构编写场景脚本
6.1.4 选择FIT表格化格式或者已知–当…时–那么的句型结构
6.1.5 规范化通用语言
6.2 将场景拆分成指令和查询
6.3 两步法流程协同确认
6.4 从场景里剔除技术考量
6.5 在Sprint过程中演进场景
6.5.1 按照特征（feature）组织场景
6.5.2 通过特征编写场景文档
6.5.3 避免重复和合并冲突
6.6 小结
6.7 参考资料
第7章 使用验收测试自动确认需求
7.1 在验收测试中引入场景
7.2 使用红–绿–重构循环自动化场景
7.3 将场景转换成验收测试
7.3.1 使用内部DSL进行调换
7.3.2 创建一个测试
7.3.3 将DSL代码写进新创建的测试中
7.4 将新创建的测试与接口连接起来
7.4.1 接口设计练习
7.4.2 场景步骤间的背景链
7.4.3 使测试失败
7.5 实现接口
7.5.1 用需求说明–情景测试替换单元测试
7.5.2 让测试通过
7.6 演进验收测试
7.7 使用持续集成并同时运行验收测试
7.8 通过测试结果来增强场景
7.9 小结
7.10 参考资料
第8章 处理非功能性需求
8.1 使用约束改善外部质量
8.1.1 将非功能性需求转换成约束条件
8.1.2 将功能性需求范围降低至一个简单场景
8.1.3 设置可度量的质量目标
8.1.4 使用行之有效的实践来测试约束
8.2 使用正确的工程实践确保内部质量
8.3 通过协作构建掌握实践
8.4 小结
8.5 参考资料
第9章 结论篇
9.1 本书概要重述
9.2 流程总结
9.3 提请注意各种角色
词汇表
七天无理由退货服务
【目录】
本店全部为正版图书
