敏捷开发流程自己总结

精品文档 敏捷开发的相关简介敏捷开发的相关简介 敏捷定义敏捷定义 Scrum 是一个轻量级的软件开发方法 Scrum 是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架 中，整个开发周期包括若干个小的迭代周期，每个小的迭代周期称为一个 Sprint，每个 Sprint 的建议长度 2 到 4 周。 在 Scrum 中，使用产品 Backlog 来管理产品或项目的需求，产品 backlog 是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。 Scrum 的开发团队总是先开发的是对客户具有较高价值的需求。在每个 Sprint 中，Scrum 开发团队从产品 Backlog 中挑选最有价值的需求进行开发。 Sprint 中挑选的需求经过 Sprint 计划会议上的分析、讨论和估算得到一个 Sprint 的任务列表， 我们称它为 Sprint backlog 。 在每个迭代结束时， Scrum 团队将交付潜在可交付的产品增量。 敏捷的原则敏捷的原则 个体与交互个体与交互胜过过程与工具过程与工具 可以工作的软件可以工作的软件胜过面面俱到的文档面面俱到的文档 客户协作客户协作胜过合同谈判合同谈判 响应变化响应变化胜过遵循计划遵循计划 这四句价值观用语句表达就是： 自组织团队与客户紧密协作，通过高度迭代式、增量式的软件开发过程响应变自组织团队与客户紧密协作，通过高度迭代式、增量式的软件开发过程响应变 化，并在每次迭代结束时交付经过编码与测试的有价值的软件。化，并在每次迭代结束时交付经过编码与测试的有价值的软件。 胜过 与客户确定合同后在初期制定并遵循基于活动的完整计划，在重型过程和工具与客户确定合同后在初期制定并遵循基于活动的完整计划，在重型过程和工具 指导下，通过完成大量文档进行知识传递，最后交付需求。指导下，通过完成大量文档进行知识传递，最后交付需求。 《敏捷宣言》《敏捷宣言》1212 条原则条原则 1.最优先的目标是通过尽早地、持续地交付有价值的软件来满足客户。 2.欢迎需求变化，甚至在开发后期。敏捷过程控制、利用变化帮助客户取得竞争 优势。 3.频繁交付可用的软件，间隔从两周到两个月，偏爱更短的时间尺度。 4.在整个项目中业务人员和开发人员必须每天在一起工作。 5.以积极主动的员工为核心建立项目， 给予他们所需的环境和支持，信任他们能 够完成工作。 6.在开发团队内外传递信息最有效率和效果的方法是面对面的交流。 7.可用的软件是进展的主要度量指标。 8.敏捷过程提倡可持续发展。发起人、开发者和用户应始终保持稳定的步调。 9.简化——使必要的工作最小化的艺术——是关键。 . 精品文档 10.持续关注技术上的精益求精和良好的设计以增强敏捷性。 11.最好的架构、需求和设计产生于自我组织的团队。 12.团队定期地对运作如何更加有效进行反思， 并相应地调整、校正自己的行为。 敏捷的角色敏捷的角色 1 1 产品负责人产品负责人 产品负责人（Product Owner）的职责如下： •确定产品的功能。 •决定发布的日期和发布内容。 •为产品的 ROI 负责。 •根据市场价值确定功能优先级。 •每个 Sprint，根据需要调整功能和优先级（每个 Sprint 开始前调整） 。 •接受或拒绝接受开发团队的工作成果。 2 ScrumMaster2 ScrumMaster 作为 Team Leader 和 Product owner 紧密地工作在一起，他可以及时地为团队成 员提供帮助。 他必须: •保证团队资源完全可被利用并且全部是高产出的。 •保证各个角色及职责的良好协作。 •解决团队开发中的障碍。 •做为团队和外部的接口，屏蔽外界对团队成员的干扰。 •保证开发过程按计划进行，组织 Daily ScrumDaily Scrum, Sprint Review and SprintSprint Review and Sprint Planning meetingsPlanning meetings。 3 Team3 Team 负责产品的开发 •一般情况人数在 5-9 个左右 •团队要跨职能 （包括开发人员、测试人员、用户界面设计师等） •团队成员需要全职。 （有些情况例外，比如数据库管理员） •在项目向导范围内有权利做任何事情已确保达到 Sprint 的目标。 •高度的自组织能力。 •向 Product Owner 演示产品功能。 •团队成员构成在 sprint 内不允许变化。 •团队整体向产品开发负责。 . 精品文档 敏捷工件敏捷工件 1 1、、ProductProduct BacklogBacklog 有优先级的故事列表，并估算故事点 产品订单：产品订单（Product Backlog）是整个项目的概要文档，它包含 已划分优先等级的、项目要开发的系统或产品的需求清单，包括功能和非功能性 需求及其他假设和约束条件。 产品负责人和团队主要按业务和依赖性的重要程度 划分优先等级， 并作出预估。预估值的精确度取决于产品订单中条目的优先级和 细致程度， 入选下一个冲刺的最高优先等级条目的预估会非常精确。产品的需求 清单是动态的，随着产品及其使用环境的变化而变化，并且只要产品存在，它就 随之存在。而且，在整个产品生命周期中，管理层不断确定产品需求或对之做出 改变，以保证产品适用性、实用性和竞争性。 2 2、、Sprint BacklogSprint Backlog 当前 Sprint 要完成的任务列表，并估算工时 • 团队成员自己挑选任务，而不是指派任务 • 对每一个任务，每天要更新剩余的工作量估算 • 每个团队成员都可以修改 Sprint backlog，增加、删除或者修改 任务 冲刺订单：冲刺订单是大大细化了的文档，用来界定工作或任务，定义团队 在 Story 中的任务清单，这些任务会将当前冲刺选定的产品订单转化为完整的 产品功能增量。冲刺订单在冲刺规划会议中形成，其包含的不会被分派，而是由 团队成员签名认领他们喜爱的任务。任务被分解为以小时为单位，没有任务可以 超过 16 个小时。如果一个任务超过 16 个小时，那么它就应该被进一步分解。 每项任务信息将包括其负责人及其在冲刺中任一天时的剩余工作量， 且仅团队有 权改变其内容。 3 3、发布燃尽图、发布燃尽图 直观反应当前发布剩余的工作量，以 Sprint 周期数和故事点数为单 位。 . 精品文档 燃尽图（Burndown Chart）是一个公开展示的图表，纵轴代表剩余工作量， 横轴代表时间， 显示当前冲刺中随时间变化而变化的剩余工作量（可以是未完成 的任务数目，或在冲刺订单上未完成的订单项的数目） 。剩余工作量趋势线与横 轴之间的交集表示在那个时间点最可能的工作完成量。 我们可以借助它设想在增 加或减少发布功能后项目的情况，我们可能缩短开发时间，或延长开发期限以获 得更多功能。它可以展示项目实际进度与计划之间的矛盾。 4 4、、SprintSprint 燃尽图燃尽图 Sprint燃尽图直观的反映了 Sprint过程中，剩余的工作量情况，Y 轴表 示剩余的工作，X 轴表示 Sprint的时间。随着时间的消耗工作量逐渐减 少，在开始的时候，由