开源测试管理系统2(禅道).doc

以太项目管理规范1 系统介绍禅道项目管理软件(ZenTaoPMS)是一款国产的，基于LGPL协议，开源免费的项目管理软件，它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款功能完备的项目管理软件，完美地覆盖了项目管理的核心流程。1.1 基本功能1. 产品管理：包括产品、需求、计划、发布、路线图等功能。2. 项目管理：包括项目、任务、团队、build、燃尽图等功能。3. 质量管理：包括bug、测试用例、测试任务、测试结果等功能。4. 文档管理：包括产品文档库、项目文档库、自定义文档库等功能。5. 事务管理：包括todo管理，我的任务、我的Bug、我的需求、我的项目等个人事务管理功能。6. 组织管理：包括部门、用户、分组、权限等功能。7. 统计功能：丰富的统计表。8. 搜索功能：强大的搜索，帮助您找到相应的数据。9. 灵活的扩展机制，几乎可以对禅道的任何地方进行扩展。10. 强大的api机制，方便与其他系统集成。1.2 访问地址1:7777/zentaopms/www （临时地址）2 基本流程3 产品经理3.1 产品经理主要工作 3.1.1 创建产品产品管理对于公司来讲，至关重要。只有做出好的产品或者服务出来，才能赢得市场，谋求发展和生存。所以产品经理的这个位子对于公司来讲，是非常关键的，相当于公司的大脑，在决定着公司前进的方向。产品和项目这两个概念被明确的区分开来。产品是需求方，决定做什么。项目是执行方，解决的是如何做的问题。而测试则是保障方，解决的是正确的做事情的问题。所以在禅道中，所有的一切都是围绕产品展开的。产品是整个项目管理活动的核心。添加完产品之后，就需要来设置产品的模块。模块相当于对产品需求的一个分类，通过组织模块，可以让大家对产品有一个宏观的把握和认识，也方便对需求进行分类和整理。3.1.2 建立计划 产品需要做规划，才能有轻重缓急，才能正确的做事。因此对于产品经理而言，计划是必需的。在计划列表页面，可以查看该计划的所有需求，也可以通过“关联需求”来维护属于这个计划的需求列表。3.1.3 需求管理 需求管理在产品管理里面属于最核心的地方了，只有好的需求，正确的需求，才能保证最终产品的质量和竞争力。需求是源头，所以必须在源头就保证需求的合理和正确。 原型图、产品设计说明书（此处供参考）很多公司的产品人员都在用原型图软件设计原型图或者非常完整的产品说明书。写完之后，交给设计人员进行页面设计，然后由开发人员合并代码。和user story相比，原型图是一个整体，可以给人宏观的把握。这是原型图的优点。比较直观。但也有它的缺点。 l 它是一个整体，所以就没有办法进行分解。你不可能分解成，做页面导航条，做页面的中间部分等。 l 没有分解，所以原型图也就没有办法进行优先级的排序。比如页面部分，有的很重要，有的不重要。但在原型图里面是体现不出来优先级的。 l 没有分解，自然也就无法进行跟踪。你没有办法得知原型图完成了多少。 l 过于死板，给设计人员和开发人员留下的发挥的空间太少。 而在禅道里面则不同。禅道的管理理念是基于scrum的。scrum里面产品经理需要维护的是user story，或者叫做用户故事，但不是原型图或者说明书。在scrum中使用原型图或者说明书的话，产品经理可以在上面通过备注的形式进行标注，注明某一个区域的重要程度，注意事项等。当然最好的方式，还是将其拆解为user story。 需求的写法（此处供参考）在禅道中，我们默认给大家提供了一个需求（user story）的模板：作为一名，我希望，这样可以。很多公司的产品经理所设计的需求，其实是设计给他心中所设想的那一个用户。在他的世界里面，整个产品就是为一个用户准备的。其实这就大错特错了。 而禅道提供的这个模板，则强迫你去设想这个需求所代表的用户是谁，这样你在写需求的时候，就可以设身处地的来思考问题。这样写出来的需求才更加合理。我希望达成的某些目的，就是需求要做的事情，这个没有什么问题。所有的需求，这个是必须的。但大家往往忘记的是后面的目的或者价值所在。也就是为什么要做这个需求。在我之前的工作经历中，产品经理往往过于强势，不给开发团队解释这个需求的目的是什么，更不要说这个需求所代表的用户是谁了。这样需求在开发和测试的时候，往往会出很多的问题。 禅道中需求处理流程需求有一个状态(status)字段，总共有四种状态，分别是草稿(draft)、激活(active)、已变更(changed)和已关闭(closed)。对应为需求的流程操作共有：创建、变更、审核、关闭、激活。需求还有一个阶段(stage)字段，用来描述激活的需求在研发过程中所处的阶段。目前总共有等待、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。3.1.4 建立发布 某一期的项目结束日后，如果这一期的版本可以对外发布的话，那么产品人员的一个职责就是创建一个发布。创建发布的意义在于周知公司里面相关部门人员，我们有新的产品上线，可以让大家开展下面的工作，也是鼓舞士气的一个很好的手段。3.1.5 路线图 3.1.6 文档管理 3.1.7 主持产品会议 3.1.8 参与项目管理、演示和总结 3.1.9 需求的基本统计报表4 项目经理4.1 项目经理篇 4.1.1 建立项目禅道里面的项目的概念，还原为原原本本的项目的概念，就是固定人，在固定的时间里面，做固定的事情。产品是通过实施项目来实现的，项目是实现产品的过程，项目的产出是产品。产品是产品，项目是项目，不要将二者混为一谈。4.1.2 组建团队项目建立之后，首要做的是组建项目团队。 团队成员在团队里面的角色是可以自由填写的，和权限没有关系。 团队成员可以在这个项目中工作的小时数。一般来讲，每个人每天都有一些琐事，不可能每天8小时完完全全的都花在这个项目上面。之所以让大家填写这个，就是不要按照每人每天8小时的满档来计算。实际情况是不可能的。4.1.3 确定需求项目团队组建完毕之后，接下来要做的一个工作就是确定这期项目要做的需求。这项任务其实是整个团队，包括产品在内，共同完成的。确定的过程应该是线下的产品计划会议。4.1.4 主持产品会议按照scrum的管理流程，产品经理在日常维护完善需求，在项目开始的时候，需要召开产品计划会议。该会议的主要任务是确定在这期项目(sprint)中要做的需求。产品经理可以事先将自己这期项目计划做的需求归并到一个计划中，然后在计划会议的时候，逐个给大家讲解需求。讲解需求的目的是要保证与会的人员，也就是项目团队，对这个需求的理解是一致的。讲解需求的时候，要给大家解释为什么这样做。以便大家理解执行。除了讲解需求，还有一个非常重要的工作，就是对需求进行优先级的排序以及工作量的估计。工作量的估计我们后面再讲，这属于scrum里面的流程，有一些工具和方法来解决。优先级的排序是非常重要的。那么这一期项目要做的需求，就应该按照优先级进行排序。这样可以保证整个公司每时每刻做的东西都是时下优先级最高的。当然，需求的优先级也不是一成不变的。产品人员可以根据实际的情况来调整某一个需求的优先级。前面提到的工作量的估计，主要解决是本期项目做多少的问题。按照优先级排列之后，然后再按照整个团队可用的工时数来计算，确定计划可以完成的需求数量。太多了，肯定做不完。太少了，团队就会有段时间无事可做。所以这个要靠整个团队慢慢摸索，达到一个相对准确的估计。4.1.5 关联产品（建议一个项目关联一个产品）禅道是支持一个项目对应多个产品的，但在实际项目管理中，不建议这样做。多个产品，会增加复杂程度，应尽量避免。可以尝试分解项目为多个项目来做。4.1.6 关联需求4.1.7 分解任务在分解任务的时候，需要注意几点： 任务分解尽量细致。按照scrum的实践，分解的任务，应该是一个人可以独立完成，最好在4-16小时之间。 任务分解应该完整，比如搭建测试环境，购买机器之类的看似无关的任务，也都应该列入任务列表。 任务的分派，应当由团队成员自愿认领为主，不要硬性指派。 任务类型应该认真选择（界面、开发、测试），这关系到相关需求所处阶段的自动计算。 项目进度：燃尽图（此处供参考）此图横轴为日期，纵轴为工时数。此工时数乃项目中所有任务剩余工时的综合，每天计算一下，形成坐标，然后把线连接起来，形成此燃尽图。燃尽图更关注于做完整体的项目还剩下多少时间。燃尽图以赤裸裸的形式把当前项目的进展状态展现出来，项目的走势如何，一目了然。所以用好燃尽图，可以很好的把握项目的进度。禅道还提供了任务的分组查看功能，比如可以按照状态来进行分组，按照指派给来进行分组等等。通过这个功能，可以很方便的统筹当前项目的状态。4.1.8 演示会议和总结会议在项目结束之后，scrum master应该召开相关人员（团队，以及其他相关的部门，领导，或者合作伙伴等等）召开演示会议。演示会议的目的旨在向大家展示本期项目团队所取得的成果，这是一个提高团队士气，增加成就感的非常好的方式，也是听取反馈，调整下一步计划的方式。演示会议不用特别正式，它不是汇报会议。so，不用准备精美的ppt，只需要有一个大屏幕，