敏捷开发知识体系整体框架.docx

1、敏捷开发知识体系整体框架1敏捷开发知识体系整体框架1.1敏捷开发工程实践111项目管理迭代开发风险价值生命周期多级项目规划完整团队每日站立会议*任务板燃尽图1.1.2需求管理需求订单业务流程草图用例驱动开发用户故事1.1.3架构演进的架构*演进的设计*基于组件的架构设计1.1.4开发结对编程测试驱动开发重构代码规范1.1.5测试单元测试*并行测试*测试管理1.1.6变更管理持续集成自动构建团队变更管理12敏捷开发管理实践描述*定义和特征说明 主要角色主要活动和最佳实践*主要输入输出工作流程13敏捷开发工程实践描述*定义和特征说明应用说明案例说明2敏捷开发核心价值观和原则2.1敏捷软件开发宣言*

2、个体和互动高于流程和文档*工作的软件高于详尽的文档*客户合作高于合同谈判响应变化高于遵循计划*也就是说，尽管右项有其价值,我们更重视左项的价值.2.2敏捷软件开发的核心价值观,并在这个过程中及时地敏捷开发的核心理念就是以最简单有效的方式快速打成目标 响应外界的变化，做出迅速的调整.2.2.1核心价值观以人为本目标导向客户为先拥抱变化222敏捷开发的原则我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。业务人员和开发人员必须相互合作，项

3、目中的每一天都不例外。激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。可工作的软件是进度的首要度量标准。敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。以简洁为本，它是极力减少不必要工作量的艺术。最好的架构、需求和设计出自自组织团队。团队定期地反思如何能提高成效，并依此调整自身的举止表现。3敏捷开发管理实践3.1ScrumScrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。 Scrum包括了一系 列实践和预定

4、义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的 Scrum主管 角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。3.1.1Scrum中的角色3.1.1.1猪”角色* 产品负责人(Product Owner)通常由市场部门的人担任敏捷教练(Scrum Master)*通常由开发组组长担任开发团队(Scrum Team)包括开发，需求，测试3.1.1.2鸡”角色用户软件是为了某些人而创建！ 就像 假如森林里有一棵树倒下了， 但没有人听到，那么它算发出了声音吗”，假如软件没有被使用，那么它算是被开发出来了么？ ”利益所有者（客户，提供商）*影响项目成功的人

5、，但只直接参与冲刺评审过程。管理者*为产品开发团体架起环境的那个人3.1.2主要活动和最佳实践迭代式软件开发两层项目规划(Two-Level Project Planning)整体团队协作(Whole Team)持续集成冲刺规划会议(Spri nt Plan Meeti ng)每日站立会议(Spri nt Daily Meet ing)冲刺复审会议(Sprint Review Meeting)3.1.3主要输入输出 产品订单(Product Backlog) 冲刺订单(Spring Backlog) 燃尽图(Burndown Chart)新的功能增量3.1.4工作流程3.1.4.1项目管理过程

6、在Scrum项目管理过程中产品负责人获取项目投资 ，并对整个产品的成功负责,完成项目商业价*产品负责人协调个中利益干系人，确定产品订单中初始的需求清单及其优先级值分析和项目整体规划，并任命合适的敏捷教练开展项目工作 3.1.4.2项目开发过程在Scrum软件开发过程中，每个冲刺就是较短的迭代，通常为24周.*在每个冲刺开始时，产品负责人和敏捷教练通过召开冲刺规划会议和 ”两层项目规划”的最佳实践制定冲刺订单（类似迭代计划）产品负责人明确在本次冲刺中实现的需求清单响应的工作任务和负责人.在每个冲刺迭代中，团队强调应用”整体团队协作”的最佳实践，通过保持可持续发展的工作节奏和每日站立会议，实现团队

7、的自组织，自适应和自管理，高效完成冲刺工作在每个冲刺结束时，团队都会召开冲刺复审会议 ，团队成员会在会上分别展示他们开发出的软件 (或其他有价值的产品)，并从产品负责人和其他利益关系人那里 ，得到反馈信息.在冲刺复审会议之后，团队会自觉招开冲刺回顾会议 ，回顾整个项目过程，讨论哪些方法做的好 哪些方面可以改进，实现软件交付过程的持续，自发的改进3.2XP3.3OpenUp3.4Lean4敏捷开发工程实践4.1迭代式开发敏捷迭代开发是指每次按照相同的开发方式短期的开发软件的部分 ，或前期开发并不详尽的软件，每次开发结束获得可以运行的软件，以供各方干系人观测，获得反馈，根据 反馈适应性的进行后续开

8、发，经过发福多次开发，逐步增加软件部分，逐步补充完善软件， 最终开发得到最后的软件.每次反复开开发叫一次迭代，在Scrum中成为Sprint，中文常译 为”冲刺”.4.2持续集成持续集成(Continuous integration)是指当代码提交后，马上启动自动编译，自动部署金 额自动化测试来快速验证软件，从而尽快的发现集成错误.4.3多级项目规划多级项目/产品规划，在软件开发领域，是指以迭代开发为基础，形成多层次的，逐步 细化的项目或产品计划.这些层层相关的项目/产品规划包括：*项目/产品愿景*项目/产品路线图版本发布计划迭代计划每日实现4.3.1项目/产品愿景在计划阶段,首先,项目sta

