本次迭代的任务目标和计划，让所有项目成员能在接下来的日子里更流畅地进行各自的工作。在这个会议上，项目经理会和团队一起对用户故事进行工作量评估，并拆分成具体的任务点，项目组成员根据自身情况主动领取任务，如果存在困难应该在这个会上提出，大家共同商议出解决方案。
（迭代+计划会议+拆故事+领任务）
小项：用户故事，这是个新的概念，您能具体介绍一下么？
Y先生：用户故事（User Story）是从用户的角度来描述用户渴望得到的功能，对于敏捷开发来说，它是开发的基础。不同于传统的瀑布式开发方式，用户故事是把原本需求拆成最小粒度的Story，以方便拆分Task，估计开发时间，领取开发任务，它应遵循INVEST规则（Independent 独立性、Negotiable 可谈判性、Valueable 有价值性，Estimable 可估计性、Sized Right 合理的尺寸、Testable 可测试性）。
用户故事的拆分有两个层面：大故事拆分成小故事，小故事拆分成任务。大故事拆解成小故事除了能通过“小规模化故事”防止小瀑布，同时也有助于识别出需求的某些细节；而小故事到任务的拆分，也就是我们常说的任务分解，可以看作类似瀑布模型中的详细设计，在这种方式中，每个任务都能在较短的时间（1-2天）完成，完成所有任务后能达到高质量实现用户故事的目的。有的人认为任务很难拆分，甚至没有必要拆分，这种思想就像是在瀑布开发模型中不做详细设计一般，设计思路还没有理清就扑入了代码的海洋，这种做法写出来的代码质量可想而知。
任务分解同时可以用来制定工作计划，分解出来的任务就是在实现故事的过程中要做的事情，每个任务需要的时间就是做这些事情分别需要的时间。从这个角度来看，如果我们很够很好地将故事分解成任务，准确地评估故事的规模，无论是使用物理看板还是TFS等工具进行任务管理，都能较好地做好迭代计划并顺利执行。下面是一个简单的在线购书网站的用户故事拆分示例：
小项：那么采用用户故事评估出来的工作量会与中心目前采用的功能点估算结果相冲突么？
Y先生：这个情况我们也有考虑到，目前我们是以中心功能点估算的结果为依据，将工作量分配到以用户故事分解出来的任务下，所以不存在冲突的问题。
小项：了解了，那除了任务分解方面，咱们还有哪些其他做法与敏捷相关？取得的效果又如何呢？
Y先生：站会，这个非常重要。现在每天早上8点半到9点来我们办公室，会看到所有的小组基本都在开站立会议，这个会议很短，一般在15分钟以内，每个人只需要回答三个问题：上次会议后完成了什么？下次会议前需要完成什么？遇到什么困难和阻碍？这个步骤一般都是在看板前完成，各项任务可视化的讨论方式有利于对项目整体执行情况的把握，问题能够尽快地被发现和得到解决，保证项目按计划进行。
另外还有每个迭代结束时的迭代评审和迭代回顾，这个我们通常作为一个会议来开，时间一般定在每个迭代结束的当日下午，在这个会议上大家会展示本阶段的项目成果，这是个重要沟通和反馈的过程，同时在这个会议中，会对本次迭代所有的故事、度量、事件从以下三方面进行归类：做的好的、做的不对的、改进意见。通过这个会议的开展，达到项目过程的不断改进和团队的不断进步。
总之敏捷是一种思想，要想真正达到完全实现我们仍需不断探索，还是开头那句话：敏捷尝试，我们一直在路上。
小项：好的，这次的访谈就到这里吧，感谢Y先生带领我们了解了敏捷那些事儿，屏幕前的你有没有觉得受益匪浅呢？还是你也有些话不吐不快？如同前几期所说，项目管理方面不管您有任何的问题和疑问，或者是好的经验想要分享，欢迎联系小项，我们将会怀着最大的诚意，欢迎您的到来！(文/小项)
