敏捷开发知识体系.doc

《敏捷开发知识体系.doc》由会员分享，可在线阅读，更多相关《敏捷开发知识体系.doc（33页珍藏版）》请在三一办公上搜索。

1、敏捷开发知识体系总体框架修订历史记录日期版本说明作者1.0初稿1 敏捷开发知识体系整体框架1.1 敏捷开发知识体系的核心敏捷开发是一个灵活的开发方法，用于在一个动态的环境中向干系人快速交付价值。其主要特点是关注的持续的交付价值，通过迭代和快速用户反馈管理不确定性和拥抱变更；它承认个人才是价值的最终源泉，强调通过有效的个人激励，提升团队的工作绩效。敏捷开发知识体系的核心是敏捷宣言，它们是敏捷开发思想和价值观的集中体现。敏捷软件开发宣言具体内容如下：我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：个体和互动 高于 流程和工具工作的软件 高于 详尽的文档客

2、户合作 高于 合同谈判响应变化 高于 遵循计划也就是说，尽管右项有其价值，我们更重视左项的价值。正确理解敏捷宣言是成功开展敏捷开发的关键，它告诉我们敏捷是一个相对的词汇，具体敏捷程度取决去项目团队的上下文，例如复杂项目由于其团队规模、技术特点和循规要求等，要求团队有更严格的治理流程和工具支持、更规范的文档和计划要求。但仍然可以借助敏捷的价值观和各种实践解决开发过程中遇到的问题。在具体的敏捷开发实践中，我们必须实事求是地采用合适的敏捷实践，以实用主义为指导思想，面向业务结果和价值，切不可为了敏捷而敏捷。围绕着敏捷宣言，敏捷开发方法的领导者定义了用于指导团队开展敏捷开发实践的必须遵循的12条基本原

3、则，它们是敏捷开发实践的总体指南。敏捷宣言遵循的12条原则如下：l 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。l 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。l 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。l 业务人员和开发人员必须相互合作，项目中的每一天都不例外。l 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。l 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。l 可工作的软件是进度的首要度量标准。l 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同

4、维持其步调稳定延续。l 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。l 以简洁为本，它是极力减少不必要工作量的艺术。l 最好的架构、需求和设计出自自组织团队。l 团队定期地反思如何能提高成效，并依此调整自身的举止表现。注：以上敏捷宣言遵循的原则摘自敏捷宣言简体中文版官方网站http:/agilemanifesto.org/iso/zhchs/1.2 敏捷开发管理实践随着敏捷开发运动的开展，如图所示，敏捷的践行者逐渐发展出两类敏捷开发最佳实践：敏捷开发管理实践和敏捷开发工程实践。敏捷开发管理实践泛指用于指导敏捷团队进行敏捷开发实践的开发方法和流程，业界应用最广的敏捷开发管理实践包括：（具

5、体实践列表将根据团队工作成果，适当改变，并包含简单描述。）l Scrum：l 极限编程（XP）：l OpenUP：l 精益开发（Lean）：l 动态系统开发(DSDM)：l 特性驱动的开发：1.3 敏捷开发工程实践敏捷开发工程实践泛指用于指导敏捷团队进行敏捷开发过程中的各种工程化最佳实践，业界应用最广的敏捷开发工程实践包括：（具体实践列表将根据团队工作成果，适当改变，并包含简单描述。） 项目管理： 迭代开发 风险价值生命周期 多级项目规划 完整团队 每日站立会议 任务板 燃尽图 需求管理： 需求订单 业务流程草图 用例驱动开发 用户故事架构： 演进的架构 演进的设计 基于组件的架构设计 开发：

6、 结对编程 测试驱动开发 重构 代码规范测试： 单元测试 并行测试 测试管理变更管理： 持续集成 自动构建 团队变更管理在敏捷开发知识体系的其它章节，将具体描述每种敏捷开发管理实践和工程实践，为了方便阅读，我们将采用统一的方式描述其中具体内容。其中，敏捷开发管理实践描述主要包括以下主要部分：l 方法定义和特性说明l 方法中包含的主要角色l 方法中包含的主要活动和最佳实践l 方法中包含的主要输入输出工件l 方法的工作流程说明而敏捷开发工程实践描述将主要包括以下主要部分：l 最佳实践定义和特性说明l 如何应用最佳实践说明l 案例说明2 敏捷开发核心价值观和原则2.1 敏捷软件开发宣言2001年2月

