人月神话与敏捷方法1 人月神话+敏捷估算与计划+敏捷软件测试(套装共2册)

《敏捷软件开发实践估算与计划》：
　　《敏捷软件开发实践估算与计划》为对敏捷项目进行估算和计划提供了紧贴实用的指导方针。
　　在本书中，敏捷联盟联合创始人MikeCohn（科恩）讨论了敏捷估算与计划背后的哲学思想，并通过列举现实世界的例子和项目案例具体展示了如何完成工作。
　　《敏捷软件开发实践估算与计划》是你开发工具箱中必不可少的敏捷估算“利器”。
　　《敏捷软件开发实践估算与计划》清晰地阐述了相关概念，并引导读者逐步找到下列问题的答案：将构建什么产品？产品规模多大？需要在何时完成？到那时我们到底能完成多少？你首先会认识到优秀的计划由哪些要素组成，接着会了解到如何才能使计划敏捷化。
　　采用《敏捷软件开发实践估算与计划》中讲述的方法，你将获得敏捷估算工具，帮助你从始至终保持敏捷、节省时间、充分利用资源并且完成更多工作。
　　《敏捷软件开发实践估算与计划》要点如下：
　　为什么传统的指令性计划会失败而敏捷计划会取得成功
　　如何使用故事点和理想人天来预估特性的规模，以及它们分别适用于哪种情形
　　重设估算的方式和时机
　　如何同时采用财务及非财务手段来确定特性的优先级
　　如何将大的特性分解为更小的、更便于管理的特性
　　如何计划迭代周期并对团队的初始进度进行预估
　　如何安排具有高度不确定性或进度相关风险的项目的进度
　　如何对由多个团队合作开发的项目进行估算
　　
　　《敏捷软件测试：测试人员与敏捷团队的实践指南》：
　　测试是敏捷开发的关键组成部分。敏捷方法的广泛应用使人们开始关注如何有效测试，同时敏捷项目改变了测试人员的角色。但是，测试人员的许多职责还是得到了不少误解，测试人员的真正职能是什么？敏捷团队真的需要具有QA背景的成员吗？“敏捷测试人员”到底意味着什么？
　　业界经验丰富的两位敏捷测试实践者和顾问克里斯平和格雷戈里在《敏捷软件测试：测试人员与敏捷团队的实践指南》中给出了这些问题和更多问题的答案。在《敏捷软件测试：测试人员与敏捷团队的实践指南》中，Crispin和Gregory定义了敏捷测试的概念，并通过来自现实敏捷团队的示例阐述测试人员的职责。她们讲述如何利用敏捷测试象限来识别需要哪些测试，谁来做，以及哪些工具有帮助。
　　《敏捷软件测试：测试人员与敏捷团队的实践指南》从测试人员的角度记录了敏捷软件开发迭代的一个完整周期，并解释了敏捷测试的七大关键成功要素。
　　
　　《人月神话》：
　　在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了具有洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。
　　《人月神话》内容来自Brooks博士在IBM公司SYSTEM／360家族和OS／360中的项目管理经验，该项目堪称软件开发项目管理的典范。
　　《人月神话》英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄、中、韩等多种文字，全球销售数百万册。确立了其在行业内的经典地位。
　　在《人月神话》第首次出版40年后的今天，我们重新整理了Brooks博士的经典内容，并将国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得集结成册免费赠与大家共享，更使《人月神话》成为国内从业者的必读经典之一。
　　《人月神话》读者包括：软件开发人员、软件项目经理、系统分析师等IT从业者。

科恩（Mike Cohn），Mountain Goat Software创办人，以帮助客户公司成长为软件开发组织为己任，专门提供Scrum与敏捷软件开发培训。Mike Cohn是敏捷运动两大公认名著（《用户故事与敏捷方法》和《敏捷估算与规划》）的作者。他曾经历任多个软件开发公司（从新创公司到《财富》40强）的技术总监，曾服务子BBC（英国国际广播公司）、Capital One（美国第—投资集团），Electronic Arts（艺电）、Experian（益百利）、Gooqle（谷歌）、Intuit（直觉软件公司）、Lexis Nexis（律商联讯）、Lockheed Martin（洛克希德·马丁）、微软、诺基亚、飞利浦、Sabre、Salesforce.com、西门子、索尼、时代华纳、雅虎等客户。他参与创力了敏捷联盟、敏捷项目领导网络和Scrum联盟。
　　
　　小弗雷德里克·布鲁克斯曾获得美国计算机领域具声望的图灵奖（A.M.Turing Award）。美国计算机协会（ACM）称赞他“对计算机体系结构、操作系统和软件工程做出了里程碑式的贡献”。
　　布鲁克斯博士1956年开始任职于IBM公司，早期担任Stretch 和Harvest计算机的体系建构师。他被认为是“IBM 360系统之父”，曾担任360系统的项目经理。凭借在此项目中的杰出贡献，他与Bob Evans和Erich Bloch在1985年获得了美国国家技术奖（National Medal of Technology）。
　　布鲁克斯博士创立了北卡罗来纳大学的计算机科学系，并于1965-1985年担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。目前其仍活跃于从事虚拟环境和科学可视化等方面的研究工作，2010年获得虚拟现实事业奖（IEEE Virtual Reality Career Award）。

