资源预览内容
第1页 / 共43页
第2页 / 共43页
第3页 / 共43页
第4页 / 共43页
第5页 / 共43页
第6页 / 共43页
第7页 / 共43页
第8页 / 共43页
第9页 / 共43页
第10页 / 共43页
亲,该文档总共43页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
禅道 * 项目管理系统使用方法李玮 兄弟软件www.vrBrothers.comBugFree 系统有什么不好?缺乏项目管理的功能什么叫项目管理系统?项目的管理者使用的软件系统。在有限的资源约束 下,运用系统的方法和理论,对项目设计的工作进 行有效管理。从项目的决策开始,到项目结束的全过程,以实现 项目的目标。简而言之,少花时间少用人,保证质量出产品。项目管理系统的基本特征 关注项目而不是关注事情 (Bug) 项目和 Bug 是有层次关系的 2 个概念。只面对 Bug 会导致思维的混乱、跳 跃、缺乏对项目的整体控制。 预算及成本控制 打算投入多少人,花多少时间完成项目? Bugfree 没这个功能。用 Project 做甘特图?天!做过就知道多费劲。要敏捷! 日程表 每天或每周应该做什么事情? 资源管理 公共资源部门如何能得到最高效的调用?大家都在抢程序、抢视觉,他们除 了加班还有别的活路吗? 有计划的实施项目 核心精髓,管理者必须清楚自己想做什么。你都不清楚? 项目监督与跟踪 哪个环节拖累了整体进度?如何快速的进行干预,调整计划?目前我们工作中存在的问题 有项目的意识,但缺少管理项目的手段 按键精灵 8.2 版的发布是一个项目。这个版本需要解决哪些需求?哪些 人需要参与?总共预计要花多少时间?目前的 Bug 系统无法满足要求需求和缺陷 (Bug) 混淆在一起 需求指的是用户希望新增的功能,而 Bug 指的是已经发布的版本存在的 不足。这是 2 个概念,但在 Bug 系统中并未区分。 导致:一些来自用户的需求没有记录,不被重视; Bug 无法对应版本。没有集成测试功能 曾经出现过的 Bug 屡次重复出现,单纯依靠测试文档无法提高测试 效率,也容易漏测高危问题。 新版改动之后,测试人员不知道改动会影响什么内容,测试无从下手。希望:最好将测试、需求、开发集成到同一个界面中。为什么要引入项目管理系统?管理项目更清晰 从关注 20 个单子 - 关注 3 个项目人员、时间分配更合理项目负责人可多些时间来喝茶禅道= 项目管理系统禅道项目管理系统 (ZenTaoPMS) 是一款国产项目 管理软件,它集产品管理、项目管理、测试管理于 一体,同时还包含了事务管理、组织管理等诸多功 能,是中小型企业项目管理的首选。更重要的,他是 Bugfree 作者亲手打造的升级版产品1 、创建产品2 、为产品创建模块、计划。3 、为模块和计划创建需求。4 、创建项目5 、项目关联产品、需求。6 、划分需求给成员。7 、完成 Build (里程碑)。8 、针对 Build 进行测试9 、修复 Bug 重新开发、测试。10 、发布稳定版本。所有的管理都是围绕产品展开。产品管理的核心是需求。需求= 用户故事。像讲故事一样描述一个需求。 作为一名 ,我希望 ,这样可以 。计划主要是给产品人员规划需求使用。它和实际的 项目没有直接的对应关系。一个项目中做的需求可 能和计划完全一样,也有可能涉及多个计划。一个计划可以关联许多需求一个计划可以关联许多需求内部发布、外部发布、正式发布已经发布的版本加上未来的 plan ,构成产品路线 图。计划主要是给产品人员规划需求使用。它和实际的 项目没有直接的对应关系。一个项目中做的需求可 能和计划完全一样,也有可能涉及多个计划。build 是在项目过程中产生的,主要用来测试使用。 build 是对内的。经过若干项目之后,产品人员可以选择发布一个版 本,发布是对外的。而且发布肯定和一个 build 对 应。已经发布的版本加上未来的 plan ,构成产品的路 线图。 项目产品禅道里面的项目的概念,还原为原原本本的项目的 概念,就是固定人,在固定的时间里面,做固定的 事情。产品是通过实施项目来实现的,项目是实现 产品的过程,项目的产出是产品。产品是产品,项 目是项目,不要将二者混为一谈。项目代号也是隐喻,可以用一个大家商定的名称来 作为团队成员内部的称呼。团队名称,可以自己定义,比如叫做南山七匹狼, 东海大鲨鱼,之类。一个项目的启动是由许多个需求组成的。关联需求的过程,是对 产品中的需求列表进行排序的过程,也是项目团队达成契约的过 程。项目中的需求列表是产品视图中的需求列表的子集。在分解任务的时候,需 要注意几点: 任务分解尽量细致。分解 的任务,应该是一个人可 以独立完成,最好在 4- 16 小时之间。 任务分解应该完整,比如 搭建测试环境,购买机器 之类的看似无关的任务, 也都应该列入任务列表。 任务的分派,应当由团队 成员自愿认领为主,不要 硬性指派。 任务类型应该认真选择, 这关系到相关需求所处阶 段的自动计算。每天需要更新自己的任务。最初预计,即创建任务的时候的最初预计。该 字段在任务开始之后,不应该再进行修改。这 个字段当任务结束之后,可以和已经消耗字段 进行对比,以纠正自己的估计。 已经消耗,则是你在这个任务上所有花费的工 时数。 预计剩余,则是你预计这个任务完成大约还需 要多少时间。如果预计剩余为 0 ,则表示任务 完成。 这里面需要特别强调的是, 最初预计已经消耗+ 预计剩余。 一定要每天更新自己所负责的任务,因为燃 尽图的绘制,就是通过预计剩余这个字段来 计算的。工时管理是提高工作效率的重要手段。系统通过定时任务,自动计算项目中所有未完 任务预计剩余时间之和,画出曲线图。燃尽图 可以告诉我们很多东西。在项目开发过程中,如果有若干功能已经开发完 毕,需要提交测试,这是应当创建一个 build ,然 后提交给 QA 进行测试。后续的 bug 管理和测试 任务管理都应当基于一个 build 展开的。源代码地址可以给出 svn 的存储路径或者其他版 本控制系统的路径。如果没有源代码地址,需要给出 build 包的存储地 址。在项目开发过程中,如果有若干功能已经开发完毕 ,需要提交测试,这是应当创建一个 build ,然后提 交给 QA 进行测试。后续的 bug 管理和测试任务管 理都应当基于一个 build 展开的。源代码地址可以给出 svn 的存储路径或者其他版本 控制系统的路径。如果没有源代码地址,需要给出 build 包的存储地址 。测试用例有自己单独的模块划分,独立于产品视图 中的模块划分。为什么独立开?是因为使用角度不同,产品视图中 的模块是给产品人员使用的,而测试用例模块是为 了维护用例使用的。目前 QA 使用的较少,不展开讲述产品经理 将产品分解为多个项目,并组建项目团队项目组长 协调产品人员、开发人员、测试人员完成项目。将 项目与需求绑定,并将需求分解为任务。 - 任务的具体实施 -产品人员:负责产品管理开发人员:负责产品研发测试人员:负责产品测试小型团队,每个人可能承担多个角色。所有的一切最终体现在每一个人每天的行动上面。我的地盘中列出了需要自己处理的任务、需 求、 bug 等。还可以通过 todo 来管理自己每天的日程。todo 类型分为三种,一种是和项目任务关联,一种 是和 bug 关联,还有一种是自定义。这样可以将项目中的任务或者 bug 转换为每天的 todo 。Todo 就是计划要做的事情很明确的知道自己目前参与了几个项目很明确的知道当前做的任务是为什么项目服务工作更有计划性,效率更高,不用加班啦每天碰头,增进感情减少做错事的可能性(曾经失败的案例,几天没问,思路完全做歪-_- )工时的管理让做事更有时间观念项目被卡住了吗?一定能及时发现预定的项目发布时间,得到了更多的保障1 、整理需求 原来的需求都跑到了 BUG 里。如果一个 BUG 本应 该是需求,那么需要将 BUG 关闭,整理后到需求 当中。 2 、建立项目 根据需求建立项目 3 、讨论项目,任务分工任何产品都有 BUG ,禅道是一个新的产品,但经 过我的评估,他带来的效率提升将可以弥补他的不 足。相信禅道,学习禅道,提高效率!
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号