《Scrum漫谈-入门教程》由会员分享，可在线阅读，更多相关《Scrum漫谈-入门教程（55页珍藏版）》请在金锄头文库上搜索。
1、Scrum漫谈 马骁驰 网名 三马 ThinkInLAMP社群2010 4 Scrum是什么 Scrum是英语中橄榄球运动的一个专业术语 表示 争球 特指一种敏捷开发的模型 敏捷是什么 是一种从90年代开始逐渐引起广泛关注的一些新型软件开发方法 XP ExtremeProgramming Scrum 为什么分享敏捷 非敏捷 瀑布式开发 软件开发的经典模型 瀑布模型的主要缺陷 程序的维护成本会越来越高 需要很多人 团队氛围压抑 感受不到激情 不方便做需求变更 引起客户不满 需求 设计阶段的问题 开发 维护阶段的问题 Scrum开发模型 Sprint流程图 产品需求 Imp 重要性 Est 大致相
2、当于一个 理想的人天 man day Sprint计划会议 计划会议要有足够的时间 最好至少8个小时取出部分产品需求做成sprint需求 并写成索引卡确定并细分每一个索引卡的故事 Story 进行工作认领 不是分配 确定每日站立会议的时间和地点确定好演示会议和回顾会议的日期 场景展示 索引卡 场景展示 计划纸牌 场景展示 故事看板 站立会议 10 15分钟迟到将接受惩罚自问自答三个问题昨天做了什么今天要做什么遇到了什么问题更新燃尽图 场景展示 每日站立会议 场景展示 燃尽图 Sprint开发周期 使用好任务看板需求 设计 开发 测试 维护注意燃尽图不要使用软件取代看板可以选择性的和XP的某些方
3、式结合测试驱动开发结对编程 场景展示 任务看板 场景展示 任务看板 演示会议 演示是跨团队的 会产生不同团队之间的交流不要关注太多的细节 以主要的功能为主让老板和客户看到非常的重要 绝对不可以被忽略 回顾会议 时间在1 3个小时找最舒适的地方 要有回顾看板 开始的时候轮流发言 而不是主动发言记录问题 总结 并讨论改进的方法 放在回顾看板上每人三个磁铁 将最重要的2 3个改进点 成为下一轮的产品需求 场景展示 回顾会议看板 回顾会议问题举例 我们应花更多时间 把故事拆分成更小的条目和任务我们办公室的环境太吵太混乱了我们做出了过度的承诺 最后只完成了一半工作 Scrum的主要缺陷 压力大不方便跨时
4、区 跨语言程序维护成本偏高无法被中断如何改善 结合XP 和客户坐在一起结对编程测试驱动开发 TDD 使用编码规范32小时工作制 结对编程 TDD和编码规范 下次分享 本PPT中没有提到的内容 Scrum中的角色 图书介绍 ScrumGathering上海演讲 Scrum在中国不管用 BasVoddeScrum和XP 神话 事实 怎样做 KaneMar技术卓越 它是什么和怎样能够做到 LasseKoskela敏捷在微软 成功的关键 MitchLacey健康的Scrum 敏捷的心跳 VernonStinebaker充满自信地每日发布软件版本 如何把接受性测试驱动开发与持续集成相结合提升您持续给客户
5、带来价值的能力 DouHanzhi QinZhiyuan怎样通过机遇工程 OpportunityEngineering 将Scrum的敏捷性和和创新潜力最大化 JulienMazloum DavidDu超越软件的Scrum 怎样在书籍翻译中成功运用敏捷思维和技巧 滕振宇 李国彪在大规模Scrum转换中的系统化思维 吕毅我已经没有银弹了 现在怎么办 徐毅敏捷估计2 0 BradSwanson 开始漫谈 Scrum对软件外包行业的影响 如何一步一步得在项目中引入Scrum 开源社区应当如何学习Scrum 谢谢 ThinkInLAMP 二 流程图 维护产品及模块一 如何来添加产品呢 让我们来看下步骤
6、 以管理员或者其他有产品管理权限的帐号登录 点击产品视图 在页面右侧 点击 新增产品 即可出来产品添加页面 第一次使用禅道 点击产品视图 会自动跳到产品添加页面 这里面 产品代号相当于大家对这个产品的一个隐喻 比如001 土豆之类 团队内部的人说起这个都是明白的 bug负责人 可以指定默认的bug负责人 这样可以适用于公司人比较多 提交bug不知道该给谁的情况 访问控制 则可以控制访问该产品的人员列表 二 设置模块添加完产品之后 就需要来设置产品的模块 模块相当于对产品需求的一个分类 通过组织模块 可以让大家对产品有一个宏观的把握和认识 也方便对需求进行分类和整理 设置模块的步骤 进入产品视图
7、 选择要维护的产品 点击菜单中的 模块维护 在这里面 可以维护某一个模块的子模块 可以编辑某一个模块 也可以删除 同时还可以维护模块的排序 建立计划具体的步骤 进入产品视图 选择某一个产品 点击 计划列表 出现计划列表页面 点击页面右侧的 创建计划 即可出现计划增加页面 在计划列表页面 可以查看该计划的所有需求 也可以通过 关联需求 来维护属于这个计划的需求列表 需求一 禅道中需求处理流程需求有一个状态 status 字段 总共有四种状态 分别是草稿 draft 激活 active 已变更 changed 和已关闭 closed 对应为需求的流程操作共有 创建 变更 审核 关闭 激活 需求还有
8、一个阶段 stage 字段 用来描述激活的需求在研发过程中所处的阶段 目前总共有等待 已计划 已立项 开发中 开发完毕 测试中 测试完毕 已验收 已发布 二 如何添加需求 进入产品视图 选择某一个产品 然后选择 需求列表 页面的 新增需求 链接 即可出现需求添加页面 创建发布添加需求的时候 注意的几个地方 优先级 必须要设定这个需求的优先级 预计工时 也就是对这个需求做一下估计 完成大约需要多少小时 单位是小时 估计不准也没有关系 关键是在这个过程 以避免产品人员不经过思考 随意添加需求的情况 由谁评审 如果公司里面的管理流程不需要评审 则可以勾选旁边的 不需要评审 复选框 需要评审的需求其状
9、态是草稿状态 进入产品视图 选择发布列表 然后点击 创建发布 即可出现创建发布的页面 其中的build 要选择相应的版本 描述里面 则可以描述此次发布解决的bug 新增的功能等等 路线图路线图 顾名思义 给大家一个发展的方向和指引 不过说实话 现在市面上的项目管理软件中提供的路线图 我基本上都没有看明白 所以在禅道中 路线图和其他软件里面的路线图的概念和展示也有不同 在禅道中 路线图由发布和将来的计划组成 如果一个计划已经过期了 就不再显示了 路线图的展示形式如下 其中绿色的部分 表示已经发布的版本 而棕色的部分 则表示是将来的计划 点击某一个计划或者是发布 可以查看相应的需求列表 需求统计报
10、表针对一些公司需要对产品需求进行统计的情况 禅道项目管理软件从2 0版本开始 提供了需求的基本统计报表功能 在产品视图下的需求子栏目 点击 统计报表 链接 即可根据需要进行需求的统计 包括 1 产品需求数量 2 模块需求数量 3 按照计划进行统计 4 按照状态进行统计 5 按照所处阶段进行统计 6 按照优先级进行统计 7 按照预计工时进行统计 8 按照由谁创建来进行统计 9 按照当前指派来进行统计 10 按照关闭原因来进行统计 11 按照变更次数来进行统计 根据版本号来进行计算 版本号 1为变更次数 组建团队 确定需求一 关联产品 二 关联需求 二 关联需求 三 注意事项 禅道是支持一个项目对
11、应多个产品的 但在实际项目管理中 不建议这样做 多个产品 会增加复杂程度 应尽量避免 可以尝试分解项目为多个项目来做 在实际操作中 可以尝试通过大屏幕投影来操作 一边演示 一边操作 分解任务具体步骤 进入项目视图 点击任务列表 然后选择新增任务 在分解任务的时候 需要注意几点 任务分解尽量细致 按照scrum的实践 分解的任务 应该是一个人可以独立完成 最好在4 16小时之间 任务分解应该完整 比如搭建测试环境 购买机器之类的看似无关的任务 也都应该列入任务列表 任务的分派 应当由团队成员自愿认领为主 不要硬性指派 任务类型应该认真选择 这关系到相关需求所处阶段的自动计算 项目进度然进图 维护bug视图模块提交bug验证bug 关闭找到自己需要的bug维护测试用例视图创建测试用例管理测试任务执行用例 并提交bug查看报表统计
