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