问题本身就说明了。在我的工作场所,这种情况经常发生,但是,许多敏捷书籍都提倡在同一个工作场所工作,并将精力集中在当前的项目中,以加快工作的速度。
也许我不太了解这个话题,也许没有那么严格,但这就是为什么我想知道敏捷在这种情况下会提出什么建议。
有人吗?
发布于 2011-04-06 23:13:30
在Scrum方法中,它只是影响估计。
您将根据每个项目的时间分配为该人员分配焦点因素。
所以,如果我对A项目和B项目进行同样的工作,A项目就会计算出这样的资源:
项目A-团队集中系数为70% Sam - 10天,100%分配(7在焦点因素后) Joe - 10天,100%分配(7在焦点因素后) Me - 10天,50%分配(在焦点因素后3.5)总计: 25天* 70%聚焦因子= 17.5预计速度
您还可以单独计算全职团队成员和兼职团队成员的焦点因子,而不是为整个团队计算一次,这是因为拆分项目的效率降低了。在这种情况下,您可以使用我的项目焦点因子( 50% )乘以个人分配的50% ( 25% ),也就是2.5天的预计速度。
这在实践中的效果如何,这将是一个因素,取决于您预先知道共享资源将在每个项目上花费多少时间,以及Scrum在其他方面对您的工作效果如何。
发布于 2011-04-07 01:11:01
在我的Scrum经验中,只有当项目和团队保持不变和专注时,才能预测速度。如果这两种情况都有变化,那么您就不能真正使用以前sprint中的速度计算来进行估计。你可以试一试,但你会比通常情况下要少得多。
一般来说,你应该尽量让团队保持不变&至少在冲刺的整个过程中都是如此,如果可能的话,更多。
发布于 2011-05-24 08:51:20
在我看来,这将严重影响所有项目。这不仅仅是估计或计划的问题。是的,你可以说,如果团队成员被分配到三个项目,并且他们对每个项目有33%的分配,你知道你需要的一切,你已经完成了,但事实并非如此。
上下文切换非常昂贵。同时,保持对多个并行项目的完全承诺是不可能的,因此,当开发人员只分配到一个项目时,33%的开发人员时间将远离33%。
另一个完全失败的地方是沟通。如果当前在项目A工作的团队成员必须与昨天在项目A上工作但目前正在处理项目B的团队成员进行某种交流,会发生什么情况?这对他们来说都是个障碍,因为第一个项目需要信息,而第二个项目则集中在完全不同的项目上,而项目A的任何问题都会让他感到不安。项目A的Scrum大师希望他的开发人员尽可能快地获得信息,而项目B的Scrum主人不希望他的团队成员被任何与项目B无关的东西所干扰。如果你想避免这一点,你必须计划团队中的所有开发人员在同一天内完成同一个项目--这是整个计划过程的一个巨大的复杂性,应该完全避免。
你还必须计划好所有的会议,以免发生冲突。你还必须明白,会议实际上是浪费的,因此,应尽可能少举行所需的会议,以保持对进程的控制。但是,如果您的团队成员在三个项目上工作,那么他必须参加这三个项目的所有会议,=>是开发人员不产生任何业务价值的会议的三倍多。
作为结论,敏捷也是关于减少浪费(是的,它来自精益方法),在团队之间共享团队成员是引入浪费和降低生产力方面最糟糕的失败之一。我想,为单个项目分配33%的业务价值,将等于从10%-16%的全职分配中交付的业务价值。这意味着开发人员不仅将参与项目的1/3时间,而且在这段时间内,他的生产力将在1/3至1/2之间。
https://softwareengineering.stackexchange.com/questions/65758
复制相似问题