9、keholder,项目/产品负责人将参与并组成工作组,他们负责 阐述项目的重要性，给出项目成功失败的关键标准以及项目整体层面 ”完成”的定义；在过程中，可以利用形成项目愿景的一些个工具 ，包括愿景盒子(Vison Box),业务收益矩阵(Busi ness Ben efits Matrix),项目范围矩阵(Scope Matrix),滑动器(Slider),成本收益矩阵 (Cost/Benefit Matrix)等；最后，项目愿景需要使用尽量简要的文档固定下来，并保证项目团 队成员都能了解.该文档需要包括：当前的问题 机会描述和理由(描述项目的重要性)项目的价值项目如何和组织的战略目标达成一致

10、*解决方案综述项目包含的关键功能项目必须服从的技术和约束条件项目范围项目的关键时间线*项目收益分析项目和其他项目的依赖性项目的相关风险以及如何消除4.3.2项目/产品路线图主要描述为了达到产品愿景而需要交付的关键功能和特性，这些特性基本处于Epic和 特性层面,不包裹用户故事(User Story).它从时间的维度来表述对愿景的支持和实现 .它 从时间维度来表达对愿景的支持和实现当项目/产品需要发布多个版本时，项目线路图就 非常重要，否则，它和发布计划相同，项目/产品线路图由项目负责人和项目经理维护 ，并 保持更新通常，会形成路线图问题或幻灯片，使用大图标显示重要的里程碑，包含的功 能和发布日

11、期等，让所有项目/产品相关人员都清楚产品各个组件的可能发布日程 4.3.3版本发布计划版本发布计划由团队成员和项目/产品负责人共同制定，并通过版本发布计划会议讨论 通过.它包括了当前版本需要交付的，达成一致的关键功能，并经过优先级排序，可以包 含EPIC和User Story.版本发布计划中常使用的概念包括：故事点，迭代团队速率和优先级 排序.通常，项目/产品负责人提出本次发布的目标，团队成员根据目标和功能特性的重要 性对故事进行排序，并依据团队速率觉得本次发布需要包含的故事点 前几次版本发布使 用估算值，其准确性随着项目/产品的时间持续而逐步精确版本发布计划是剧本适应性可 调整的计划，会随着

12、项目演进而改变.434迭代计划迭代计划是对版本发布计划的再次细化，同样由团队成员和项目/产品负责人共同制定 并听过迭代计划会议讨论通过.迭代会议负责两件事情：根据当前状态确定是否需要对版本计划做出更新为当前的迭代计划制定迭代计划迭代计划中常使用的概念包括：拆分Epic和User Story,任务,任务估算.在迭代会议 上,成员首先根据当前的项目变化对发布计划进行更新 ，然后根据更新后的，重新排序过的故事制定当前迭代需要完成的故事，并对这些故事进行详细的任务拆分.成员在认领完 任务后，会对任务的实现时间做出估算，估算值需要具体到这些估算信息可以方便任何成 员追踪任务的进度.4.3.5每日实现没事

13、实现是团队成员完成任务的具体过程，它依据任务估算值并根据任务最终实现情 况更新该值.在敏捷方法中，使用每日站会议来报告进度.通过15分钟的站立形式，团队 成员报告故事或者任务的完成，未完成状态，而解决层面的问题则在会议之后处理.4.4完整团队Scrum团队必须具备的三个完整性：4.4.1团队职责完整性4.4.1.1产品负责人(Product Owner)确定产品的功能。*决定发布的日期和发布内容。为产品的收益(profitability of the product)负责。根据市场价值确定功能优先级。*在30天内调整功能和调整功能优先级。接受或拒绝接受开发团队的工作成果4.4.1.2敏捷教练(

14、Scrum Master)负责监督整个Scrum项目进程，调整开发计划保证团队资源完全可被利用并且全部是高产出的。保证各个角色及职责的良好协作。解决团队开发中的障碍。做为团队和外部的接口，屏蔽外界对团队成员的干扰。 保证开发过程按计划进行，组织 Daily Scrum, Sprint Review and Spri nt Pla nning meet ings。4需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发 生变化.根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的 燃尽图*需要找出阻碍Scrum的障碍和依赖，根据优先级指定计划解决这些障碍个人

15、问题或冲突在 Scrum里是需要解决的。这些都需要被澄清，或通过内部的沟通解决，或向管 理层和HR寻求帮助解决Scrum Master需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发生变化。 Scrum Master需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的Burndown Chart。 Scrum Master还必须仔细考虑进展中的开放任务数，进展中的工 作需要得到最小化，以实现精益生产率的收益。Scrum Master需要找出阻碍 Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定 计划解决这些障碍。其中有些问题可以在

