敏捷开发知识体系样本

SUBJECTTITLE敏捷开发知识体系总体框架修订历史记录日期版本阐明作者1.0草稿

敏捷开发知识体系整体框架敏捷开发知识体系核心敏捷开发是一种灵活开发办法，用于在一种动态环境中向干系人迅速交付价值。其重要特点是关注持续交付价值，通过迭代和迅速顾客反馈管理不拟定性和拥抱变更；它承认个人才是价值最后源泉，强调通过有效个人勉励，提高团队工作绩效。敏捷开发知识体系核心是敏捷宣言，它们是敏捷开发思想和价值观集中体现。敏捷软件开发宣言详细内容如下：咱们始终在实践中探寻更好软件开发办法，身体力行同步也协助她人。由此咱们建立了如下价值观：个体和互动高于流程和工具工作软件高于详尽文档客户合伙高于合同谈判响应变化高于遵循筹划也就是说，尽管右项有其价值，咱们更注重左项价值。对的理解敏捷宣言是成功开展敏捷开发核心，它告诉咱们敏捷是一种相对词汇，详细敏捷限度取决去项目团队上下文，例如复杂项目由于其团队规模、技术特点和循规规定等，规定团队有更严格治理流程和工具支持、更规范文档和筹划规定。但依然可以借助敏捷价值观和各种实践解决开发过程中遇到问题。在详细敏捷开发实践中，咱们必要实事求是地采用适当敏捷实践，以实用主义为指引思想，面向业务成果和价值，切不可为了敏捷而敏捷。环绕着敏捷宣言，敏捷开发办法领导者定义了用于指引团队开展敏捷开发实践必要遵循12条基本原则，它们是敏捷开发实践总体指南。敏捷宣言遵循12条原则如下：咱们最重要目的，是通过持续不断地及早交付有价值软件使客户满意。欣然面对需求变化，虽然在开发后期也同样。为了客户竞争优势，敏捷过程掌控变化。经常地交付可工作软件，相隔几星期或一两个月，倾向于采用较短周期。业务人员和开发人员必要互相合伙，项目中每一天都不例外。激发个体斗志，以她们为核心搭建项目。提供所需环境和增援，辅以信任，从而达到目的。无论团队内外，传递信息效果最佳效率也最高方式是面对面交谈。可工作软件是进度首要度量原则。敏捷过程倡导可持续开发。负责人、开发人员和顾客要可以共同维持其步调稳定延续。坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。以简洁为本，它是极力减少不必要工作量艺术。最佳架构、需求和设计出自自组织团队。团队定期地反思如何能提高成效，并依此调节自身举止体现。注：以上敏捷宣言遵循原则摘自敏捷宣言简体中文版官方网站敏捷开发管理实践随着敏捷开发运动开展，如图所示，敏捷践行者逐渐发展出两类敏捷开发最佳实践：敏捷开发管理实践和敏捷开发工程实践。敏捷开发管理实践泛指用于指引敏捷团队进行敏捷开发实践开发办法和流程，业界应用最广敏捷开发管理实践涉及：（详细实践列表将依照团队工作成果，恰当变化，并包括简朴描述。）Scrum：极限编程（XP）：OpenUP：精益开发（Lean）：动态系统开发(DSDM)：特性驱动开发：敏捷开发工程实践敏捷开发工程实践泛指用于指引敏捷团队进行敏捷开发过程中各种工程化最佳实践，业界应用最广敏捷开发工程实践涉及：（详细实践列表将依照团队工作成果，恰当变化，并包括简朴描述。）项目管理：迭代开发风险价值生命周期多级项目规划完整团队每日站立会议任务板燃尽图需求管理：需求订单业务流程草图用例驱动开发顾客故事架构：演进架构演进设计基于组件架构设计开发：结对编程测试驱动开发重构代码规范测试：单元测试并行测试测试管理变更管理：持续集成自动构建团队变更管理在敏捷开发知识体系其他章节，将详细描述每种敏捷开发管理实践和工程实践，为了以便阅读，咱们将采用统一方式描述其中详细内容。其中，敏捷开发管理实践描述重要涉及如下重要某些：办法定义和特性阐明办法中包括重要角色办法中包括重要活动和最佳实践办法中包括重要输入输出工件办法工作流程阐明而敏捷开发工程实践描述将重要涉及如下重要某些：最佳实践定义和特性阐明如何应用最佳实践阐明案例阐明敏捷开发核心价值观和原则敏捷软件开发宣言2月，17位在当时被称之为“轻量级办法学家”软件开发领域领军人物汇集在美国犹她州滑雪胜地雪鸟（Snowbird）雪场。通过两天讨论，“敏捷”（Agile）这个词为全体约会者所接受，用以概括一套全新软件开发价值观。这套价值观，通过一份简要扼要《敏捷宣言》，传递给世界，宣布了敏捷开发运动开始。敏捷软件开发宣言咱们始终在实践中探寻更好软件开发办法，身体力行同步也协助她人。由此咱们建立了如下价值观：个体和互动

高于流程和工具

工作软件

