Question

谁知道JIRA应用实践:如何有效地进行任务采集和分配？

Answer 1

JIRA Duration：5个月
Project Background: Name: XXXX （新的开发项目）
Team Size: (4-9) （中途有加人和减人的情况）
Other：以下仅仅是本人的一些不成熟的想法和实践经验，仅供参考，欢迎有价值的“批判”和探讨本文主要介绍的是通过JIRA来解决项目中的一些问题，并不会讲述JIRA的整体功能，如有兴趣，建议去官方网站查询注意：后期的有些抓图是基于JIRA4的该项目采用JIRA，一来使用经验比较丰富；二来主要是考虑到该项目的特点：需要快速，高效地去处理一些棘手的问题项目特点：开发流程不标准（没有严格遵循软件开发流程）需求极其不稳定（海外客户不断进行产品功能及其流程的重新定义），变化很快，没有正式的需求文档系统提交的周期比较短 （schedule非常紧）团队组建时间比较短，人员变化比较快 （时而加人，时而减人）存在的问题：总有很多的，不断更新的question log，这些大量的issue会有如下的问题: 如何确保每一个question，项目组都能够执行下去？Open / Close / KIV 的issue如何进行跟踪？（open-closed,02 closed – open?）相互关联的issue在项目组是不是被group到一起执行？ （如果分开任务安排，可能会浪费时间）数量很多的情况下，如何有效地查询？如何确保每次Release的scope是正确的？时间非常紧急的情况下，如何有效地记录出现的各种问题？（需求变更，Bug等等）时间和资源有限的情况下，如何最优地使用当前的团队资源（如何进行及时的，适当的任务分配）？如何减少沟通的时间？（花费最少的时间，通过适当的方式，正确地实现项目需求）还有很多的问题，当时间很紧急并且需求很不稳定的情况下，一般的问题也会变得很棘手JIRA应用实践 – Issue 采集和分配A.目的：不漏掉发现的每一个问题（存在的，可能的，潜在的）和 每一个新的功能（来源于客户变更，来源于项目组内部）B.何时做：当出现以下这些情况的时候，就会通过JIRA来创建Issue （或者更新Issue）: 内部交叉测试发现BugPM / PL 二次测试出现bug随机使用系统发现的莫名其妙的问题 （或者不是很友好的UI和功能）来自于客户的需求变更 （Question Log里的变更，Mail通知的变更，口头传播的变更，及时沟通工具通知的变更）项目开发初期，一些可以暂时可以忽略的问题（或者例外信息）来自于项目组内部的新功能（比如系统Log，性能优化，安全方面考虑）C.如何做：（创建/更新的Issue的要求）： 计划好Release 的版本，执行该任务的成员及其完成任务的时间 （目前不需要关注的问题，可以放置到一个特定的版本里（No Schedule））（很多情况，可能无法预期版本或者人员，可以暂时不设置，随着开发的进程，不断地根据优先级来调整）如果是比较大的问题，使用sub-task 来分配给不同的成员（团体合作）对于需求变更的问题，更新详细说明，始终反映最新的需求如果发现此问题与其他问题有关联，使用Link功能创建联系（同时建议，相似的任务分配给同一个（批）成员）某些复杂的问题，可以同时将Design & Solution 和一些注意事项也描述出来
（实际执行过程中，这种一般都是大的CR，很多小的Bug等不用特别详细,因为bug相关的UI实例或者例外信息已经足以说明该问题）保留来自于客户的原始需求，并且转化到项目组可以执行的需求 （既保证来源于客户的需求原汁原味，又要保证有可以执行的需求）相关的Mail 和 需求图片等，作为附件也要放置到JIRA上 （保证相关性可追溯）对上面的内容等保持及时的更新 （实时性，正确性）D.实例一：
下图是来源于Mail里的一个客户需要实现的需求包含Issue ID (对应于question log ID)相关的参考资料（Mail/文档/图片）有联系的Issues 链接（更快地找到有联系的问题，相互进行参考，避免重复工作）子任务（任务比较大，需要多人一起来做）详细的内容说明，包含客户的需求和详细的需求说明（项目级别的需求一般会比客户的需求要详细的很多，包含我们想到的一些隐性需求等等）E.实例二： 对于新增加的模块，提供UI Demo 和所有的功能描述通过这个，能得到什么？