Epic【史诗级故事】，简单点，你就理解为软件的版本好了，不需要太详细的秒速，但是要说清楚这个版本需要哪些大功能Feature【特性】，你都在【史诗级故事】中说好了要哪些大功能了，那作为它的子级的【特性】自然就是每个你需要的大功能的描述，但是由于一个大功能的实现有许多众所周知或者实际做了才知道的前置的或者后发的条件，所以【特性】的完成一定被项目中所有成员认可是一个较长的过程，所以肯定还需要进一步细化Story【用户故事/积压工作项】，把特性细化了以后就是这个了，故事之所以叫故事是因为内容读起来就像故事，参考中小学生作文吧，故事的三要素：参与者、行为、结果，（管理员在XX界面点击了【XXX】按钮后，界面跳转至【XXXX】界面）仅供参考。可以看出，故事要细致，描述细节，有明确的验收标准，任何人看完都应该知道如何操作，测试人员也可以以此来作为测试用例。Task【任务】，这是只有开发才知道的细节了，上面几个都是无论什么人都能看懂的东西，任务描述的应该是开发中的细节，比如（修改AAA类的BBB方法，提升执行效率）或者（将XXX功能的原有做法改为使用命令模式），只有开发才懂得的细节，由于此类工作也需要耗时，而且耗时可能还不短，这会违背“快速迭代”的基本价值观，所以当一个【故事】涉及到此类的行为时，就可能需要较长时间来迭代，所以应该在【故事】下建立【任务】来说明工作的具体内容

说到底，人才是核心，只是大多数人根本沉不住气，也就不明白如何才能和别人精诚合作

1.将需求分解成稍微具体的特性【长篇故事】，将长篇故事分解为一板一眼的小故事，理解故事背后的用户行为而制定任务 特性【长篇故事】应该描述共同愿景，生动并有比较现实的验收标准，但这个故事背后还有一些前置条件和后发需求没有详细描述，但由于前置条件和后发需求理所当然，所以众所周知，并使所有人共同认为这样的故事的实现是一个较长的过程 小故事应该有十分具体且现实的描述，有非常明确地验收标准，满足故事的三要素，参与者、行为、结果，整体描述像诉说一个故事，并使任何人都能听都能懂，故称为用户故事 任务建立在小故事之上，每个小故事的实现必定意味着代码的修改，而代码的修改是只有开发者才能明白的行为，无法用故事诉说，故建立任务，具体描述对代码的修改行为 任务故事的制定不能违背项目的使命并不脱离共同愿景和现实2.应对变化的需求 在故事以及任务撰诉清澈的前提下，每个任务或故事的实现时间将不会太长，在用户及时反馈的情况下，每次需求的变化损耗的时间只是一至两个工作日 使用更好的代码管理工具，对每个任务建立分支，每个功能独立实现，最后合并实现迭代，若过程中出现需求改变导致的反工，则将反工前的任务分支和当前任务分支合并，以实现快速的反工完毕 寻求经验者的帮助，分析用户思维 尽量从简，越简单的基础功能，修改的代价越小