《敏捷软件开发实践估算与计划》：
第Ⅰ部分 问题与目标
第1章 计划的目的
1．1 为何要进行估算和计划
1．1．1 减少风险
1．1．2 降低不确定性
1．1．3 提供更好的决策支持
1．1．4 建立信任
1．1．5 传递信息
1．2 优秀的计划是什么
1．3 敏捷计划是什么
1．4 小结
1．5 讨论题
第2章 计划失败的原因
2．1 基于活动而不是基于特性进行计划
2．1．1 活动不会提前完成
2．1．2 延误沿着计划表向下传递
2．1．3 活动不是互相独立的
2．2 多任务处理导致更多的延迟
2．3 不按优先级开发特性
2．4 忽视了不确定性
2．5 把估算当作承诺
2．6 小结
2．7 讨论题
第3章 敏捷方法
3．1 项目的敏捷开发方法
3．1．1 敏捷团队作为一个整体工作
3．1．2 敏捷团队按短迭代周期工作
3．1．3 敏捷团队每次迭代交付一些成果
3．1．4 敏捷团队关注业务优先级
3．1．5 敏捷团队进行检查和调整
3．2 敏捷计划方法
3．2．1 计划的不同层次
3．2．2 满意条件
3．3 小结
3．4 讨论题

第Ⅱ部分 估算大小
第4章 使用故事点估算大小
4．1 故事点是相对的
4．2 速度
4．3 小结
4．4 讨论题
第5章 使用理想人天进行估算
5．1 理想时间和软件开发
5．2 以理想人天作为对大小的度量
5．3 给出一个而不是多个估算值
5．4 小结
5．5 讨论题
第6章 估算方法
6．1 共同估算
6．2 估算的尺度
6．3 得到估算值的方法
6．3．1 专家意见
6．3．2 类比
6．3．3 分解
6．4 计划扑克
6．4．1 更小规模的会议
6．4．2 何时玩计划扑克
6．5 为什么计划扑克会有效
6．6 小结
6．7 讨论题
第7章 重估
7．1 Swim Stats Web站点
7．2 不进行重估的情况
7．3 需要重估的情况
7．3．1 场景1：不进行重估
7．3．2 场景2：重估完成的故事
7．3．3 场景3：相对大小改变时进行重估
7．4 重估部分 完成的故事
7．5 重估的目的
7．6 小结
7．7 讨论题
第8章 在故事点和理想人天之间进行选择
8．1 有利于故事点的考虑因素
8．1．1 故事点有助于驱动跨功能的行为
8．1．2 故事点估算不会过期
8．1．3 故事点是对大小的纯粹度量
8．1．4 故事点估算通常更快
8．1．5 我的理想人天不等于你的理想人天
8．2 有利于理想人天的考虑因素
8．2．1 理想人天在团队以外更容易解释
8．2．2 理想人天估算更容易开始
8．2．3 理想人天便于预测速度
8．3 建议
8．4 小结
8．5 讨论题

第Ⅲ部分 为价值制定计划
第9章 确定主题的优先级
9．1 确定优先级时的因素
9．1．1 价值
9．1．2 成本
9．1．3 新知识
9．1．4 风险
9．2 综合4个因素
9．3 一些例子
9．3．1 基础设施
9．3．2 用户界面设计
9．4 小结
9．5 讨论题
……
第10章 确定经济优先级
第11章 确定渴望度优先级
第12章 分解用户故事

第Ⅳ部分 进度计划
第13章 发布计划精粹
第14章 迭代计划
第15章 选择迭代长度
第16章 估算速度
第17章 不确定性缓冲计划
第18章 计划多团队项目

第Ⅴ部分 跟踪与交流
第19章 监督发布计划
第20章 监督迭代计划
第21章 关于计划的沟通

第Ⅵ部分 敏捷计划有效的原因
第22章 敏捷计划有效的原因
第Ⅶ部分 案例分析
第23章 案例分析：Bomb Shelter Studio

