敏捷开发流程(自己总结)

1、精品文档敏捷开发的相关简介敏捷定义Scrum 是一个轻量级的软件开发方法Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期包括若干个小的迭代周期，每个小的迭代周期称为一个Sprint ，每个 Sprint的建议长度 2 到 4 周。在 Scrum 中，使用产品 Backlog 来管理产品或项目的需求，产品 backlog 是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum 的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中， Scrum开发团队从产品Backlog 中挑选最有价值的需求进行开发。Sprint中挑

2、选的需求经过Sprint计划会议上的分析、 讨论和估算得到一个Sprint的任务列表，我们称它为 Sprintbacklog。在每个迭代结束时， Scrum团队将交付潜在可交付的产品增量。敏捷的原则个体与交互胜过过程与工具可以工作的软件胜过面面俱到的文档客户协作胜过合同谈判响应变化胜过遵循计划这四句价值观用语句表达就是：自组织团队与客户紧密协作，通过高度迭代式、增量式的软件开发过程响应变化，并在每次迭代结束时交付经过编码与测试的有价值的软件。胜过与客户确定合同后在初期制定并遵循基于活动的完整计划，在重型过程和工具指导下，通过完成大量文档进行知识传递，最后交付需求。敏捷宣言 12 条原则1. 最

3、优先的目标是通过尽早地、持续地交付有价值的软件来满足客户。2. 欢迎需求变化， 甚至在开发后期。 敏捷过程控制、 利用变化帮助客户取得竞争优势。3. 频繁交付可用的软件，间隔从两周到两个月，偏爱更短的时间尺度。4. 在整个项目中业务人员和开发人员必须每天在一起工作。5. 以积极主动的员工为核心建立项目， 给予他们所需的环境和支持， 信任他们能够完成工作。6. 在开发团队内外传递信息最有效率和效果的方法是面对面的交流。7. 可用的软件是进展的主要度量指标。8. 敏捷过程提倡可持续发展。发起人、开发者和用户应始终保持稳定的步调。9. 简化使必要的工作最小化的艺术是关键。.精品文档10. 持续关注技

4、术上的精益求精和良好的设计以增强敏捷性。11. 最好的架构、需求和设计产生于自我组织的团队。12. 团队定期地对运作如何更加有效进行反思， 并相应地调整、 校正自己的行为。敏捷的角色1 产品负责人产品负责人（ Product Owner ）的职责如下：? 确定产品的功能。? 决定发布的日期和发布内容。? 为产品的 ROI 负责。? 根据市场价值确定功能优先级。?每个 Sprint ，根据需要调整功能和优先级（每个Sprint开始前调整）。? 接受或拒绝接受开发团队的工作成果。2 ScrumMaster作为 TeamLeader 和 Product owner 紧密地工作在一起，他可以及时地为团

5、队成员提供帮助。他必须 :? 保证团队资源完全可被利用并且全部是高产出的。? 保证各个角色及职责的良好协作。? 解决团队开发中的障碍。? 做为团队和外部的接口，屏蔽外界对团队成员的干扰。? 保证开发过程按计划进行，组织 Daily Scrum , Sprint Review and Sprint Planning meetings 。3 Team负责产品的开发? 一般情况人数在 5-9 个左右? 团队要跨职能（包括开发人员、测试人员、用户界面设计师等）? 团队成员需要全职。（有些情况例外，比如数据库管理员）? 在项目向导范围内有权利做任何事情已确保达到Sprint 的目标。? 高度的自组织能力

6、。? 向 Product Owner 演示产品功能。? 团队成员构成在 sprint 内不允许变化。? 团队整体向产品开发负责。.精品文档敏捷工件1、 ProductBacklog有优先级的故事列表，并估算故事点产品订单：产品订单（ Product Backlog ）是整个项目的概要文档，它包含已划分优先等级的、 项目要开发的系统或产品的需求清单， 包括功能和非功能性需求及其他假设和约束条件。 产品负责人和团队主要按业务和依赖性的重要程度划分优先等级， 并作出预估。预估值的精确度取决于产品订单中条目的优先级和细致程度，入选下一个冲刺的最高优先等级条目的预估会非常精确。 产品的需求清单是动态的，

7、 随着产品及其使用环境的变化而变化， 并且只要产品存在， 它就随之存在。而且，在整个产品生命周期中， 管理层不断确定产品需求或对之做出改变，以保证产品适用性、实用性和竞争性。2、 Sprint Backlog当前 Sprint要完成的任务列表，并估算工时? 团队成员自己挑选任务，而不是指派任务? 对每一个任务，每天要更新剩余的工作量估算? 每个团队成员都可以修改 Sprint backlog ，增加、删除或者修改任务冲刺订单：冲刺订单是大大细化了的文档，用来界定工作或任务， 定义团队在 Story 中的任务清单，这些任务会将当前冲刺选定的产品订单转化为完整的产品功能增量。 冲刺订单在冲刺规划会

8、议中形成， 其包含的不会被分派， 而是由团队成员签名认领他们喜爱的任务。 任务被分解为以小时为单位， 没有任务可以超过 16 个小时。如果一个任务超过 16 个小时，那么它就应该被进一步分解。每项任务信息将包括其负责人及其在冲刺中任一天时的剩余工作量， 且仅团队有权改变其内容。3、发布燃尽图直观反应当前发布剩余的工作量，以Sprint周期数和故事点数为单位。.精品文档燃尽图（ Burndown Chart ）是一个公开展示的图表，纵轴代表剩余工作量，横轴代表时间， 显示当前冲刺中随时间变化而变化的剩余工作量 （可以是未完成的任务数目，或在冲刺订单上未完成的订单项的数目） 。剩余工作量趋势线与横