7、，17位在当时被称之为“轻量级方法学家”的软件开发领域领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一份简明扼要的敏捷宣言，传递给世界，宣告了敏捷开发运动的开始。敏捷软件开发宣言我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：个体和互动高于 流程和工具工作的软件高于 详尽的文档客户合作高于 合同谈判响应变化高于 遵循计划也就是说，尽管右项有其价值，我们更重视左项的价值。注：以上敏捷软件开发宣言摘自敏捷宣言简体中文版官方网

8、站http:/agilemanifesto.org/iso/zhchs/2.2 敏捷开发的核心价值观敏者，疾也。对外来的刺激做出迅速、机灵的反应；捷者，獵也。以最短的路径去追赶和实现目标。敏捷开发的核心理念就是以最简单有效的方式快速的达成目标，并在这个过程中及时地响应外界的变化，做出迅速的调整。敏捷开发的第一条价值观就是“以人为本”，强调“个体（人）”及“个体”间的沟通与协作在软件开发过程中的重要性。这个顺序不是偶然而为之的，敏捷开发将重视个体潜能的激发和团队的高效协作作为其所推崇的第一价值观。敏捷开发的第二条价值观就是“目标导向”。同其他众多管理理论和模型一样，敏捷开发认同目标导向是成功的关

9、键，因为没有目标也就无所谓成功。敏捷开发的价值观中清楚地阐明，软件开发的目标是“可工作的软件”，而不是面面俱到的文档。而遗憾的是，很多软件项目已经在纷繁的文档之中迷失了自己的目标。敏捷开发的第三条价值观就是“客户为先”。虽然敏捷开发强调的第一价值观是“以人为本”，但敏捷宣言的缔造者们并没有忘记客户，相反他们真正的理解客户的需求、懂得如何与客户合作。敏捷价值观里强调的“客户为先”即不是简单的把客户当作“上帝”、简单的推崇“客户至上”，客户要求什么、我们就做什么；也不是把客户当作“谈判桌上的对手”甚至“敌人”，去斗智斗勇。敏捷价值观里中把客户当成了合作者和伙伴，把自己的使命定位为“帮助客户取得竞争

10、优势”。敏捷开发的第四条价值观就是“拥抱变化”。人们常说“世界上唯一不变的就是变化”，大多数人也相信事实确实如此。而以往很多的软件项目却忽视了这一点，或者更准确的说是它们不愿意“正视”。它们总是试图用详尽的计划与预先穷举这些变化，然后又试图通过严格遵循计划来控制变化的发生，而结果往往是被不断涌现的变化击垮。敏捷开发价值观中承认变化是软件开发的一部分、并相信正是客户在不断变化其需求的过程中明晰了其真正的需要。因而敏捷开发欢迎变化、拥抱变化，并可坦然应对变化，正是这些变化为客户和项目带来了价值。最后，我们还应记住敏捷宣言中的最后一条：“尽管右项有其价值，我们更重视左项的价值”敏捷宣言并未否定或贬损

11、“右项”的价值，在敏捷开发的价值观中承认“流程和工具”、“详尽的文档”、“合同谈判”以及“遵循计划”的重要性，只是两相比较，“更重视左项的价值”。2.3 敏捷开发的原则2.3.1 敏捷开发的原则敏捷宣言遵循的原则l l我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。l l欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。l l经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。l l业务人员和开发人员必须相互合作，项目中的每一天都不例外。l l激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。l l

12、不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。l l可工作的软件是进度的首要度量标准。l l敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。l l坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。l l以简洁为本，它是极力减少不必要工作量的艺术。l l最好的架构、需求和设计出自自组织团队。l l团队定期地反思如何能提高成效，并依此调整自身的举止表现。注：以上敏捷宣言遵循的原则摘自敏捷宣言简体中文版官方网站http:/agilemanifesto.org/iso/zhchs/2.3.2 敏捷开发原则的应用敏捷开发原则是对敏捷价值观的解释和实践，它将敏