《敏捷软件测试：测试人员与敏捷团队的实践指南》：
第Ⅰ部分 简介
第1章 敏捷测试的定义
1．1 敏捷价值
1．2 “敏捷测试”意味着什么
1．3 敏捷团队中角色和活动的情境
1．4 敏捷测试有何不同
1．5 整体团队运作方式
1．6 小结
第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 团队建设
4．5 小结
第5章 迁移传统过程
5．1 寻找轻量级过程
5．2 度量标准
5．3 缺陷跟踪
5．4 测试计划
5．5 现有的过程和模型
5．6 小结

第Ⅲ部分 敏捷测试象限
第6章 测试的目的
6．1 敏捷测试象限
6．2 知道一个用户故事何时完成
6．3 管理技术债务
6．4 上下文环境中的测试
6．5 小结
第7章 支持团队的面向技术测试
7．1 敏捷测试基础
7．2 为什么编写并运行这些测试
7．3 面向技术的测试在何处停止
……

第Ⅳ部分 自动化
第13章 自动化的原因和障碍
第14章 敏捷测试自动化策略

第Ⅴ部分 测试人员经历的一个迭代
第15章 测试人员在发布或主题
第16章 迭代前的准备
第17章 迭代开始
第18章 编码和测试
第19章 迭代结束时的收尾工作
第20章 成功的交付

第Ⅵ部分 总结
第21章 关键成功要素

术语表
参考文献

《人月神话》

《敏捷软件开发实践估算与计划》：
　　现在，让我们来讨论一下当今可能作为潜在银弹的最先进的技术进步。它们各自针对什么样的问题？它们属于必要问题，或者依然是我们接下来要解决的次要困难？它们是提供了创新，还是仅仅做出了一些改进？
　　Ada和其他高级编程语言。近来，最被吹捧的开发进展之一是编程语言Ada，一种20世纪80年代的高级语言。Ada实际上不仅仅反映了语言概念上的突破性进展，而且蕴涵了鼓励现代设计和模块化概念运用的重要特性。由于Ada采用的是抽象数据类型、层次结构的模块化理念，所以Ada理念可能比语言本身更加先进。Ada使用设计来承载需求，作为这一过程的自然产物，它可能过于丰富了。不过，这并不是致命的，因为它的词汇子集可以解决学习问题，硬件的进展能提供更高的MIPS（每秒百万指令集），减少编译的成本。软件系统结构化的先进理念实际上非常好地利用了MIPS上的进展。20世纪60年代，曾在内存和循环成本上广受谴责的操作系统，如今已被证明是一种能使用某些MIPS和廉价内存的非常优秀的系统。
　　然而，Ada仍然不是消灭软件生产率怪兽的银弹。毕竟，它只是另一种高级语言，这类语言最大的回报来自第一次切换，它通过使用更加抽象的语句来开发，降低了机器的次要复杂度。一旦这些难题被解决，就只剩下非常少的问题了，解决剩余部分的获益必然也要少一些。
　　我预言，在以后的10年中，当Ada的效率被大家评估认可时，它会产生相当大的变化，但并不是因为任何特别的语言特性，不是由于这些语言特性被合并在一起，也不是因为Ada开发环境会不断发展进步。Ada的最大贡献在于编程人员培训方式的转变，即需要对开发人员进行现代软件设计技术培训。
　　面向对象编程。软件专业的一些学生坚持面向对象编程是当今若干新潮技术中最富有希望的。我也是其中之一。达特茅斯的Mark Sherman提出，必须仔细地区别两个不同的概念：抽象数据类型和层次化类型，后者也被称为类（class）。抽象数据类型的概念是指对象类型应该通过一个名称、一系列合适的值和操作来定义，而不是理应被隐藏的存储结构。抽象数据类型的例子是Ada包（以及私有类型）和Modula的模块。
　　层次化类型，如Simula-67的类，是允许通用接口的定义被后续子类型精化的。这两个概念是互不相干的——可以只有层次化，没有数据隐藏；也可能是只有数据隐藏，而没有层次化。两种概念都体现了软件开发领域的进步。
　　它们的出现都消除了开发过程中的非本质困难，允许设计人员表达自己设计的内在特性，而不需要表达大量句法上的内容，这些内容并没有添加新的信息。对于抽象数据类型和层次化类型，它们都解决了高级别的次要困难并允许采用较高层次的表现形式来表达设计。
　　不过，这些提高仅仅能消除所有设计表达上的次要困难。软件的内在问题是设计的复杂度，上述方法并没有对它有任何的促进。除非在我们现在的编程语言中，不必要的低层次类型说明占据了软件产品设计的90%，面向对象编程才能带来数量级上的提高。对面向对象编程这颗“银弹”，我深表怀疑。
　　人工智能。很多人期望人工智能上的进展可以给软件生产率和质量带来数量级上的增长，但我不这样认为。究其原因，我们必须剖析“人工智能”意味着什么，以及它是如何应用的。
　　……