敏捷软件开发方法与实践

作者简介

《敏捷软件开发方法与实践》第1章阐述了敏捷软件开发方法出现的历史背景、敏捷宣言、敏捷原则及最新动态；第2章介绍了常见的敏捷软件开发方法及其相互间的简单比较；在第3章至第5章中，作者结合自己的敏捷项目开发经验，融合其他方法，介绍了敏捷软件交付模型以及部分敏捷项目管理和开发实践；第6章从组织变革实施模型的角度分析了软件开发组织（全企业或企业中的一些部门）如何进行敏捷转型；第7章介绍了在分布式开发环境和团队中如何采用敏捷实践。

《敏捷软件开发方法与实践》的目标读者包括软件行业从业人员、高等院校软件工程专业本科生和研究生以及对敏捷软件开发感兴趣的教学研究人员。

书籍目录

第1章　敏捷软件开发方法的历程　1.1　敏捷方法的出现　　1.1.1　软件开发简史　　1.1.2　敏捷方法是历史的必然　1.2　敏捷联盟与敏捷宣言　　1.2.1　个人与沟通胜过过程与工具　　1.2.2　可工作软件胜过面面俱到的文档　　1.2.3　客户协作胜过合同谈判　　1.2.4　响应变化胜过遵循计划　1.3　敏捷原则　　1.3.1　敏捷的十二项原则　　1.3.2　敏捷实践和原则与传统方法的比较　1.4　敏捷方法动态　　1.4.1　敏捷领导力运动　　1.4.2　敏捷成熟度模型第2章　敏捷软件方法族　2.1　Scrum方法　　2.1.1　理论方法与经验方法　　2.1.2　Scrum——经验式过程框架　　2.1.3　Scrum流程与实践　2.2　极限编程方法　　2.2.1　XP的过程模型　　2.2.2　XP的价值观、原则和实践　　2.2.3　XP2的一些变化　2.3　Crystal方法　2.4　特性驱动开发方法　　2.4.1　FDD中的角色和职责　　2.4.2　FDD开发过程　2.5　精益软件开发　　2.5.1　丰田生产系统与精益生产　　2.5.2　精益软件开发原则和工具　2.6　适应性软件开发　2.7　动态系统开发方法　　2.7.1　DSDM项目生命周期阶段的四个步骤　　2.7.2　DSDM的原则　2.8　敏捷统一过程　　2.8.1　AUP的四个总体阶段　　2.8.2　AUP规程及在各阶段的工作　　2.8.3　增量式发布　　2.8.4　AUP的原则　2.9　各种敏捷方法的简单总结第3章　敏捷项目交付模型　3.1　敏捷软件交付模型　3.2　项目规划　　3.2.1　本阶段工作概述　　3.2.2　统一不同涉众的目标和愿景　　3.2.3　确定项目初始范围　　3.2.4　制定初始发布计划　3.3　迭代开发　　3.3.1　项目启动　迭代O　　3.3.2　迭代开发过程　3.4　发布前的用户验收测试　　3.4.1　发布前验收测试的必要性　　3.4.2　用户验收测试的分类及实施第4章　敏捷管理实践　4.1　项目范围管理　　4.1.1　引例　　4.1.2　项目管理三角形　　4.1.3　需求变更管理　　4.1.4　敏捷范围管理　4.2　每日站立会议(Stand-up)　　4.2.1　Stand-up及其作用　　4.2.2　Stand-up的常用实践　　4.2.3　Stand-up的常见问题　4.3　项目进度跟踪　　4.3.1　发布进度跟踪　　4.3.2　迭代进度跟踪　4.4　迭代回顾　　4.4.1　回顾的作用　　4.4.2　迭代回顾过程——海星图法　　4.4.3　其他回顾方法　4.5　项目风险管理　　4.5.1　风险识别　　4.5.2　风险评估　　4.5.3　风险应对　　4.5.4　风险管理检查　4.6　促进信息交换的工作空间　　4.6.1　作战墙　　4.6.2　开放式工作室第5章　敏捷开发实践　5.1　敏捷需求分析　　5.1.1　传统需求分析和敏捷需求分析的对比　　5.1.2　敏捷需求划分的单位　　5.1.3　敏捷需求分析的时机和细化过程　　5.1.4　敏捷需求分析中的文档　5.2　设计与编码实践　　5.2.1　简单设计　　5.2.2　重构　　5.2.3　持续集成　　5.2.4　测试驱动开发　　5.2.5　演进式设计　5.3　测试　　5.3.1　开发沙箱测试　　5.3.2　自动化验收测试　　5.3.3　探索测试　　5.3.4　冒烟、Sanity与回归测试第6章　软件开发企业的敏捷转型　6.1　采用敏捷与敏捷转型　6.2　企业转型决策分析　　6.2.1　转型动因分析　　6.2.2　判断敏捷是否是企业所需　　6.2.3　选择变革方式　6.3　企业变革模型　　6.3.1　Lewin变革模型　　6.3.2　Kotter变革实施模型　6.4　转型的实施过程　　6.4.1　产生紧迫感　　6.4.2　建立强有力的领导联盟　　6.4.3　确立转型愿景　　6.4.4　沟通转型愿景　　6.4.5　排除障碍　　6.4.6　计划并夺取短期胜利　　6.4.7　巩固成果并深化变革　　6.4.8　变革成果制度化第7章　分布式环境下的敏捷实践　7.1　分布式敏捷和案例项目简述　7.2　敏捷方法面临的困难　　7.2.1　沟通障碍　　7.2.2　语言与文化背景差异　　7.2.3　缺乏控制　　7.2.4　缺乏信任　　7.2.5　现场业务分析师的强势　7.3　一些改进性实践　　7.3.1　沟通改进　　7.3.2　保持项目状态可视　　7.3.3　增进信任　　7.3.4　减少转手工作　　7.3.5　额外的客户联系　　7.3.6　更详细的需求文档　　7.3.7　持续的过程调整参考文献