13、捷的价值观落实到具体的可操作的原则之上，严格的遵循这十二条原则，是敏捷软件开发项目得以成功的基石。可以说这十二条原则已经囊括了软件项目管理的基本流程，而且这些流程足够具体：它告诉我们项目管理的第一步就是要明确目标，而软件项目的终极目标就是“不断地及早交付有价值的软件使客户满意”；它提示我们软件工程的起始点是需求，而需求的固有特征就是不断变化，敏捷开发过程要“掌控变化”；它强调“可工作的软件是进度的首要度量标准”，因而需要以尽可能短的周期“经常地交付可工作的软件”；它重视相关干系人的协调（“业务人员和开发人员必须相互合作”、“责任人、开发人员和用户要能够共同维持其步调稳定延续”），重视激发个人潜

14、能（“激发个体的斗志”），要求团队使用最高效的沟通方式（“面对面的交谈”）；它推崇技术变革所具备的强大能量（“坚持不懈地追求技术卓越和良好设计”）；它强调精益生产（简洁为本），要求项目采用“自组织”团队管理模式，并指出“定期的总结反思”，是校准团队行为、最终达成目标的有效途径。成熟的敏捷开发团队，完全可以不再需要任何附加的冗余流程（工程技术流程除外），而成功的完成软件的开发和交付。当然，敏捷开发团队也可以以这十二条原则为基础，进一步的细化敏捷项目的管理流程、步骤、和方法工具，以便这些原则能够更好的被团队理解和执行。对以上所有原则的严格遵守将大大提高敏捷项目成功的可能性。3 主要的敏捷开发管理实

15、践3.1 敏捷开发管理实践描述模板3.1.1 方法定义和特性说明3.1.2 方法中包含的主要角色3.1.3 方法中包含的主要活动和最佳实践3.1.4 方法中包含的主要输入输出工件3.1.5 方法的工作流程说明3.2 敏捷开发方法之Scrum3.2.1 Scrum方法定义和特性说明术语Scrum来源于橄榄球活动，在英文中的意思是橄榄球里的争球。在橄榄球比赛中，双方前锋站在一起紧密相连，当球在他们之间投掷时，他们奋力争球。1995年，在奥斯汀举办的OOPSLA 95上，萨瑟兰和施瓦伯首次提出了Scrum概念，并在随后的几年中逐步将其与业界的最佳实践融合起来，形成一种迭代式增量软件开发过程和敏捷项目

16、管理方法，并在2001年敏捷联盟（Agile Alliance）形成后受到了更多欢迎。Scrum是一种灵活的软件管理过程，它提供了一种经验方法，可以帮助你驾驭迭代，实现递增的软件开发过程。这一过程是迅速、有适应性、自组织的，它发现了软件工程的社会意义，使得团队成员能够独立地集中在创造性的协作环境下工作。Scrum采用了经验方法，承认问题无法完全理解或定义，关注于如何使得开发团队快速推出和响应需求能力的最大化。因此，Scrum的一个关键原则就是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。 Scrum是一个包括了一系列实践和预定义

17、角色的过程框架。任何软件开发过程框架都可以由最基本的三个要素组成：角色（人）、活动及其输入输出的工件。Scrum 框架主要包括以下内容： 角色； 产品负责人（Product Owner）； Scrum主管（Scrum Master）； 团队成员； 活动； 冲刺规划会议（Sprint Plan Meeting）； 每日站立会议（Scrum Daily Meeting）； 冲刺复审会议（Sprint Review Meeting）； 冲刺回顾会议（Sprint Retrospective Meeting）； 工件； 产品订单（Product Backlog）； 冲刺订单（Sprint Backlo

18、g）； 燃尽图（Burndown Chart）； 新的功能增量。下面我们就从角色、活动和工件三个维度对整个Scrum过程进行简单介绍。3.2.2 Scrum方法中包含的主要角色Scrum定义了许多角色，根据猪和鸡的笑话可以分为两组，猪和鸡。一天，一头猪和一只鸡在路上散步。鸡看了一下猪说：“嗨，我们合伙开一家餐馆怎么样？”。猪回头看了一下鸡说：“好主意，那你准备给餐馆起什么名字呢？”。鸡想了想说：“餐馆名字叫火腿和鸡蛋怎么样？”。“我不这么认为”，猪说，“我全身投入，而你只是参与而已”。“猪”角色：是全身投入项目和Scrum过程的人，主要包括代表利益干系人的产品负责人，同项目经理类似的Scrum

