Scrum上路.ppt

路漫漫其修远兮 吾将上下而求索 我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观： ? 个体与交互 重于 过程和工具可用的软件 重于 完备的文档客户协作 重于 合同谈判响应变化 重于 遵循计划? 在每对比对中，后者并非全无价值，但我们更看重前者。 Kent Beck Mike Beedle Arie van BennekumAlistair Cockburn Ward Cunningham Martin FowlerJames Grenning Jim Highsmith Andrew HuntRon Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken SchwaberJeff Sutherland Dave Thomas 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。 项目过程中，业务人员与开发人员必须在一起工作。 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。 可用的软件是衡量进度的主要指标。 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。 对技术的精益求精以及对设计的不断完善将提升敏捷性。 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。 最佳的架构、需求和设计出自于自组织的团队。 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。 * * * * * * * * * * * * * * * * * * * * * * * * * * 《硝烟中的Scrum和XP》导读 Scrum是一味药，仅此而已 硝烟中的Scrum—从哪里开始 我们才刚上路 药？还是良好的生活习惯？ Scrum不能解决我们的问题，能解决问题的是我们自己 一支出色团队靠的不是技术，不是流程，而是有良好素质的团队成员。良好素质包括进取心、责任心、良好的习惯、热情…… Scrum提供了一套实践方法，帮软件团队养成良好的习惯 好吧，如果这样说有点空洞，让我们走进一步看 药名：Scrum 种类：敏捷软件开发方法 适用症： 重量级流程导致的软件开发环节复杂 面向任务、面向职责的开发模式导致的各司其职、流程环节衔接不畅，项目进度的掌控困难 以上两条导致的项目/产品开发周期过长 药物原理： 目标驱动，在统一的软件交付目标下组织团队 依靠团队的智慧做项目评估、计划乃至设计、开发、测试 抓住最基本的项目开发属性：周期 + 质量 软件开发周期与质量的关系 资源一定的情况下，软件开发周期跟质量相互制约，但不是反比 以T代表某个项目的开发时间，B代表项目的Bug数（类比质量），不同团队执行该项目的T*B值是一个区间 良好团队就是尽可能保证T*B的值尽量小，挖掘可能空间的潜值 Scrum有助于塑造良好团队，降低项目的T*B值 Scrum是一味药，仅此而已 硝烟中的Scrum—从哪里开始 我们才刚上路 Scrum角色和职责 产品负责人 – 定义开发目标，需要实现的feature和优先级 Scrum Master – 保证团队高效而不受打扰地工作，优化工作条件、过程 团队 – 自组织地完成项目开发，使用一切可行手段保证进度和质量 Scrum过程 前期：产品负责人整理业务需求，形成Product Backlog库 执行：以Sprint为单位迭代式地完成Sprint Backlog。每个Sprint以Sprint Planning开始，通过每日例会跟踪进度和issue。Sprint结束时交付可运行的产品 后期：每个Sprint完成后，通过Sprint回顾发现问题和改进点，制定下个Sprint要引入的新的实践 看上去没什么特别？别着急，我们来看Scrum的精髓---- Scrum是一个“检查并适应”的框架，在三个角色（产品负责人/Scrum Master/团队）、三种仪式（Sprint计划/Sprint回顾/每日例会）和三种制品（产品Backlog/Sprint Backlog/燃尽图）的基础上，你可以根据公司或者项目的情况，因地制宜引入任何有利于缩短开发周期、提高产品质量的