高于详尽文档

客户合伙

高于合同谈判

响应变化

高于遵循筹划也就是说，尽管右项有其价值，咱们更注重左项价值。注：以上敏捷软件开发宣言摘自敏捷宣言简体中文版官方网站敏捷开发核心价值观敏者，疾也。对外来刺激做出迅速、机灵反映；捷者，獵也。以最短途径去追赶和实现目的。敏捷开发核心理念就是以最简朴有效方式迅速达到目的，并在这个过程中及时地响应外界变化，做出迅速调节。敏捷开发第一条价值观就是“以人为本”，强调“个体（人）”及“个体”间沟通与协作在软件开发过程中重要性。这个顺序不是偶尔而为之，敏捷开发将注重个体潜能激发和团队高效协作作为其所推崇第一价值观。敏捷开发第二条价值观就是“目的导向”。同其她众多管理理论和模型同样，敏捷开发认同目的导向是成功核心，由于没有目的也就无所谓成功。敏捷开发价值观中清晰地阐明，软件开发目的是“可工作软件”，而不是面面俱到文档。而遗憾是，诸多软件项目已经在纷繁文档之中迷失了自己目的。敏捷开发第三条价值观就是“客户为先”。虽然敏捷开发强调第一价值观是“以人为本”，但敏捷宣言缔造者们并没有忘掉客户，相反她们真正理解客户需求、懂得如何与客户合伙。敏捷价值观里强调“客户为先”即不是简朴把客户当作“上帝”、简朴推崇“客户至上”，客户规定什么、咱们就做什么；也不是把客户当作“谈判桌上对手”甚至“敌人”，去斗智斗勇。敏捷价值观里中把客户当成了合伙者和伙伴，把自己使命定位为“协助客户获得竞争优势”。敏捷开发第四条价值观就是“拥抱变化”。人们常说“世界上唯一不变就是变化”，大多数人也相信事实的确如此。而以往诸多软件项目却忽视了这一点，或者更精确说是它们不乐意“正视”。它们总是试图用详尽筹划与预先穷举这些变化，然后又试图通过严格遵循筹划来控制变化发生，而成果往往是被不断涌现变化击垮。敏捷开发价值观中承认变化是软件开发一某些、并相信正是客户在不断变化其需求过程中明晰了其真正需要。因而敏捷开发欢迎变化、拥抱变化，并可坦然应对变化，正是这些变化为客户和项目带来了价值。最后，咱们还应记住敏捷宣言中最后一条：“尽管右项有其价值，咱们更注重左项价值”——敏捷宣言并未否定或贬损“右项”价值，在敏捷开发价值观中承认“流程和工具”、“详尽文档”、“合同谈判”以及“遵循筹划”重要性，只是两相比较，“更注重左项价值”。

敏捷开发原则

敏捷开发原则敏捷宣言遵循原则l

咱们最重要目的，是通过持续不断地及早交付有价值软件使客户满意。l

欣然面对需求变化，虽然在开发后期也同样。为了客户竞争优势，敏捷过程掌控变化。l

经常地交付可工作软件，相隔几星期或一两个月，倾向于采用较短周期。l

业务人员和开发人员必要互相合伙，项目中每一天都不例外。l

激发个体斗志，以她们为核心搭建项目。提供所需环境和增援，辅以信任，从而达到目的。l

无论团队内外，传递信息效果最佳效率也最高方式是面对面交谈。l

可工作软件是进度首要度量原则。l

敏捷过程倡导可持续开发。负责人、开发人员和顾客要可以共同维持其步调稳定延续。l

坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。l

以简洁为本，它是极力减少不必要工作量艺术。l

最佳架构、需求和设计出自自组织团队。l

团队定期地反思如何能提高成效，并依此调节自身举止体现。注：以上敏捷宣言遵循原则摘自敏捷宣言简体中文版官方网站