16、团队内部解决，有些则要团队之间的协调，还有的要管 理层的介入来解决.4.4.1.3开发团队(Scrum Team)具有不同特长的团队成员，人数控制在 5-7个左右，跨职能，包括开发，需求，测试*弱化分工，每个人都参与设计，开发与测试*确定Sprint目标和具体说明的工作成果。*在项目向导范围内有权利做任何事情已确保达到 Sprint的目标。*向Product Owner演示产品功能。4.4.2团队素质完整性*要具备很强的集体协作精神 .*要具备良好的沟通能力必须能积极主动的接受新的事物，要具备创新能力要具备极强的自我管理能力和积极主动的精神443沟通的完整性* Sprint启动会每日站立会议

17、Sprint回顾会444案例4.5验收测试驱动开发ATDDTDD只是开发人员的职责，通过单元测试用例来驱动功能代码的实现。 ATDD在准备实施一个功能或特性之前，首先团队需要定义出期望的质量标准和验收细则，以明确而且 达成共识的验收测试计划（包含一系列测试场景）来驱动开发人员的 TDD实践和测试人员的测试脚本开发。面向开发人员，强调如何实现系统以及如何检验。*挑选用户故事*为故事写测试实现测试实现故事4.6结对编程结对编程可以看做是一种敏捷化的 Code Review4.7新结对编程两位程序员新成结对小组，每人一台电脑，坐在临近的工位上，两人合作完成一组功 能（可以是两个或多个独立的模块）的设

18、计，代码实现.但对已某一个模块来说设计和代码 是分开的，一个人负责设计，另一个人负责写代码，对于其他模块则反之.4.8确定冲刺计划4.8.1定义和说明目的：ST和PO共同决定在接下来的冲刺周期内的目标以及那些功能和任务需求要完成主要角色：ST, PO, SM主要输入：Product backlog,团队的能力主要输出：Sprint Backlog冲刺会议分两个部分1解决本次冲刺要完成哪些需求2解决这些选择的需求要如何被完成482案例4.9故事点估算故事点是表述一个用户故事，一项功能或一件工作的整体大小的一种度量单位.数值 本身不重要，重要的是这些故事之间对比体现相对大小.4.9.1计划扑克开始

19、时，美人得到一张扑克，上面有任务点(？, 0, 1/2, 1,2, 3, 5, 8, 13, 20, 40, 100,无穷).?代表无法 估算，无穷代表故事太大开始对故事进行估算，先由PO介绍这个故事的描述.接着澄清问题每一个组员从扑克中挑选可以代表这个故事的卡片 ，集体亮牌最高分和最低分的组员像团队做出解释全组成员自由讨论几分钟重新打分，直到全组统一.4.9.2 敏捷估算 2.0(Agile Estmating 2.0)po像团队成员介绍每一个用户故事，确保所有需求相关的问题都在做估算前得到解决整个团队参与游戏：一次由一人将一个故事卡片放在合适的位置 ，规模小的在左，规模大的在右，一样大的竖

20、排.轮流移动故事卡片，直到整个团队都认同白板上故事卡的排序为止 .团队将故事点(Story Point)分配给每个故事.4.10 需求订单(Product Backlog)记录用户需求的列表，包括产品所有需要的特征.每一项包含了需求标题，描述，重要性，故事点(或其他表示大小的数字)需求订单式开放的，团队每个成员都可以编写和维护在整个项目开放生命周期内，需求订单需要不断维护，管理与跟踪需求变化4.11燃尽图在项目完成之前，对需要完成的工作的一种可视化表示.燃烧故事点.每天更新一次*具备可视性*具备风险预估，提醒团队目前完成情况*具备可估量，直接显示当前还需要的时间.4.11.1燃尽图常见问题4.

21、12每日站立会议(Daily Scrum)每日站立会议旨在让团队统一目标，协调内部问题的解决，绝非进度汇报.一般不超过 15分钟.我们上次开会后你都干了什么在我们下次开会之前你要做什么 每个你负责的、正在做的任务还剩下多少时间你的工作被阻碍了吗4.13 任务板(Task board)为项目团队提供一个便利的工具用于管理他们的工作是团队成员对本冲刺的工作一目了然任务板通常设立与项目团队日常工作的公共空间的一面墙上 .任务板上得信息包括该冲洗计划完成的用户故事和相应的任务，分别卸载卡片上，按照一定的方式贴在任务板上 (To Do, In Progress, Done).团队成员通过调整任务卡得位置和上面的信息反映任务的执行 情况.4.13.1用户故事卡每张卡片记录一条用户故事，故事点.4.13.2任务卡每个用户故事卡片通对应的多个任务卡.每张卡片记录一条任务，到目前为止完成该 任务所需的工作量(小时).随着进展试试更新.4.13.3任务板的使用4.13.4用户故事作为某个角色 ,我希望 实现何种功能 ,以便 带来何种价值.如：作为一个用户，我希望在每次退出系统前得到是否保存的提示 ，以便所有内容都被成功存储了.4.14测试驱动开发(TDD)先开发测试用例，然后再开发代码.