19、主管和开发团队。产品负责人（Product Owner）：代表了客户的意愿，这保证Scrum团队在做从业务角度来说正确的事情。同时他又代表项目的全体利益干系人，负责编写用户需求（用户故事），排出优先级，并放入产品订单（Product Backlog），从而使项目价值最大化的人。他利用产品订单，督促团队优先开发最具价值的功能，并在其基础上继续开发，将最具价值的开发需求安排在下一个冲刺迭代（Sprint）中完成。他对项目产出的软件系统负责，规划项目初始总体要求、ROI目标和发布计划，并为项目赢得驱动及后续资金。Scrum主管（Scrum Master）：负责Scrum过程正确实施和利益最大化的人，

20、确保它既符合企业文化，又能交付预期利益。Scrum主管的职责是向所有项目参与者讲授Scrum方法，正确的执行规则，确保所有项目相关人员遵守Scrum规则，这些规则形成了Scrum过程。Scrum主管并非团队的领导（由于他们是自我组织的），他的主要工作是去除那些影响团队交付冲刺目标的障碍，屏蔽外界对开发团队的干扰。“Scrum主管是保证Scrum成功的牧羊犬”。开发团队：负责找出可在一个迭代中将产品待开发事项（冲刺订单）转化为功能增量的方法。他们对每一次迭代和整个项目共同负责，在每个冲刺中通过实行自管理、自组织，和跨职能的开发协作，实现冲刺目标和最终交付产品。一般由59名具有跨职能技能的人（设计

21、者，开发者等）组成。 “鸡”角色：并不是实际Scrum过程的一部分，但是必须考虑他们。 敏捷方法的一个重要方面是使得用户和利益所有者参与每一个冲刺的评审和计划并提供反馈。用户：软件是为了某些人而创建！就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？”。利益所有者（客户，提供商）：影响项目成功的人，但只直接参与冲刺评审过程。经理：为产品开发团体架起环境的那个人。如图3.4所示为Scrum方法中的主要角色。图3. Scrum方法中的主要角色3.2.3 Scrum方法中包含的主要活动和最佳实践Scrum作为软件开发过程框架，它包含

22、的主要最佳实践包括以下几个方面。迭代式软件开发：通过将整个软件交付过程分成多个迭代周期，帮助团队更好地应对变更，应对风险，实现增量交付、快速反馈。两层项目规划（Two-Level Project Planning）：基于远粗近细的原则和项目渐进明细的特点，通过将概要的项目整体规划和详细的近期迭代计划有机结合，帮助团队有效提高计划的准确度、资源管理能力和项目的按时交付能力。整体团队协作（Whole Team）：通过关注保持整个团队可持续发展的工作节奏、每日站立会议和自组织的工作分配，实现团队的高效协作和工作，实现提高整个团队生产力的目的。持续集成：通过进行更频繁的软件集成，实现更早的发现和反馈错

23、误、降低风险，并使整个软件交付过程变得更加可预测和可控，以交付更高质量的软件。Scrum的活动主要由冲刺规划会议（Sprint Plan Meeting）、每日站立会议（Sprint Daily Meeting）、冲刺复审会议（Sprint Review Meeting）和冲刺回顾会议（Retrospective Meeting）组成。Scrum提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范（Disciplines），这些有助于创造自我组织的团队。冲刺规划会议：冲刺开始时，均需召开冲刺规划会议，产品负责人和团队共同探讨该冲刺的工作内容。产品负责人从最优先的待开发事项中进行筛

24、选，告知团队其预期目标；团队则提出在接下来的冲刺内，评估预期目标可实现的程度。冲刺规划会议一般不超过8小时。在前4个小时中，产品负责人向团队展示最高优先级的产品，团队则向他询问产品订单的内容、目的、含义及意图。而在后4小时，团队则计划本冲刺的具体安排。每日站立会议：在冲刺中，每一天都会举行项目状况会议，被称为Scrum或“每日站立会议”。每日站立会议有一些具体的指导原则： 会议准时开始。对于迟到者团队常常会制定惩罚措施（例如罚款、做俯卧撑、在脖子上挂橡胶鸡玩具等）。 欢迎所有人参加，但只有“猪”类人员可以发言。 不论团队规模大小，会议被限制在15分钟。 所有出席者都应站立（有助于保持会议简短）