敏捷开发原则应用敏捷开发原则是对敏捷价值观解释和实践，它将敏捷价值观贯彻到详细可操作原则之上，严格遵循这十二条原则，是敏捷软件开发项目得以成功基石。可以说这十二条原则已经囊括了软件项目管理基本流程，并且这些流程足够详细：它告诉咱们项目管理第一步就是要明确目的，而软件项目终极目的就是“不断地及早交付有价值软件使客户满意”；它提示咱们软件工程起始点是需求，而需求固有特性就是不断变化，敏捷开发过程要“掌控变化”；它强调“可工作软件是进度首要度量原则”，因而需要以尽量短周期“经常地交付可工作软件”；它注重有关干系人协调（“业务人员和开发人员必要互相合伙”、“负责人、开发人员和顾客要可以共同维持其步调稳定延续”），注重激发个人潜能（“激发个体斗志”），规定团队使用最高效沟通方式（“面对面交谈”）；它推崇技术变革所具备强大能量（“坚持不懈地追求技术卓越和良好设计”）；它强调精益生产（简洁为本），规定项目采用“自组织”团队管理模式，并指出“定期总结反思”，是校准团队行为、最后达到目的有效途径。成熟敏捷开发团队，完全可以不再需要任何附加冗余流程（工程技术流程除外），而成功完毕软件开发和交付。固然，敏捷开发团队也可以以这十二条原则为基本，进一步细化敏捷项目管理流程、环节、和办法工具，以便这些原则可以更好被团队理解和执行。对以上所有原则严格遵守将大大提高敏捷项目成功也许性。重要敏捷开发管理实践敏捷开发管理实践描述模板办法定义和特性阐明办法中包括重要角色办法中包括重要活动和最佳实践办法中包括重要输入输出工件办法工作流程阐明敏捷开发办法之ScrumScrum办法定义和特性阐明术语Scrum来源于橄榄球活动，在英文中意思是橄榄球里争球。在橄榄球比赛中，双方前锋站在一起紧密相连，当球在她们之间投掷时，她们奋力求球。1995年，在奥斯汀举办OOPSLA'95上，萨瑟兰和施瓦伯初次提出了Scrum概念，并在随后几年中逐渐将其与业界最佳实践融合起来，形成一种迭代式增量软件开发过程和敏捷项目管理办法，并在敏捷联盟（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.AUTONUM\*ArabicScrum办法中重要角色Scrum办法中包括重要活动和最佳实践Scrum作为软件开发过程框架，它包括重要最佳实践涉及如下几种方面。迭代式软件开发：通过将整个软件交付过程提成各种迭代周期，协助团队更好地应对变更，应对风险，实现增量交付、迅速反馈。两层项目规划（Two-LevelProjectPlanning）：基于远粗近细原则和项目渐进明细特点，通过将概要项目整体规划和详细近期迭代筹划有机结合，协助团队有效提高筹划精确度、资源管理能力和项目准时交付能力。整体团队协作（WholeTeam）：通过关注保持整个团队可持续发展工作节奏、每日站立会议和自组织工作分派，实现团队高效协作和工作，实现提高整个团队生产力目。持续集成：通过进行更频繁软件集成，实现更早发现和反馈错误、减少风险，并使整个软件交付过程变得更加可预测和可控，以交付更高质量软件。Scrum活动重要由冲刺规划会议（SprintPlanMeeting）、每日站立会议（SprintDailyMeeting）、冲刺复审会议（SprintReviewMeeting）和冲刺回顾会议（RetrospectiveMeeting）构成。Scrum倡导所有团队成员坐在一起工作，进行口头交流，以及强调项目关于规范（Disciplines），这些有助于创造自我组织团队。冲刺规划会议：冲刺开始时，均需召开冲刺规划会议，产品负责人和团队共同探讨该冲刺工作内容。产品负责人从最优先待开发事项中进行筛选，告知团队其预期目的；团队则提出在接下来冲刺内，评估预期目的可实现限度。冲刺规划会议普通不超过8小时。在前4个小时中，产品负责人向团队展示最高优先级产品，团队则向她询问产品订单内容、目、含义及意图。而在后4小时，团队则筹划本冲刺详细安排。每日站立会议：在冲刺中，每一天都会举办项目状况会议，被称为Scrum或“每日站立会议”。每日站立会议有某些详细指引原则：会议准时开始。对于迟到者团队经常会制定惩罚办法（例如罚款、做俯卧撑、在脖子上挂橡胶鸡玩具等）。欢迎所有人参加，但只有“猪”类人员可以发言。无论团队规模大小，会议被限制在15分钟。所有出席者都应站立（有助于保持会议简短）。会议应在固定地点和每天同一时间举办。在会议上，每个团队成员需要回答三个问题：今天你完毕了那些工作？明天你打算做什么？完毕你目的与否存在什么障碍？（Scrum主管需要记下这些障碍）冲刺复审会议：普通4个小时，由团队成员向产品负责人向其她利益有关人展示Sprint周期内产品开发状况，并决定下一次Sprint内容。冲刺回顾会议（RetrospectiveMeeting）：每一种冲刺完毕后，都会举办一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。举办冲刺回顾会议是为了进行持续过程改进。会议时间限制在4小时。如图3.AUTONUM\*Arabic所示表达Scrum办法中重要活动和交付件。图3.AUTONUM\*ArabicScrum办法中重要活动和交付件Scrum办法中包括重要输入输出工件产品订单：产品订单（ProductBacklog）是整个项目概要文档，它包括已划分优先级别、项目要开发系统或产品需求清单，涉及功能和非功能性需求及其她假设和约束条件。产品负责人和团队重要按业务和依赖性重要限度划分优先级别，并作出预估。预估值精准度取决于产品订单中条目优先级和细致限度，入选下一种冲刺最高优先级别条目预估会非常精准。产品需求清单是动态，随着产品及其使用环境变化而变化，并且只要产品存在，它就随之存在。并且，在整个产品生命周期中，管理层不断拟定产品需求或对之做出变化，以保证产品合用性、实用性和竞争性。.冲刺订单：冲刺订单（SprintBacklog）是大大细化了文档，用来界定工作或任务，定义团队在Sprint中任务清单，这些任务会将当前冲刺选定产品订单转化为完整产品功能增量。冲刺订单在冲刺规划会议中形成，其包括不会被分派，而是由团队成员签名认领她们爱慕任务。任务被分解为以小时为单位，没有任务可以超过16个小时。如果一种任务超过16个小时，那么它就应当被进一步分解。每项任务信息将涉及其负责人及其在冲刺中任一天时剩余工作量，且仅团队有权变化其内容。燃尽图：燃尽图（BurndownChart）是一种公开展示图表，纵轴代表剩余工作量，横轴代表时间，显示当前冲刺中随时间变化而变化剩余工作量（可以是未完毕任务数目，或在冲刺订单上未完毕订单项数目）。剩余工作量趋势线与横轴之间交集表达在那个时间点最也许工作完毕量。咱们可以借助它设想在增长或减少发布功能后项目状况，咱们也许缩短开发时间，或延长开发期限以获得更多功能。它可以展示项目实际进度与筹划之间矛盾。新功能增量：Scrum团队在每个冲刺周期内完毕、可交付产品功能增量。Scrum办法工作流程阐明在Scrum项目管理过程中，普通产品负责人获取项目投资，并对整个产品成功负责。她会协调各种利益干系人，拟定产品订单中初始需求清单及其优先级，完毕项目商业价值分析和项目整体规划，并任命适当Scrum主管开展项目工作。如图3.7所示表达Scrum办法全景图。图3.AUTONUM\*ArabicScrum办法全景图在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-UpMeetings

