敏捷开发scrum介绍.pptVIP

特性看板图 概念 流程 实践 总结 表情日历（Niko-niko Calenda） 概念 流程 实践 总结 任务看板与燃尽图结合 概念 流程 实践 总结 评审会议 　根据团队这次 Sprint 所发布的版本，评审相关的 Backlog 中的问题，检查是否已达到Sprint 的目标 概念 流程 实践 总结 回顾会议 概念 流程 实践 总结 障碍 Backlog?十大典型障碍 会议规则没能被遵循 产品远景和 Sprint 目标不清晰 没有产品负责人负责回答提问 产品 Backlog 未能按商业价值区分优先级 并不是所有负责交付产品的人员都是团队里的成员 Scrum Master 还要处理其他任务，不能集中精力 团队人数过多（多于7个开发人员） 团队没有能坐在一起工作的空间 团队的 Sprint Backlog 混乱 概念 流程 实践 总结 软件推荐：TRICHORD 概念 流程 实践 总结 Scrum是一味药，仅此而已 Scrum不能解决我们的问题，能解决问题的是我们自己 Scrum提供了一套实践方法，帮软件开发团队养成良好的习惯 概念 流程 实践 总结 实施Scrum—归纳用到的实践 实践 参与角色 目的/好处 注意事项 Backlog 产品负责人 以简单的、面向目标的方式描述需求 愿景比需求细节更重要，团队需要知道为什么做而不光是做什么 Sprint会议 产品负责人 Scrum Master 团队 集中沟通需求细节，用团队的智慧制定Sprint计划 控制会议时间，安排茶歇时间，分支话题另行安排讨论，所有人都参与进来 任务墙 Scrum Master 团队 使项目任务可视化 任务单位以小于等于1天为宜 每日例会 Scrum Master 团队 更新进度，发现问题 控制时间为10-15分钟，站立会议 概念 流程 实践 总结 实践 参与角色 目的/好处 注意事项 Backlog演示 产品负责人 QA 团队成员 检查产品是否达到需求要求和测试要求 建议在QA测试环境进行 Sprint回顾 产品负责人 Scrum Master 团队 总结经验教训，反馈到后面的Sprint，持续改进工作方法 头脑风暴的方式，轻松的讨论氛围，每次选中小于5个的问题进行解决 Tech Show 团队 团队技术交流 短时间，高频率 守门员 团队 为团队成员创造安静的工作条件，增加对工作的focus程度 团队成员轮流做守门员，逐渐培养每个人对问题的解决能力 概念 流程 实践 总结 实践 参与角色 目的/好处 注意事项 Double Check 团队成员 交叉检查项目制品是否达到要求 关键制品如设计文档、核心代码、Release Notes等必须Double Check Checklist Scrum Master 团队 总结记录经验教训，作为后续项目的检查项 解决问题后及时更新 概念 流程 实践 总结 其他更高的实践一览 实践 参与角色 目的/好处 注意事项 单元测试 团队成员 采用测试优先的方式保证代码质量 结对编程 团队 提高设计和代码质量，经验共享，加强合作 任务纸牌 团队 Scrum Master 增加任务评估的客观性 概念 流程 实践 总结 附：《敏捷宣言》 个体与交互 胜过 过程和工具可用的软件 胜过 完备的文档客户协作 胜过 合同谈判响应变化 胜过 遵循计划? 在每对比对中，后者并非全无价值，但我们更看重前者。 附：《敏捷宣言》的12准则 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。 项目过程中，业务人员与开发人员必须在一起工作。 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。 可用的软件是衡量进度的主要指标。 敏捷过程提倡可持续的开发速度。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。 不断关注优秀的技能和好的设计的将提升敏捷能力。 要做到简单，即尽最大可能减少不必要的工作。这是一门艺术。 最佳的架构、需求和设计出自于自组织的团队。 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。 参考资料 Scrum的核心价值观是：承诺、专注、公开、敬重和勇气。 它提倡自我管理、涌现机制、可视性和评估/适应循环的根本原则。?? 敏捷方法尊重人性，强调效率 * * Scrum的核心在于迭代，整个过程只有三个角色。产品负责人的职责是利用产品backlog，督促团队优先开发具有价值的功能，并在其基础上继续 开发。产品负责人