前言

自1968年“软件危机”【Naur et al 1969】一词出现以来，软件产业从业者和学者一直在探讨如何将传统行业中的工程方法应用于软件行业，希望软件的开发过程以一种受控、可预测的方式进行，并因此出现了软件工程这一学科。40多年来，软件从仅仅应用于国防军事和航空航天等高端领域，逐渐渗透到几乎所有的产业，甚至已经像水和空气一样成为人类日常生活和工作不可或缺的元素。相应地，软件开发领域相继出现了许多不同的开发过程和模型，从瀑布式模型、螺旋式模型，到CMMI软件能力成熟度评估和改进框架等。这些过程模型和框架无一例外地都是基于“完美的结果产生于精确控制的过程”这个理念，对软件开发生命周期中的计划与执行都十分重视，“按计划、不超预算、实现了预定的需求规格范围、产出物的质量可接受”，成了一种公认的、软件开发项目成功的标准。对于最早利用计算机软件的国防军事和航空航天等复杂的、需要大量预先设计的应用领域来说，上述模型或项目成功标准依然成立。但是就数量上来说，在今天，更多的软件项目是服务于面对市场激烈竞争氛围的企业。能否快速响应市场的变化、调整自己的经营和管理方式，是决定一个企业能否生存和发展的根本因素，在这种情况下，已有的软件开发过程和模型就显得有些滞重，从而造成企业的信息化系统研发经常不能满足其日新月异的经营方式所需。为此，从20世纪90年代中后期开始，在企业应用软件开发的圈子里，陆续出现了一些轻量级的开发方法【Fowler 2004】，这些方法以企业业务价值最大化为目标，快速适应企业的业务变化，并尽量缩短企业信息系统从规划到初次投入使用的时间周期。在2001年的一次学术讨论会上，这些方法的创作者和拥护者们总结了这些方法的共性，发表了敏捷宣言，并将这些方法统一到“敏捷”这一面旗帜之下[Agilemanifesto 2001】。最近十几年来，很多敏捷软件开发方法的成功案例，终于使之从“草根一族”渐渐走入了主流软件开发方法学的厅堂：CMM／CMMI的核心发起单位——卡耐基一梅隆大学的SEI，也专门有研究报告，以论证敏捷方法和CMMI的兼容性和互补性[Glazer et al 2008】；兼并了著名的软件工程工具厂商Rational的业界大鳄IBM，也宣称推出自己的敏捷软件开发解决方案[IBM 2009]。国内敏捷软件开发的起步虽然较欧美晚，但在经济全球化的今天，敏捷热潮也逐渐从国外传到国内，尤其是随着业界领导厂商之一的ThoughtWorks公司进入中国市场，以及一贯致力于敏捷方法推广的IT专业媒体网站InfoQ中文站的开通，使得敏捷方法在中国也正以燎原之势快速地传播。通过其官方网站不难看出，国内最大的软件企业华为公司也已经开始采用这种方法【Huawei 2009】。

章节摘录

插图：4）聚焦团队工作方向根据Stand.up对过去24小时工作状况的总结，结合项目的最新状态，团队需要确定今后24小时内的工作重点，并将每个人的工作重心统一到一个方向上，避免个别团队成员因个人的兴趣或对当前工作重点理解的不准确而将时间浪费在非当前最重要的事情上。5）加强团队建设项目团队通过每天的Stand-up沟通信息，分享彼此所遇到的困难并相互协助，共同克服，同时每个人都主动向团队作出自己为项目成功所付出努力的承诺，这非常有助于团队增进团结，提升凝聚力，甚至比任何其他形式的、专门用来进行团队建设的活动还有效。6）外部涉众的随机检查点高级经理、项目投资人或项目外对项目状况感兴趣的人都可以作为听众列席Stand-up，这样做能够有效减少专门的、费力的项目状况通报会。不过，一般来说，即便高级经理和项目投资人参加了每次的Stand-up，项目还是需要正式的项目报告，如项目总体进度等还是需要从更宏观的、Stand-up不能覆盖的高度进行总结和报告。只不过项目报告的周期可以拉长，范围和形式可得到简化。

图书封面

---

 敏捷软件开发方法与实践下载

---