25、。 会议应在固定地点和每天的同一时间举行。在会议上，每个团队成员需要回答三个问题： 今天你完成了那些工作？ 明天你打算做什么？ 完成你的目标是否存在什么障碍？（Scrum主管需要记下这些障碍）冲刺复审会议：一般4个小时，由团队成员向产品负责人向其他利益相关人展示Sprint周期内的产品开发情况，并决定下一次Sprint的内容。冲刺回顾会议（Retrospective Meeting）：每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在4小时。如图3.所示表示Scrum方法中的主要活动和交付件。图3. Scr

26、um方法中的主要活动和交付件3.2.4 Scrum方法中包含的主要输入输出工件产品订单：产品订单（Product Backlog）是整个项目的概要文档，它包含已划分优先等级的、项目要开发的系统或产品的需求清单，包括功能和非功能性需求及其他假设和约束条件。产品负责人和团队主要按业务和依赖性的重要程度划分优先等级，并作出预估。预估值的精确度取决于产品订单中条目的优先级和细致程度，入选下一个冲刺的最高优先等级条目的预估会非常精确。产品的需求清单是动态的，随着产品及其使用环境的变化而变化，并且只要产品存在，它就随之存在。而且，在整个产品生命周期中，管理层不断确定产品需求或对之做出改变，以保证产品适用性

27、、实用性和竞争性。.冲刺订单：冲刺订单（Sprint Backlog）是大大细化了的文档，用来界定工作或任务，定义团队在Sprint中的任务清单，这些任务会将当前冲刺选定的产品订单转化为完整的产品功能增量。冲刺订单在冲刺规划会议中形成，其包含的不会被分派，而是由团队成员签名认领他们喜爱的任务。任务被分解为以小时为单位，没有任务可以超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。每项任务信息将包括其负责人及其在冲刺中任一天时的剩余工作量，且仅团队有权改变其内容。燃尽图：燃尽图（Burndown Chart）是一个公开展示的图表，纵轴代表剩余工作量，横轴代表时间，显示当前冲刺

28、中随时间变化而变化的剩余工作量（可以是未完成的任务数目，或在冲刺订单上未完成的订单项的数目）。剩余工作量趋势线与横轴之间的交集表示在那个时间点最可能的工作完成量。我们可以借助它设想在增加或减少发布功能后项目的情况，我们可能缩短开发时间，或延长开发期限以获得更多功能。它可以展示项目实际进度与计划之间的矛盾。新的功能增量：Scrum团队在每个冲刺周期内完成的、可交付的产品功能增量。3.2.5 Scrum方法的工作流程说明在Scrum项目管理过程中，一般产品负责人获取项目投资，并对整个产品的成功负责。他会协调各种利益干系人，确定产品订单中初始的需求清单及其优先级，完成项目的商业价值分析和项目整体规划

29、，并任命合适的Scrum主管开展项目工作。如图3.7所示表示Scrum方法的全景图。图3. Scrum方法全景图在Scrum软件开发项目中，每个冲刺就是一个为期30天的迭代。在每个冲刺开始时，产品负责人和Scrum主管通过召开冲刺规划会议和“两层项目规划”的最佳实践，制定冲刺订单（类似于迭代计划），明确将在本次冲刺中实现的需求清单，相应的工作任务和负责人。在每个冲刺迭代中，团队强调应用“整体团队协作”的最佳实践，通过保持可持续发展的工作节奏和每日站立会议，实现团队的自组织、自适应和自管理，高效完成冲刺工作。在每个冲刺结束时，团队都会召开冲刺复审会议，团队成员会在会上分别展示他们开发出的软件（或

30、其他有价值的产品），并从产品负责人和其他利益干系人那里，得到反馈信息。在冲刺复审会议之后，团队会自觉召开冲刺回顾会议，回顾整个项目过程，讨论那些方面做得好，哪些方面可以改进，实现软件交付过程的持续、自发的改进。3.3 敏捷开发方法之Lean软件开发基于Toyota Lean生产概念 减少浪费无用的功能20%的功能往往能够提供80%的价值，你需要的是这样的一个流程。变来变去如果出现需求变来变去的情况，那么是你太早的文档化需求；如果出现专门的测试和修复的阶段，那么是你测试得太晚。跨越边界组织边界通常会增加超过25%的成本，是降低响应时间和妨碍沟通的隔离带减少浪费的方法延迟决策抛弃那种认为只有具备完

