142 积分 多伦多 Ahmad 是开源的倡导者和开发者工具爱好者。目前在 Mashape 领导优秀的工程团队,构建世界一流的 API 工具和市场。在业余时间,Ahmad 在 Technology & Leadership 上写博客,指导早期创业公司,并构建被全球数千名开发者使用的开源项目。 思想开放 作者
发表的评论
简短说明一下,这个评论串非常精彩,我想继续进行这个讨论,因为我想向大家学习更多关于什么有效和什么无效。
为了更深入的讨论,我邀请您在 Github (长篇幅 & 公开) 和 Gitter (公开 & 实时) 上与围绕开放开发方法的更大的社区进行讨论:https://opendevelopmentmethod.org/#resources
大家好,感谢大家所有的回复、问题,甚至不同意!:)
很高兴看到一个对工作质量充满热情的社区想要改进它。这一点很重要,因为没有完美的系统。如果您不同意,那么您已经限制了自己改进您偏好的系统的任何可能性。
话虽如此,这里有一个重要的点需要澄清,我很惊讶 Scrum / Agile 专家和顾问尚未指出这一点
敏捷和 Scrum 是相关但不同的。敏捷描述了一组指导原则,用于通过迭代开发构建软件。敏捷原则在《敏捷宣言》中得到了最好的描述,通常被称为敏捷方法论。
Scrum 是一套具体的规则,专门用于项目管理,它恰好遵循《敏捷宣言》。
敏捷是一种方法论,Scrum 是一种流程。
我碰巧同意《敏捷方法论宣言》(http://www.agilemanifesto.org/),我甚至同意宣言背后的许多,但不是全部的 *原则* (另一个需要记住的区别)
另一方面,Scrum 虽然根植于敏捷方法论,但似乎更关注流程、任务、术语和团队成员角色,因此 - 在我看来 - 失去了合法性。
超越敏捷/Scrum,更重要的是,自敏捷方法论和 Scrum 诞生以来,软件开发的世界已经发生了多次变化,不仅技术本身比以往任何时候都更加多样化和互联互通,人们的工作方式也发生了演变,包括何时、何地和如何工作。
在 Scrum 时代,产品的定义意味着在单一环境中运行的单个工作软件,这种情况不再准确,也不再可以接受。
我们生活在一个产品需要跨越微服务、移动平台以及多屏和无屏设备的世界中。软件开发人员、产品设计师和架构师的技能和工具不再适合这个多维世界,因此团队变得更大、更多样化,并将责任分担到 Scrum 不足的地方。
我的信息很简单,让我们跳出框框,从开源世界吸取教训,开源世界在没有流程、规则和项目管理方法的约束下蓬勃发展,看看有什么可以应用到我们的日常流程(Scrum 或其他)中,并进行改进和调整,以便我们可以交付更好的产品。
我之所以声明“方法论”而不是规定的“流程”,是为了让社区能够讨论、批评和改进所提供的原则和宗旨,以便下一个逻辑步骤演变为讨论应用什么流程,或者如何改进/更改我们现有的流程并创建下一个版本。
Scrum 社区拒绝讨论 Scrum 2.0 似乎相当自相矛盾,毕竟《敏捷宣言》完全是关于持续交付、反馈和改进的。为什么不将相同的原则应用于 Scrum 本身呢?