SAFe -企业规模的敏捷框架。
基本上采用敏捷方法,并且每季度对计划事件进行一次为期12周的迭代,并进行为期2周的冲刺。
Context是一家正在从传统开发转向基于敏捷SAFe的方法的公司。
快速出现的是“瀑布冲刺”,这样敏捷所要解决的许多问题,特别是围绕质量改进的问题,就不会发生。这是因为,根据他们对SAFe的理解,业务是:
发布于 2018-07-08 16:52:43
虽然我认为SAFe根本不是敏捷的,但它只是为相同的角色、过程带来了新的词汇,而且可能没有变化,就像您所描述的那样。
但SAFe确实要求内置质量作为其核心价值之一。因此,我感到不安的是,你需要在一个安全的环境中为它的实践辩护。听起来是时候谈谈SAFe 精益敏捷领导者了,它也是核心SAFe实现的一部分。他们应该在实施路线图上放置一些项目,以确保每个人都接受了内置质量的培训。
他们采取的不是正面攻击敏捷,而是采取“拥抱和扩展”营销策略,这样你就会发现从敏捷和精益世界中听到的每一个流行词,包括Scrum、看板、XP、精益创业、精益用户体验( Lean )、持续交付和DevOps。但这只是一种营销策略。大多数情况下,他们只是重新定义这些术语的含义,以模糊它们的目的。Epic变成了一个“小型业务案例”;当被称为“精益治理”时,治理的概念听起来不那么繁重;当项目管理定位为“敏捷程序管理”时,程序管理可能会引起较少的焦虑。关于迭代和敏捷的不断讨论掩盖了这样一个现实,即这些“敏捷发布培训”大多每10周发生一次。我可以继续,但希望你能明白重点。敏捷和精益的核心优势已经丧失。更准确地说,如果您遵循他们的流程,我发现您将无法想象您能够从有效使用敏捷和精益方法中获得创新的潜在好处。https://svpg.com/revenge-of-the-pmo/
在加入SAFe公司之前,我会三思而后行。*古德勒克。
发布于 2018-08-07 18:38:01
我的经验是,当一个团队看到他们的旧流程不能产生预期的结果后,就更容易说服他们改变流程。他们可能认识到某些事情是错误的,但不认识到这个过程就是问题所在。您可以通过收集与您想要进行的更改相关的度量来帮助他们。量化代码质量是很困难的,但是即使有吵闹、不完美的度量标准也足以让人们体验不同的过程。
https://sqa.stackexchange.com/questions/34657
复制相似问题