敏捷开发知识体系.docx
《敏捷开发知识体系.docx》由会员分享，可在线阅读，更多相关《敏捷开发知识体系.docx（36页珍藏版）》请在冰点文库上搜索。
敏捷开发知识体系
敏捷开发知识体系总体框架
修订历史记录
日期
版本
说明
作者
1.0
初稿
1敏捷开发知识体系整体框架
敏捷开发知识体系的核心
敏捷开发是一个灵活的开发方法，用于在一个动态的环境中向干系人快速交付价值。
其主要特点是关注的持续的交付价值，通过迭代和快速用户反馈管理不确定性和拥抱变更；它承认个人才是价值的最终源泉，强调通过有效的个人激励，提升团队的工作绩效。
敏捷开发知识体系的核心是敏捷宣言，它们是敏捷开发思想和价值观的集中体现。
敏捷软件开发宣言具体内容如下：
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。
由此我们建立了如下价值观：
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
正确理解敏捷宣言是成功开展敏捷开发的关键，它告诉我们敏捷是一个相对的词汇，具体敏捷程度取决去项目团队的上下文，例如复杂项目由于其团队规模、技术特点和循规要求等，要求团队有更严格的治理流程和工具支持、更规范的文档和计划要求。
但仍然可以借助敏捷的价值观和各种实践解决开发过程中遇到的问题。
在具体的敏捷开发实践中，我们必须实事求是地采用合适的敏捷实践，以实用主义为指导思想，面向业务结果和价值，切不可为了敏捷而敏捷。
围绕着敏捷宣言，敏捷开发方法的领导者定义了用于指导团队开展敏捷开发实践的必须遵循的12条基本原则，它们是敏捷开发实践的总体指南。
敏捷宣言遵循的12条原则如下：
●我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
●欣然面对需求变化，即使在开发后期也一样。
为了客户的竞争优势，敏捷过程掌控变化。
●经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
●业务人员和开发人员必须相互合作，项目中的每一天都不例外。
●激发个体的斗志，以他们为核心搭建项目。
提供所需的环境和支援，辅以信任，从而达成目标。
●不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
●可工作的软件是进度的首要度量标准。
●敏捷过程倡导可持续开发。
责任人、开发人员和用户要能够共同维持其步调稳定延续。
●坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
●以简洁为本，它是极力减少不必要工作量的艺术。
●最好的架构、需求和设计出自自组织团队。
●团队定期地反思如何能提高成效，并依此调整自身的举止表现。
注：
以上敏捷宣言遵循的原则摘自敏捷宣言简体中文版官方网站
敏捷开发管理实践
随着敏捷开发运动的开展，如图所示，敏捷的践行者逐渐发展出两类敏捷开发最佳实践：
敏捷开发管理实践和敏捷开发工程实践。
敏捷开发管理实践泛指用于指导敏捷团队进行敏捷开发实践的开发方法和流程，业界应用最广的敏捷开发管理实践包括：
（具体实践列表将根据团队工作成果，适当改变，并包含简单描述。
）
●Scrum：
●极限编程（XP）：
●OpenUP：
●精益开发（Lean）：
●动态系统开发（DSDM）：
●特性驱动的开发：
敏捷开发工程实践
敏捷开发工程实践泛指用于指导敏捷团队进行敏捷开发过程中的各种工程化最佳实践，业界应用最广的敏捷开发工程实践包括：
（具体实践列表将根据团队工作成果，适当改变，并包含简单描述。
）
项目管理：
▪迭代开发
▪风险价值生命周期
▪多级项目规划
▪完整团队
▪每日站立会议
▪任务板
▪燃尽图
需求管理：
▪需求订单
▪业务流程草图
▪用例驱动开发
▪用户故事
架构：
▪演进的架构
▪演进的设计
▪基于组件的架构设计
开发：
▪结对编程
▪测试驱动开发
▪重构
▪代码规范
测试：
▪单元测试
▪并行测试
▪测试管理
变更管理：
▪持续集成
▪自动构建
▪团队变更管理
在敏捷开发知识体系的其它章节，将具体描述每种敏捷开发管理实践和工程实践，为了方便阅读，我们将采用统一的方式描述其中具体内容。
其中，敏捷开发管理实践描述主要包括以下主要部分：
●方法定义和特性说明
●方法中包含的主要角色
●方法中包含的主要活动和最佳实践
●方法中包含的主要输入输出工件
●方法的工作流程说明
而敏捷开发工程实践描述将主要包括以下主要部分：
●最佳实践定义和特性说明
●如何应用最佳实践说明
●案例说明
2敏捷开发核心价值观和原则
敏捷软件开发宣言
2001年2月，17位在当时被称之为“轻量级方法学家”的软件开发领域领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。
经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。
这套价值观，通过一份简明扼要的《敏捷宣言》，传递给世界，宣告了敏捷开发运动的开始。
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。
由此我们建立了如下价值观：
个体和互动 高于流程和工具
工作的软件 高于详尽的文档
客户合作 高于合同谈判
响应变化 高于遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
注：
以上敏捷软件开发宣言摘自敏捷宣言简体中文版官方网站
敏捷开发的核心价值观
敏者，疾也。
对外来的刺激做出迅速、机灵的反应；捷者，獵也。
以最短的路径去追赶和实现目标。
敏捷开发的核心理念就是以最简单有效的方式快速的达成目标，并在这个过程中及时地响应外界的变化，做出迅速的调整。
敏捷开发的第一条价值观就是“以人为本”，强调“个体（人）”及“个体”间的沟通与协作在软件开发过程中的重要性。
这个顺序不是偶然而为之的，敏捷开发将重视个体潜能的激发和团队的高效协作作为其所推崇的第一价值观。
敏捷开发的第二条价值观就是“目标导向”。
同其他众多管理理论和模型一样，敏捷开发认同目标导向是成功的关键，因为没有目标也就无所谓成功。
敏捷开发的价值观中清楚地阐明，软件开发的目标是“可工作的软件”，而不是面面俱到的文档。
而遗憾的是，很多软件项目已经在纷繁的文档之中迷失了自己的目标。
敏捷开发的第三条价值观就是“客户为先”。
虽然敏捷开发强调的第一价值观是“以人为本”，但敏捷宣言的缔造者们并没有忘记客户，相反他们真正的理解客户的需求、懂得如何与客户合作。
敏捷价值观里强调的“客户为先”即不是简单的把客户当作“上帝”、简单的推崇“客户至上”，客户要求什么、我们就做什么；也不是把客户当作“谈判桌上的对手”甚至“敌人”，去斗智斗勇。
敏捷价值观里中把客户当成了合作者和伙伴，把自己的使命定位为“帮助客户取得竞争优势”。
敏捷开发的第四条价值观就是“拥抱变化”。
人们常说“世界上唯一不变的就是变化”，大多数人也相信事实确实如此。
而以往很多的软件项目却忽视了这一点，或者更准确的说是它们不愿意“正视”。
它们总是试图用详尽的计划与预先穷举这些变化，然后又试图通过严格遵循计划来控制变化的发生，而结果往往是被不断涌现的变化击垮。
敏捷开发价值观中承认变化是软件开发的一部分、并相信正是客户在不断变化其需求的过程中明晰了其真正的需要。
因而敏捷开发欢迎变化、拥抱变化，并可坦然应对变化，正是这些变化为客户和项目带来了价值。
最后，我们还应记住敏捷宣言中的最后一条：
“尽管右项有其价值，我们更重视左项的价值”——敏捷宣言并未否定或贬损“右项”的价值，在敏捷开发的价值观中承认“流程和工具”、“详尽的文档”、“合同谈判”以及“遵循计划”的重要性，只是两相比较，“更重视左项的价值”。
敏捷开发的原则
敏捷开发的原则
敏捷宣言遵循的原则
●l 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
●l 欣然面对需求变化，即使在开发后期也一样。
为了客户的竞争优势，敏捷过程掌控变化。
●l 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
●l 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
●l 激发个体的斗志，以他们为核心搭建项目。
提供所需的环境和支援，辅以信任，从而达成目标。
●l 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
●l 可工作的软件是进度的首要度量标准。
●l 敏捷过程倡导可持续开发。
责任人、开发人员和用户要能够共同维持其步调稳定延续。
●l 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
●l 以简洁为本，它是极力减少不必要工作量的艺术。
●l 最好的架构、需求和设计出自自组织团队。
●l 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
注：
以上敏捷宣言遵循的原则摘自敏捷宣言简体中文版官方网站
敏捷开发原则的应用
敏捷开发原则是对敏捷价值观的解释和实践，它将敏捷的价值观落实到具体的可操作的原则之上，严格的遵循这十二条原则，是敏捷软件开发项目得以成功的基石。
可以说这十二条原则已经囊括了软件项目管理的基本流程，而且这些流程足够具体：
它告诉我们项目管理的第一步就是要明确目标，而软件项目的终极目标就是“不断地及早交付有价值的软件使客户满意”；它提示我们软件工程的起始点是需求，而需求的固有特征就是不断变化，敏捷开发过程要“掌控变化”；它强调“可工作的软件是进度的首要度量标准”，因而需要以尽可能短的周期“经常地交付可工作的软件”；它重视相关干系人的协调（“业务人员和开发人员必须相互合作”、“责任人、开发人员和用户要能够共同维持其步调稳定延续”），重视激发个人潜能（“激发个体的斗志”），要求团队使用最高效的沟通方式（“面对面的交谈”）；它推崇技术变革所具备的强大能量（“坚持不懈地追求技术卓越和良好设计”）；它强调精益生产（简洁为本），要求项目采用“自组织”团队管理模式，并指出“定期的总结反思”，是校准团队行为、最终达成目标的有效途径。
成熟的敏捷开发团队，完全可以不再需要任何附加的冗余流程（工程技术流程除外），而成功的完成软件的开发和交付。
当然，敏捷开发团队也可以以这十二条原则为基础，进一步的细化敏捷项目的管理流程、步骤、和方法工具，以便这些原则能够更好的被团队理解和执行。
对以上所有原则的严格遵守将大大提高敏捷项目成功的可能性。
3主要的敏捷开发管理实践
敏捷开发管理实践描述模板
方法定义和特性说明
方法中包含的主要角色
方法中包含的主要活动和最佳实践
方法中包含的主要输入输出工件
方法的工作流程说明
敏捷开发方法之Scrum
Scrum方法定义和特性说明
术语Scrum来源于橄榄球活动，在英文中的意思是橄榄球里的争球。
在橄榄球比赛中，双方前锋站在一起紧密相连，当球在他们之间投掷时，他们奋力争球。
1995年，在奥斯汀举办的OOPSLA'95上，萨瑟兰和施瓦伯首次提出了Scrum概念，并在随后的几年中逐步将其与业界的最佳实践融合起来，形成一种迭代式增量软件开发过程和敏捷项目管理方法，并在2001年敏捷联盟（AgileAlliance）形成后受到了更多欢迎。
Scrum是一种灵活的软件管理过程，它提供了一种经验方法，可以帮助你驾驭迭代，实现递增的软件开发过程。
这一过程是迅速、有适应性、自组织的，它发现了软件工程的社会意义，使得团队成员能够独立地集中在创造性的协作环境下工作。
Scrum采用了经验方法，承认问题无法完全理解或定义，关注于如何使得开发团队快速推出和响应需求能力的最大化。
因此，Scrum的一个关键原则就是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。
Scrum是一个包括了一系列实践和预定义角色的过程框架。
任何软件开发过程框架都可以由最基本的三个要素组成：
角色（人）、活动及其输入输出的工件。
Scrum框架主要包括以下内容：
▪角色；
▪产品负责人（ProductOwner）；
▪Scrum主管（ScrumMaster）；
▪团队成员；
▪活动；
▪冲刺规划会议（SprintPlanMeeting）；
▪每日站立会议（ScrumDailyMeeting）；
▪冲刺复审会议（SprintReviewMeeting）；
▪冲刺回顾会议（SprintRetrospectiveMeeting）；
▪工件；
▪产品订单（ProductBacklog）；
▪冲刺订单（SprintBacklog）；
▪燃尽图（BurndownChart）；
▪新的功能增量。
下面我们就从角色、活动和工件三个维度对整个Scrum过程进行简单介绍。
Scrum方法中包含的主要角色
Scrum定义了许多角色，根据猪和鸡的笑话可以分为两组，猪和鸡。
一天，一头猪和一只鸡在路上散步。
鸡看了一下猪说：
“嗨，我们合伙开一家餐馆怎么样？
”。
猪回头看了一下鸡说：
“好主意，那你准备给餐馆起什么名字呢？
”。
鸡想了想说：
“餐馆名字叫火腿和鸡蛋怎么样？
”。
“我不这么认为”，猪说，“我全身投入，而你只是参与而已”。
“猪”角色：
是全身投入项目和Scrum过程的人，主要包括代表利益干系人的产品负责人，同项目经理类似的Scrum主管和开发团队。
产品负责人（ProductOwner）：
代表了客户的意愿，这保证Scrum团队在做从业务角度来说正确的事情。
同时他又代表项目的全体利益干系人，负责编写用户需求（用户故事），排出优先级，并放入产品订单（ProductBacklog），从而使项目价值最大化的人。
他利用产品订单，督促团队优先开发最具价值的功能，并在其基础上继续开发，将最具价值的开发需求安排在下一个冲刺迭代（Sprint）中完成。
他对项目产出的软件系统负责，规划项目初始总体要求、ROI目标和发布计划，并为项目赢得驱动及后续资金。
Scrum主管（ScrumMaster）：
负责Scrum过程正确实施和利益最大化的人，确保它既符合企业文化，又能交付预期利益。
Scrum主管的职责是向所有项目参与者讲授Scrum方法，正确的执行规则，确保所有项目相关人员遵守Scrum规则，这些规则形成了Scrum过程。
Scrum主管并非团队的领导（由于他们是自我组织的），他的主要工作是去除那些影响团队交付冲刺目标的障碍，屏蔽外界对开发团队的干扰。
“Scrum主管是保证Scrum成功的牧羊犬”。
开发团队：
负责找出可在一个迭代中将产品待开发事项（冲刺订单）转化为功能增量的方法。
他们对每一次迭代和整个项目共同负责，在每个冲刺中通过实行自管理、自组织，和跨职能的开发协作，实现冲刺目标和最终交付产品。
一般由5~9名具有跨职能技能的人（设计者，开发者等）组成。
“鸡”角色：
并不是实际Scrum过程的一部分，但是必须考虑他们。
敏捷方法的一个重要方面是使得用户和利益所有者参与每一个冲刺的评审和计划并提供反馈。
用户：
软件是为了某些人而创建！
就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？
”。
利益所有者（客户，提供商）：
影响项目成功的人，但只直接参与冲刺评审过程。
经理：
为产品开发团体架起环境的那个人。
如图3.4所示为Scrum方法中的主要角色。
图3.Scrum方法中的主要角色
Scrum方法中包含的主要活动和最佳实践
Scrum作为软件开发过程框架，它包含的主要最佳实践包括以下几个方面。
迭代式软件开发：
通过将整个软件交付过程分成多个迭代周期，帮助团队更好地应对变更，应对风险，实现增量交付、快速反馈。
两层项目规划（Two-LevelProjectPlanning）：
基于远粗近细的原则和项目渐进明细的特点，通过将概要的项目整体规划和详细的近期迭代计划有机结合，帮助团队有效提高计划的准确度、资源管理能力和项目的按时交付能力。
整体团队协作（WholeTeam）：
通过关注保持整个团队可持续发展的工作节奏、每日站立会议和自组织的工作分配，实现团队的高效协作和工作，实现提高整个团队生产力的目的。
持续集成：
通过进行更频繁的软件集成，实现更早的发现和反馈错误、降低风险，并使整个软件交付过程变得更加可预测和可控，以交付更高质量的软件。
Scrum的活动主要由冲刺规划会议（SprintPlanMeeting）、每日站立会议（SprintDailyMeeting）、冲刺复审会议（SprintReviewMeeting）和冲刺回顾会议（RetrospectiveMeeting）组成。
Scrum提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范（Disciplines），这些有助于创造自我组织的团队。
冲刺规划会议：
冲刺开始时，均需召开冲刺规划会议，产品负责人和团队共同探讨该冲刺的工作内容。
产品负责人从最优先的待开发事项中进行筛选，告知团队其预期目标；团队则提出在接下来的冲刺内，评估预期目标可实现的程度。
冲刺规划会议一般不超过8小时。
在前4个小时中，产品负责人向团队展示最高优先级的产品，团队则向他询问产品订单的内容、目的、含义及意图。
而在后4小时，团队则计划本冲刺的具体安排。
每日站立会议：
在冲刺中，每一天都会举行项目状况会议，被称为Scrum或“每日站立会议”。
每日站立会议有一些具体的指导原则：
▪会议准时开始。
对于迟到者团队常常会制定惩罚措施（例如罚款、做俯卧撑、在脖子上挂橡胶鸡玩具等）。
▪欢迎所有人参加，但只有“猪”类人员可以发言。
▪不论团队规模大小，会议被限制在15分钟。
▪所有出席者都应站立（有助于保持会议简短）。
▪会议应在固定地点和每天的同一时间举行。
在会议上，每个团队成员需要回答三个问题：
▪今天你完成了那些工作？
▪明天你打算做什么？
▪完成你的目标是否存在什么障碍？
（Scrum主管需要记下这些障碍）
冲刺复审会议：
一般4个小时，由团队成员向产品负责人向其他利益相关人展示Sprint周期内的产品开发情况，并决定下一次Sprint的内容。
冲刺回顾会议（RetrospectiveMeeting）：
每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。
举行冲刺回顾会议是为了进行持续过程改进。
会议的时间限制在4小时。
如图3.所示表示Scrum方法中的主要活动和交付件。
图3.Scrum方法中的主要活动和交付件
Scrum方法中包含的主要输入输出工件
产品订单：
产品订单（ProductBacklog）是整个项目的概要文档，它包含已划分优先等级的、项目要开发的系统或产品的需求清单，包括功能和非功能性需求及其他假设和约束条件。
产品负责人和团队主要按业务和依赖性的重要程度划分优先等级，并作出预估。
预估值的精确度取决于产品订单中条目的优先级和细致程度，入选下一个冲刺的最高优先等级条目的预估会非常精确。
产品的需求清单是动态的，随着产品及其使用环境的变化而变化，并且只要产品存在，它就随之存在。
而且，在整个产品生命周期中，管理层不断确定产品需求或对之做出改变，以保证产品适用性、实用性和竞争性。
.
冲刺订单：
冲刺订单（SprintBacklog）是大大细化了的文档，用来界定工作或任务，定义团队在Sprint中的任务清单，这些任务会将当前冲刺选定的产品订单转化为完整的产品功能增量。
冲刺订单在冲刺规划会议中形成，其包含的不会被分派，而是由团队成员签名认领他们喜爱的任务。
任务被分解为以小时为单位，没有任务可以超过16个小时。
如果一个任务超过16个小时，那么它就应该被进一步分解。
每项任务信息将包括其负责人及其在冲刺中任一天时的剩余工作量，且仅团队有权改变其内容。
燃尽图：
燃尽图（BurndownChart）是一个公开展示的图表，纵轴代表剩余工作量，横轴代表时间，显示当前冲刺中随时间变化而变化的剩余工作量（可以是未完成的任务数目，或在冲刺订单上未完成的订单项的数目）。
剩余工作量趋势线与横轴之间的交集表示在那个时间点最可能的工作完成量。
我们可以借助它设想在增加或减少发布功能后项目的情况，我们可能缩短开发时间，或延长开发期限以获得更多功能。
它可以展示项目实际进度与计划之间的矛盾。
新的功能增量：
Scrum团队在每个冲刺周期内完成的、可交付的产品功能增量。
Scrum方法的工作流程说明
在Scrum项目管理过程中，一般产品负责人获取项目投资，并对整个产品的成功负责。
他会协调各种利益干系人，确定产品订单中初始的需求清单及其优先级，完成项目的商业价值分析和项目整体规划，并任命合适的Scrum主管开展项目工作。
如图3.7所示表示Scrum方法的全景图。
图3.Scrum方法全景图
在Scrum软件开发项目中，每个冲刺就是一个为期30天的迭代。
在每个冲刺开始时，产品负责人和Scrum主管通过召开冲刺规划会议和“两层项目规划”的最佳实践，制定冲刺订单（类似于迭代计划），明确将在本次冲刺中实现的需求清单，相应的工作任务和负责人。
在每个冲刺迭代中，团队强调应用“整体团队协作”的最佳实践，通过保持可持续发展的工作节奏和每日站立会议，实现团队的自组织、自适应和自管理，高效完成冲刺工作。
在每个冲刺结束时，团队都会召开冲刺复审会议，团队成员会在会上分别展示他们开发出的软件（或其他有价值的产品），并从产品负责人和其他利益干系人那里，得到反馈信息。
在冲刺复审会议之后，团队会自觉召开冲刺回顾会议，回顾整个项目过程，讨论那些方面做得好，哪些方面可以改进，实现软件交付过程的持续、自发的改进。
敏捷开发方法之Lean软件开发
基于ToyotaLean生产概念
减少浪费
无用的功能 20%的功能往往能够提供80%的价值，你需要的是这样的一个流程。
变来变去 如果出现需求变来变去的情况，那么是你太早的文档化需求；如果出现专门的测试和修复的阶段，那么是你测试得太晚。
跨越边界 组织边界通常会增加超过25%的成本，是降低响应时间和妨碍沟通的隔离带
减少浪费的方法
延迟决策 抛弃那种认为只有具备完整的规约之后才能开发的想法。
消除依赖 系统架构应该允许在任何时间增添任何功能。
保持可能 把代码当成验证的机会–同时使代码易于变更。
在最后一刻才做出决策 做决策之前尽可能多的了解信息。
Lean软件开发的原则
消除浪费 价值流图完整的解决方案
构建质量 基础规程持续验证
延迟决策 保持可能
快速交付 排队理论
关注学习 产品&流程
尊重个人 团队伙伴
优化整体 系统思考Set-baseddesign
敏捷开发方法之极限编程（XP）
XP（eXtremeProgramming）
极限编程核心实践
*SmallReleases
*Refactoring
*Testing/Test-drivenDevelopment
*PairProgramming
*SustainablePace/40-hourWeek
*TeamCodeOwnership
*CodingStandards/Conventions
*SimpleDesign
*Metaphor（e.g.,chalkboardapp）
*PlanningGame
*ContinuousIntegration/Build
*On-siteCustomer
StoryCardsSummarizeRequirements
PrototypeUIsandUInavigation
Stand-UpM
升级会员 