31、整的规约之后才能开发的想法。消除依赖系统架构应该允许在任何时间增添任何功能。保持可能把代码当成验证的机会 同时使代码易于变更。在最后一刻才做出决策做决策之前尽可能多的了解信息。3.3.1 Lean软件开发的原则消除浪费价值流图 完整的解决方案构建质量基础规程 持续验证延迟决策保持可能快速交付排队理论关注学习产品&流程尊重个人团队 伙伴优化整体系统思考 Set-based design3.4 敏捷开发方法之极限编程 (XP)3.4.1 XP (eXtreme Programming)3.4.2 极限编程核心实践*Small Releases*Refactoring*Testing / Test-

32、driven Development*Pair Programming*Sustainable Pace / 40-hour Week*Team Code Ownership*Coding Standards/Conventions*Simple Design*Metaphor (e.g., chalkboard app)*Planning Game*Continuous Integration / Build*On-site CustomerStory Cards Summarize RequirementsPrototype UIs and UI navigationStand-Up Me

33、etingsWorkspace EnvironmentIteration CompletenessArchitectural Spike3.5 敏捷开发方法之OpenUP* OpenUP 是一个精益的统一过程，它在结构化的生命周期中采用迭代和增加的方法。OpenUP 强调注重实效的、敏捷哲学，将关注重点放在软件开发的协作本性上面。它是一种不约束工具和拘泥于仪式的开发过程，可以被扩展到非常广泛的项目类型之中。* OpenUP 将项目划分为迭代：有计划的、有时限的迭代操作，通常以周为单位。迭代使团队注重以一种可预见的方式向涉众发送增长式的价值。迭代计划定义了在迭代期间应当完成哪些工作，其结果是一个

34、可以演示的构造。OpenUP 团队将自组织如何实现迭代目标以及提交结果。团队定义和“牵引”工作条目列表 中的任务。OpenuP 采用迭代生命周期（组织微增量是如何被应用的）来得到一个稳定的、复合系统需要的构造，从而逐步的向迭代的目标前进。*OpenUP 将项目生命周期分为四个阶段：启始、精化、构建和产品化。项目生命周期为涉众和团队成员提供可见度和决策点。这将更有效的进行管理，并且允许您在适当的时间做出是否继续的决定。项目计划定义了生命周期，我们得到的最终结果是一个发布的应用程序。3.5.1 IBM Rational 统一软件过程(RUP)* 是基于软件开发最佳实践构建的软件开发框架* 是基于W

35、eb的，包含模板、指南、工具向导及在线帮助等的可裁剪的知识库* 推荐迭代增量式的开发* 在RUP方法论中：需求使用用例来表达以架构为中心项目管理是面向风险的关注基于技术风险进行需求俳优、现在强调商业优先级* OpenUP和AgileUP都是敏捷的实例4 主要的敏捷开发工程实践4.1 敏捷开发工程实践描述模板4.1.1 最佳实践定义和特性说明4.1.2 如何应用最佳实践说明4.1.3 案例说明4.2 迭代式开发迭代开发，也称迭代式开发，在软件开发领域，指每次按照相同的开发方式开发软件的部分，或前期开发并不详尽的软件，经过反复多次开发，逐步增加软件部分，逐步补充完善软件，最终达到最后的软件。其中每

36、次反复开发叫做一次迭代。 需要说明的是，狭义的迭代开发和狭义的增量开发是不同的。狭义的迭代开发中，每次迭代处理的范围是不变的，这与数学中的迭代算法相同；狭义的增量开发中，每次开发是增量地扩大范围。在目前的大量软件开发实践中，软件的规模都比较大，不可能一次迭代的范围就能覆盖软件全部，多数迭代处理的范围是需要增加的，而在业界书面材料上，有“迭代增量式开发、“迭代化增量开发”，“迭代式增量开发”等的提法。在敏捷开发领域，为简便计，采用“敏捷迭代开发”的提法。因此在敏捷迭代开发中，每次迭代处理的范围是可以增加的，也可以保持不变，甚至可以缩减范围。 在敏捷软件开发中，敏捷迭代开发需满足3个条件：1，迭代

