本文主要是介绍敏捷开发-任务拆解、工作量评估和任务指派，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在之前的文章我首先讲了1)敏捷的第一步-每日站立会，然后讲了如何2)用看板管理项目或者管理自己的工作待办，今天是第三个主题，讲如何3)在实际项目中做任务拆解、估时和工作指派。
任务拆解和评估
任务拆解和评估是一项需要非常细致、需要经验的活，通常一般由Team Leader来拆解、评估人天和指派人员。
- 有的人说你这是假敏捷。
- 工作量要自己评估任务，不需要Leader评估；
- 工作量要用故事点，不要用人天；
- 任务要自己认领，不需要用人指派。
你说的都对。但我们在实践中通常看其实际效果决定是否采用。理论或者学说可以指导实践，但是不能替代实践。只有经过实践验证的理论也才是最有说服力的。这里我们之所以用人天评估工作且由Team Leader 指派工作是因为，
- - Leader 对整个项目整体架构，模块划分、实现细节更了解，所以他来拆解也更合理
- - Leader 了解每个人的实力水平和工作效率，已经知道这个工作安排哪位同学完成更适合。人天是结合了故事点和执行人员两种因素后，在时间上/工作量上的评估，更容易理解和也容易跟进。
- - Leader 需要承担项目整体快速推进的职责，需要能指派团队成员快速完成工作，指派工作这种做法非常高效。
经过实践后，我们发现这样做是完全没有问题的。
任务拆解原则
我们的任务拆解有两个重要的原则 1）高价值优先原则 2）粒度不要超过3人天。
高价值任务优先拆解：拆解任务时，优先拆解高价值的任务。始终优先处理对最终用户和产品的价值最大的功能和特性，团队和产品的价值才能最大化。
任务粒度要不超过3人天，也就是说如果一个任务需要三人天内完成。三天内没有完成是一件非常严重的事情。如果是拆分的不合理，应该第一天就需要反馈出来；如果是遇到了问题，也不应该第三天才提出来，毕竟我们是每天站立会。其实工作中最怕的就是事先没反馈、事中没进展然后在截止日期无法交付。
我们期望能保持小粒度的任务，每天都有进展，而不是一个个巨大的任务分配下去后半个月都没进展，这样会导致团队成员对任务没有感知度，项目很大程度上会失控，最后交付日期出现「惊吓」的结局。
本文小结
本文主要讲了我们在敏捷开发实践中的一些做法，包括 Team Leader 拆解任务、评估工作量和指派人员完成任务，我们认为这样做对于整个团队是最高效的、风险也是最小的；对于任务拆解，我们主要有两个大原则：高价值优先原则和粒度不要超过3人天。这样做有助于让我们保持聚焦，始终关注那些对用户和产品价值最大的功能和特性上。
这篇关于敏捷开发-任务拆解、工作量评估和任务指派的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
