禅道使用总结ppt
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
-
说明：
1、产品负责人负责整理user story，形成左侧的product backlog。 2、发布计划会议：product owner负责讲解user story，对其进行估算和排序， 发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。 3、迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成 该story的所有任务，终每个任务都有明确的负责人，并完成工时的初估计。 4、每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今 天计划做什么，有什么问题。 5、演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责 向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成 新的story。 6、回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一 次迭代继续改进，已达到持续改进的效果。
-
选择禅道的理由
一、遇到的问题：
1、工作无记录、无明确输出或输出的工件不 受控，知识不能被积累，造成非常大的浪费。 2、无专业的测试管理工具，bugfree只适合做 缺陷管理，且不能对测试用例进行管理，需要 使用额外的工具管理用例，且无法与需求进行 关联。 3、版本发布后不方便与测试用例关联，导致 测试不充分、漏测等情况- 出现。
-
悲催的，纠结的
• 项目经理 • 开发人员 • 测试人员 • 产品经理
-
一切都源自于混乱
• 混乱的战略 • 混乱的组织结构 • 混乱的产品和需求 • 混乱的项目流程 • 混乱的代码 • 混乱的程序结构 • 混乱的测试 • 混乱的客户 • 混乱的时代 • 混乱的地球
-
2、解决方案
让我们来看下敏捷是如何在混乱中建立秩序的...
-
形成节奏，节奏产生效率(周期)
• 通过小步快跑的方式，建立产品、研发、客户、市场的节奏。 • 时间片管理。 • 节奏可以产生效率。 • 节奏可以带来预期。 • 节奏可以带来信任。 • 节奏可以带来创新。
-
持续改进研发过程和实践(过程)
• 定期总结和反馈，每一轮迭代都改进一点。 • 持续的改进软件的架构，找到最佳解决方案。 • 简洁实现。 • 事情做得很复杂很容易，但做得很简单很难。
禅道使用总结
-
目录
• 一、为什么使用禅道
•1、遇到的问题 •2、解决方案
• 二、怎么使用禅道
•1、预备知识 •2、现场演示Baidu Nhomakorabea
-
一、为什么使用禅道
• 遇到了问题！！！
-
作为项目经理，您是否有如下的感觉？
• 一头是老板，一头是团队，既要对老板负责，又要对团队负责， 压力重大。
• 项目马上就结束了，但还有很多功能没有实现，还有一堆bug没 有解决。
√
×
√
√
√
√
√
Project （单机）
× × √ √ × √ √ —— √ × × × ×
二、怎么使用禅道
-
预备知识
产品需 求储备
每日 站会
SCRUM
具备商业价 值的产出
概述： 优势：
迭代需 求储备
迭代
以最快的速度完成核心功能（最有价值的功能），在此基础上进行完善。
1、软件在开发过程中不可见，能给投资人和开发团队带来信心。 2、项目意外中止（如撤资、开发团队散伙等），投资人可以得到具备商业价值的产品。
-
作为测试，您是否有如下感觉呢？
• 天啊，明天就上线了，代码还没有提交呢。 • 天啊，开发的bug也太多了。 • 天啊，要测WIN7、WIN8、WIN8.1、WIN10、中文版、英文版、葡
语版、32位、64位... • 天啊，我还有那么多测试用例没有跑呢。 • 天啊，测试需求又变更了，之前写的用例没用了。 • 天啊，我一个人对付5个开发...... • 天啊，线上又出bug了，又要挨训了。 • 天啊，我还要负责过程改进，还要监督流程。 • ......
-
和客户沟通合作(客户)
• 有谈判，更要有合作。 • 面对面改成背靠背。 • 挖掘客户真正的需求。 • 现场客户。 • 客户的反馈是调整我们前进路线的最佳指导。
-
简言之，分之而后治之
• 将复杂的产品分解为一个个的用户故事 • 将复杂的团队分解为一个个的敏捷团队 • 将长期的研发过程分解为一次次的冲刺 • 将复杂的程序分解为一个个的对象，方法，用例 • 将长期的战斗分解为一次次的小进步，小胜利 • 分之而后明之，明之而后有序，有序则治也
选择禅道的理由
二、禅道的优势
•1、功能全面
项目管理、任务管理、缺陷管理、需求管理、文档管理…
•2、规范
为整个项目开发周期提供了控制流程，且能够将项目相关 的工件进行有机组合，方便统一管理。
•3、开源
开源版本免费，允许二次开发
•4、美观
个人爱好
•5、配置简单
-
功能类别 制定项目计划
控制项目进展 执行项目规范
高的工资。 • 我是不是该考虑下逃离北上广了？
-
作为产品经理，您是否有如下感觉？
• 为什么开发连这么简单的功能都做不出来。 • 为什么我的需求开发和测试都理解偏差了呢? • 为什么上线会出那么多的bug? • 为什么开发做出来的东西和我预期的总是有很大差距？ • 为什么我要的东西总是会延期？ • ....
-
精简金字塔式管理，实现自我管理团队(团队)
• 研发类团队有其特殊性，个体的因素起着非常关键的作用。不能 按照工程类项目管理方式来管理。
• 过分强调控制，势必会产生各种各样的流程和检查。 • 完全没有控制，就放羊了。 • 放而不乱。 • 每个敏捷团队(5-9人)都很健康，积极，整个公司也会好。 • 借助群体的力量提升个体的技能和效率。
-
将庞杂的产品细分成若干小型版本(产品)
• 将庞杂混乱的产品细分成若干小型发布。 • 曳光弹。 • release offen, release early。 • 完成比完美更重要 • 在全部必要的功能全部实现之前，你我所实现的再重要的功能都
无人买单，无法体现其价值 • 我们购买到的其实都是不完整的产品，即使是ipad, iphone.
• 团队里面总是有那么一两个刺头。 • 资源总是那么紧张。 • 产品经理又变更需求了。
-
作为研发人员，您是否有如下感觉呢？
• 天啊，需求又变更了。 • 今天晚上又要加班了，唉，老婆又要抱怨了。 • 该死的浏览器，该死的ie，该死的微软。 • 我想学点新东西，没时间啊。 • 测试的人也太bt了，老挑我毛病。 • 项目经理啥都不懂，在那儿装。 • 填完日报填周报，有啥用？ • 我是不是该考虑考虑跳槽了？其他人都拿着比我
禅道 VS TFS
工具名称
功能明细
实现方法
明确项目范围
需求评审
确立项目质量
编写测试用例
估算项目成本
人力资源成本 其它成本
需求分解
制定工作计划
版本规划
制定任务
搭建项目开发环境
——
生成报表
进度管控
组织培训
组织讨论
流程管控 文档管理
流程/审批
文件归档 -
禅道
TFS
√
√
√
√
√
√
×
×
√
√
√
√
√
√
——
——
√
√
×
说明：
1、产品负责人负责整理user story，形成左侧的product backlog。 2、发布计划会议：product owner负责讲解user story，对其进行估算和排序， 发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。 3、迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成 该story的所有任务，终每个任务都有明确的负责人，并完成工时的初估计。 4、每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今 天计划做什么，有什么问题。 5、演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责 向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成 新的story。 6、回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一 次迭代继续改进，已达到持续改进的效果。
-
选择禅道的理由
一、遇到的问题：
1、工作无记录、无明确输出或输出的工件不 受控，知识不能被积累，造成非常大的浪费。 2、无专业的测试管理工具，bugfree只适合做 缺陷管理，且不能对测试用例进行管理，需要 使用额外的工具管理用例，且无法与需求进行 关联。 3、版本发布后不方便与测试用例关联，导致 测试不充分、漏测等情况- 出现。
-
悲催的，纠结的
• 项目经理 • 开发人员 • 测试人员 • 产品经理
-
一切都源自于混乱
• 混乱的战略 • 混乱的组织结构 • 混乱的产品和需求 • 混乱的项目流程 • 混乱的代码 • 混乱的程序结构 • 混乱的测试 • 混乱的客户 • 混乱的时代 • 混乱的地球
-
2、解决方案
让我们来看下敏捷是如何在混乱中建立秩序的...
-
形成节奏，节奏产生效率(周期)
• 通过小步快跑的方式，建立产品、研发、客户、市场的节奏。 • 时间片管理。 • 节奏可以产生效率。 • 节奏可以带来预期。 • 节奏可以带来信任。 • 节奏可以带来创新。
-
持续改进研发过程和实践(过程)
• 定期总结和反馈，每一轮迭代都改进一点。 • 持续的改进软件的架构，找到最佳解决方案。 • 简洁实现。 • 事情做得很复杂很容易，但做得很简单很难。
禅道使用总结
-
目录
• 一、为什么使用禅道
•1、遇到的问题 •2、解决方案
• 二、怎么使用禅道
•1、预备知识 •2、现场演示Baidu Nhomakorabea
-
一、为什么使用禅道
• 遇到了问题！！！
-
作为项目经理，您是否有如下的感觉？
• 一头是老板，一头是团队，既要对老板负责，又要对团队负责， 压力重大。
• 项目马上就结束了，但还有很多功能没有实现，还有一堆bug没 有解决。
√
×
√
√
√
√
√
Project （单机）
× × √ √ × √ √ —— √ × × × ×
二、怎么使用禅道
-
预备知识
产品需 求储备
每日 站会
SCRUM
具备商业价 值的产出
概述： 优势：
迭代需 求储备
迭代
以最快的速度完成核心功能（最有价值的功能），在此基础上进行完善。
1、软件在开发过程中不可见，能给投资人和开发团队带来信心。 2、项目意外中止（如撤资、开发团队散伙等），投资人可以得到具备商业价值的产品。
-
作为测试，您是否有如下感觉呢？
• 天啊，明天就上线了，代码还没有提交呢。 • 天啊，开发的bug也太多了。 • 天啊，要测WIN7、WIN8、WIN8.1、WIN10、中文版、英文版、葡
语版、32位、64位... • 天啊，我还有那么多测试用例没有跑呢。 • 天啊，测试需求又变更了，之前写的用例没用了。 • 天啊，我一个人对付5个开发...... • 天啊，线上又出bug了，又要挨训了。 • 天啊，我还要负责过程改进，还要监督流程。 • ......
-
和客户沟通合作(客户)
• 有谈判，更要有合作。 • 面对面改成背靠背。 • 挖掘客户真正的需求。 • 现场客户。 • 客户的反馈是调整我们前进路线的最佳指导。
-
简言之，分之而后治之
• 将复杂的产品分解为一个个的用户故事 • 将复杂的团队分解为一个个的敏捷团队 • 将长期的研发过程分解为一次次的冲刺 • 将复杂的程序分解为一个个的对象，方法，用例 • 将长期的战斗分解为一次次的小进步，小胜利 • 分之而后明之，明之而后有序，有序则治也
选择禅道的理由
二、禅道的优势
•1、功能全面
项目管理、任务管理、缺陷管理、需求管理、文档管理…
•2、规范
为整个项目开发周期提供了控制流程，且能够将项目相关 的工件进行有机组合，方便统一管理。
•3、开源
开源版本免费，允许二次开发
•4、美观
个人爱好
•5、配置简单
-
功能类别 制定项目计划
控制项目进展 执行项目规范
高的工资。 • 我是不是该考虑下逃离北上广了？
-
作为产品经理，您是否有如下感觉？
• 为什么开发连这么简单的功能都做不出来。 • 为什么我的需求开发和测试都理解偏差了呢? • 为什么上线会出那么多的bug? • 为什么开发做出来的东西和我预期的总是有很大差距？ • 为什么我要的东西总是会延期？ • ....
-
精简金字塔式管理，实现自我管理团队(团队)
• 研发类团队有其特殊性，个体的因素起着非常关键的作用。不能 按照工程类项目管理方式来管理。
• 过分强调控制，势必会产生各种各样的流程和检查。 • 完全没有控制，就放羊了。 • 放而不乱。 • 每个敏捷团队(5-9人)都很健康，积极，整个公司也会好。 • 借助群体的力量提升个体的技能和效率。
-
将庞杂的产品细分成若干小型版本(产品)
• 将庞杂混乱的产品细分成若干小型发布。 • 曳光弹。 • release offen, release early。 • 完成比完美更重要 • 在全部必要的功能全部实现之前，你我所实现的再重要的功能都
无人买单，无法体现其价值 • 我们购买到的其实都是不完整的产品，即使是ipad, iphone.
• 团队里面总是有那么一两个刺头。 • 资源总是那么紧张。 • 产品经理又变更需求了。
-
作为研发人员，您是否有如下感觉呢？
• 天啊，需求又变更了。 • 今天晚上又要加班了，唉，老婆又要抱怨了。 • 该死的浏览器，该死的ie，该死的微软。 • 我想学点新东西，没时间啊。 • 测试的人也太bt了，老挑我毛病。 • 项目经理啥都不懂，在那儿装。 • 填完日报填周报，有啥用？ • 我是不是该考虑考虑跳槽了？其他人都拿着比我
禅道 VS TFS
工具名称
功能明细
实现方法
明确项目范围
需求评审
确立项目质量
编写测试用例
估算项目成本
人力资源成本 其它成本
需求分解
制定工作计划
版本规划
制定任务
搭建项目开发环境
——
生成报表
进度管控
组织培训
组织讨论
流程管控 文档管理
流程/审批
文件归档 -
禅道
TFS
√
√
√
√
√
√
×
×
√
√
√
√
√
√
——
——
√
√
×