Tim*_*ght 88 agile project-management scrum
我很好地阅读了Scrum的好处和过程.我在积压,燃尽图表,迭代,使用用户故事以及Scrum"框架"的其他各种概念上获得了想法.
据说......我在一家网络开发公司工作,一次管理多个项目,六个团队成员组成"生产团队".
Scrum如何处理多个项目？您是否仍然只是在一定时间内为单个项目安排迭代,整个团队都会对其进行处理,然后在迭代完成后再使用新的迭代继续下一个项目？或者是否有一种"敏捷"的方式来管理多个项目,并且只有一个团队同时进行自己的迭代？
Chr*_*tta 60
Scrum确实没有要求你必须在一个独立的产品上工作.它只是声明需要完成一些事情(产品积压),在下一次迭代中有一定的开发时间(根据项目速度计算)并且客户选择了一些项目/ business作为将在下一次迭代(sprint backlog)中完成的问题/任务池中具有最高优先级.
没有理由产品积压和sprint积压必须来自一个项目 - 即使在单个项目中,也会有像独立项目一样的离散工作单元 - UI,业务层,数据库架构等.特别是企业软件开发就像这样,你有许多代码库,所有代码库都必须进步.Scrum流程 - 会议,问题,烧毁图表等 - 无论是一个项目还是多个项目都可以工作.
话虽如此,实际上每次迭代通常都有一个主题 - "做报告模块"或"与XYZ系统的API接口" - 以便很多问题来自一个项目或区域,并且在迭代结束时,您可以指向大量工作并对其进行勾选.
phi*_*ant 25
我认为答案取决于" 谁将优先考虑积压项目 "(即决定首先需要做什么).如果这是一个人,则此人是您项目的产品负责人,并且您可以将所有项目的所有项目(或每个项目的待办事项)都有一个待办事项 - 并且您在计划时选择所有项目的待办事项项目一个冲刺.在这种情况下,Scrum"工作正常".
如果每个项目都有责任,那么你可能会遇到一些麻烦,每个负责人都会 - 或多或少地有意识地 - 试图支持它的项目.恕我直言,您只需拥有一名产品负责人,并有权通过仲裁解决优先事项.
在这种情况下应遵循的一条规则是在Sprint期间永远不要更改Sprint内容.如有必要,您可以将迭代时间缩短为两到三周,以降低在当前Sprint中添加紧急项目的风险.
ano*_*res 16
我不同意.我认为在sprint期间让团队专注于单个项目是关键.如果您有一些无法为整个开发过程做出贡献的专家(内容作者,图形人员,业务流程分析师等),那么当他们无法再做出贡献时,我会将他们从团队中移除.或者更好的是,让他们接受一些不同的任务训练,这样他们就可以为测试等事情做出贡献.
另外要记住的是,并行运行项目会导致计划失败.考虑一下:为了简单起见,我们假设我们有5个项目使用相同的团队,并在同一天开始.每个项目需要3个月的努力,在并行运行的最佳情况下,您将同时完成所有这些并且需要15个月.你的速度会因为你只能在单个冲刺中适应1/5个月的力量而得到提升.您还将同时进行5次演示会议.最好的情况是,您在15个月内交付5个项目,您的竞争对手将声称他们可以在3中完成相同的工作.您的团队估计成熟度将受到影响,因为他们只能考虑20%的可用劳动力.您可能会发现实际上无法在单个sprint中执行某些任务.如果你必须从5改变工作项目的数量,你的团队将不得不调整他们的估计习惯,这将损害团队的效率.此外,如果简单的任务重新分配可能需要在工作开始之前启动新的开发环境,您的团队将发现很难进行自我组织.
如果您要连续运行相同的5个项目,那么您将在相同的15个月内交付第5个项目,但是您可以让您的客户知道您的团队需要您有12个月的积压并且您可以使用那个时候来完善你的项目目标.或者如果你有一个持续的积压,你知道是时候开始雇用另一个团队了.然而,您最好的项目在3个月内完成,客户在活动期间已经看到了快速的改进.您可以在一年前完成该项目,并将其放在简历上.你的冲刺速度会在这段时间内稳定下来,你可能会发现在一两个项目之后它的步伐很大,并且能够在给定的冲刺中完成更多.
我认为连续运行项目是组织试图采用Scrum面临的最大障碍之一.这是与解构项目经理角色相关的重大文化变革,但对Scrum流程的好处是巨大的.
请记住,EVERYBODY不需要是一个完整的团队成员.他们可以让您的客户在候诊室,为开发过程做准备.我将业务分析师,网络架构师和图形设计人员作为领域专家,并根据需要将其附加到团队中.让他们用sprint 0运行.你会惊讶于在外观和工作流程上的工作.为您的客户做好准备也是一件好事,他们的理解是,当开发真正开始时,他们的参与程度可能会上升,并且对他们来说很重要.让他们知道时间表,以便他们有足够的时间提前处理假期和假期等事情.
我一直处于这种精确的状况.
如果您在项目中拥有一个产品所有者,那么Phillipe绝对是正确的; 一个团队的一个冲刺应该工作得很好.
如果您拥有多个产品所有者,那么理想情况下,业务方需要选择一个"优先级",负责安排工作.这绝对是最好的解决方案.
如果(可能就是这种情况),企业不想改变他们想要优先排序的方式(这太方便了),那么你可以拆分团队.并运行两个并发冲刺.但是如果有一个六人小组,我不会把它分成三个以上的小组(我根本不想拆分它,但我认为2-3个小组是可行的).正如肯尼所暗示的那样进一步分裂,并且拥有一个人的团队对我来说似乎毫无意义,因为那时你不再拥有团队,只有个别程序员.
如果你正在分裂团队,我没有找到合并站立的很多价值,除非你有很多单独的冲刺工作在很多相同的代码库,但是那可能是为了合并这些团队的一个参数冲刺.
我认为 anopres 是对的：最好的方法是通过 scrum 避免同时进行多个项目。尽一切努力让人们知道并行运行太多是低效的。
让我们假设 5 人的团队有 5 个项目，每个项目大约 3 个月。
方法 1：每个人在团队中从事单个项目
方法 2：每个项目 1 次冲刺，切换项目
方法 3：单个冲刺 5 个项目
方法 4：推荐 - 串行化工作
如您所见，解决方案 4 通常更好，因为项目交付速度更快，团队合作高效。其他方法包括上下文切换浪费时间、没有完整的团队协作、所有项目的总交付时间很长等。
那么积压的整理又如何呢？如果团队同时处理单个项目，那就很简单 - 每个人都会加入。如果有多个项目，我们可能需要委派单个人进行单独的美容会议（不涉及整个团队）。
重要的是要让客户相信，3 个月后开始第二个项目仍然会导致更快的交付（6 个月后），而不是我们立即与所有其他项目一起开始。这是管理者们看到的一种幻觉——我们同时启动5个项目，我们努力工作，一点一点地交付。但最终这并不高效。
这就是为什么我不相信 Scrum 对于并行的多个项目是有效的，将其匹配到框架并根据 Scrum 规则工作是非常棘手的。有时，有 2 个项目可以让所有人都忙碌起来可能会很好，但我们添加的项目越多，scrum 的效率就会越低。也许看板是一种替代方案，只是为了查看进度和团队合作（不像 Scrum 团队那么强大）？
问候，亚当
小智 5
我最近一直在阅读另一种观点,即在敏捷环境中,项目的概念可能适得其反,可以消除.根据这种思路,组织应该专注于发布.这是因为项目是人为的工作箱,在完成之前不会产生任何价值.它们违背了敏捷经常提供可交付价值的目标.一个版本是更符合利落的线条,因为它是朝提供价值,并因为它的范围可以减少或基于什么球队可以在下一个前交付扩大面向释放.
有一个潜在的中间立场,其中以前称为贵公司的项目现在被重新打包为常见的敏捷主题或功能.这种方法的好处是,主题或功能现在可以按照产品所有者认为合适的价值实现.
仍然存在一个团队致力于多个产品的问题,这是一个问题,因为对领域知识和可能的技术技能的合理关注.但产品与敏捷建,甚至多个产品由单一的建队,都在不断累积释放 -able值.相比之下,项目在完成之前是没有价值的(许多人没有).
需要考虑的事情......