37、的时间长度，也称为迭代周期，是有短迭代周期的要求的，一般的，敏捷迭代周期不超过8周，推荐的迭代周期是2周到4周。2，迭代的产物是可运行的软件。3，获得迭代的反馈，并处理反馈，反馈作为迭代开发中至关重要的一个方面，必须得到足够的重视。归纳以上，敏捷迭代开发是指每次按照相同的开发方式短期的开发软件的部分，或前期开发并不详尽的软件，每次开发结束获得可以运行的软件，以供各方干系人观测，获得反馈，根据反馈适应性的进行后续开发，经过反复多次开发，逐步增加软件部分，逐步补充完善软件，最终开发得到最后的软件。迭代开发的优点：1、降低风险，在进行大规模的投资之前就可以进行关键的风险分析2、得到早期用户反馈，各次

38、迭代为各方干系人提供了一个机会以对进行中又可运行的软件进行评论、反馈，同时能够对未来的开发趋势产生影响。每次迭代都能回顾了一个能够表明各方需求决定以及开发团队对这些需求理解的软件版本，可以决定如何修改项目方向或是划分剩余需求的优先次序。3、对过程的测量是通过对实现的评定（而不仅仅是文档）来进行的，更加直观，更加体现用户价值。4、能够自然的处理变更，快速的适应新情况。快速的开发周期，可以通过后续的迭代来纠正前期迭代的误解、失误，在迭代之间自然的、平滑的处理变更。5、可以对局部的实现进行部署，建立团队交付能力的信心。 关于敏捷迭代开发的几个问题：1，迭代的时间长度是否每个迭代都可以调整？敏捷开发的

39、迭代周期选择和项目类型、复杂度、敏捷规模化程度有关，敏捷开发讲究固定的节奏，建议按照固定的节奏开发，因此某个迭代碰到特殊情况，尽量保证迭代时间窗不变，在不得以的情况下可以调整迭代周期长度。2，敏捷开发时，上个迭代结束后是否可以安排一段缓冲期后，再开展下个迭代吗？敏捷开发讲究固定的节奏，强烈不建议安排缓冲期，相关任务可以安排在下个迭代中。3，是否可以将原瀑布生命周期的阶段作为迭代？比如将需求分析阶段改称为需求迭代，迭代的目标产物就是需求规格说明书。这种做法不符合敏捷开发方法。敏捷迭代的目标产物应当是可运行的，不能仅仅出文档。4.3 持续集成英文是Continuous integration持续集

40、成是指当代码提交后，马上启动自动编译、自动部署和自动化测试来快速验证软件，从而尽快地发现集成错误。持续集成要素：统一的代码库自动编译自动部署自动测试每次代码递交后都会在持续集成服务器上触发一次集成保证快速集成，集成总时间长度不超过开发人员的一个休息间隙。 持续集成原则：1. 所有的开发人员需要在本地机器上做本地编译，然后再提交的版本控制库中。2. 需要有专门的集成服务器来执行集成,每天可以执行多次集成。3. 每次集成争取都要100%通过，如果集成失败，马上修复，修复失败的集成是优先级最高的事情。4. 每次成功的集成都可以生成可运行的软件。4.4 多级项目规划： 多级项目规划定义：多级项目/产品

41、规划，在软件开发领域，是指以迭代开发为基础，形成多层次的、逐步细化的项目或产品计划。这些层层相关的项目/产品规划包括：项目/产品愿景、项目/产品路线图、版本发布计划、迭代计划、每日实现（Daily Scrums）。 角色、产出物和其他说明： 1、项目/产品愿景：项目Stakeholder、项目/产品负责人将参与并组成工作组，他们负责阐述项目的重要性、给出项目成功失败的关键标准以及项目整体层面“完成”的定义。形成项目愿景的一些工具，包括愿景盒子（Vision Box）、业务收益矩阵（Business Benifits Matrix）、项目范围矩阵（Scope Matrix）、滑动器（Slider

42、）、成本收益矩阵（Cost/Benefit Matrix）等。最后，项目愿景需要使用尽量简要的文档固定下来，并保证项目团队成员都能了解。该文档需要包括：问题、机会描述和理由（描述项目的重要性）；项目的价值；项目如何和组织的战略目标达成一致；解决方案综述；项目包含的关键功能；项目必须服从的技术和约束条件；项目范围；项目的关键时间线；项目收益分析；项目和其他项目的依赖性；项目的相关风险以及如何消除。 2、项目路线图：项目/产品路线图主要描述为了达到产品愿景而需要交付的关键功能和特性，这些特性基本处于Epic和特性层面，不包括User Story。它从时间的维度来表述对愿景的支持和实现。当项目/产品

