轻松敏捷开发流程之Scrum.ppt

Wiki wiki，一起 Scrum 开发部 /设计组 /John.lee 2011/05/12 我们熟悉的瀑布 优 可按阶段划分 优 只需关注后续 优 可分迭代运行 缺 缺乏反馈 缺 完成时才能看结果 缺 不适应需求变化 缺 有强制完成日期 你找到不同之处了吗？ Scrum是一种迭代式增量软件开发过程 敏捷宣言 个体和交互 胜过 过程和工具 1 可以工作的软件 胜过 面面俱到的文档 2 客户合作 胜过 合同谈判 3 响应变化 胜过 遵循计划 4 3 4 2 1 一个小故事 鸡：我们合伙开饭店吧！ 猪：那我们卖什么？ 鸡：鸡蛋和火腿吧！ 猪，摇摇头：我 全身 投入，而你只是 参与 而已。 VS 谁是 “ 猪 ” ，我吗？ PO Master 产品负责人 团队主管，不 是团队领导 “猪” 我的团队，我 们做主 Team 猪类人员是 全身心投入 的人。 PO是干什么的？ 负责维护产品 BackLog的人 代表利益相关者的利益 决定发布的日期和发布内容 每个 Sprint，根据需要调整功能和优先级 为产品的 ROI负责 接受或拒绝团队工作成果 什么是 Master？ 为 Scrum过程负责的人 确保 Scrum的正确使用 使得 Scrum的收益最大化 保证团队成员不被外界力量所影响。 保证各个角色及职责的良好协作。 Team，我们最关注 由 59人组成 拥有高度自组织能力 都具有跨职能能力 必须是全职的 构成在 Sprint内不许变更 每人都对团队负责 每个人都很重要 谁是 “ 鸡 ” ，他吗？ 鸡角色并 不是 实际 Scrum过程的一部分，但是 必须考 虑 他们。 鸡 是干什 么 的？ 反 馈 信息 反 馈 用 户 用 户 需求，以便 项 目 满 足客 户 需求。 计划 帮 助 对 下一 个 sprit进 行 计 划 ，希望 拥 有某些功能。 评审 对 每 个 sprit内 容 进 行分析 建 议 。 Scrum会议 每一个迭代评审时都能交付可运行的产品。 1、产出产品 BackLog 2、对项目大概描述 1、细化每个 sprint要做的事情 2、排出迭代优先级 3、团队成员选择喜欢的任务 1、昨天完成了什么 2、今天准备做什么 3、昨天到今天遇到了什么困难 1、 sprint结束后召开 2、自我改进的回忆 1、 sprint结束前召开 2、为 PO演示 Sprint内容 3、接受评价 项目启动 Sprint回顾 Sprint计划 每日站会 Sprint评审 Scrum文档 产品 BackLog 困难 BackLog 文档 A B 燃尽图等 D 迭代 BackLog C 项目运行过程中， 遇到的困难与阻力。 一个公开展示的图表， 显示当前冲刺中未完 成的任务数目 。 整个项目的概要文 档，开放的，可编 辑的，天为单位。 项目的详细文档， 以小时为单位，每 个任务不得超过 16 个小时。 回顾 PO在项目启动前做 好 Product Backlog 团队与 PO在每个 Sprint 开始前制定好 Sprint的任 务与优先级 进入 Sprint，按照预定计划执行， 在 Sprint结束前给 PO演示可交 付功能，并在结束后做 Sprint回 顾。 每日站会，找出当前 计划困难所在，并以 团队的力量解决之 一个可交付的产品 20%的时间完成 80%的产品价值 执 行 多 个 迭 代 我的 Scrum 整理需求 搜集需求 Sprint 体会 门户项目 Share Point QQ 空间 IBM Oracle 利用 MindManager归纳出各大门 户系统的功能与它的分支节点。 以图文并茂的形式，将原形展 现，以便分析时理解。 注意名词解析，以便他人理解。 我的 Scrum 搜集需求 Sprint 体会 整理需求 整理好梗概 归纳总结形成 潜在需求 以问卷的形式 进行需求调查 确立产品 Backlog 调查问卷 注意事项 1、问题不能有歧义，并且不宜过长。 2、问题内容不能有多个，即一问一答。 3、正反两问必须表达同一个意思。 4、确立问卷对象角色，以对象位置视角出发 5、术语解析，深入浅出 我的 Scrum 搜集需求 Sprint 体会 整理需求 完善 Product Backlog 1、分析故事情景，并归类 2、给故事情景估计故事点 3、分析项目工作时长 项目启动 1、 PO确定 Product Backlog的情景优先级 2、给出期望。 我认为我们存在的缺陷： 1、 Product Backlog并非 PO负责维护； 2、调查问卷对象过于狭窄； 3、调查问卷不规范； 3、启动会议没有 “ 鸡类 ” 人员参与； 4、故事情景未安排堆栈优先级； 5、故事点评估不够成熟。 我的 Scrum 搜集需求 整理需求 体会 Sprint Sprint计划 1、团队成员分析细化故事情景。 2、团队成员作下承诺某个时间内完成某项任务。 我认为我们存在的缺陷： 1、并非产品负责人讲解需求，更像 master在讲解； 2、团队成员讨论任务时常跑题； 3、似乎未发挥每个成员喜欢什么做什么的 Scrum特点； 4、对任务划分经验不足，导致故事点完成数波动大； 我的 Scrum 搜集需求 整理需求 体会 Sprint 每日站会 1、上次站会到这次站会干了什么？ 2、这次站会到下次站会要干什么？ 3、上次站会到这次站会，你遇到了什么困难？ 我认为我们存在的缺陷： 1、站会中不像成员对团队汇报，更像对 master汇报； 2、站会缺少书记员； 3、站会提出的困难缺少总结与归纳，避免下次出现类似困难； 4、困难 Backlog机制未能成形。 我的 Scrum 搜集需求 整理需求 体会 Sprint Sprint评审 1、演示本次 Sprint完成的内容； 2、 PO对内容进行评审并给出意见； 3、将 PO的意见列入下一个 Sprint的开发计划。 我认为我们存在的缺陷： 1、没有 “ 鸡类 ” 人员参与； 2、没有较好的演示机制，例如演示的 Excel或 PPT。 我的 Scrum 搜集需求 整理需求 体会 Sprint Sprint回顾 1、自我审查； 2、自我改进； 3、没有 “ 鸡类 ” 人员参与。 我认为我们存在的缺陷： 1、缺乏个人对自己上个 Sprint的反省； 2、如果有日常的站会笔记，此时则可被总结归纳，并作备案。 我的 Scrum 搜集需求 整理需求 Sprint 体会 1、过少的 “ 鸡类 ” 人员参与的敏捷项目，容易与客户脱轨。 2、 Scrum应该是快乐的并富有激情的，是不易让人感觉到疲惫的开发流程， 但是经过几个 Spint下来，我觉得天天都好累，是我出了问题还是 Scrum在 说谎？ 3、团队成员沟通方面仍有待提高， PO与团队其他成员貌似脱节了，我记得 只有在评审与回顾时， PO才悄然出现，我认为是不够的。 4、团队成员受到外力影响了吗？答案是肯定的。 5、我太懒了，懒得去写单元测试，我太笨了，不会弄 JS的单元测试，我太 傻了，为什么天天加班？ 6、没事多反思，始终会进步的。 芝麻开花节节高 Scrum就是芝麻开花。 完成一个 Sprint就开一朵。 最终灿烂如天上的白朵朵。 感谢阅读！ 沙扬娜拉。