WorkspaceEnvironment

IterationCompleteness

ArchitecturalSpike

敏捷开发办法之OpenUP*OpenUP是一种精益统一过程，它在构造化生命周期中采用迭代和增长办法。OpenUP强调注重实效、敏捷哲学，将关注重点放在软件开发协作本性上面。它是一种不约束工具和拘泥于典礼开发过程，可以被扩展到非常广泛项目类型之中。

*OpenUP将项目划分为迭代：有筹划、有时限迭代操作，普通以周为单位。迭代使团队注重以一种可预见方式向涉众发送增长式价值。迭代筹划定义了在迭代期间应当完毕哪些工作，其成果是一种可以演示构造。OpenUP团队将自组织如何实现迭代目的以及提交成果。团队定义和“牵引”工作条目列表中任务。OpenuP采用迭代生命周期（组织微增量是如何被应用）来得到一种稳定、复合系统需要构造，从而逐渐向迭代目的迈进。

*

OpenUP将项目生命周期分为四个阶段：启始、精化、构建和产品化。项目生命周期为涉众和团队成员提供可见度和决策点。这将更有效进行管理，并且容许您在恰当时间做出与否继续决定。项目筹划定义了生命周期，咱们得到最后成果是一种发布应用程序。IBM®Rational®统一软件过程(RUP)*是基于软件开发最佳实践构建软件开发框架

*是基于Web，包括模板、指南、工具向导及在线协助等可裁剪知识库

*推荐迭代增量式开发

*在RUP办法论中：

需求使用用例来表达

以架构为中心

项目管理是面向风险

关注基于技术风险进行需求俳优、当前强调商业优先级

*OpenUP和AgileUP都是敏捷实例

