敏捷开发-任务拆解、工作量评估和任务指派

在之前的文章我首先讲了1)敏捷的第一步-每日站立会,然后讲了如何2)用看板管理项目或者管理自己的工作待办,今天是第三个主题,讲如何3)在实际项目中做任务拆解、估时和工作指派。

任务拆解和评估

任务拆解和评估是一项需要非常细致、需要经验的活,通常一般由Team Leader来拆解、评估人天和指派人员。

有的人说你这是假敏捷。- 工作量要自己评估任务,不需要Leader评估;- 工作量要用故事点,不要用人天;- 任务要自己认领,不需要用人指派。

你说的都对。但我们在实践中通常看其实际效果决定是否采用。理论或者学说可以指导实践,但是不能替代实践。只有经过实践验证的理论也才是最有说服力的。这里我们之所以用人天评估工作且由Team Leader 指派工作是因为,

  • Leader 对整个项目整体架构,模块划分、实现细节更了解,所以他来拆解也更合理

  • Leader 了解每个人的实力水平和工作效率,已经知道这个工作安排哪位同学完成更适合。人天是结合了故事点和执行人员两种因素后,在时间上/工作量上的评估,更容易理解和也容易跟进。

  • Leader 需要承担项目整体快速推进的职责,需要能指派团队成员快速完成工作,指派工作这种做法非常高效

经过实践后,我们发现这样做是完全没有问题的。

任务拆解原则

我们的任务拆解有两个重要的原则 1)高价值优先原则 2)粒度不要超过3人天。

高价值任务优先拆解:拆解任务时,优先拆解高价值的任务。始终优先处理对最终用户和产品的价值最大的功能和特性,团队和产品的价值才能最大化。

任务粒度要不超过3人天,也就是说如果一个任务需要三人天内完成。三天内没有完成是一件非常严重的事情。如果是拆分的不合理,应该第一天就需要反馈出来;如果是遇到了问题,也不应该第三天才提出来,毕竟我们是每天站立会。其实工作中最怕的就是事先没反馈、事中没进展然后在截止日期无法交付。

我们期望能保持小粒度的任务,每天都有进展,而不是一个个巨大的任务分配下去后半个月都没进展,这样会导致团队成员对任务没有感知度,项目很大程度上会失控,最后交付日期出现「惊吓」的结局。

本文小结

本文主要讲了我们在敏捷开发实践中的一些做法,包括 Team Leader 拆解任务、评估工作量和指派人员完成任务,我们认为这样做对于整个团队是最高效的、风险也是最小的;对于任务拆解,我们主要有两个大原则:高价值优先原则和粒度不要超过3人天。这样做有助于让我们保持聚焦,始终关注那些对用户和产品价值最大的功能和特性上。


阅读我的更多文章

DevOps|研发提效-敏捷开发之每日站立会
DevOps|研发提效-敏捷开发之任务看板
高效能敏捷交付团队反思:特性团队(FeatureTeam)+Scrum
研发效能组织能力建设之特性团队FeatureTeam(上)
DevOps | 互联网、软件公司基础设施建设(基建)哪家强?