作者小头像 Lv.1
更多个人资料
0 成长值
0 关注
0 粉丝
+ 关注 私信

个人介绍

这个人很懒，什么都没有留下

感兴趣或擅长的领域

暂无数据
个人勋章
TA还没获得勋章~
成长雷达
0
0
0
0
0

个人资料

个人介绍

这个人很懒，什么都没有留下

感兴趣或擅长的领域

暂无数据

达成规则

以上满足项可达成此勋章

主题 | 回复
【新版本特性】（更新至10月）华为云 项目管理服务ReleaseNotes
发布时间 2018-09-20 09:15:48 最后回复 冷言冷语 2018-10-17 09:15:48 版块 项目管理
2828 2 0
请问项目规划中的Epic、Feature、Story和Task的关系
发布时间 2018-09-19 15:07:38 最后回复 别人都叫我哥哥 2018-10-10 15:07:38 版块 项目管理
33936 3 0
他的回复: Epic【史诗级故事】，简单点，你就理解为软件的版本好了，不需要太详细的秒速，但是要说清楚这个版本需要哪些大功能Feature【特性】，你都在【史诗级故事】中说好了要哪些大功能了，那作为它的子级的【特性】自然就是每个你需要的大功能的描述，但是由于一个大功能的实现有许多众所周知或者实际做了才知道的前置的或者后发的条件，所以【特性】的完成一定被项目中所有成员认可是一个较长的过程，所以肯定还需要进一步细化Story【用户故事/积压工作项】，把特性细化了以后就是这个了，故事之所以叫故事是因为内容读起来就像故事，参考中小学生作文吧，故事的三要素：参与者、行为、结果，（管理员在XX界面点击了【XXX】按钮后，界面跳转至【XXXX】界面）仅供参考。可以看出，故事要细致，描述细节，有明确的验收标准，任何人看完都应该知道如何操作，测试人员也可以以此来作为测试用例。Task【任务】，这是只有开发才知道的细节了，上面几个都是无论什么人都能看懂的东西，任务描述的应该是开发中的细节，比如（修改AAA类的BBB方法，提升执行效率）或者（将XXX功能的原有做法改为使用命令模式），只有开发才懂得的细节，由于此类工作也需要耗时，而且耗时可能还不短，这会违背“快速迭代”的基本价值观，所以当一个【故事】涉及到此类的行为时，就可能需要较长时间来迭代，所以应该在【故事】下建立【任务】来说明工作的具体内容
【产品经理-全连接系列 之002】企业应该如何开展敏捷，或者DevOps这样的研发变革（1）
发布时间 2018-09-27 19:17:13 最后回复 白先生 2020-11-19 19:17:13 版块 项目管理
11817 3 1
【产品经理-全连接系列 之001】Epic/Feature/Story/Task/Bug到底是什么？
发布时间 2018-09-20 13:08:31 最后回复 白先生 2020-11-19 13:08:31 版块 项目管理
19190 8 0
他的回复: 1.将需求分解成稍微具体的特性【长篇故事】，将长篇故事分解为一板一眼的小故事，理解故事背后的用户行为而制定任务 特性【长篇故事】应该描述共同愿景，生动并有比较现实的验收标准，但这个故事背后还有一些前置条件和后发需求没有详细描述，但由于前置条件和后发需求理所当然，所以众所周知，并使所有人共同认为这样的故事的实现是一个较长的过程 小故事应该有十分具体且现实的描述，有非常明确地验收标准，满足故事的三要素，参与者、行为、结果，整体描述像诉说一个故事，并使任何人都能听都能懂，故称为用户故事 任务建立在小故事之上，每个小故事的实现必定意味着代码的修改，而代码的修改是只有开发者才能明白的行为，无法用故事诉说，故建立任务，具体描述对代码的修改行为 任务故事的制定不能违背项目的使命并不脱离共同愿景和现实2.应对变化的需求 在故事以及任务撰诉清澈的前提下，每个任务或故事的实现时间将不会太长，在用户及时反馈的情况下，每次需求的变化损耗的时间只是一至两个工作日 使用更好的代码管理工具，对每个任务建立分支，每个功能独立实现，最后合并实现迭代，若过程中出现需求改变导致的反工，则将反工前的任务分支和当前任务分支合并，以实现快速的反工完毕 寻求经验者的帮助，分析用户思维 尽量从简，越简单的基础功能，修改的代价越小