重要敏捷开发工程实践敏捷开发工程实践描述模板最佳实践定义和特性阐明如何应用最佳实践阐明案例阐明迭代式开发迭代开发，也称迭代式开发，在软件开发领域，指每次按照相似开发方式开发软件某些，或前期开发并不详尽软件，通过重复多次开发，逐渐增长软件某些，逐渐补充完善软件，最后达到最后软件。其中每次重复开发叫做一次迭代。需要阐明是，狭义迭代开发和狭义增量开发是不同。狭义迭代开发中，每次迭代解决范畴是不变，这与数学中迭代算法相似；狭义增量开发中，每次开发是增量地扩大范畴。在当前大量软件开发实践中，软件规模都比较大，不也许一次迭代范畴就能覆盖软件所有，多数迭代解决范畴是需要增长，而在业界书面材料上，有“迭代增量式开发"、“迭代化增量开发”，“迭代式增量开发”等提法。在敏捷开发领域，为简便计，采用“敏捷迭代开发”提法。因而在敏捷迭代开发中，每次迭代解决范畴是可以增长，也可以保持不变，甚至可以缩减范畴。在敏捷软件开发中，敏捷迭代开发需满足3个条件：1，迭代时间长度，也称为迭代周期，是有短迭代周期规定，普通，敏捷迭代周期不超过8周，推荐迭代周期是2周到4周。2，迭代产物是可运营软件。3，获得迭代反馈，并解决反馈，反馈作为迭代开发中至关重要一种方面，必要得到足够注重。归纳以上，敏捷迭代开发是指每次按照相似开发方式短期开发软件某些，或前期开发并不详尽软件，每次开发结束获得可以运营软件，以供各方干系人观测，获得反馈，依照反馈适应性进行后续开发，通过重复多次开发，逐渐增长软件某些，逐渐补充完善软件，最后开发得到最后软件。迭代开发长处：1、减少风险，在进行大规模投资之前就可以进行核心风险分析2、得到初期顾客反馈，各次迭代为各方干系人提供了一种机会以对进行中又可运营软件进行评论、反馈，同步可以对将来开发趋势产生影响。每次迭代都能回顾了一种可以表白各方需求决定以及开发团队对这些需求理解软件版本，可以决定如何修改项目方向或是划分剩余需求优先顺序。3、对过程测量是通过对实现评估（而不但仅是文档）来进行，更加直观，更加体现顾客价值。4、可以自然解决变更，迅速适应新状况。迅速开发周期，可以通过后续迭代来纠正前期迭代误解、失误，在迭代之间自然、平滑解决变更。5、可以对局部实现进行布置，建立团队交付能力信心。关于敏捷迭代开发几种问题：1，迭代时间长度与否每个迭代都可以调节？敏捷开发迭代周期选取和项目类型、复杂度、敏捷规模化限度关于，敏捷开发讲究固定节奏，建议按照固定节奏开发，因而某个迭代遇到特殊状况，尽量保证迭代时间窗不变，在不得以状况下可以调节迭代周期长度。2，敏捷开发时，上个迭代结束后与否可以安排一段缓冲期后，再开展下个迭代吗？敏捷开发讲究固定节奏，强烈不建议安排缓冲期，有关任务可以安排在下个迭代中。3，与否可以将原瀑布生命周期阶段作为迭代？例如将需求分析阶段改称为需求迭代，迭代目的产物就是需求规格阐明书。这种做法不符合敏捷开发办法。敏捷迭代目的产物应当是可运营，不能仅仅出文档。持续集成英文是Continuousintegration持续集成是指当代码提交后，立即启动自动编译、自动布置和自动化测试来迅速验证软件，从而尽快地发现集成错误。持续集成要素：统一代码库自动编译自动布置自动测试每次代码递交后都会在持续集成服务器上触发一次集成保证迅速集成，集成总时间长度不超过开发人员一种休息间隙。持续集成原则：1.所有开发人员需要在本地机器上做本地编译，然后再提交版本控制库中。2.需要有专门集成服务器来执行集成,每天可以执行多次集成。3.每次集成争取都要100%通过，如果集成失败，立即修复，修复失败集成是优先级最高事情。4.每次成功集成都可以生成可运营软件。多级项目规划：多级项目规划定义：多级项目/产品规划，在软件开发领域，是指以迭代开发为基本，形成多层次、逐渐细化项目或产品筹划。这些层层有关项目/产品规划涉及：项目/产品愿景、项目/产品路线图、版本发布筹划、迭代筹划、每日实现（DailyScrums）。角色、产出物和其她阐明：1、项目/产品愿景：项目Stakeholder、项目/产品负责人将参加并构成工作组，她们负责阐述项目重要性、给出项目成功失败核心原则以及项目整体层面“完毕”定义。形成项目愿景某些工具，涉及愿景盒子（VisionBox）、业务收益矩阵（BusinessBenifitsMatrix）、项目范畴矩阵（ScopeMatrix）、滑动器（Slider）、成本收益矩阵（Cost/BenefitMatrix）等。最后，项目愿景需要使用尽量简要文档固定下来，并保证项目团队成员都能理解。该文档需要涉及：问题、机会描述和理由（描述项目重要性）；项目价值；项目如何和组织战略目的达到一致；解决方案综述；项目包括核心功能；项目必要服从技术和约束条件；项目范畴；项目核心时间线；项目收益分析；项目和其她项目依赖性；项目有关风险以及如何消除。2、项目路线图：项目/产品路线图重要描述为了达到产品愿景而需要交付核心功能和特性，这些特性基本处在Epic和特性层面，不涉及UserStory。它从时间维度来表述对愿景支持和实现。当项目/产品需要发布各种版本时，项目路线图就非常重要，否则，它和发布筹划相似。项目/产品路线图由项目负责人和项目经理维护，并保持变化。普通，会形成路线图文档或幻灯片，使用大图标显示重要里程碑、包括功能和发布日期等，让所有项目/产品有关人员都清晰产品各个组件也许发布日程。3、版本发布筹划：版本发布筹划由团队成员和项目/产品负责人共同制定，并通过版本发布筹划会议讨论通过。它涉及了当前版本需要交付、达到一致核心功能，并通过优先级排序，可以包括Epic和UserStory。支持版本发布筹划某些概念为故事点、迭代、团队速率和优先级排序。普通，项目/产品负责人提出本次版本发布目的，团队成员依照目的和功能特性重要性对故事进行排序，并根据团队速率决定本次发布需要包括故事点。前几次版本发布使用估算值，其精确度随着项目/产品时间持续而逐渐精准。版本发布筹划是具备适应性且可调节筹划，会随着项目演进而变化。4、迭代筹划：迭代筹划是对版本发布筹划再次细化，同样由团队成员和项目/产品负责人共同制定，并通过迭代筹划会议讨论通过。迭代会议负责2件事情：依照当前状态拟定与否需要对版本筹划作出更新；为当前迭代制定迭代筹划。支持迭代筹划某些概念为拆分Epic和UserStory、任务、任务估算。在迭代会议上，成员一方面依照当前项目变化对发布筹划进行更新，然后依照更新后、重新排序过故事制定当前迭代需要完毕故事，并对这些故事进行详细任务拆分。成员在认领完任务后，会对任务实现时间做出估算，估算值需要详细到这些估算信息可以以便任何成员追踪任务进度。5、每日实现：每日实现是团队成员完毕任务详细过程，它根据任务估算值并依照任务最后实现状况更新该值。在敏捷办法中，使用每日站立会议来报告进度，通过15分钟站立形式，团队成员报告故事或者任务完毕、未完毕状态，而解决层面问题则在会议之后解决。注：完整多级项目规划包括如上5个层面，仅包括版本发布筹划、迭代筹划有时也被称为2级项目规划。完整团队-闫建伟敏捷开发最佳实践--完整团队近来几年，以SCRUM为代表敏捷开发思想在软件开发界悄然兴起，大量实践表白，敏捷开发大大提高了软件开发效率和软件质量，协助软件公司提高了效益同步也减少了成本。据调查，在欧美软件公司已有近半数公司开始使用软件开发，在国内多家公司也悄然兴起。如果您开发团队还在面临需求时时多变、开发周期过长、软件质量低下等难以解决问题，那么从老式意义开发团队向敏捷开发团队转型已是事在必行。当前比较符合敏捷开发思想开发模式有XP极限编程、RUP、Lean和Scrum，其中最流行当属Scrum开发办法。下面笔者将结合自己亲自参加各种Scrum开发模式团队经验，谈一谈如何构建一只符合Scrum开发思想完整团队。一方面对比一下Scrum团队与老式开发团队区别。1、Scrum团队中不再有老式意义上产品经理、项目经理、开发经理，而是引入了ProductOwner、ScrumMaster和Scrum团队等新角色，团队中普通会包括各种职责成员，例如由需求设计、开发和测试人员共同构成团队。2、老式开发团队普通是项目经理下达工作内容，而Scrum团队倡导自我管理，按照兴趣和能力挑选任务。3、从前开发团队普通是接到任务后分头工作、独立完毕，而当前Scrum团队需要互相配合工作，互相协作完毕任务。4、老式开发过程中，普通是经历一种大时间段开发过程才完毕一次产品发布，而Scrum开发过程中，产品是迭代增量发布，普通是在每个Sprint结束时交付可发布软件。下面我来简介一下Scrum团队完整性某些体现。1、Scrum团队职责完整性在一种原则SCRUM团队中分为3种角色，分别是ProductOwner、ScrumMaster和Scrum团队。她们职责如下：ProductOwner需要拟定产品功能和完毕时间，并对产品收益负责，需要依照市场需求拟定产品功能优先级。ProductOwner重要工作是依照市场需求拟定产品功能，将其列入ProductBacklog中，并为这些功能拟定优先级。ProductOwner角色普通由市场部门人员来担任。ScrumMaster负责监督整个Scrum项目进程，调节项目筹划，保证开发团队成员能力可以胜任开发，促使团队中不同角色可以进行充分沟通和交流，并负责为项目进程扫清障碍，保障每日开发进度及某些寻常开发管理工作。ScrumMaster普通由开发组组长担当。Scrum团队，普通由5-10个全职成员构成，团队成员横跨各种职能，普通涉及开发、需求、测试人员，人们在弱化分工，每个人都参加设计、开发与测试中，这也是团队职责完整性一种体现。2、Scrum团队素质完整性一方面，要具备很强集体协作精神。敏捷开发倡导一种重要思想就是集体协作，虽然个人能力再强，不懂得集体协作，这种人也不是敏捷开发团队所需要。另一方面，Scrum团队成员需要详细良好沟通能力。敏捷开发中最强调就是沟通，最有效沟通方式就是面对面交流，那种只会埋头工作而沟通能力不强员工，在敏捷开发团队里也是吃不开。第三，Scrum团队成员必要能积极积极接受新事物，要具备创新能力。敏捷开发与老式开发模式最大优势就是拥抱变化，面对时时变化客户需求，那些不能及时转变思维、墨守成规成员是不能胜任。最后，Scrum团队成员要具备极强自我管理能力和积极积极精神。自我管理是敏捷开发团队中不可或缺素质，那些工作时只会被别人引导而不能积极自我管理人也是不适合。3、Scrum沟通完整性Scrum团队除了寻常工作之外，有三个重要会议也是要坚持，这三个会议召开好坏，直接影响到Scrum开发过程效果。这三个会议分别是Sprint启动会、每日站立会议和Sprint回顾。一方面来简介一下Sprint启动会,这个会议重要目是要依照ProductOwner制定产品或项目筹划在Sprint开始时做准备工作，普通是由ProductOwner依照市场前景和商业价值制定一种排好序客户需求列表，这个列表就是ProductBackLog。当Sprintbacklog拟定后，ScrumMaster带领ScrumTeam去分解这些功能点，细化成Sprint一种个任务.这些任务就是细化来实行这些功能点活动.SprintPlanning这个阶段需要控制在4个小时。