43、需要发布多个版本时，项目路线图就非常重要，否则，它和发布计划相同。项目/产品路线图由项目负责人和项目经理维护，并保持变化。通常，会形成路线图文档或幻灯片，使用大图标显示重要的里程碑、包含的功能和发布日期等，让所有项目/产品相关人员都清楚产品各个组件的可能发布日程。 3、版本发布计划：版本发布计划由团队成员和项目/产品负责人共同制定，并通过版本发布计划会议讨论通过。它包括了当前版本需要交付的、达成一致的关键功能，并经过优先级排序，可以包含Epic和User Story。支持版本发布计划的一些概念为故事点、迭代、团队速率和优先级排序。通常，项目/产品负责人提出本次版本发布的目标，团队成员根据目标和

44、功能特性的重要性对故事进行排序，并依据团队速率决定本次发布需要包含的故事点。前几次版本发布使用估算值，其准确度随着项目/产品的时间持续而逐步精确。版本发布计划是具备适应性且可调整的计划，会随着项目演进而改变。 4、迭代计划：迭代计划是对版本发布计划的再次细化，同样由团队成员和项目/产品负责人共同制定，并通过迭代计划会议讨论通过。迭代会议负责2件事情：根据当前状态确定是否需要对版本计划作出更新；为当前的迭代制定迭代计划。支持迭代计划的一些概念为拆分Epic和User Story、任务、任务估算。在迭代会议上，成员首先根据当前的项目变化对发布计划进行更新，然后根据更新后的、重新排序过的故事制定当前

45、迭代需要完成的故事，并对这些故事进行详细的任务拆分。成员在认领完任务后，会对任务的实现时间做出估算，估算值需要具体到这些估算信息可以方便任何成员追踪任务的进度。 5、每日实现：每日实现是团队成员完成任务的具体过程，它依据任务估算值并根据任务最终实现情况更新该值。在敏捷方法中，使用每日站立会议来报告进度，通过15分钟的站立形式，团队成员报告故事或者任务的完成、未完成状态，而解决层面的问题则在会议之后处理。 注：完整的多级项目规划包含如上5个层面，仅包含版本发布计划、迭代计划有时也被称为2级项目规划。4.5 完整团队-闫建伟敏捷开发最佳实践-完整团队最近几年，以SCRUM为代表的敏捷开发思想在软件

46、开发界悄然兴起，大量的实践表明，敏捷开发大大的提高了软件的开发效率和软件质量，帮助软件企业提高了效益的同时也降低了成本。据调查，在欧美的软件企业已经有近半数的企业开始使用软件开发，在国内的多家公司也悄然兴起。如果您的开发团队还在面临需求时时多变、开发周期过长、软件质量低下等难以解决的问题，那么从传统意义的开发团队向敏捷开发团队转型已是事在必行。现在比较符合敏捷开发思想的开发模式有XP极限编程、RUP、Lean和Scrum，其中最流行的当属Scrum开发方法。下面笔者将结合自己亲自参与多个Scrum开发模式团队的经验，谈一谈如何构建一只符合Scrum开发思想的完整团队。首先对比一下Scrum团队

47、与传统开发团队的区别。1、 Scrum团队中不再有传统意义上的产品经理、项目经理、开发经理，而是引入了Product Owner、Scrum Master和Scrum团队等新角色，团队中通常会包含多个职责的成员，比如由需求设计、开发和测试人员共同组成的团队。2、 传统开发团队通常是项目经理下达工作内容，而Scrum团队提倡自我管理，按照兴趣和能力挑选任务。3、 从前的开发团队通常是接到任务后分头工作、独立完成，而现在Scrum团队需要相互配合工作，相互协作完成任务。4、 传统开发过程中，通常是经历一个大时间段的开发过程才完成一次产品发布，而Scrum开发过程中，产品是迭代增量发布的，通常是在每个Sprint结束时交付可发布软件。下面我来介绍一下Scrum团队