在上一篇文章中，我先讲了1）敏捷的第一步——每日站会，然后讲了如何2）使用看板管理项目或者管理自己的待办事项，今天是第三个话题，如何在实际项目中做任务分解、估算和工作分配。敏捷开发
任务拆解和评估是一项非常细致和经验丰富的工作，通常由组长通常负责拆解、评估工日和分配人员。
有人说你是假敏捷。你是对的。 但是，在实践中，我们通常会根据其实际效果来决定是否采用它。 理论或学说可以指导实践，但不能取代实践。 只有在实践中得到证明的理论才是最有说服力的。 我们之所以在这里对工作进行评估，由组长来分配工作，是因为组长对整个项目的整体架构、模块划分、实现细节有更好的了解，所以他拆解比较合理。工作负载应自行评估，不需要领导者
工作量应基于故事点，而不是人日;
任务应该由自己认领，不需要分配。
领导了解每个人的实力水平和工作效率，并且已经知道哪个学生更适合完成这项工作。 将故事点和高管这两个因素结合起来后，更容易理解和跟进时间和工作量的评估。
领导者负责快速推进整个项目，需要能够指派团队成员快速完成工作，效率非常高。
经过练习，我们发现这样做完全没有问题。
我们的任务拆解有两个重要原则：1）价值优先原则，2）粒度不应超过3人天。
价值任务的优先级拆解：拆解任务时，先拆解价值的任务。 只有始终优先考虑对最终用户和产品最有价值的功能和特性，才能使团队和产品的价值最大化。
任务的粒度不应超过 3 个工日，即如果一个任务需要在 3 天内完成。 三天不做是一件非常严重的事情。 如果拆分不合理，应该需要在第一天反馈;如果你有问题，你不应该在第三天提出来，毕竟我们每天都会站起来。 其实，工作中最可怕的就是没有提前反馈，流程没有进展，然后最后期限无法交付。
我们期望能够保持小粒度的任务，每天都在取得进展，而不是半个月不进的庞大任务分配，这会导致团队成员对任务毫无意识，项目将在很大程度上失控，最终交付日期将有一个可怕的结局。
本文重点介绍我们在敏捷开发实践中的一些实践，包括团队领导分解任务、评估工作量以及指派人员完成任务，我们认为这对整个团队来说是最有效、风险最小的对于任务拆解，我们主要有两大原则：价值优先原则和粒度不应超过 3 人天。 这样做有助于我们专注于对用户和产品最有价值的功能和特性。