另一方面，每日站立会议，顾名思议是每天开站会。这个会议是让团队成员可以面对面在一起，同步当前工作进度和状态。普通每个成员需要轮流回答“昨天我做了什么”、“今天筹划做什么”和“遇到了哪些困难”三个问题。这个会议普通要严格控制在10分钟左右，不适当过长。最后，在一种迭代周期结束时候，要召开迭代回顾会。这个会议一方面要演示本迭代完毕工作内容，需求、开发和技术人员要做有关评审工作，由ProductOwner来拟定完毕了哪些功能，哪些工作还没有完毕。此外，整个团队还要回顾本迭代内哪些工作完毕好，继续发扬和保持下去，哪些工作完毕不好，需要进行什么样改进。这三个会议是Scrum开发过程中不可缺少重要构成某些，一定要持续将这些会议坚持下去，才干真正体会到敏捷开发带来好处。ATDD(验收测试驱动开发)-刘曙光ATDD定义：AcceptanceTDD是测试驱动开发核心理念一种扩展，是指在用测试驱动开发实现某个详细功能之前，将会一方面编写功能测试或验收测试，从系统功能角度驱动开发过程。ATDD是一种团队行为及过程，ATDD周期包括挑选故事，给故事写测试，实现测试以及最后实现故事这四个环节。1、挑选顾客故事：迭代开始前筹划会议，这个会议中，客户会决定下一种迭代该做哪些故事，及给故事排优先级。普通状况下可先选取较高优先级顾客故事。2、为故事写测试：在为故事编写测试时候，客户是最适合写验收测试人，而对于实际状况由于客户参加度和技能问题，可行方式是由客户、开发人员、测试人员共同参加编写验收测试，给故事拟出一系列测试。在编写测试用例时只关注完毕故事必要要做几件事情，形成简朴清单，后来在详细实现故事或者验收测试时在细化测试，添加更多细节，讨论各某些如何工作，拟定客户对界面与否有特别规定等。依照功能类型，相应测试可以是一组顺序操作，或者是一组输入及相应输出。此外在故事实现过程中还难免会发现原有测试外新测试，合理做法是，在征求客户意见后，咱们应当把新验收测试加入到清单中。3、自动化测试：在完毕验收测试编写后，就需要把验收测试转化成可执行验收测试，这时候，团队常会引入某些相对成熟测试框架及商业化自动化测试工具。这些框架和工具普通可化分为API级别功能测试（如采用Fit和FitNesse框架）和自动化GUI测试（如可采用核心字驱动框架和商业自动化工具等），团队可以依照开发应用及团队自身状况选取使用其中一种或组合使用。API级别功能测试，使团队可以在不牵涉UI层状况下测试业务逻辑。而自动化GUI测试在实际应用中，团队所采用自动化测试框架（普通需要团队自行开发）针对GUI测试成熟度特别重要，良好框架可通过测试用例、界面对象、数据分离，大大减少由于频繁界面变化而对已有自动化脚本影响。4、实现故事：实现新功能，让新加入验收测试通过。ATDD自身并不会限制实现功能方式，但是使用ATDD人普通倾向与在实现过程中采用TDD方式。这样在代码层面，采用TDD办法以测试驱动方式编写代码。在软件特性和功能层面，使用ATDD办法以测试驱动方式构建系统，这两个不同层面上结合使用测试驱动，既能保证软件内部质量同步能保证开发出软件能满足对的功能需求。结对编程-高航前言：在敏捷软件开发各种实践中，结对编程（PairProgramming）是特别有争议，特别是在国内软件公司或团队，几乎看不到有真正实践、施行，并带来效果。相比于其她敏捷软件开发办法火热及它们带来成效，结对编程可以说备受冷落。它看上去很美，但想要成功实践，可谓障碍重重。那么实用为王，咱们是不是可以秉承结对编程先进核心理念和思想，而将它实践框架加以改造，让它更适合咱们工作流程和习惯，最后成功实践并提高研发效率和质量呢？于是有了下面一种变形、可实践结对编程办法。老式结对编程定义及特性：两位程序员形成结对小组，肩并肩地坐在同一台电脑前合伙完毕同一种设计、同一种算法、同一段代码或同一组测试。结对编程可以看作是一种敏捷化代码检查（CodeReview），其最后目的是提高软件产品质量。代码检查工作是公认提高软件产品质量重要活动之一，但在实践中，成功应用也并不多见，因素是老式代码检查办法只能在某个功能完全开发完毕后才进行检查，效率不高。而更大问题是，检查人对被检查人代码所实现业务功能并不十分清晰，因此只能检查代码格式、语法与否规范，对实现逻辑与否满足业务需求往往无法检查。这导致了诸多公司和团队代码检查都流于形式。结对编程就解决了这一问题，它不需要代码都写完才开始检查，而是在两个人互相协作过程中，实时进行多次交叉检查，大大提高了效率，并且由于两人同步完毕设计和代码，对业务需求也都理解，因此检查时可以验证代码与否满足了需求、与否符合业务逻辑。但是，老式结对编程模式也有某些显而易见问题导致其难以实践，例如人们紧张两个用一台电脑做同样一件事情，是不是挥霍了人力资源？两个人个性、习惯、水平都不同，在对等地位上同步做一件事情会不会产生冲突和矛盾？她们之间沟通和协作会顺畅吗？会不会感到不自在？新结对编程定义及特性：两位程序员形成结对小组，每人一台电脑，坐在临近工位上，两人合伙完毕一组功能（可以是两个或各种独立模块）设计、代码实现。但对于某一种模块来说设计和代码是分开，一种人负责设计，另一种人负责写代码，对于其她模块则反之。当某个功能阶段性完毕后，由其设计人员对代码进行检查。当前，诸多敏捷开发倡导者们都在积极寻找可实践结对编程变形体，以打破结对编程这种看上去很美，摸上去扎手状况。而上述这种形式新结对编程，也是咱们几经摸索总结出来一种可实践结对编程形式，并在产品团队中成功应用。它继承了结对编程核心理念，让代码检查更加高效、进一步。也在两人合伙模式上，更适应实际工作状况和工作习惯，以做到真正可实践、可应用。下面详细简介这种新结对编程内容。1、角色与参加形式：在可实践结对编程中，参加人是开发人员，她们两个人形成一种小组，临近而坐，在详细某个功能或任务上，两个人所扮演角色是有承办关系，一种是设计者、另一种是开发者，一种是审查者、另一种是被审查者。而在在总体上，两个人关系又是平等，由于设计与开发、审查与被审核对于两个人来说是互相。这样就避免了某些结对小组中两人在协同工作中会产生冲突与矛盾。2、重要活动与工作流程：这里咱们举例来说，两个开发人员甲和乙，形成结对编程小组，共同负责两个功能A和B。工作开始，甲进行A设计工作，并给出设计文档(关于设计文档阐明请见“题外话”)。乙进行B设计工作，并给出设计文档。两人设计工作完毕后，互相阅读对方设计文档并进行交流，两人要保证对对方设计内容理解清晰，并指出对方文档中描述不本地方让其修改，最后保证设计内容是清晰明确，并且甲、乙两人对A、B功能设计都熟悉明确并思想一致。接下来开始代码开发工作，甲按照乙设计文档开发功能B，乙按照甲设计文档开发功能A。代码开发工作进行到某个段落后，甲对乙开发功能A代码进行审查，检查代码格式和规范以及代码实现与否符合甲设计业务逻辑，如有问题，则请乙进行修改并复查，乙同样反之对B进行审查，最后达到代码开发完毕，A、B两个功能都进行过多次审查和修改，并且甲、乙两人都确认两个代码是合格，并符合业务需求。这样，功能A、B设计和代码实现就是有甲、乙共同协作完毕，两人共同对两个功能负责，并且两人对两个功能设计和实现都清晰，更为重要是甲、乙两人工作是互相并行配合，不会产生冲突，更为容易推广施行。3、额外好处：按照可实践结对编程模式完毕软件开发，不但高效完毕了代码检查，提高了软件质量，还带来了某些额外好处：1、每个模块至少两个人熟悉，这样在有人请假时候均有backup，不会导致严重耽误工作进度。如果有人要离职，交接工作普通也会非常轻松，几乎没有什么需要特别交接。2、进行结对两个开发人员互相阅读设计文档和代码实现，实际也是一种互相学习过程，因此结对编程也起到了某些知识传播、培训作用。题外话：关于敏捷开发中设计文档，说某些题外话。敏捷开发与老式瀑布型开发一种很重要区别就是：在研发活动中各环节流转承办时，瀑布型开发是以文档为主，思想交流与沟通为辅。而敏捷开发是以思想交流与沟通为主，文档为辅。因此在瀑布型开发中，对设计文档格式和规范等规定比较高。而敏捷开发中设计文档，只是要描述清晰设计思想，并作为一种辅助手段，将核心内容存留作为根据即可，不需要规范模板。可以依照设计者习惯，以最高效形式描述清晰设计内容，并且清晰明确即可。在结对编程实践中，所涉及到设计文档书写，都是以此种方式进行。拟定冲刺筹划-袁斌、钱岭两位专家请将这某些整顿成为一种最佳实践：敏捷规划，如何，多谢！-DJ袁斌：“拟定冲刺筹划”草稿：冲刺会议目：Scrum团队和产品负责人（ProductOwner）共同决定在接下来冲刺周期内目的以及哪些功能和任务需要完毕。冲刺会议参加最重要角色：Scrum团队，产品负责人以及ScrumMaster冲刺会议重要输入工件：ProductBacklog、团队能力冲刺会议重要输出工件：SprintBacklog冲刺会议重要流程阐明：冲刺会议最重要参加人员是Scrum团队，产品负责人以及ScrumMaster，同步感兴趣管理层或者客户代表也可以参加。整