9、轴之间的交集表示在那个时间点最可能的工作完成量。 我们可以借助它设想在增加或减少发布功能后项目的情况， 我们可能缩短开发时间， 或延长开发期限以获得更多功能。它可以展示项目实际进度与计划之间的矛盾。4、 Sprint 燃尽图Sprint 燃尽图直观的反映了Sprint 过程中，剩余的工作量情况，Y 轴表示剩余的工作， X 轴表示 Sprint 的时间。随着时间的消耗工作量逐渐减少，在开始的时候， 由于估算上的误差或者遗漏工作量有可能呈上升态势。Sprint过程1、 Sprint 计划会议? 团队从产品 backlog 中挑选他们承诺完成的条目。 （做什么）?创建 Sprint Backlog（

10、怎么做）? 标识具体的任务并为任务做估算? 由团队协作完成，而不是 ScrumMaster.精品文档? 考虑了高层设计2、 Scrum 每日站会团队每天进行 15 分钟的检验和适应的会议称为 Scrum每日站会。每日站会上，每个团队成员需要汇报以下三个问题：? 从上次会议到现在完成了哪些工作。? 下次会议前准备完成什么。? 工作中遇到了哪些障碍。汇报的对象是团队，不是任何一位领导（PO,SM,团队负责人）。汇报的重点在于提出问题，进而解决。每日站会不是进度汇报会议， 这个会议是为将产品 backlog 条目转化成为增量的人（团队）召开的。团队承诺实现 Sprint 目标和完成产品 Backlo

11、g 条目。每日站会是检验朝向 Sprint 目标的进程，如果有必要进行后续会议对 Sprint 中的下一步工作进行调整， 目的在在于增加团队实现目标的可能性。 这是 Scrum经验过程中的重要检验和适应的会议。3、 Sprint 评审会议Sprint 评 审会 议用 来演 示在 这个 Sprint 中开 发的 产品 功能 给 Product Owner.Produc Owner 会组织这阶段的会议并且邀请相关的干系人参加。? 团队展示 Sprint 中完成的功能? 一般是通过现场演示的方式展现功能和架构? 不要太正式? 不需要 PPT? 一般控制在 2 个小时? 团队成员都要参加? 可以邀请所

12、有人参加4、 Sprint 回顾会议Sprint 回顾会议上，全体成员讨论有哪些好的做法可以启动，哪些不好的做法不能再继续下去了，哪些好的做法要继续发扬。? 团队的定期自我检视，发现什么是好的，什么是不好的。? 一般控制在 15-30 分钟? 每个 Sprint 都要做? 全体参加? Scrum Master? 产品负责人? 团队? 可能的客户或其它干系人.精品文档开发流程阶段参与人事务输出开发调研 PO ，SM ，讨论产品需求条目故事列表团队问卷调查分析工作量 估 SM ，团队使用估算扑克估算故事点带估算的故事算确定故事的依赖关系列表发布计划 PO ，SMPO 确定当前发布的时间和应该包含产

13、品 Backlog会议的故事PO 向各干系人公开发布规划Sprint计 SM ，团队 PO 确定最近 1-2 个 Sprint 的最优先 Sprint划会议级故事Backlog团队从产品 Backlog 中的最高优先级故事中挑选承诺完成的条目分解条目成为工作项评估工作项工时（小时为单位）SprintSM ，团队按 Sprint Backlog 产出软件产品潜在可交付的软件产品必须是潜在可交付的 （经过 产品增量完整测试，可运行，有完整用户文档）Sprint评 PO ，SM ，团队向 PO 及相关干系人演示产品增审会议团队量.精品文档收集意见，为下一个Sprint 作准备Sprint回 PO ，

14、SM ，对开发流程进行回顾， 检查哪些方法 更好的 Scrum顾会议团队是值得保留的，哪些是要废弃的。流程敏捷的开发流程1首先组建 scrum 团队（ 5-9 人）2确定团队成员职责（ scrummaster,po,team ）3需求设计分析，列出 product backlog,格式如下 :IDNAMEIMPESTHOW TO DEMONOTES注意事项： DEEPDetailedappropriately(粗细适中 ) ：指将当前优先级高的功能模块尽量细化，而相对优先级较低的功能模块，只需要知道大体功能点既可。Estinnated(估算过的 ) ：对每个功能点进行估算。Emergent(

15、涌现的 ) ：功能模块随着开发的推移是变化的，因此每次迭代完成都要重新调整。Prioritized(排好优先级的 ) ：将功能模块根据商业价值进行排序。产品功能模块的优先级最好用（10，20，30 计算），方便需求变更，附加功能插入。4 sprint planning-想要什么以及为什么？5 选择部分 product backlog（优先级）作为当前sprint的 sprint.精品文档backlog ，并创建 sprint面板。6 sprint 准备会，确定每个人做什么以及怎么做（最好是，自己选择）？确定此次 sprint 的“可交付物”（也就是完成这次迭代要达到的效果）。并且确定当前 sprint 哪些功能是必须实现的（ must），哪些是应该做的，但若没时间就算了（ should ），哪些是不太需要，但有更好（ could ）。7 sprint开发开始，创建sprint的任务版和 sprint backlog的燃尽图，并确保每日更新，每日晨会。Sprint任务版 :Sprint backlogto dodoingdone燃尽图：在迭代开发过程中， 会发生需求的变更或者功能点的添加， 但只要对本次迭代影响不是特别大，就不要对本次迭代发生变更。 （记录迭代中的变更