如何为短敏捷/冲刺周期进行智能资源规划?[关闭]

给你的资源一些自由。如果它是敏捷的-他们会很高兴的。

“在sprint期间,可能很难为他们分配新任务,因为大多数项目在那一点上都与计划的工作联系在一起”

项目管理的味道。

如果你已经“预先计划”了所有的工作,那就不是很敏捷了,是吗?敏捷=灵活。你应该可以在不破坏任何东西的情况下重新排列。

如果你的计划“中断”了,你的计划太多,敏捷性太低。

你不应该过度计划这种事。

敏捷技术的一个(美妙的)目的是尝试并消除许多不必要的计划,因为你承认你的项目计划会改变,如果你坚持一种经过实践检验的、真实的计划方法,比如通用瀑布法(Reqs->Specs->Design->Dev->QA->Releas你将会经历很多不必要的迭代和浪费时间。

要么减少计划,要么拥有一个活动池,如果开发人员有灵活的使用时间,他们可以从中获取这些活动(小的功能请求、老的ui错误、不太重要的东西,如果需要可以删除)

在这种情况下,有可能从计划的工作中腾出资源。

首先,我开始谈论人或团队成员,而不是资源(“尊重人”)。

在sprint期间可能很难为他们分配新任务

你不应该把任务分配给别人(这听起来像是微观管理)。任务在队列(sprint)中,团队应该自我组织以完成项目,首先关注最重要的项目。

在这种情况下,计划资源的最佳方法是什么?

最好的办法就是不去做。

我认为敏捷仍然需要计划,否则任何人都会从待办事项列表中提取任何东西,开始处理完全不相关的任务,它将无法到达任何地方。为了达到共同的目标,需要对工作进行规划。如果存在跨职能团队,则需要计划数据库和环境资源的可用性

首先,我不确定你在遵循什么“敏捷”方法。在敏捷scrum中,scrummaster管理backlog,用户故事由团队加权(优先)。这确保了他们不会只是“从积压中提取任何东西”。每个sprint都有一个共同的目标。

敏捷开发不仅仅意味着任何人都可以在sprint中做任何事情……它仍然有一个结构,每天都有展示进度和在需要时为sprint添加更多内容的备份,还有sprint回顾和sprint计划会议。关键是团队在scrummaster的指导下自我管理工作。