|
|
4 回复 | 直到 10 年前
|
1
14
在我看来,Scrum的最终目标是能够发布一个新的增量 结束之后 短跑的换句话说,冲刺的结果是 可释放的 增量(不是释放的增量)。 因此,对我来说,选项1似乎有点太早了(我们的产品积压项目是在冲刺结束时完成的,但在演示之前完成的,并且我们的“完成”定义中不包括“发布到生产中”,因为这不是我们真正控制的,这是另一个团队的工作)。 不知怎的,我认为选项2意味着你没有把所有需要“完成”的事情包括在你对“完成”的定义中。我肯定不是说这很容易做到,而且很可能需要一段时间来真正包括所有需要达到的步骤 可释放的 在您的定义中,完成并进行必要的组织变革,以实现目标。 就我个人而言,我还是没有 真的? 达到了这个流动性水平(在每个冲刺时释放),而在每个冲刺过程中(IST,UAT),我们实际上每2周释放4次冲刺,最后一次冲刺是一种释放冲刺,带有“特殊”产品积压项,如执行负载测试,必要时优化(尽管没有太多糟糕的SU)rprises now),编写文档(为生产团队,为用户)。缩短发布周期需要进行更深入的更改,而这些更改目前无法完成,在我们的情况下实际上是不需要的。当然,你的背景是不同的。 也见相关问题: |
|
|
2
3
这取决于行业、市场和许多其他因素。没有单一的答案。记住,Scrum是一个框架, it doesn't fit all . 我见过 解1 最有效的。 在冲刺结束时,您应该有一个可能发布的产品版本。它在小型初创企业或小公司中非常有效。这是他们的竞争优势之一。质量保证人员可以轻松加入团队。这可以在软件不重要的大公司中实现。( 解2 ) 我在一个安全性至关重要的大型企业中实现了Scrum。由于法规和认证限制,在冲刺之后发布是不可能的。你必须经历一个漫长的发布过程,开发者必须参与其中。我们必须为此努力。 但在大多数软件工厂,他们可以在演示后发布,几乎只需点击一下。当您使这成为可能时,您就获得了迭代开发的所有能力,这是一个非常大的竞争优势。 从商业的角度来看,在每次迭代结束时不发布也是一个好的实践。 |
|
|
3
1
如果我谦虚地假设您在软件行业,那么您的问题或解决方案的答案就是将企业Scrum模型与一个可靠的项目发布计划和项目时间表计划结合使用。 应该有一个操作支持Scrum团队,其中可能包括数据库管理员、应用服务器管理员、高级QA人员和高级生产支持分析师。这个团队可以为开发Scrum团队负责完整的QA回归和负载测试、发布管理、代码部署和其他操作支持活动。另一方面,开发Scrum团队只需生成可发布的软件,并将其放在操作支持团队的货架上。 在您的这个特定场景中,操作支持团队将在其产品积压列表上有积压,以对开发团队生产的搁置产品进行回归测试和负载测试活动-注意回归最好是开发过程的一部分!!!! 现在,发布每个Sprint的组织需要让操作团队落后于开发团队一周或两周,例如,如果Scrum开发团队正在开发2.0版代码,那么操作支持团队应该部署1.0版代码,开发团队在2周前完成了“搁置”。 最重要的是,发布计划需要有正确的时间表。在Scrum中可能有一种误解,即每个Scrum团队都有自己的发布计划,因为他们是自我管理的,他们会自己进行部署等,这在一定程度上是正确的,但是团队计划也需要与项目范围的发布计划相适应,并且时间表也需要相应地适应。 按照项目时间表协调时间表和组织积压工作的责任主要在采购订单的肩上,而管理层则负责培训采购订单,使其最有效地工作。所以简单的答案是=2周是开发团队和进行QA或发布活动的运营团队之间的一个很好的差距,但是时间线和差距应该根据项目需要进行调整。 如果你需要更多的细节,请询问。讨论这个问题的谈话会更容易解释,但我希望这能回答你的问题。顺便说一句,对于开发团队来说,在冲刺结束后的第二天发布(prod)是一个坏主意,但是你可以尝试它,检查和适应;)并且1周是一个足够好的间隔,但这取决于你的应用程序有多大,你的数据有多大,以及你有多少资源。 谢谢,希德·泰朗。认证的Scrum大师 |
|
|
4
0
我的理解是,在冲刺结束时“完成”是很重要的,而不必在另一个冲刺中承担“技术债务”,在另一个冲刺中,人们必须重新编写以前发布的软件。 |
推荐文章